For example, I have three classes: Flock, Bird, Velocity. I also have two properties: hasMember (the domain is Flock, range is Bird), and hasAttribute (the domain is Bird, and the range is Velocity). Now I want to add a EquivalentClass restriction to Flock class as the definition. Let consider a very simple definition: in a flock, all birds have the same velocity. How to express this in OWL?
Warning: this answer is in fact incorrect, please look at the comments to see why.
To the question "Could we use owl:sameAs in an OWL restriction?" the answer is no, not in an OWL (2) ontology. However, you can do whatever you like in an OWL Full ontology (i.e., an RDF graph interpreted according to the OWL RDF-based semantics). Yet, this is irrelevant to the details of your question where you want to say something about the velocity of the birds in a flock.
There is a solution to your problem within the limits of OWL 2 DL. Introduce a property flockVelocity and make the property chain hasMember o hasAttribute a subproperty of flockVelocity. Make flockVelocity a functional property and you're done. Alternatively, you could define a cardinality restriction on flockVelocity. In Turtle:
:hasMember a owl:ObjectProperty;
rdfs:domain :Flock;
rdfs:range :Bird .
:hasAttribute a owl:ObjectProperty; # why not :hasVelocity?
rdfs:domain :Bird;
rdfs:range :Velocity .
:flockVelocity a owl:ObjectProperty, owl:FunctionalProperty;
owl:propertyChainAxiom (:hasMember :hasAttribute) .
Done. If you don't care about being in OWL DL and allow yourself total OWL Full freedom, you could use a blank node instead of :flockVelocity such that you don't have to introduce an artificial property name.
Related
I tried to use the same object property between multiple classes, but I got a warning that the same object property has been set multiple times as follows, can you please let me know what is wrong with that and how to solve it? Does this restrict reasoning later on (i.e. confuse the reasoner since the same object property is set multiple times)?
Thanks
Contrary to the comments it actually is very problematic to use the same object property between multiple classes.
What you don't see in your visualization is that in RDF/OWL, the starting point of your relation arrows is modelled as rdfs:domain and the target point of the arrows is modelled as rdfs:range.
The semantic of an OWL class is that it is a set of individuals and rdfs:domain and rdfs:range specify the domain, respectively range of a relation. That is, they specify the sets of allowed values in subject, respectively object position of a triple with that relation in the predicate position.
If you express your example in RDF Turtle it would look like this:
:hasPart rdfs:domain :ClassA, :ClassB;
rdfs:range :ClassB, :ClassC, :ClassD.
This causes multiple problems:
Intersection
The semantic of multiple domains, respectively ranges, is the intersection of those classes, not the union!
Even if we disregard the relation between :ClassB and :ClassD, this means :hasPart is only allowed by individuals that are instances of class C and class D at the same time!
For example, lets say class A is "car", class B is "tire" and class C is "motor". Now you want to say that a car can have tires and motors but what you actually specify is that a car can only have things that are a motor and a tire at the same time!
Unwanted but allowed usage
If you fix the first problem but specifying the union instead of the intersection, it will be very messy in serialized RDF because you need a large amount of triples to represent OWL restrictions such as unions. But even if you do that, you could now connect an instance of class A with an instance of class D, which is not allowed in the image.
Solution
The solution is simple, just separate those relations, for example into :hasB, :hasC and :hasD, although in a real scenario you can probably find a more suitable naming scheme, where the "has" prefix is often not used. For example, in DBpedia, the property for the country of a city is expressed using dbo:country, not dbo:hasCountry.
When creating an OWL ontology, what are the consequences of declaring :
ex:myHasPart a owl:ObjectProperty .
ex:myHasPart owl:subPropertyOf <http://purl.org/dc/terms/hasPart> .
In OWL 1 : I read from http://bloody-byte.net/rdf/dc_owl2dl/ that it implies that ex:myHasPart will be an AnnotationProperty. Can it be both an ObjectProperty and an AnnotationProperty ?
In OWL 2 : What would be the consequences/entailments ?
How can I choose in Protégé to work in OWL1 or OWL2 ?
Additionnally, what are the consequences in terms of OWL-DL vs. OWL-Full ? would my ontology still be at the OWL-DL level ?
Is it a good practice to declare subProperties of dcterms like this ? I think I need a general explanation on this.
What could be the alternative to link ex:myHasPart with dcterms:hasPart ? rdfs:seeAlso ? skos:broadMatch ?
From the two triples you write, we can just say that if you have a triple <x> ex:myHasPart <y>, then we can infer <x> dc:hasPart <y> (in both OWL 1 and OWL 2, using either direct semantics or RDF-based semantics).
But the complete consequences of the axioms can only be fully estimated by knowing what else is in your ontology. If you only have those two triples, your ontology is not in OWL (1/2) DL. But reasoners won't care, they'll usually assume that dc:hasPart is an object property too, and things will be just fine. Also, if you have an additional statement saying:
dc:hasPart a owl:AnnotationProperty .
then the ontology is not valid OWL DL, nor OWL 2 DL, no matter what else you have in it (an IRI can only be denoting at most one type of property, annotation, datatype, or object). It is still usable in many OWL tools that will not care (like Protégé, for instance). Reasoners probably don't care either, as long as you don't use the properties in bizarre ways, e.g., with both literals and non literals.
To answer specifically to your questions:
In OWL 1 : I read from http://bloody-byte.net/rdf/dc_owl2dl/ that it implies that ex:myHasPart will be an AnnotationProperty. Can it be both an ObjectProperty and an AnnotationProperty ?
No, the two triples imply that ex:myHasPart is an owl:ObjectProperty. In an OWL 2 ontology, a property cannot be object and annotation at the same time. In an OWL 2 Full ontology, they can (an OWL 2 Full ontology is just an RDF graph). In OWL 1, an OWL DL ontology cannot have an object property that is an annotation property at the same time, while an OWL Full ontology can.
In OWL 2 : What would be the consequences/entailments ?
Pretty much the same thing as in OWL 1, but it depends what semantics you are using: Direct Semantics or RDF-based semantics? The direct semantics only applies to OWL 2 ontologies, not to OWL 2 Full ontologies, so you would have to, at least, declare your ontology <yourOnto> a owl:Ontology and declare the term dc:hasPart as an owl:objectProperty. Reasoners can be more tolerant. In any case, there is not going to be anything bad happening, unless you are messing up with the rest of the ontology.
How can I choose in Protégé to work in OWL1 or OWL2 ?
You can choose a version of Protégé that does not support OWL 2 (if you can still manage to find one). Otherwise, any version after 4.0 uses OWL 2. But from a syntactic point of view, there is no reason to restrict to OWL 1. The reasoning is done independently from the editor in Protégé, so whether you have OWL 1 or OWL 2 reasoning depends on which plugin you have. However, OWL reasoners that do not support OWL 2 are simply obsolete, there is not much sensible reasons to still use them.
Additionnally, what are the consequences in terms of OWL-DL vs. OWL-Full ? would my ontology still be at the OWL-DL level ?
I think I already explained this.
Is it a good practice to declare subProperties of dcterms like this ? I think I need a general explanation on this.
I do not see any reason why it would be considered good practice, but I don't see a reason to actively prevent people from doing so.
What could be the alternative to link ex:myHasPart with dcterms:hasPart ? rdfs:seeAlso ? skos:broadMatch ?
Your suggestions seem valid to me. But do you really need to make that link explicit?
I've been searching around but couldn't find a good way to model the following, I have two classes in owl and one is the base class of the other:
:Base rdf:type owl:Class .
:Sub rdf:type owl:Class;
rdfs:subClassOf :Base .
:hasDescription rdf:type owl:DatatypeProperty .
I want all instances of :Base to have a fixed description (:hasDescription "BASE"), and all instances of :Sub to have a different fixed description (:hasDescription "SUB"). But I want to avoid creating a triple for every instances such as
:Base1 rdf:type :Base;
:hasDescription "BASE" .
I tried using owl:Restriction :
:Base rdf:type owl:Class .
rdf:subClassOf [ rdf:type owl:Restriction ;
owl:onProperty :hasDescription ;
owl:hasValue "BASE"
] .
:Sub rdf:type owl:Class;
rdfs:subClassOf :Base ,
[ rdf:type owl:Restriction ;
owl:onProperty :hasDescription ;
owl:hasValue "SUB"
] .
but this wouldn't work because then :Sub would have both "BASE" and "SUB" as description since it's a subclass of :Base, which in turn is a subclass of the restriction with value "BASE". Anyone has any suggestion on how this can be done in owl? Thanks.
I think that this is probably possible, but it highlight the differences between object oriented programming languages and the class hierarchies as present in OWL. They're very different things, and it might make sense to consider changing your model, because you may not find a satisfactory solution to this issue.
Every instance of a subclass is an instance of all of its ancestors. That's why if you assert something like
Base SubClassOf (hasDescription value "BASE")
all the instances of the subclassses of Base will also have that value. (You already know that, of course; you described it in the question.)
You can say that instances of Base that are not instances of Sub have the value "BASE" and that instances of Sub have the value "SUB" with two axioms. One says that instances of Sub have the value "SUB" (you already know how to do this):
Sub SubClassOf (hasDescription value "SUB")
To say that instances of Base that are not instances of Sub have the value "BASE", you use a general class axiom like:
Base and (not Sub) SubClassOf (hasDescription value "BASE")
The process of creating general class axioms has been discussed in other questions and answers, and isn't difficult. See, e.g.:
owl protege how can I describe a class that has just some properties?
Defining Protege class with expression of numerical data
Inferencing in protege
The difficulty that you may run into is getting this axiom to be used. In general, when you assert that something is an instance of Base, you don't explicitly assert that it's not an instance of a subclass. That's a manifestation of the Open World Assumption: just because you don't know that something is true does not mean that you don't know that it's false.
You can do that, of course, by adding an additional type assertion to individuals. For instance, if x is a Base and not a Sub, you just need to say that:
x : Base
x : not Sub
I've defined a class as restriction for a property:
:A rdf:type owl:Class ;
owl:equivalentClass [ rdf:type owl:Restriction ;
owl:onProperty :P ;
owl:someValuesFrom xsd:string
] .
and would like to 'reuse' this restriction in another class, whereby I'm using the equivalentClass hierarchy:
:B rdf:type owl:Class ;
owl:equivalentClass :A.
But then I'm confused with the results shown by Protege: The :B is displayed as equivalentClass to :A (as expected) but as "subClassOf (Anonymous Ancestor)" to "P some xsd:string". I've expected, that :B inherits the property restriction also as equivalentClass.
The subclassing of the property restriction in B instead of equivalent class relation influences the type inferencing of an individual that contains the property P:
:Ind rdf:type owl:NamedIndividual ;
:P "p" .
A reasoner (I'm using FACT++) infers that the Ind is of type A because it contains the property P, and of type B - because it is A, and A is equal to B, but not because of the property P.
So, I'd like to ask, why the property restriction is inherited as subClassOf in my example, and if there is a posibility to inherit it as equivalentClass?
Thanks for any hint.
View from A:
View from B:
Be careful not to confuse Protégé's behaviour with how a reasoner works, or how OWL works. It's possible that, when you apply reasoning in Protégé, Protégé is only asking for what is in the upper hierarchy of the classes. Maybe Protégé does not ask the reasoner what is equivalent. I have noticed that, for several kinds of inferences, Protégé does not display them, even when the reasoners are themselves able to deduce them. I have never put my nose into Protégé's source code, and I have only limited knowledge of how Pellet work, limited theoretical knowledge of HermiT's algorithm, no other knowledge of the code of other reasoners, so I cannot say more.
In any case, you are not misunderstanding how the semantics of OWL works, and this is probably not a bug in the reasoner. It is certainly due to the way Protégé works.
I have modelled the following in my Ontology:
Club employs some Player, Player hasNationality some Nationality, Player hasNationalStatus value National_Player, Country is equivalent to Nationality.
I want the Ontology to infer that:
If a Player hasNationality some Nationality and, Player hasNationalStatus value National_Player then, Country(Same as the nationality the player has) employs Player.
As an example:
{Steven_Gerrard} hasNationality value England and, {Steven_Gerrard} hasNationalStatus value National_Player therefore, {England} employs [Steven_Gerrard}.
Is there a possible way to add this knowledge to Protege?
Thanks.
Edit:
Error Messages:
Error 42 Logged at Tue Apr 01 20:49:24 BST 2014
OWLReasonerRuntimeException: Non-simple object property 'http://www.semanticweb.org/u1cjd/ontologies/2014/1/untitled-ontology-2#employs' is used as a simple one
and
Error 43 Logged at Tue Apr 01 20:49:24 BST 2014
ReasonerInternalException: tRole.cpp:243: assertion 'Ancestor.empty() && Descendant.empty()' fails
This is possible, and it's actually very similar to the technique I mentioned in an answer to your previous question, Adding statements of knowledge to an OWL Ontology in Protege), and the structure of this answer is almost identical to my answer to a recent answers.semanticweb.com question, OWL property inference from blank node - modelling.
You just need to use some rolification and a property chain axiom. The point to note is that the existing data has the form of the upper arrows, and the desired information is in the lower arrows.
It's not enough to give employs the subproperty hasNationality-1, because you want to ensure that the player has a particular national status. This is where you need rolification. You want employs to have a subproperty chain of hasNationality-1 • p, where p is a special property that only relates players with national status to themselves. You can do that with rolification. Just declare a new object property RNationalPlayers and assert the axioms
hasNationalStatus value National_Player EquivalentTo R_NationalPlayer some Self
inverse(hasNationality) o R_NationalPlayer subPropertyOf employs
In the description logic syntax, these would be something like:
=hasNationalStatus.National_Player ≡ ∃RNationalPlayer.Self
hasNationality-1 • RNationalPlayer ⊑ employs
This will work in some reasoners, but unfortunately, this does bring us out of OWL 2 DL and into OWL full. This was discussed in some detail in the comments on this answer. As the error message in the updated question indicates, employs is now a non-simple property, and used in a place where only simple properties should be used. See 11.1 Property Hierarchy and Simple Object Property Expressions for more about what makes a property simple or not, and 11.2 The Restrictions on the Axiom Closure for more about properties can appear where.
However, it sounds like you're using a reasoner that supports SWRL rules, in which case you could simply add the rule:
hasNationality(?player,?country) ∧ hasNationalStatus(?player,National_Player) → employs(?country,?player)