W3C home > Mailing lists > Public > public-semweb-lifesci@w3.org > March 2013

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

From: Oliver Ruebenacker <curoli@gmail.com>
Date: Mon, 18 Mar 2013 06:21:34 -0400
Message-ID: <CAA=X4OAq4Xx-N7iZ=Bnh0-DhJ34xeby+4NKbwVM54dDrKSTQLA@mail.gmail.com>
To: David Booth <david@dbooth.org>
Cc: (wrong string) žİMžEK <s.umutcan@gmail.com>, Kingsley Idehen <kidehen@openlinksw.com>, w3c semweb HCLS <public-semweb-lifesci@w3.org>
     Hello David,

On Sun, Mar 17, 2013 at 9:52 PM, David Booth <david@dbooth.org> wrote:
> On 03/17/2013 10:55 AM, Oliver Ruebenacker wrote:
>>
>>       Hello,
>>
>> On Sat, Mar 16, 2013 at 12:30 PM, David Booth <david@dbooth.org> wrote:
>>>
>>> You are in good company in thinking that a URI always denotes the same
>>> resource, because that is a widespread misconception.  (I call it Myth #1
>>> in
>>> http://dbooth.org/2010/ambiguity/paper.html .)  But it simply is not true
>>> in
>>> the RDF semantics.
>>> [...]
>>> That is precisely why it is helpful to keep different perspectives in
>>> different graphs, as Jeremy suggested.
>>
>>
>>    That's a little bit like saying, since floating-point numbers are
>> not perfectly precise, the 1.376 in my data may not be the same as the
>> 1.376 in your data, and therefore the two values should be kept in
>> separate spaces.
>
>
> I don't follow what you mean.  A floating point number like 1.376 may be
> used as an approximation of some real number, but it is exactly the same
> floating point number in all RDF graphs.

  I'm not talking about how RDF handles floating point numbers. I'm
just using floating point numbers as an example to show how flawed
your logic is. If your logic would hold, that URIs have no meaning
without context, because they are only approximate, then by the same
logic, it would follow that floating-point numbers have no meaning
without context.

     Take care
     Oliver

-- 
IT Project Lead at PanGenX (http://www.pangenx.com)
The purpose is always improvement
Received on Monday, 18 March 2013 10:22:03 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:53:01 UTC