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).
Related
In protege a reflexive property is assigned to all individuals relgardless of domain and range and the class to which individuals belongs.
so what is the use of this restriction?
P.S: lets say there is three individuals:
NamedIndividual( :John )
NamedIndividual( :alex )
NamedIndividual( :BMW )
and an object proeprty:
ObjectProperty( :hasFriend )
ReflexiveObjectProperty(:hasFriend)
running pellet deduce that :
BMW hasFriend BMW
This inference is conceptually meaningless
Papers like The even more irresistible SROIQ and Foundations of Description Logics point out that reflexive and irreflexive properties are closely related to the exists r.Self concept. I.e. Narcissist can be defined as Narcissist \sqsubseteq loves.Self.
The SROIQ paper actually mentions that the main use cases for reflexive and irreflexive properties are limited and only make sense when used along with cardinality restrictions. I.e. if you define PopularPerson as someone with at least 2 friends, and hasFriend is reflexive, then by asserting an individual has 1 known friend will result in that individual being classified as a PopularPerson because the individual is already assumed to be its own friend.
Interestingly, the paper also mentions that reflexive(r) is equivalent to adding the GCI top \sqsubseteq exists r.Self to the TBox. Personally for me this is more intuitive and provides the control I think you seem to want to achieve. In particular this allows you to replace \top with whatever class of your choice. A similar equivalent exists for irreflexive properties.
I have the following information:
s:Marshmallow rdfs:subClassOf s:Android
s:galaxyEdge6 s:OS s:Marshmallow;
s:price 350.
...
I need to be search for phones that are both Android and have a price > 400.
I have written:
CONSTRUCT {?phone rdf:type s:Android}
WHERE {?phone s:OS ?opSystem.
?opSystem rdfs:subClassOf s:Android.}
SELECT ?phone WHERE {
?phone rdf:type s:Android.
?phone s:price ?value.
FILTER(?value < 400) }
I am not fully sure what the purpose of a construct is. I mean, is it a more complex form of querying; or is it something that helps define information for later querying (like what I have done above)?
I also do not know if what I have written is correct.
edit: left out FILTER
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.
In OWL, is it possible to query a class that does not have a property?
Suppose I have an object property R and I want to retrieve all classes that do not have the property R. Also, suppose that I have already closed all classes with closures.
I was trying this:
suppose the propety in question is hasProperty, my query was this
hasProperty only Nothing
But it doesn't work
What do you mean by "class that does not have a property"?
Semantically, a class is a set of individuals and a property is a set of pairs of individuals. Given these two sets, what do you mean by "class has / has not a property"?
Regarding your example query
hasProperty only Nothing
lets rewrite it a bit so that we can think about it in natural language. This gives better intuition about the meaning of this query.
First lets rename hasProperty to follows (or whatever English verb), then we have:
follows only Nothing
This is semantically equivalent to
follows only (not Thing)
which is semantically equivalent to
not (follows some Thing)
Now we have gotten rid of the only which is a confusing part of OWL and is better avoided. So now we can verbalize the query in English as:
those who do not follow anything
or
who does not follow anything?
or more formally
which individuals of the ontology are known
not to have a follow relationship to any other individual
E.g. if your ontology states that
John does not follow Mary.
John does not follow himself.
Every individual in the ontology is either John or is Mary.
then John will be the answer to the above query.
You can also get a named class as the query answer if the asked restriction holds for a (named) group of individuals. In any case, the following must hold: if you asserted that the answer (or a member of it) does have a follow-relation to some individual then it would render the ontology inconsistent.
OWL does not have any means for querying the data. SPARQL is used for that. So the SPARQL query to find all class definitions that do not have the property :R would be:
SELECT ?cls
WHERE {
?cls a owl:Class .
FILTER NOT EXISTS {?cls :R ?o}
}
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 .