RE: owl:sameAs - Is it used in a right way?

SKOS addresses terms, i.e., lexical resources, vocabularies, rather than concepts (ontologies), so could be used if you have perhaps distinct terminology that maps to OWL/RDF ontologies. SKOS provides term resources that help you map your vocabulary to OWL ontologies. That’s its purpose. So if you want different ways to refer to the same object, use SKOS to map your different terms to the ontology object.

Thanks,
Leo

From: Umutcan ŞİMŞEK [mailto:s.umutcan@gmail.com]
Sent: Friday, March 15, 2013 5:00 PM
To: Jeremy J Carroll
Cc: Alan Ruttenberg; Kingsley Idehen; public-semweb-lifesci@w3.org
Subject: Re: owl:sameAs - Is it used in a right way?

And I forgot to ask, can there be a solution based on SKOS vocabulary? AFAIK, SKOS properties are more flexible and semantically looser than owl:sameAs.

On 15-03-2013 22:40, Jeremy J Carroll wrote:
I think Jim's solution looks to me like the best realistic one going forward … having somewhat looser variants of owl:sameAs and ask people to be a bit honest with their use of sameAs …

For Alan's approach, I feel a problem is that what we are doing is making an approximate model of the world, not a completely accurate copy.
Alan is of course correct that the description and the thing are different, and if we want to be precise we would make that clear, and failing to make this distinction may lead us into trouble; but whenever we say anything about anything, the things we didn't say greatly out-number the things we did say, and making a judgment as to what is important is hard, and people will get it wrong.

I think most people, most of the time, do not want to be bothered saying, "Well this is my opinion, and your opinion may differ, and believe me if you wish" …. which is what making the careful distinction between the thing and its description amounts to.

So IMO, Alan is correct, but somehow missing the point.

Jeremy



On Mar 15, 2013, at 12:56 PM, Alan Ruttenberg <alanruttenberg@gmail.com<mailto:alanruttenberg@gmail.com>> wrote:


There's another perspective, which is to to distinguish descriptions of things from the things themselves. This works if you can agree on identity of the thing but not necessarily on the way to describe it. As an example, consider the class of cars manufactured by Nissan (call it Cn). If you can agree on a URI for that class, you can each write descriptions that have foaf:primaryTopic Cn.

Depending on how careful you want to be, you can then use one or two graphs. If you have your predicate relate descriptions then you can use a single graph. For example  instead of having a predicate hasNumberOfDoors that relates cars to a count of doors you can have  describedHasNumberOfDoors that relates a description of a car to a number with the interpretation that the author of the description asserts that the car has 4 doors.

Or, if you want to make assertions about the car, then use two graphs. Each can make statements of the sort [isPrimaryTopicOf <description>] hasNumberOfDoors 4. Since we are talking now about the cars, there could be different perspectives, so to control that you put each author's assertions in a different graph.

I think this is a better strategy than using sameAs. There are a bunch of problems with sameAs, not least of which is that often the assertions are incorrect - they mean something different, Jim's post gives a strategy to relate them without using sameAs, but I'd assert that general ways of relating descriptions takes more than a couple of relations, and should be an orthogonal problem. With the primaryTopic method I suggest the relationship that matters for your application - that the descriptions are pointing to the same thing, is explicit, and doesn't need new predicates, though it does require some level of coordination.

Best,
Alan

On Fri, Mar 15, 2013 at 2:55 PM, Umutcan ŞİMŞEK <s.umutcan@gmail.com<mailto:s.umutcan@gmail.com>> wrote:
That made it clear, thanks again. I'm sure it will be helpful for other developers either  in the future.

Umutcan


On 15-03-2013 20:29, Jeremy J Carroll wrote:
I did not find this a rookie question at all.

This seems to get to the heart of some of the real difficult issues in Semantic Web.

My perspective is different from yours, and a resource description that I author is a description of the resource from my perspective; a resource description that you author is a description from your perspective.

If I have some detailed application that depends in some subtle way on my description, I may want to ignore your version; on the other hand, a third party might want to use both of our points of view.

One way of tacking this problem is to have three graphs for this case:

Gj, Gu, G=

Gj contains triples describing my point of view
Gu contains triples describing your point of view
G= contains the owl:sameAs triples

Then, in some application contexts, we use Gj, sometimes Gu, and sometimes all three.

Jeremy




On Mar 15, 2013, at 11:02 AM, Umutcan ŞİMŞEK <s.umutcan@gmail.com<mailto:s.umutcan@gmail.com>> wrote:
Thanks for the quick answer : )

So this issue is that subjective for contexts which allows to use owl:sameAs to link resources  if they are not semantically even a little bit related in real world?

Sorry if I'm asking too basic questions. I'm still a rookie at this :D

Umutcan


On 15-03-2013 19:38, Kingsley Idehen wrote:
On 3/15/13 1:05 PM, Umutcan ŞİMŞEK wrote:
My question is, does LODD use owl:sameAs properly? For instance, are those two resources, dbpedia:Metamizole and drugbank:DB04817 (code for Metamizole), really identical? Or am I getting the word "property" in the paper wrong?
The question is always about: do those URIs denote the same thing? Put differently, do the two URIs have a common referent?

## Turtle ##

<#i> owl:sameAs <#you>.

## End ##

That's a relation in the form of a 3-tuple based statement that carries entailment consequences for a reasoner that understand the relation semantics. Through some "context lenses" the statement above could be accurate, in others totally inaccurate.

Conclusion, beauty lies eternally in the eyes of the beholder :-)