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
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.
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.
I have a quite simple ontology written in OWL 2, describing my particular world (TBox).
Since I have to store a lot of individuals, I would like to avoid scalability problems of triplestores, storing them out of the ontology (e.g., in a database table). At the same time, I would like to exploit reasoning capabilities.
For example, if I stored my individuals assertions directly into my ontology:
:Mary a :Female
:Mary :motherOf :John
...
with an opportune modelling, I could entail after a reasoning that:
:Mary a :Parent
:Mary a :Mother
...
...but what if I stored my individuals assertions outside of my ontology? Is there a framework/best practice to manage this scenario?
I know that similar questions have been asked in different ways here but still I see no solution for it...
I would like to add a restriction which states that individuals of class A have exactly 1 data type property value. I have been trying i.e. inserting hasXValue exactly 1 on equivalent classes Protege tab. Also, I have tried also combining min and max restrictions. However, as stated by other people´s posts, it is consistent to have 0 or 1 declaration of value but not 2. I have understood some explanations about the world assumption in OWL but then I would like to know which kind of axiom it could be used for doing this restriction.
In fact, the easiest solution that worked for me is by querying within a SPARQL ASK query, looking the no existence of an instance that pertains to certain class and does not have a data type property value (I have use FILTER NON EXISTS). In this way, I can have a true/false value stating that there is or not any individual with no data type property value declaration. However, I would like the reasoner to say that the model is inconsistent in this case.
My objective is that if I have to declare a lot of instances of a class that must have i.e. an ID, not miss any declaration. Moreover, I would like not having to execute a query for checking it. Thus, I though that cardinality restrictions were the correct choice.
Any help on this? Thanks in advance!
If I'm not mistaken, you are trying to use OWL for validation, which requires a closed world interpretation of the semantics to get the kind of inconsistency errors you'd like to see. As you've noticed, out of the box, you're not going to get that behavior because that's not what OWL was designed for.
There was a workshop on this exact topic, and now there is a W3C working group to explore how to do validation in a standardized way.
Stardog's implementation of integrity constraints uses OWL (Manchester) syntax, amongst others, for authoring constraints, which you could create in Protege, but Stardog itself doesn't have a Protege plugin. As an aside, it translates constraints into SPARQL queries which use FILTER NOT EXISTS much in the same manner as you did by hand, except that it does so automatically.
Other inputs to the working group are SPIN and SHEX. SHEX is not worth looking at, but SPIN could be another decent option for you. It won't, as far as I know, work with Protege, but it is integrated with an IDE (TopBraid) and has a SPARQL based syntax.
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.