- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Fri, 28 Oct 2011 09:20:32 -0400
- To: www-tag@w3.org
- Message-ID: <4EAAAC20.8010704@openlinksw.com>
On 10/28/11 3:59 AM, Larry Masinter wrote: > (stuck in my drafts folder) > > " The specification governing Uniform Resource Identifiers (URIs) [rfc3986] allows URIs to mean anything at all" > can be read incorrectly. A spec usually "allows" something by enabling it, providing a mechanism for accomplishing it. > of RFC 3986 does not itself enable or provide a mechanism for URIs to "mean anything at all", it just doesn't make restrictions that disallow that. ("tdb:" provides a mechanism, for example.) > > I’m not sure what to do with this. Maybe just "allows a URI to mean anything at all, or at least does not restrict the meaning". A URI is an Identifier. The letters U-R-I stand for: Uniform Resource Identifier. Thus, is cannot mean anything. It simply means URIs can Identity anything. > > > "To use a URI to mean something, an agent (a) selects a URI, (b) provides a definition of the URI in a manner that permits discovery by agents who encounter the URI, and (c) uses the URI." > > I don't agree with the order of (a) and (b). I think the order is more like (b) then (a), where (b) is "providing information which might be identified via a URI" and (a) is "putting together the URI which has the definition that leads to the meaning intended". I really believe we are making this more complex that it needs to be. An Identifier is a mechanism for Identifying. A URI is an Identifier. Kingsley > > Larry > -- > http://larry.masinter.net > > > -----Original Message----- > From: www-tag-request@w3.org [mailto:www-tag-request@w3.org] On Behalf Of Jonathan Rees > Sent: Saturday, June 25, 2011 9:13 AM > To: www-tag@w3.org > Subject: Comments solicited: "Providing and discovering definitions of URIs" > > Comments solicited: "Providing and discovering definitions of URIs" > > (message being sent to www-tag, bcc: public-lod and semantic-web) > > As most of you know, the 9-year-old "httpRange-14" turf war is an > annoyance and embarrassment in efforts to develop RDF, linked data, > the Semantic Web, and Web architecture. > > As a step toward getting closure I've prepared a document (with > the help of the TAG and the AWWSW task group): > > http://www.w3.org/2001/tag/awwsw/issue57/20110625/ > > which attempts to record the variety of approaches that have been > offered. I have attempted to record in a neutral way all the main > proposals that have been put forth and present them in a way that > permits them to be compared. I'm sure I have failed to be completely > neutral, but if so I'm confident you will tell me. > > How to actually get closure is yet to be determined, but a first step > might be to get all the relevant information collected in this > document so that we all know what the issues and opportunities are. > > This document is for informational purposes only and its future is > not yet determined. I would have polished it a bit more but given > current debate on www-tag and public-lod I felt it was more important > to get it out than to tie up loose ends. > > Please comment on the www-tag@w3.org list. I will revise the document > based on comments received. > > If you wish to review the debate please see > http://www.w3.org/wiki/HttpRange14Webography > > Best > Jonathan > > Abstract > > The specification governing Uniform Resource Identifiers (URIs) > [rfc3986] allows URIs to mean anything at all, and this unbounded > flexibility is exploited in a variety contexts, notably the Semantic > Web and Linked Data. To use a URI to mean something, an agent (a) > selects a URI, (b) provides a definition of the URI in a manner that > permits discovery by agents who encounter the URI, and (c) uses the > URI. Subsequently other agents may not only understand the URI (by > discovering and consulting the definition) but may also use the URI > themselves. > > A few widely known methods are in use to help agents provide and > discover URI definitions, including RDF fragment identifier resolution > and the HTTP 303 redirect. Difficulties in using these methods have > led to a search for new methods that are easier to deploy, and perform > better, than the established ones. However, some of the proposed > methods introduce new problems, such as incompatible changes to the > way metadata is written. This report brings together in one place > information on current and proposed practices, with analysis of > benefits and shortcomings of each. > > The purpose of this report is not to make recommendations but rather > to initiate a discussion that might lead to consensus on the use of > current and/or new methods. > > (this is TAG ISSUE-57 / ACTION-579) > -- Regards, Kingsley Idehen President& 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 Friday, 28 October 2011 13:20:50 UTC