- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Thu, 21 Mar 2013 10:27:40 -0400
- To: public-semweb-lifesci@w3.org
- Message-ID: <514B18DC.8040804@openlinksw.com>
On 3/20/13 10:58 PM, David Booth wrote: > > Thus, to be very clear, under the existing RDF Semantics > specification, a given URI does *not* necessarily map to only one > resource. True, but I don't think the statement above always provides the clarity intended. "Resource" is a synonym of "Entity" as *now* clearly stated in the latest RDF concepts guide [1]. Once we get over the conflation inherent in "Resource" and look towards "Entity" the issue starts to get much clearer, as exemplified by RDF based Linked Data [2] and its specific use of URIs to denote "Entities" while also identifying their "Descriptor Documents". All "Resources" aren't of the same medium. The Web, Internet are mediums distinct from the medium we *refer to* as the real-world. Thus, the claim that everything is a "Resource" without medium specificity is one of the ultimate recipes for unproductive debate and confusion, as a zillion mail threads over the years have demonstrated. In the context of RDF, a URI denotes an Entity. In the context of RDF based Linked Data, a URI denotes an Entity in a manner that enables it resolve to a Web Document (denoted by its own URI which is usually a URL) that describes the denoted entity (aka. URI referent) . Links: 1. http://www.w3.org/TR/rdf11-concepts/#resources-and-statements -- showcasing the critical "Resource" fix 2. http://twitpic.com/cbk8ul -- illustrating HTTP URI duality and the Semiotic triangle . -- Regards, Kingsley Idehen Founder & CEO OpenLink Software Company Web: http://www.openlinksw.com Personal Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca handle: @kidehen Google+ Profile: https://plus.google.com/112399767740508618350/about LinkedIn Profile: http://www.linkedin.com/in/kidehen
Attachments
- application/pkcs7-signature attachment: S/MIME Cryptographic Signature
Received on Thursday, 21 March 2013 14:28:03 UTC