can we use owl:SameAs between two predicates?
Asked Answered
P

3

12

What is the difference between using <DC:title> <owl:SameAs> <NS:title> and <DC:title> <owl:equivalentProperty> <NS:title>

Here NS is some namespace.

Parentage answered 16/8, 2011 at 3:7 Comment(0)
V
11

owl:sameAs is intended for individuals, owl:equivalentProperty is intended for RDFS/OWL properties, and owl:equivalentClass is intended for RDFS/OWL classes.

I guess you're stating equivalence between these properties so that you can infer

:individual1 ns:title "The Title".

from an existing statement

:individual1 dc:title "The Title".

or vice versa. I haven't tried this, but I'd assume that DL-based OWL reasoners (that is, most OWL reasoners) will only do the appropriate inference if owl:equivalentProperty is used. On the other hand, if you wanted to infer

:individual2 dc:title "The Title".

from an existing statement

:individual1 dc:title "The Title".

then you should use an owl:sameAs statement to relate the two individuals.

Volition answered 16/8, 2011 at 8:35 Comment(3)
I completely agree with your statement, but my point is , since we can use sameAs for any types of resources and predicate is also a type of resource, so is it technically correct to use sameAs for predicates.Parentage
No. owl:sameAs is for equivalence of invidivuals. It is not for “any kind of resource”. If you want reasoning to work, you'll have to use owl:equivalentProperty.Volition
In OWL 1, it says the following about equivalentProperty: "Property equivalence is not the same as property equality. ... Property equality should be expressed with the owl:sameAs construct." It's hard for me to determine, did this changed in OWL 2?Sessler
C
8

Two differences:

Firstly some OWL reasoners will object to owl:sameAs between properties, or simply ignore it. They maintain strong distinction between individuals and classes / properties.

Secondly (and this is more significant) equivalence (like owl:equivalentProperty) is not the same as identity (owl:sameAs). The latter says that we are dealing with one thing with different names, whereas the former says that there are two things which have the same extension (that is, hold between the same things).

If that's not clear here's an example:

# My book has ns:title "My book"
:book ns:title "My book" .

# My title property is defined in my vocabulary document
ns:title rdfs:isDefinedBy <http://example.com/my-vocab> .

Using owl:sameAs my book also has dc:title "My book" and dc:title is defined by my vocabulary document. Oops, DC may not be happy about that.

With owl:equivalentProperty my book also has dc:title "My book" (great), but it doesn't imply that dc:title is defined by vocabulary document (phew).

Choanocyte answered 16/8, 2011 at 14:36 Comment(1)
I don't think reasoners will object, they'll infer that the properties are individuals as well and hence will fall into OWL-Full, which you don't really want.Copp
T
2

The short answer is "no, don't do this" as explained in cygris's answer. There is, however, more subtlety in the question if you really want to know the implications of using owl:sameAs VS. owl:equivalentProperty.

First, a little correction about the terms in the question: In RDF, a predicate is something that is in the second position of a triple. RDF have no way of referring to positions in triples, so you cannot use a property between two predicates. What is certainly meant by the OP is "can we use owl:sameAs between two properties". Properties can be identified with IRIs, IRIs can occur anywhere in a triple, subject and object can be related by way of a predicate, and any IRI are allowed in any position of a triple. So, syntactically speaking, it is allowed to relate two properties with owl:sameAs.

The question is, though, whether it makes sense to do so, and what the implications are. The issue is that there is something quantumdesque about RDF graphs: the meaning of an RDF graph is a superposition of meanings, and you only know the observable meaning when you apply some reasoning according to some formal semantics. RDF 1.1 Semantics defines multiple semantics (so-called entailment regimes) but none of them gives a specific meaning to owl:sameAs, so applying RDF(S) reasoning wouldn't bring anything useful. Consequently, if such is the observed meaning of the graph, owl:sameAs between properties is useless.

The real interesting things arise when one applies OWL semantics. But even in OWL, there is a duality of meanings with the OWL 2 Directed Semantics and the OWL 2 RDF-based Semantics. Let us consider an example RDF graph:

<p>  a  owl:ObjectProperty;
     dc:creator  "AZ" .
<q>  a  owl:ObjectProperty;
     dc:date  "2016-06-07"^^xsd:date  .
<r>  a  owl:ObjectProperty, owl:DeprecatedProperty;
     dc:date  "1981-01-14"^^xsd:date .
<s>  a  owl:ObjectProperty;
     dc:date  "2016-06-07"^^xsd:date .
<p>  owl:sameAs  <q> .
<r>  owl:equivalentProperty  <s>
<a>  <p>  <b> .
<c>  <r>  <d> .

Let us start with the RDF-based semantics. On the one hand, IRIs <r> and <s> denote equivalent properties, so we can conclude:

<c>  <s>  <d> .

On the other hand, IRIs <p> and <q> name the same resource, so we can conclude that (among other things):

<q>  dc:creator  "AZ" .
<p>  dc:date  "2016-06-07"^^xsd:date .
<a>  <q>  <b> .
<p>  owl:equivalentClass  <q> .

The difference is that everything one says about <p> holds for <q> because it is the same! In general, different property names refer to different properties, because they must be attached to different metadata (such as rdfs:isDefinedBy, rdfs:label, rdfs:comment, DC terms).

Let us now apply the Direct Semantics to this. It fails. The Direct Semantics does not apply to RDF graphs, it applies to ontologies in the functional-style syntax of the OWL 2 Structural Specification. In order to interpret an RDF graph according to the Direct Semantics, one has first to map the graph to an OWL 2 ontology in the functional syntax. This requires that the RDF graph satisfies some constraints, in order to be an OWL 2 Ontology in RDF graph form.

One obligation is that all individuals have to be explicitly declared as members of some OWL classes. Another requirement is that owl:sameAs can only apply to individuals. Individuals are strictly disjoint from properties, but there is a little trick: an individual name can be the same as a property name (this is called punning). All properties must be declared as either object properties, datatype properties, or annotation properties. A name must be given to the ontology, together with a statement that explicitly says that it is an ontology. So, a version of the RDF graph that is a valid OWL 2 Ontology in RDF graph form is as follows:

<>  a  owl:Ontology .  # Give a name to the ontology and declare it as such
dc:creator  a  owl:AnnotationProperty .  # Declare property
dc:date  a  owl:Annotation Property .  # Declare property
<p>  a  owl:ObjectProperty;
     dc:creator  "AZ" .
<q>  a  owl:ObjectProperty;
     dc:date  "2016-06-07"^^xsd:date  .
<r>  a  owl:ObjectProperty, owl:DeprecatedProperty;
     dc:date  "1981-01-14"^^xsd:date .
<s>  a  owl:ObjectProperty;
     dc:date  "2016-06-07"^^xsd:date .
<p>  a  owl:Thing .  # <p> used with owl:sameAs: must be declared as individual
<q>  a  owl:Thing .  # <q> used with owl:sameAs: must be declared as individual
<a>  a  owl:Thing .  # Declare individual
<b>  a  owl:Thing .  # Declare individual
<c>  a  owl:Thing .  # Declare individual
<d>  a  owl:Thing .  # Declare individual
<p>  owl:sameAs  <q> .
<r>  owl:equivalentProperty  <s>
<a>  <p>  <b> .
<c>  <r>  <d> .

On this graph, we can apply the OWL 2 Direct Semantics, with which we can conclude:

<c>  <s>  <d> .

None of the other triples given before with the RDF-based Semantics can be inferred. In particular, the fact the <p> and <q> denote the same individual does not allow to conclude anything about the properties named <p> and <q>.

Again, in this case, it's usually not a good idea to use owl:sameAs.

In conclusion, however you interpret the RDF graph, using owl:sameAs to relate two properties is likely not a good idea.

Tedmann answered 7/6, 2016 at 14:29 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.