Title: General Issue: Overloading of owl:sameAs
Diagram (this article has no graphical representation)
Users | MichaelUschold |
---|---|
Domains | General |
Competency Questions | |
Scenarios | |
Proposed Solutions (OWL files) | |
Related patterns |
Issue: owl:sameAs is being used in the linked data community in a way that is inconsistent with its semantics.
Correct Usages: A common case of a correct use is to link one resource that denotes a particular real world object to another resource that denotes the same object. Typically this will be done in two different collections of resources from two different namespaces. Examples:
Possibly correct usage:
Probably incorrect usages:
The first two are similar in that there is a confusion between a resource denoting a real world entity and a web page that contains information about that real world entity.
The books example is interesting because for most intents and purposes, people just want to say: yes, the books we are talking about in each case are the same. So owl:sameAs seems highly appropriate. This likely work much of the time. It could be a problem for someone wanting to analyze an Amazon web page for say its structure and layout. Then the book that the web page is featuring is an attribute of the web page, not the web page itself.
Issue: even if the usage is strictly incorrect, in some cases it may not matter. It depends on the intended use. Using owl:sameAs in a variety of ways with somewhat vague semantics can actually be an advantage.
We can have best of both worlds if we have a more generic relation that is being used the way owl:sameAs is now (vaguely) and having sub-relations that have more specific meanings.
Issue: If we move to a new vocabulary of similarity relationships that inludes the curent sameAs (as strictly defined) as well as a looser relationship (as sameAs is often used in practice), then there is a communication and migration challenge getting people to use them correctly.
Maybe what is now called “sameAs: should be renamed to “literalSameAs� and then the strictly correct uses of sameAs could be changed to literalSameAs, and the loose ones would remain the same.
Ideas / Proposals
More vocabulary needed to cover different cases. The vocabulary should provide clear and formal semantics, in the way that sameAs has, the semantics will be weaker.
Essentially the same thing: The main thing being talked about by one resource is for all non-technical intents and purposes the same thing that is being talked about by the other resource.Examples
Use existing properties like rdfs: seeAlso and skos:related to denote similarity, which is what owl:sameAs is often used for.
This may have some merit, but often these have too weak a semantics.
Distinguish a set of core assertions about a resource from ancillary assertions. See: http://dbooth.org/2007/uri-decl/
Blog Summary: http://blog.hubjects.com/2007/07/using-owlsameas-in-linked-data.html
It's been a very long and interesting thread on Linking Open Data forum and elsewhere, about the use and semantics of owl:sameAs. I just suggested the following best practices :
Granted, from a pure logical viewpoint, those assertions are strictly equivalent since owl:sameAs is a symmetrical property, but from a social/trust viewpoint, having each side declaring it in a specific direction could be interpreted as a formal proof of agreement. It's what have been done e.g. between DBpedia and GeoNames. The title thread shows once again by its sheer length, and if necessary, that there is no universal way to ground such agreement, which belongs to the realm of language and social communication.
Good points raised: