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

SKOS properties only apply to concepts. So if you're describing concepts,
go wild. But they don't cover the world.

Jim


On Fri, Mar 15, 2013 at 5:00 PM, Umutcan ŞİMŞEK <s.umutcan@gmail.com> wrote:

>  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>
> 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>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>
>>> 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 :-)
>>>>>
>>>>>
>>>>
>>
>>
>
>
>


-- 
Jim McCusker
Programmer Analyst
Krauthammer Lab, Pathology Informatics
Yale School of Medicine
james.mccusker@yale.edu | (203) 785-4436
http://krauthammerlab.med.yale.edu

PhD Student
Tetherless World Constellation
Rensselaer Polytechnic Institute
mccusj@cs.rpi.edu
http://tw.rpi.edu