Hi all
how to traverse resultset returned by a query in jena .. I want to traverse each row returned
There are quite detailed recipes for this in the Jena ARQ documentation: jena.sourceforge.net/ARQ/app_api.html
Related
We would like to use SPARQL in the following scenario:
Execute SPARQL query, e.g.
PREFIX brick: https://brickschema.org/schema/1.1/Brick#
SELECT ?ahu WHERE { ?ahu rdf:type brick:AHU }
Iterate over SPARQL query results and filter the results based on data from another source than RDF database, e.g. "filter out any ahu that do not have valid metadata a SQL database"
Execute another SPARQL query for each filtered result in the previous step, e.g.
PREFIX brick: https://brickschema.org/schema/1.1/Brick#
SELECT ?myZone WHERE {
?myZone rdf:type brick:HVAC_Zone .
"a particular ahu from previous steps" brick:feeds ?myZone}
Both SPARQL queries cannot be expressed as one SPARQL query since interaction with another data source is needed. How shall we design query in step 3 such that it "points" to the particular triplet (or SPARQL query result)?
Can SPARQL be used to query an empty ontology (with no individuals), to retrieve information about the restrictions (axioms or object properties) put on a class?
Here's a snippet of my ontology in turtle syntax:
How can a SPAQRL query, if possible, be formulated to retrieve the following triples from the ontology:
And if not possible to do this directly with SPARQL, is there a workaround for it using dotNetRDF OntologyAPI?
Thanks in advance!
We're running SPARQL queries on some clinical ontology data in our MarkLogic server. Our queries look like the following:
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
PREFIX cts: <http://marklogic.com/cts#>
SELECT *
FROM <http://example/ontologies/snomedct>
WHERE {
?s rdfs:label ?o .
FILTER cts:contains(?o, cts:word-query("Smoke*", "wildcarded"))
}
LIMIT 10
We expected to get sorted results based off of relevance score, but instead they seemed to be in some random order. Tried many ways with the query but nothing worked. After some research we found this statement in the MarkLogic docs:
When understanding the order an expression returns in, there are two
main rules to consider:
cts:search expressions always return in relevance order (the most relevant to the least relevant).
XPath expressions always return in document order.
Does this mean that cts:contains is a XPath expression that always return in document order? If that's the case, how can we construct a SPARQL query that returns in relevance order?
Thanks,
Kevin
In the example you have, the language you are using is SPARQL - with a fragment filter of the cts:contains.
IN this case, the cts:contains is only useful in isolating fragment IDs that match - thus filtering the candidate documents used in the SPARQL query. Therefore, I do not believe that the the cts relevance is taken into account.
However, you could possibly get results you are looking for in a different way: Do an actual cts:search on the documents in question - then filter them using a cts:triple-range-query.
https://docs.marklogic.com/cts:triple-range-query
I tried one SPARQL query in two different engines:
Protege 4.3 - SPARQL query tab
Jena 2.11.0
While the query is the same the results returned by these two tools are different.
I tried a DESCRIBE query like the following:
DESCRIBE ?x
WHERE { ?x :someproperty "somevalue"}
Results from protege give me tuples that take ?x as subject/object; while the ones from jena are that take ?x as subject only.
My questions are:
Is the syntax of SPARQL uniform?
If I want DESCRIBE to work as in protege, what should I do in Jena?
To answer your first question yes the SPARQL syntax is uniform since you've used the same query in both tools. However what I think you are actually asking is should the results for the two tools be different or not? i.e. are the semantics of SPARQL uniform
In the case of DESCRIBE then yes the results are explicitly allowed to be different by the SPARQL specification i.e. no the semantics of SPARQL are not uniform but this is only in the case of DESCRIBE.
See Section 16.4 DESCRIBE (Informative) of the SPARQL Specification which states the following:
The query pattern is used to create a result set. The DESCRIBE form
takes each of the resources identified in a solution, together with
any resources directly named by IRI, and assembles a single RDF graph
by taking a "description" which can come from any information
available including the target RDF Dataset. The description is
determined by the query service
The important part of this is the last couple of sentences that say the description is determined by the query service. This means that both Protege's and Jena's answers are correct since they are allowed to choose how they form the description.
Changing Jena DESCRIBE handling
To answer the second part of your question you can change how Jena processes DESCRIBE queries by implementing a custom DescribeHandler and an associated DescribeHandlerFactory. You then need to register your factory like so:
DescribeHandlerRegistry.get().set(new YourDescribeHandlerFactory());
I have built a simple webpage as the frontend user interface for users to enter the sparql query. I am using Jena ARQ as the backend (I am using Grails) sparql query engine. Currently, users can only enter a "Select" query and I use:
ResultSet results = qexec.execSelect();
to execute the query and return the result. But now, I also want users to send Describe and Construct query from the same page to the backend. As has been discussed in this thread: Jena Sparql and construct, we need to use
Model results = qexec.execConstruct()
at the backend. So my question is, at the backend, how can I know if the query string is a Select query, a Describe Query or a Construct query, so that I can select from execSelect(), execDescribe() or execConstruct()? Is there anything I need to change for the frontend?
The Query class has methods for finding out the type of the query:
if (qexec.getQuery().isSelectType()) {
ResultSet results = qexec.execSelect();
// ...
} else {
Model results = qexec.execConstruct();
// ...
}
To be complete, you should probably handle DESCRIBE and ASK as well.