I have OWL ontology, Protege 5. I want starting form a source class S, to retrieve all destination classes D where S is related to Ds by means of to-one cardinality through objectProperty i.e S ([0..*] - 1) D despite what is the connecting objectProperty.
In DL, it would be something similar to :
S ⊑ =1r:D;
where S is my source concept, D is a variable concept and r is a variable objectProperty.
First Point:
How to express this in Manchester Syntax to use it in Protege DL query?
Second Point:
For such query, what are the considered types of property restriction that the reasoner will consider when trying to answer the query? e.g cardinality restriction, functional properties, someValuesFrom, allValuesFrom?
Thanks.
You can't write the kind of query that you're asking about in the DL query syntax. The DL query syntax doesn't have any place for variables; all you can write are class expressions, after which you can ask for the individuals in that class, or subclasses or superclasses of the class. So the answer to the first question is that you can't express your query in the Manchester syntax.
For the second point, there may be reasoners that can help you draw a conclusion here. For instance, you might be able to use a reasoner that supports SPARQL queries and write the template of the class expression with variables. You'd end up with something like this (but this is untested):
prefix xsd: <http://www.w3.org/2001/XMLSchema#>
prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>
prefix owl: <http://www.w3.org/2002/07/owl#>
select ?s ?p ?d where {
?s rdfs:subClassOf [ a owl:Restriction ;
owl:qualifiedCardinality "1"^^xsd:nonNegativeInteger ;
owl:onProperty ?p ;
owl:onClass ?d ]
}
I don't know whether or not most OWL reasoners will be able to handle that though. As mentioned above, the typical task for an OWL reasoner is to look at class expression and determine its subclasses, and superclasses. This is getting more complicated.
Related
I have a set of information (not all shown, of course):
s:Marshmallow rdfs:subClassOf s:Android
s:galaxyEdge6 s:OS s:Marshmallow;
s:price 350.
...
I want to query phones that are both Android and have a price less than 400.
My query:
SELECT ?phone WHERE {
?phone s:OS ?system
?system rdfs:subClassOf s:Android
?phone s:price ?value
} FILTER (?value < 400)
Based on my query above, do I need to include ?system rdfs:subClassOf s:Android? Or can I remove that line and change the one above it to: ?phone s:OS s:Android?
s:Marshmallow rdfs:subClassOf s:Android
This entails that any individual that is a s:Marshmallow is also a s:Android. You don't use a (rdf:type) as a predicate, so there is nothing to infer.
To illustrate why it should even be dangerous to infer such a thing, consider foaf:membershipClass. This links an individual (foaf:Group) to a class of its members in such a way that both are equivalent (i.e. being a member of the group infers having a specific class, and vice-versa). Yet it would be dangerous to infer from foaf:membershipClass ex:MyClass something like foaf:membershipClass owl:Thing, when owl:Thing is obviously a superclass here.
You have two options of dealing with this. Without modifying the ontology, you can simply turn s:OS into a, then you can infer s:galaxyEdge6 a s:Android from s:galaxyEdge6 a s:Marshmallow. However, I don't like this approach, since it's too far from a real-world "is a" relationship, and it's harder to query the OS.
Personally I would choose SKOS for modelling the concept of an OS, i.e. having s:Android a skos:Concept and s:Marshmallow skos:broader s:Android. However, you will most likely also need OWL to specify that having s:OS <narrower> entails s:OS <broader> (which you would have to do without using SKOS anyway).
I'm trying to learn how to use Blazegraph.
I have created an ontology and added it to the database. No problems. Blazegraph seems easy to use.
Now to my question. I notice that if I query the database now, I get triples from the ontology as answers from sparql queries. So if I add data to the same database, the answers from sparql queries will be from the ontology mixed with the data itself.
Should I not keep the ontology in the same database, or how do I avoid mixing the ontology with the data?
To avoid mixing the ontology with the data, you can namespace the ontology. For example,
#prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
#prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
#prefix foaf: <http://xmlns.com/foaf/0.1/> .
<#JW>
a foaf:Person ;
foaf:name "James Wales" ;
foaf:mbox <mailto:jwales#bomis.com> ;
foaf:homepage <http://www.jameswales.com> ;
foaf:nick "Jimbo" ;
foaf:depiction <http://www.jameswales.com/aus_img_small.jpg> ;
foaf:interest <http://www.wikimedia.org> ;
foaf:knows [
a foaf:Person ;
foaf:name "Angela Beesley"
] .
<http://www.wikimedia.org>
rdfs:label "Wikimedia" .
rdf, rdfs, and foaf are all ontologies. Instead of bringing all of them into the document, they're declared in the namespace. You can point the namespace to your owl file (or whatever your ontology is in) and use it the same way. Blazegraph will still be able to reason over the graph as long as it can access the ontology definition.
I am trying to understand the semantics of rdfs domain and range. Because I am from an object oriented background, I am struggling to understand the semantics and how to validate data against the rdfs statements.
Here is a sample file in turtle format:
PREFIX owl: <http://www.w3.org/2002/07/owl#>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
prefix tmpl: <http://template.example.com/>
prefix data: <http://data.example.com/>
tmpl:Thing a owl:Class.
tmpl:Employment rdfs:subClassOf tmpl:TemporalThing.
tmpl:Party rdfs:subClassOf tmpl:Thing.
tmpl:Individual rdfs:subClassOf tmpl:Party.
tmpl:Organisation rdfs:subClassOf tmpl:Party.
tmpl:LimitedLiabilityCompany rdfs:subClassOf tmpl:Organisation.
tmpl:hasCurrentEmployer a owl:ObjectProperty;
rdfs:domain tmpl:Party;
rdfs:range tmpl:Party.
data:Simon a tmpl:Individual;
skos:prefLabel "Simon S".
data:PtyLtd a tmpl:LimitedLiabilityCompany.
data:Simon tmpl:hasCurrentEmployer data:PtyLtd.
tmpl:Animal a owl:Thing.
data:Beans a tmpl:Animal.
data:Simon tmpl:hasCurrentEmployer data:Beans.
I am using GRAPHDB as my test environment. I would expect the last statement to fail with some sort of message because 'Beans' is an 'Animal' which is not a 'Party'.
Yet, GRAPHDB just accepts the statement.
Any ideas?
EDIT
Based on Stanislav's comment below: While An inference engine might not have a problem with this, we can use the domain and range for error checking in an application.
As said in the comments, you misunderstood the semantics of domain and range.
P rdfs:domain D
P rdfs:range R
mean that if a statement s P o holds, then (with a reasoner running), it could be inferred that s rdf:type D and o rdf:type R.
Domain and range are never restrictions on the the property. That has to be clear.
To understand how things work, check for examplem OWL direct semantics for object properties here.
I have class called ResponseInformation that a has a datatype property called hasResponseType, which must have only the following string values: "Accept", "Decline" and "Provisional".
I understand that I can model this as a set of individuals of a class called ResponseType which are then called accept, decline, and provisional respectively, and an owl:oneOf axiom stating that the class ResponseType is equivalent to exactly "one of" this set of instances. However, I came to realise that OWL 2 supports lists of values as ranges for datatype properties. For example, I can specify the following as the range of my hasResponseType property in Protege: {"Accept" , "Decline" , "Provisional"}
This seems like the easier of the two options, as it does not involve creating extra classes, individuals etc. I was wondering about the potential tradeoffs if I take the second option, i.e. is there any other advantage, or disadvantage other than the convenience?
This second option is not particularly simpler or easier. In one case, you need an extra class and 3 individuals; in the other case, you need an extra datatype and 3 values. I don't see a significant difference in terms of effort of ontology development. In terms of reasoning, it depends on the implementation, but I'm not sure reasoners are usually better at handling enumerated datatypes rather than enumerated classes.
Besides, there is a conceptual problem in saying that a "response type" is a sequence of character. Especially, thinking of a "decline" response type, which would be "refuser" in French, I would find it hard to argue that "refuser" is a character string that starts with a capital "D"! With individuals, I can indicate different names for different languages and provide a description of them. Besides, why must response types be strictly limited to only these three types? I would rather model this as follows:
:ResponseType a owl:Class .
:accept a :ResponseType;
rdfs:label "Accept"#en, "Accepter"#fr;
rdfs:comment "This response type indicates that the request is accepted."#en,
"Ce type de réponse indique que la requête est acceptée."#fr .
:decline a :ResponseType .
rdfs:label "Decline"#en, "Refuser"#fr;
rdfs:comment "..."#en, "..."#fr .
:provisional a :ResponseType .
rdfs:label "Provisional"#en, "Provisoire"#fr;
rdfs:comment "..."#en, "..."#fr .
[] a owl:AllDifferent;
owl:members ( :accept :decline :provisional ) .
:hasResponseType a owl:ObjectProperty;
rdfs:range :ResponseType .
If you really want Accept, Deny and Provisional to be the only possible response types, you can add:
:ResponseType rdfs:subClassOf [
a owl:Class;
owl:oneOf ( :accept :decline :provisional )
] .
If you want to be more concise, you can also write:
:accept a owl:Thing .
:decline a owl:Thing .
:provisional a owl:Thing .
:hasResponseType a owl:ObjectProperty;
rdfs:range [
a owl:Class;
owl:oneOf ( :accept :decline :provisional )
] .
The alternative that you were looking for can be expressed like this:
:hasResponseType a owl:DatatypeProperty;
rdfs:range [
a rdfs:Datatype;
owl:oneOf ( "Accept" "Decline" "Provisional" )
] .
Yes, the Turtle serialisation has 3 less lines, but it does not mean that with an efficient user interface it would be much faster.
I think that Antoine Zimmermann's answer covers how you can do this fairly well. I do agree that effort required to implement the two approaches is similar. I expect, though I haven't tested this, that some types of reasoning will be more efficient on the datatype option, since I expect that typed literals can be compared for equality and inequality much faster than individuals can be.
However, I think that I'd still suggest taking the enumerated individuals (so that hasResponseType is an object property) approach for at least two reasons:
As Atoine's answer points out, it is somewhat dubious that the response type is actually a character string. Instead, it seems like the response type would have a label (or multiple labels, e.g., in different languages) that's a character string.
(This is my primary point.) If you want to say anything about response types, they need to be individuals. For instance, when response types are individuals, you can give them additional types, e.g.,
Accept a GuaranteedResponse
Decline a not GuaranteedResponse
Provisional a not GuaranteedResponse
and then you could ask, for instance, how many not GuaranteedRepsonses a given poller collected. You could also associate a code with each response type, e.g.,
Accept hasCode "x789"
Decline hasCode "x234"
Provisional hasCode "x900"
and then pass this on to the responses:
hasResponseCode subPropertyOf hasResponseType o hasCode
You won't be able to do this if your ResponseTypes are literals, because literals can't be the subject of statements.
What is the difference between EquivalentClass and SubClass of? While reading through OWL primer, i find the tutorial uses SubClassOf a lot to declare a new class, as follows
SubClassOf(
:Teenager
DataSomeValuesFrom( :hasAge
DatatypeRestriction( xsd:integer
xsd:minExclusive "12"^^xsd:integer
xsd:maxInclusive "19"^^xsd:integer
)
)
)
Can I write
EquivalentClass(
:Teenager
DataSomeValuesFrom( :hasAge
DatatypeRestriction( xsd:integer
xsd:minExclusive "12"^^xsd:integer
xsd:maxInclusive "19"^^xsd:integer
)
)
)
instead?
When stating that A is a subclass of B, this restricts A to necessarily inherit all characteristics of B, but not the other way around. In your example, A = Teenager, and B = hasAge [12:19] (my own notation, but you get the idea).
This means that any instance of Teenager in the OWL ontology must necessarily also have the property hasAge with a value in the range [12:19], but not the other way around. Specifically, this does not mean that any instance of something with the property hasAge with a value in the range [12:19] is also an instance of Teenager. To make this clear, consider an instance (called c) of class Car. We might also say that:
c . hasAge 13
This says that instance c of Car is 13 years old. However, with the subclass axiom defining Teenager above, a reasoner would not infer that c is also an instance of Teenager (perhaps as we'd want, if teenagers are people, not cars).
The difference when using equivalence is that the subclass relationship is implied to go in both directions. So, if we were to instead include the second axiom that defined Teenager to be equivalent to anything with the property hasAge with a value in the range [12:19], then a reasoner would infer that the car c is also an instance of Teenager.
Equivalent classes might have the same members, e.g.,
:USPresident owl:equivalentClass :USCommanderInChief
will both have the same individuals (all or some of the US presidents). So if we assert that John Adams was a USCommanderInChief it can be inferred that John Adams was also a US President.
With subclass, we're indicating a hierarchy. e.g., GrannySmithApple is a type of Apple.
:USPresident owl:equivalentClass :USCommanderInChief .
is the same as
:USPresident rdfs:subClassOf :USCommanderInChief ;
:USCommanderInChief rdfs:subClassOf :USPresident .