I think I am going crazy! I have followed the various tutorials for Owl and Protege and still cannot figure out the answer. Use case is simple. I have defined a class called ‘Person’. I have defined a data property called hasFirstName. I have added a ‘subclass of’ restriction to Person like this : ‘hasFirstName exactly 1 string’. I have also added an individual called Alex of type Person, and have not added the hasFirstName property. I expect the reasoner to complain as I have specified the cardinality of 1, and asserted that Alex is a Person, but have not added the property value to Alex individual, yet the reasoner does not complain. If however I add two statements e.g. hasFirstName ‘Alex’ and hasFirstName ‘John’ then I get a complain. What I am doing wrong? Any help will be most appreciated, thanks.
There's no inconsistency in the first case. OWL makes the open world assumption, which means that something being unknown is different from it being known to be true or known to be false. Your username, at the time I'm writing this answer is user3552593. I'm relatively confident that you have a name, and that's not inconsistent with the fact that I don't know what it is yet.
By saying that
Person ⊑ =1 hasFirstName.String
and that
Alex : Person
you can infer that
Alex : =1 hasFirstName.String
There's nothing inconsistent with that; Alex, by virtue of Alex's personhood, has exactly one first name—we just don't know what it is yet.
Related
It seems to me that the definition of a EquivalentTo class doesn't work properly in Protégé 5.2.0. Hopefully, it is a misunderstanding on my side.
Here is the example : Link to a simple ontology that gives an unexpected result.
The problem happens when I use a min cardinality condition on some ObjectProperties. In the provided example, the classification in SubClassObject of the Object(using Pellet) doesn't work for the hasPart min 2 Part but does for hasPart min 1 Part. As you see, the element5 has 4 Parts as defined.
Has anybody ever met a similar issue?
Thank you in advance,
As #StanislavKralin said : Edit > Make all individuals different.
In my personal experience afterwards, be aware that it will considerably increase computing time of reasoning.
I'm learning OWL 2.0 using Protégé 4.0 and Pellet 2.2, and I'm trying to understand underlying concepts progressively.
So, starting with class hierarchies, I made one class "Cat" as a SubClassOf "Things".
If I start Pellet, everything works fine, but if I DL query "Cat", I have Directsubclasses "Nothing" and Subclasses "Nothing" appearing in red.
What does it mean?
Why is it red?
Justifications are like :
Explanation for: Nothing SubClassOf Cat
<Entailment1252345325436>SubClassOf Nothing and (not (Cat))
What does it mean?
Why are there like an infinity of these "Entailment" justifications (I mean I only created 1 class).
Is there an error I made I have to correct to avoid this phenomenon? Or should I just don't care about it?
Thank you ^_^!
Nothing is the empty class, sometimes written as ⊥ in DL notation. In most cases, if you have a class that's equivalent to Nothing, it's a modeling error. E.g., if you accidentally define
Car EquivalentClass (hasDoors exactly 2)
Car EquivalentClass (hasDoors exactly 4)
you'll find that Car is now equivalent to Nothing because something can't have exactly 2 and exactly 4 doors. That's an accident. There's nothing logically incorrect with it, but usually you don't want your classes to necessarily be empty. So, Protege shows necessarily empty classes in red.
Of course, the empty class, Nothing, is a subclass of every class, just like the empty set is a subset of every set, and it's necessarily empty.
So, there's actually nothing wrong with what you're seeing. Nothing should be red, and it should be a subclass of every class. Everything is working the way that it should.
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)
My question is related to SWRL rules and actually was already asked by another user (see Ontology property definition in Protégé-OWL / SWRL). Still, after following the instructions on how to get it to work, I was not successful.
In my ontology I have to work with some complex temporal facts (related to time intervals etc.), therefore I import the Time Ontology. Before tackling the real problem, I'm consider a simple example, testing how to assign a value to a data property based on a SWRL rule. The simple example deals with a class Person. There also is a class BirthYear (subclass of the Instant class from the Time Ontology). The object property bornInYear, with domain Person and range BirthYear relates a Person with the year of his/her birth. I would like to calculate the age of the person in the current year, therefore I formulate this SWRL rule:
Person(?p) ∧ bornInYear(?p, ?birthYear) ∧ subtract(?age, 2014, ?birthYear)
→ age(?p, ?age)
After creating an individual of class Person and asserting that his/her BirthYear has the value "1977", I would expect Pellet to calculate that this person's age is 37. This does not happen. Any idea why? Is the SWRL rule correct? (In order to know if the value 37 is asserted to the data property age, I look at the "Property assertions" view of the individual p. I also make sure, that in the reasoner preferences the check box 'Object Property Assertions" is checked.) My example ontology reads as follows:
Prefix(SWRLexample:=<http://www.semanticweb.org/ontologies/2014/1/SWRLexample#>)
Prefix(xsd:=<http://www.w3.org/2001/XMLSchema#>)
Prefix(swrlb:=<http://www.w3.org/2003/11/swrlb#>)
Prefix(owl:=<http://www.w3.org/2002/07/owl#>)
Prefix(:=<http://www.semanticweb.org/ontologies/2014/1/untitled-ontology-101#>)
Prefix(time:=<http://www.w3.org/2006/time#>)
Prefix(xml:=<http://www.w3.org/XML/1998/namespace>)
Prefix(rdf:=<http://www.w3.org/1999/02/22-rdf-syntax-ns#>)
Prefix(swrl:=<http://www.w3.org/2003/11/swrl#>)
Prefix(rdfs:=<http://www.w3.org/2000/01/rdf-schema#>)
Ontology(<http://www.semanticweb.org/ontologies/2014/1/SWRLexample>
Import(<http://www.w3.org/2006/time>)
Declaration(Class(SWRLexample:BirthYear))
SubClassOf(SWRLexample:BirthYear time:Instant)
Declaration(Class(SWRLexample:Person))
Declaration(ObjectProperty(SWRLexample:bornInYear))
ObjectPropertyDomain(SWRLexample:bornInYear SWRLexample:Person)
ObjectPropertyRange(SWRLexample:bornInYear SWRLexample:BirthYear)
Declaration(DataProperty(SWRLexample:age))
AnnotationAssertion(rdfs:comment SWRLexample:age "Age of a person in years")
DataPropertyDomain(SWRLexample:age SWRLexample:Person)
DataPropertyRange(SWRLexample:age xsd:int)
Declaration(NamedIndividual(SWRLexample:birthYear1))
ClassAssertion(SWRLexample:BirthYear SWRLexample:birthYear1)
DataPropertyAssertion(time:year SWRLexample:birthYear1 "1977"^^xsd:gYear)
Declaration(NamedIndividual(SWRLexample:p1))
ClassAssertion(SWRLexample:Person SWRLexample:p1)
ObjectPropertyAssertion(SWRLexample:bornInYear SWRLexample:p1 SWRLexample:birthYear1)
DLSafeRule(Body(ClassAtom(SWRLexample:Person Variable(<urn:swrl#p>)) ObjectPropertyAtom(SWRLexample:bornInYear Variable(<urn:swrl#p>) Variable(<urn:swrl#birthYear>)) BuiltInAtom(swrlb:subtract Variable(<urn:swrl#age>) "2014"^^xsd:integer Variable(<urn:swrl#birthYear>)))Head(DataPropertyAtom(SWRLexample:age Variable(<urn:swrl#p>) Variable(<urn:swrl#age>))))
)
There are a few problems (but I'm glad that that other answer was a useful starting point):
age is a data property, so you not only need to make sure that "the check box 'Object Property Assertions' is checked," but also 'Data Property Assertions', since it's a datatype assertion that you're looking for.
BornInYear is an object property, so ?birthYear in bornInYear(?p, ?birthYear) must be an individual. However, swrlb:subtract's arguments must be numeric literals. To use swrlb:subtract, you'll need to get the integer value of the year in the rule and perform the arithmetic on that. You should be able to do that without too much trouble, although I'm not sure if you'll still be able to use the value "1977"^^xsd:gYear. SWRL does define some functions working with dates and times, though (see 8.5. Built-Ins for Date, Time and Duration). Not all the reasoners support that, though (e.g., I don't think Pellet does). However, the value of the year property does need to be an xsd:gYear.
Here are the successive steps :
Go to metadata tab
Import temporal ontology, prefix it as temporal.
Go to SWRL tab
Write rule as follows :
Person(?x) ^ hasDOB(?x, ?dob) ^ temporal:duration(?age, "now", ?dob, temporal:Years) -> hasAge(?x, ?age)
where Person is a class
hasDOB,hasAge are object properties
I was explaining to a friend a few days ago the concept or inheritance and containers.
He has very little programming knowledge so it was really just a friendly chat.
During the conversation he came to me with a question that i just couldn't answer.
"Why cant you just have an array of the top level class, and add anything to it"
I know this is a bad idea having being told so before by someone far smarter but for the life of me i couldn't remember why.
I mean we do it all the time with inheritance.
Say we have class animal which is parent of cat and dog. If we need a container of both of these we make the array of type animal.
So lets say we didn't have that inheritance link, couldn't we just use the base object class and have everything in the one container.
No specific programming language.
Syntactically, there is no problem with this. By declaring an array of a specific type, you are giving implicit information about the contents of that array. You could well declare a contain of Object instances, but it means you lose all the type information of the original class at compile-time.
It also means that each time you get an object out of the array at runtime, the only field instances and methods you know exist are the fields/methods of Object (which arguably is a compile time problem). To use any of the fields and methods of more specific subclasses of the object, you'd have to cast.
Alternatively, to find out the specific class at runtime you'd have to use features like reflection which are overkill for the majority of cases.
When you take elements out of the container you want to have some guarantees as to what can be done with them. If all elements of the container are returned as instances of Animal (remember here that instances of Dog are also instances of Animal) then you know that they can do all the things that Animals can do (which is more things than what all Objects can do).
Maybe, we do it in programming for the same reason as in Biology? Reptiles and Whales are animals, but they are quite different.
It depends on the situation, but without context, it's definitely okay in most (if not all) object-oriented languages to have an array of a base type (that is, as long as they follow all the substitution principles) containing various instances of different derived types.
Object arrays exist in certain cases in most languages. The problem is that whenever you want to use them, you need to remember what type they were, and stay casting them or whatever.
It also makes the code very horrible to follow and even more horrible to extend, not to mention error prone.
Plant myplant = new Plant();
listOfAnimals.Add(myplant);
would work if the list is object, but you'd get a compile time error if it was Animal.