I have used an object property O to relate Class A with Class B. I also have instance a and b of classes A and B respectively. I have used the same object property O to relate the instances a and b.
Again, I have used the same object property O to link a with c, where c is an instance of Class C which is not linked with class A or B using any object property.
Reasoners are still showing that the Ontology is Consistent.
My question is "Should this not be marked as inconsistent by the reasoners? Please enlighten me regarding your answer, whether the answer is 'Yes' or 'No' and the reason behind your answer"?
Thanks in advance.
You understand the semantics of domain and range axioms incorrectly. In the case of your object property O it merely states that whenever 2 individuals x, y are linked via O it means that the reasoner will infer that x is of type A and y is of type B.
In the case linking individuals a and c where c is of type C you will notice that c is also now inferred to be of type B.
If you want to see an inconsistency, what you can do is make classes B and C disjoint. Then linking a and c via O will result in an inconsistency.
BTW, if you are interested, on my blog I write about OWL2 ontologies and the use of reasoners and some of the counter intuitive ways in which reasoners can seem to "fail".
Related
May question is a bit basic. But I do not know what happens when we define "data range expressions" in protege? Does it limit the range only to the literals written there?
In what cases can we use "data range expressions?"
Below is an example that I saw in an ontology:
The semantics of data property domains and ranges are given by
which you can find defined in the direct semantics of OWL 2.
This means that for every 2 individuals x and y that are related by a data property DPE, that x is of type CE and y is of type DR.
In your example it means that if x and y are related via test type then the reasoner will infer x is of type Concrete placement OR Test and y is of type {"Self-inspection", "Third-Party Monitoring"}.
Update based on comment
This means that if individual y does not have the value of either "Self-inspection" OR "Third-Party Monitoring", it will result in the ontology being inconsistent.
So, yes, the user has to choose between these 2 values.
I have created an ontology in Protege 5.2 and now I am trying to create correctly the object properties of my corresponding classes. Here is a snippet of my UML diagram according to which I have built my ontology:
Snippet of my ontology
Regarding the isLocated object property, they are characterized in the following way: If a Node X has a SITE value Z, and the same value Z appears in SITEIST of a Location Y, then Node X is Located in Location Y.
Should I look into SWRL rules or is there some way to encode this without having to go there?
Thank you guys in advance!
In SWRL you can achieve that straightforward:
locationHasSiteIst(?l, ?s) ^ nodeHasSite(?n, ?s) -> nodeLocatedInLocation(?n, ?l)
If you want yo make it in OWL, you need to make locationHasSiteIst and nodeHasSite as object properties, and Site as a class instead of a datatype, then you can use object property chaining and inclusion in Protege as follows:
nodeHasSite o inverse(locationHasSiteIst) SubPropertyOf nodeLocatedInLocation
The last line means that if a node n1 is located in site1, and a location l1 is located in s1 as well, then n1 is located in l1.
Is there any difference between the following ways of expressing multiple necessary conditions in ontology (via Protege)
Each necessary condition expressed one by one inside the SubclassOf Section (for class A):
instrument some B
object some C
All of those stated at once (via the class expression editor)
instrument some B and object some C
Are 1 and 2 semantically the same?
Yes they are equivalent. The choice of which way to go is yours: which approach do you find more readable? That is the best choice.
When I create a RDFS_MEM_RDFS_INF model in Jena and read some RDFS-File, a number of statements, that were not explicitly stated in the file are added. E.g. if we have a triple
a p b
and p is a rdfs:subPropertyOf q, than
a q b is
also in the model. A concrete example is the following: if
a skos:related b
is in the file
a skos:semanticRelation b
is also in the model.
Is there any possibility to check whether a statement in the model is an axiom or an inferred one? There are such methods for OWL Models, but I use the RDFS Model. A trivial solution would be to build two models, one without and one with inference, but I would prefer a less memory consuming solution.
Jena InfModel has a method getRawModel(). This Model wont contain the inferred statements, it will contain only the axioms in the file. use a check against that. If you are using the OntModel it has got a method getBaseModel().
To preserve djthequest's answer from a comment:
Jena InfModel has a method getRawModel(). This Model wont contain the
inferred statements, it will contain only the axioms in the file. use
a check against that. If you are using the OntModel it has got a
method getBaseModel().
and Christian Wartena's response indicating that this was a solution:
Thanks. This works fine! I didn't find that method when I was reading
the documentation last week.
(I'll remove this answer if djthequest posts one.)
I came across the original statement of the Liskov Substitution Principle on Ward's wiki tonight:
What is wanted here is something like the following substitution property: If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when o1 is substituted for o2 then S is a subtype of T." - Barbara Liskov, Data Abstraction and Hierarchy, SIGPLAN Notices, 23,5 (May, 1988).
I've always been crap at parsing predicate logic (I failed Calc IV the first time though), so while I kind of understand how the above translates to:
Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.
what I don't understand is why the property Liskov describes implies that S is a subtype of T and not the other way around.
Maybe I just don't know enough yet about OOP, but why does Liskov's statement only allow for the possibility S -> T, and not T -> S?
the hypothetical set of programs P (in terms of T) is not defined in terms of S, and therefore it doesn't say much about S. On the other hand, we do say that S works as well as T in that set of programs P, and so we can draw conclusions about S and its relationship to T.
One way to think about this is that P demands certain properties of T. S happens to satisfy those properties. Perhaps you could even say that 'every o1 in S is also in T'. This conclusion is used to define the word subtype.
As pointed by sepp2k there are multiple views explaining this in the other post.
Here are my two cents about it.
I like to look at it this way
If for each object o1 of type TallPerson there is an object o2 of type Person such that for all programs P defined in terms of Person, the behavior of P is unchanged when o1 is substituted for o2 then TallPerson is a subtype of Person. (replacing S with TallPerson and T with Person)
We typically have a perspective of objects deriving some base class have more functionality, since its extended. However with more functionality we are specializing it and reducing the scope in which they can be used thus becoming subtypes to its base class(broader type).
A derived class inherits its base class's public interface and is expected to either use the inherited implementation or to provide an implementation that behaves similarly (e.g., a Count() method should return the number of elements regardless of how those elements are stored.)
A base class wouldn't necessarily have the interface of any (let alone all) of its derived classes so it wouldn't make sense to expect an arbitrary reference to a base class to be substitutable for a specified derived class. Even if it appears that only the subset of the interface that supported by the base class's interface is required, that might not be the case (e.g., it could be that a shadowing method in the specific derived class is referred to).