From what I've understood as reading the book Foundations of Semantic Web Technologies concerning owl formal semantics, Hitzler et al have put forward two kinds of model-theoretic semantics for SROIQ: one is the model checking like approach (where we check different interpretations to find the models of our KB) and the other is via predicate logic. In the latter approach, the book just translates SROIQ into predicate logic.
However, the book is a bit confusing for me and I do not know if I have gotten some points right, so here are my questions:
Is model-checking a kind of model-theoretic semantics?
Is translating your SROIQ into predicate logic also a model-theoretic semantics?
How is translating SROIQ into predicate logic a kind of "semantics"? Is that because after the conversion, we can pick up FOL semantics and algorithms?
Thanks!
P.S. This is a link to the book! Just in case!
Model theoretic semantics is how you determine the meaning of axioms - i.e., what rules are available to build a model or to check it is a valid one. Two examples: OWL semantics and RDF semantics. They have a lot of overlap but are not identical.
Model checking does not define semantics, it applies semantic rules defined in a model to actual knowledge bases. Translation to another formalism, e.g., predicates, might maintain the same semantics (i.e., all models stay the same in both formalisms), but this depends on the formalism involved.
Related
I want to say that in my ontology each individual has exactly one most-specific type.
In this case:
Is it accurate to say my ontology does not allow multiple inheritance? I don't quite understand what multiple inheritance means in ontologies. Is this refer to rdf:type or rdfs:subclassOf? because I don't mind if a concept has multiple parents but I don't want individuals to have multiple types.
Is it accurate to say in my ontology all classes are pairwise disjoint, or should I say for instance in the ontology classes are pairwise disjoint unless they are participating in subsumption relation with each other?
Is there a better terminology or way to actually describe such ontologies?
In literature you can find the expression "multiple inheritance" referring to both the extensional (rdf:type) and intensional (rdfs:subclassOf) meanings. RDF/OWL natively support both of them.
No, in general this is not correct. I don't think there is an official (and unambiguous) term for "individual being instance of multiple classes".
Your first statement is a sufficient condition, while the second one is necessary and sufficient. Alternatively, you can say that if two classes share an individual, then one of the two is a subclass of the other one.
I think that "one most-specific type" is already a well-describing terminology.
When an ontology is created from text consisting of a set of sentences, it can be useful to bind any given concept with all the sentences, where it is present. But that inevitably leads to a nasty duplication of sentences, when the usual Annotation is used for storing the related text.
E.g. the sentence "Attributive language is the base language which allows: Atomic negation (negation of concept names that do not appear on the left hand side of axioms), Concept intersection, Universal restrictions, Limited existential quantification." would need to be copied as an Annotation to the Entities: Attributive language, Language, Atomic negation, Negation, Concept names, Axiom, Concept intersection, Universal restriction, Limited existencial quantification.
What is in your opinion a good way to avoid copying the same sentence to several locations and yet to have traces from the Entity to the relevant sentences?
I would create a named individual with an IRI and attach the sentence to it, then add a relationship from the concepts to the individual.
The individual might have a type, e.g., Sentence, but this is not necessary. Properties used can be annotation properties or data/object properties.
I have been trying to research making rdf schema compatible with web ontology language but I am still new and still getting mixed up. any help with this is highly appreciated.
I need to know if there is anything I should remove or omit from rdfs to make it compatible with the owl.
To the best of my knowledge, almost every RDFS class expression and property hierarchy are valid in OWL.
Exceptions are containers and uses of rdfs:Resource and rdf:Property.
Edit:
From the OWL 2 specs:
2.3 Semantics
The OWL 2 Structural Specification document defines the abstract structure of OWL 2 ontologies, but it does not define their meaning. The Direct Semantics [OWL 2 Direct Semantics] and the RDF-Based Semantics [OWL 2 RDF-Based Semantics] provide two alternative ways of assigning meaning to OWL 2 ontologies, with a correspondence theorem providing a link between the two. These two semantics are used by reasoners and other tools, e.g., to answer class consistency, subsumption and instance retrieval queries.
So you need to be aware first of what semantics is appropriate for your application. RDF semantics is fully included in OWL 2 FULL, so if you /need/ all RDF constructs, you'll have to deal with OWL 2 FULL, which means any reasoners you can use will be incomplete.
The most common situation, however, is to need only OWL 2 DL or a simpler profile; this poses restrictions on the RDF constructs used.
As mentioned before, subclass axioms in RDFS are compatible with OWL; subproperty axioms as well. Restrictions are: all classes and properties need to be declared; properties can be declared as object, data or annotation properties, but cannot have two types.
For an RDF centric view, see this blog post: http://www.epimorphics.com/web/wiki/owl-2-rdf-vocabularies
At first this problem seems trivial: given two ontologies, which term in ontology A best refers to a term in ontology B.
But its simplicity is deceptive: this problem is extremely hard and has currently lead to thousands of academic publications, without any consensus on how to solve this problem.
Naively, one would expect that simply looking at the term "Heart Attack" in both ontologies would suffice.
However, ontologies almost never encode the same phrase.
In simple cases "Heart Attack" might be coded as "Heart Attacks", or "Heart attack (non-fatal)", but in more complicated cases it might only be coded as "Myocardial infarction".
In other cases it is even more complicated, for example dealing with compound (composed) terms.
More importantly, simply matching the term (or string) ignores the "ontological structure".
What if "Heart Attack" in ontology A is coded as caused-by high blood pressure, whereas in ontology B it might be coded as withdrawl-from-trial-non-fatal.
In this case it might be valid to match the two terms, but not trivially so.
And this assumes the equivalent term exists at all.
It's a classical problem called Semantic/Ontology Matching, Alignment, or Harmonization. The research out there involves lexical similarity, term usage in free text, graph homomorphisms, curated mappings (like MeSH/WordNet), topic modeling, and logical inference (first- or higher-order logic). But which is the most user friendly and production ready solution, that can be integrated into a Java(/Clojure) or Python app? I've looked at Ontology matching: A literature review but they don't seem to recommend anything ... any suggestions or experiences?
Have a look at http://oaei.ontologymatching.org/2014/results/ . There were several tracks open for matchers to be sent in and be evaluated. Not every matcher participates in every track. So you might want to read the track descriptions and pick one that seems to be the most similar to your problem. For example if you don't have to deal with multiple languages you probably don't have to check the MultiFarm track. After that check the results by having a look at Recall, Precision and F-Measure and decide for yourself. You also might want to check out some earlier years.
In the W3 OWL specification the properties of individuals are divided in to two groups: datattype properties and object properties. Object properties are defined (as one article I found put it):
"Object properties (owl:ObjectProperty) relates individuals (instances) of two OWL classes.
So in essence, object properties could also be called "individual properties", because they don't just point to generic objects of any sort, they point specifically to individuals.
Now, if this was just some random spec I would assume the authors simply chose their names poorly, but this is a W3 spec, and one specifically on the storage of knowledge no less; I have to assume people thought about the names of things!
Therefore, I'm hoping someone here can explain this seemingly strange naming choice. After all, you can call damn near anything in any spec an "ObjectFoo", because Object is a super-generic term, but normally people use the most specific term possible, not the least, when they name things.
Is there perhaps some other case where an ObjectProperty can refer to something other than an individual, or anything else I'm missing that might explain this?
The term "ObjectProperty" was (most probably) coined to distinguish it from "DatatypeProperty", in the sense that the latter can only have (datatyped) literal values, as opposed to full objects. And yes, it's not just individuals that can be the value of an ObjectProperty, classes can be values of them too - although if you do that, your ontology is no longer valid OWL DL and becomes OWL Full instead. But it's valid from a modeling perspective.
My answer is also a comment to Jeen. OWL DL and OWL Full are 2 distinct languages with a different (even disjoint) abstract syntax. OWL DL syntax is defined in terms of its structural specification. OWL Full syntax is RDF. The structural specification of OWL does not even contain any RDF triple.
Now, in OWL DL, it is invalid to relate two classes with an object property. Object properties can only relate instances of owl:Thing. They cannot relate literals, properties, ontologies, or datatypes either. If you call the notion IndividualProperty, you are creating an inconsistency in naming because DatatypeProperty does not mean a property that relates datatypes. It is a property that relates literals. So a better name would be ClassProperty. Or you would have to change both DatatypeProperty and ObjectProperty into LiteralProperty and IndividualProperty.
All in all, there are various ways to deal with this, the working group chose the one which gathered more votes. That's all how it always works in a standardisation group.
The name comes from "Subject Predicate Object". Those are properties that link the Subject with the Object, as opposite to Datatype Properties that are merely attributes.