I am using SPARQL plugin in protege to query my ontology, and I found out that it only works for asserted statements and not inferred ones. How can I change this?
SPARQL is defined by several standards. SPARQL 1.1 Query, the main standard, only shallowly relies on RDF semantics. A typical SPARQL query engine is not inferring anything from the RDF/RDFS terms like rdfs:subClassOf, rdfs:range, etc. However, the SPARQL standards also define SPARQL 1.1 Entailment Regimes, which defines how SPARQL engines should answer queries when they do implement inference, which is optional. In order to know whether a SPARQL query engine implements an entailment regime (such as RDFS or OWL DL), you may have to look at the documentation of the engine, or there may be a SPARQL service description available in RDF. SPARQL 1.1 Service Description is yet another SPARQL standard that provides an RDF vocabulary, and a standard way to interpret it, for knowing what features a SPARQL engine is implementing.
Related
So, I need to run SPARQL query over a semantic database but some of the triples are not going to be in the database but are going to be provided by webservices (and not as a SPARQL endpoint). I would want to be able to run a SELECT query that take into consideration those additional triples but without having to insert them in the database, is there a way to do that ?
This is not part of the SPARQL spec, so "no" is the general answer.
That said, Virtuoso (possibly among others) lets you include an external RDF source (a/k/a webservice) as part of the FROM (among other methods), to be dereferenced during SPARQL query processing.
Such webservice need not be a SPARQL endpoint, but best performance will result if it provides RDF (though serialization may vary).
The Virtuoso Sponger can also be invoked on the fly to derive RDF from many document formats (with an obvious performance hit). To pursue, please raise this to the OpenLink Community Forum.
Is it possible to infer new knowledge about an ontology only from a query in SPARQL?
I have a question about the use of the SPARQL language about ontologies. So far I have thought that SPARQL is the equivalent to the SQL language in the relational databases, that is to say, that with SPARQL it is only possible to consult the data that are explicitly in the ontology, without having access to the data that can be inferred , leaving the responsibility of the inference to the reasoners.
However, I have read documents from which I infer that SPARQL does have the capacity to infer implicit and non-explicit knowledge in the ontology. Is my inference true? That is, is it possible to infer knowledge through a SPARQL query without the need for a reasoner? If the answer is true, then what advantages does the use of a reasoner have over the use of SPARQL?
Greetings, Manuel Puebla.
Yes, on-the-fly inference may be a feature of the SPARQL processor, so you can get the benefits of inference/reasoning directly from a SPARQL query. (See Virtuoso SPARQL endpoints inference rules for some discussion of how this is done in Virtuoso, for example.)
I have a pizza ontology that defines different types of pizzas, ingredients and relations among them.
I just want to understand several basic things:
Is it correct that I should apply SPARQL if I want to obtain information without
reasoning? E.g. which pizzas contain onion?
What is the difference between SPARQL and reasoning algorithms
like Pellet? Which queries cannot be answered by SPARQL, while can
be answered by Pellet? Some examples of queries (question-like) for the pizza ontology would be helpful.
As far as I understand to use SPARQL from Java with Jena, I
should save my ontology in RDF/XML format. However, to use Pellet
with Jena, which format do I need to select? Pellet uses OWL2...
SPARQL is a query language, that is, a language for formulating questions in. Reasoning, on the other hand, is the process of deriving new information from existing data. These are two different, complementary processes.
To retrieve information from your ontology you use SPARQL, yes. You can do this without reasoning, or in combination with a reasoner, too. If you have a reasoner active it means your queries can be simpler, and in some cases reasoners can derive information that is not really retrievable at all with just a query.
Reasoners like Pellet don't really answer queries, they just reason: they figure out what implicit information can be derived from the raw facts, and can do things like verifying that things are consistent (i.e. that there are no logical contradictions in your data). Pellet can figure out that that if you own a Toyota, which is of type Car, you own a Vehicle (because a Car is a type of Vehicle). Or it can figure out that if you define a pizza to have the ingredient "Parmesan", you have a pizza of type "Cheesy" (because it knows Parmesan is a type of Cheese). So you use a reasoner like Pellet to derive this kind of implicit information, and then you use a query language like SPARQL to actually ask: "Ok, give me an overview of all Cheesy pizzas that also have anchovies".
APIs like Jena are toolkits that treat RDF as an abstract model. Which syntax format you save your file in is immaterial, it can read almost any RDF syntax. As soon as you have it read in a Jena model you can execute the Pellet reasoner on it - it doesn't matter which syntax your original file was in. Details on how to do this can be found in the Jena documentation.
When querying some linked data SPARQL endpoints via SPARQL queries, what is the type of reasoning provided (if any)?
For example, DBpedia SNORQL endpoint doesn't even provide the basic subclass inference (if A subClassOf B and B subClassOf C, then A subClassOf C). While FactForge SPARQL endpoint provides some inference (though it is not clear what kind of inference it is), and provides the possibility to switch that inference on and off.
My question:
How is it possible to identify the kind of inference applied? and if the inference support is limited, could it be extended using the endpoint only?
Inference controls will vary with the engine as well as the endpoint.
The public DBpedia SPARQL endpoint (powered by Virtuoso, from my employer, OpenLink Software) does provide various inference rules (accessible through the "Inference rules" link at the top right corner of the SPARQL endpoint query form page) which are controlled by pragmas in your SPARQL (not SNORQL, to which form you linked), such as --
DEFINE input:inference 'urn:rules.skos'
You can see the content of any predefined ruleset via SPARQL -- for the above
SELECT *
FROM <urn:rules.skos>
WHERE { ?s ?p ?o }
You can see the live query and results.
See this tutorial containing many examples.
While inference is not universally supported across SPARQL endpoints, most of the inferences supported by RDFS, RSFS+ and OWL 2 RL profiles are supported by SPARQL itself. For example, querying for instances of :A using your subClassOf entailment can be supported with SPARQL property paths:
SELECT ?inst
WHERE {
?cls rdfs:subClassOf* :A .
?inst a ?cls .
}
The first triple pattern gets all subclasses of :A, including :A (use + instead of * if you just want subclasses of :A), and the second triple finds all instances of all those classes.
To see how most of OWL 2 can be implemented with SPARQL, see Reasoning in OWL 2 RL and RDF Graphs using Rules. With a couple of exceptions, all of these can be implemented in SPARQL (and in fact you probably won't need some of them, such as eq-ref, (which is good for a computational lol that logicians may scoff at)).
There are few uses cases, beyond heavy-lifting classification problems, that can't be solved with a subset of the OWL 2 RL rules.
So, in the end, a recommendation is to understand what entailments you need. Chances are that OWL has totally overthought the issue and you can live with a few SPARQL patterns. And then you can hit the SPARQL endpoints without having to worry about whether specific inference profiles are supported.
currently, I found out that I can query using model (Model) syntax in Jena in a rdf after loading the model from a file, it gives me same output if I apply a sparql query. So, I want to know that , is it a good way to that without sparql? Though I have tested it with a small rdf file. I also want to know if I use Virtuoso can i manipulate using model syntax without sparql?
Thanks in Advance.
I'm not quite sure if I understand your question. If I can paraphrase, I think you're asking:
Is it OK to query and manipulate RDF data using the Jena Model API instead of using
SPARQL? Does it make a difference if the back-end store is Virtuoso?
Assuming that's the right re-phrasing of the question, then the first part is definitively yes: you can manipulate RDF data through the Model and OntModel APIs. In fact, I would say that's what the majority of Jena users do, particularly for small queries or updates. I find personally that going direct to the API is more succinct up to a certain point of complexity; after that, my code is clearer and more concise if I express the query in SPARQL. Obviously circumstances will have an effect: if you're working with a mixture of local stores and remote SPARQL endpoints (for which sending a query string is your only option) then you may find the consistency of always using SPARQL makes your code clearer.
Regarding Virtuoso, I don't have any direct experience to offer. As far as I know, the Virtuoso Jena Provider fully implements the features of the Model API using a Virtuoso store as the storage layer. Whether the direct API or using SPARQL queries gives you a performance advantage is something you should measure by benchmark with your data and your typical query patterns.