I knew this might be a stupid question but I don't know the answer :)
I am using protege4 I built my ontology and when I tried to use DL Query from the DL query tap in protege4 it executes fine and I get results.
However, when I click "Add to ontology" to add my query to the ontology it adds it but without any query results!!! Why are there no query results? and how to see it?
Thanks
First some terminology:
Every OWL ontology is a set of OWL axioms.
Every DL-Query is an OWL class expression.
Every DL-Query result is a set of OWL entities.
You can only add axioms to an ontology. You cannot add class expressions nor sets of entities to an OWL ontology.
The "Add to ontology" button seems to create a new EquivalentClasses-axiom on the basis of the query (i.e. class expression), and a named class (given by the user), and then asserts this axiom into the active ontology, i.e.
EquivalentClasses(new_name query)
(I didn't quite get it working like this in my version of Protege 4, but such a functionality would make sense.)
The current OWL2 specification does not say anything about how to store class expressions and query results in the ontology. These have to be specified and calculated every time from scratch after you load the ontology from the file.
Related
Sparql has a notion of a "default graph" that is queried when no graph context is specified, and which (depending on the triple store) may be the union of proper graphs available in a repository, or it may be a separate, "null graph"; so far so good.
But sparql also has a keyword DEFAULT that can be specified instead of a graph name, as in
SELECT *
FROM DEFAULT
WHERE { ... }
What does this command do? I can only interpret it as an explicit way to request the same thing that would happen when there's no FROM clause at all. But is this correct? I could find no documentation about it. And what about using it in update queries, or with CLEAR, COPY, etc.? Can anyone point to documentation of the meaning and intended use of this keyword, or at least shed some light on why it exists?
When you have one or more FROM or FROM NAMED statements in a query then the dataset for the query is composed of only those graphs. Per SPARQL 1.1 Query Specification Section 13.2:
The FROM and FROM NAMED keywords allow a query to specify an RDF dataset by reference; they indicate that the dataset should include graphs that are obtained from representations of the resources identified by the given IRIs (i.e. the absolute form of the given IRI references). The dataset resulting from a number of FROM and FROM NAMED clauses is:
a default graph consisting of the RDF merge of the graphs referred to in the FROM clauses, and
a set of (IRI, graph) pairs, one from each FROM NAMED clause.
If there is no FROM clause, but there is one or more FROM NAMED clauses, then the dataset includes an empty graph for the default graph.
So basically the presence of those clauses creates a query dataset that potentially hides some/all graphs in the underlying dataset. Your query operates over this query dataset.
As noted in Andy's answer FROM DEFAULT is a proposed future extension to the SPARQL language that would allow explicitly referring to the datasets default graph (whatever that may be). Currently there's no standardised way to do this, so only queries that omit any FROM clauses can access the default graph unless your service provides some non-standard way to refer to it e.g. a custom URI for referencing the default graph.
For your specific example query:
SELECT *
FROM DEFAULT
WHERE { ... }
This would have the effect of forming a query dataset with a default graph using the services default and no named graphs visible i.e. any GRAPH ?g { } clauses would not match in this query
FROM DEFAULT is a feature that has been proposed for future work sparql-1.2/issues/43.
The grammar covers both SPARQL Query and SPARQL Update because they share a considerable about of the grammar. They have different entry points (QueryUnit and UpdateUnit).
The DEFAULT keyword appears in GraphOrDefault and GraphRefAll. Both of which are only used in SPARQL Update.
ADD, MOVE, CODE use GraphOrDefault; CLEAR and DROP use GraphRefAll.
FROM is followed by either an iri, or NAMED iri.
Omitting FROM means the implicit default graph.
I have an ontology in Protege and want to write some SPARQL queries.
The ontology is set up like this:
Thing > Beverages > Wine > Red_wine
Then I have added different red wines as instances. They also have some object properties like fromCountry, goesWellWith and priceRange
How do I create a SPARQL query for returning for example a red wine from France, that goes well with pork, and priceRange 100-199?
If you want to return certain resources in your knowledge base you need a SELECT query.
As the commenters have stated, it is not possible to answer your question exactly as you didn't provide enough information on how your data is modelled and you are expected to show your own efforts and where they failed.
You can find an detailed overview of SPARQL 1.1 at https://www.w3.org/TR/2013/REC-sparql11-overview-20130321/ or a more approachable tutorial at https://www.w3.org/2009/Talks/0615-qbe/.
As far as I can guess from your question, your query should look similar to this:
SELECT ?wine WHERE
{
?wine a :RedWine;
:goesWellWith :Pork;
:priceRange :PriceRange100To199.
}
Please adapt this query to your exact model and show us your results.
If you mean "just one result" with "a red wine", you can add "LIMIT 1".
You could also model the price range differently, for example by having a minPrice and maxPrice, as this would enable more precise queries using filters.
P.S.: I changed your :Red_wine to :RedWine as camel case is usually used for class URIs.
I am using this client
http://yasgui.laurensrietveld.nl
and I hope to query bioportal http://bioportal.bioontology.org
Most of my prior queries had a PREFIX and no FROM part. Can I move any FROM URL into PREFIX?
Using YASGUI client, what is the difference between FROM and the Endpoint field?
Can I rewrite any query with a from statement into a query that does not have it?
I am not able to list for example details of Human Phenotype Ontology concept id: HP:0000023 because I am not sure what to put into FROM or if to use it at all.
There are a number of terms and mechanisms here. Let's go over them one by one.
First of all, a PREFIX clause is simply a declaration of a syntax shortcut, for use within your query. So this line:
PREFIX ex: <http://example.org/>
says that the string ex: is a shortcut for the string http://example.org/. If you have this prefix declared at the start of your query, you can use ex:someUrl (instead of <http://example.org/someUrl>) in other places in your query. It's simply there to make queries easier to read and write, but apart from that it has no influence on the meaning of your query.
A SPARQL endpoint is another term for a web service that can answer SPARQL queries.
The FROM clause of a SPARQL query determines the dataset (or more precisely, the default graph, which is part of the dataset) over which the query is executed. Any SPARQL endpoint may contain several graphs, each identified by a URI (so-called named graphs). A collection of such graph together is a dataset. If you don't specify a FROM clause (and perhaps also one or more FROM NAMED clauses), the dataset queried is simply whatever default dataset the endpoint chooses.
So, what this mean for your specific questions?
Most of my prior queries had a PREFIX and no FROM part. Can I move any FROM URL into PREFIX?
As you can see from the above explanation, that would make no sense. They are different mechanisms, for different purposes, that just both happen to use URIs.
Using YASGUI client, what is the difference between FROM and the Endpoint field?
The endpoint field defines which service YASGUI needs to send the query to. The FROM clause tells the endpoint what dataset you want to query.
Can I rewrite any query with a from statement into a query that does not have it?
Not generally, no. The absence of a FROM clause means that the endpoint executes the query over its default dataset. Depending on how that endpoint is configured, this may mean that you either get a lot more results (namely not just from the one dataset you want, but from a lot of others) or none at all (in case the dataset you wanted to query is not part of the endpoint's default dataset).
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 a simple question which I suspect has no simple answer. Essentially, I want to check whether it is true that one OWL expression (#B) follows on logically from another (#A) - in other words I want to ask: is it true that #A -> #B?
The reason for this is that I'm writing a matching algorithm for an application which matches structures in a knowledge based (represented by the #KnowledgeStructure class) to a structure which describes the needs of the current application state (#StateRequirement). Both structures have properties which have string values representing OWL expressions over the state of a third kind of structure (#Model). These are: #KnowledgeStructure.PostCondition which expresses how the knowledge structure being applied to #Model will transform #Model; and #StateRequirement.GoalCondition, which expresses the #Model state that the application aims to achieve. I want to see, therefore, if the #KnowledgeStructure will satisfy the #StateRequirement by checking that the #KnowledgeStructure.PostCondition produces the desired #StateRequiremment.GoalCondition. I could express this abstractly as: (#KnowledgeStructure.Postcondition => #StateRequirement.GoalCondition) => Match(#KnowledgeStructure, #StateRequirement). Less confusingly I could express this as: ((#A -> #B) -> Match(#A, #B)) where both #A and #B are valid OWL expressions.
In the general case I would like to be able to express the following rule: "If it is true that the expression #B follows from #A, then the expression Match(#A, #B) is also true".
Essentially, my question is this: how do I pose or realise such a rule in OWL? How do I test whether one expression follows from another expression? Also, are existing reasoners sufficiently powerful to determine the relation #A -> #B between two expressions if this relation is not explicitly stated?
I'm not 100% sure that I fully understood the question, but from what I grasped I would face the situation in this way.
First of all I refer to Java because all the libraries I know are meant for this language. Secondly, I don't think that OWL on its own is able to satisfy your goal, given that it can represent rules and axioms, but it does not provide reasoning, that is, you need a reasoner, so you need to build a program that uses it, plus doing additional processing that I will sketch below:
1) You didn't mention it, but I guess you have an underlying ontology w.r.t. you need to prove your consequence relation (what you denote with symbol "->"). If the ontology is not explicit, maybe it can be extracted/composed from the textual expressions you mentioned in the question.
2) you need to use a library for ontology manipulation, I suggest OWL API from Manchester University, it is very powerful and simple, in the tutorial under section "documentation" you have an overview of the main functionalities, including the use of reasoners (the example shows Hermit, but the principle holds for any other reasoner).
3) At this point you need to check if the ontology is consistent (otherwise anything can be derived, as it often happens with false premises)
4) You add the following axiom to the ontology (you build it directly in Java, no need to serialize back, you can let the reasoner work on the in-memory representation) and check for consistency: A \sqsubseteq B, that is, using the associated interpretation: A^I \subseteq B^I, so it is equivalent to A => B (they have the same truth table).
5) At this point you can add the axiom Match(A,B), where A and B are your class expressions and Match is a Role/Relation that relates all the class expressions for which the second is a consequence of the first.
6) After a number of repetitions of these steps you may want to serialize the result and store it, and this again can be achieved quite simply using OWL API from the in-memory representation.
For some basics about Description Logics (the logic underpinning OWL ontologies) you can refer to A description logic Primer (2012), Horrocks et al. and to Foundations of Description Logics (2011), Rudolph.
I'm not a logician or a DL expert, so please verify all the information I provided and feel free to correct me :)