OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: RE: [xri] [Fwd: Re: Clarifying what a URL identifies (Four Uses o f aURL)]

The issue of how to use URIs to identify abstract or real-world things (as
opposed to network locations) is a very hot topic these days (this week!) at
the W3C. The TAG list is having very heated discussions on this topic. 

Specifically, there is a document discussing the ambiguities of using HTTP
urls in different contexts (or rather, any single URI scheme in multiple


Definitely a fascinating line of thought that dovetails in some ways with
our motivations. Specifically, relative to this document, I think we'd
describe the XRI effort as a "name indicates meaning" approach to
identifying real world resources.

Also see http://www.w3.org/2002/11/dbooth-names/dbooth-rfc2396-analysis.htm
which reviews rfc2396 (defining URIs) with a similar critical eye (long).


> -----Original Message-----
> From: Peter C Davis [mailto:peter.davis@neustar.biz]
> Sent: Thursday, January 23, 2003 7:19 AM
> To: 'xri@lists.oasis-open.org'
> Subject: [xri] [Fwd: Re: Clarifying what a URL identifies 
> (Four Uses of
> a URL)]
> This prompts me to raise an issue, which i think is incompletely 
> addressed with laisons to other standards bodies:
> I think we need formal language (in the requirements draft) which 
> ecourages the research into complimentary and conflicting resource 
> expression methodologies.
> Having said that, todays mention of outside entities questioning the 
> need/benefits for this TCs output (which drives clarification in the 
> requirements draft), goes a long way to this end.  Clear 
> articulation of 
> the gaps in current resource identifier notations should be 
> included in 
> the introduction.
> The W3C TAG, in particular, is likely to keep a scepticle eye, until 
> these shortcommings are well laid out.
> --- peterd
> -------- Original Message --------
> Subject: Re: Clarifying what a URL identifies (Four Uses of a URL)
> Resent-Date: Thu, 23 Jan 2003 06:42:20 -0500 (EST)
> Resent-From: www-tag@w3.org
> Date: Thu, 23 Jan 2003 11:17:48 +0000
> From: Graham Klyne <GK@ninebynine.org>
> To: Tim Berners-Lee <timbl@w3.org>
> CC: Sandro Hawke <sandro@w3.org>, www-tag@w3.org
> References: <200301212127.h0LLRNA15108@wadimousa.hawke.org>
> At 10:02 PM 1/22/03 -0500, Tim Berners-Lee wrote:
>  >One *can* introduce a new system with a different design
>  >and argue its merits. Sandro has designed an alternative
>  >system http://www.w3.org/2002/12/rdf-identifiers/
>  >which seems consistent and I haven't finished thinking
>  >about - there are things I like about it and things I don't.
>  >But it does address all the questions, I think.
> FWIW, I think Sandro's proposal is consistent with the 
> current state of RDF
> specification, and other views of URIs that have been expressed here,
> except maybe the view that http: URIs (without fragments) 
> should always
> denote documents (I hope I don't misinterpret).  My point of 
> divergence
> with that proposal is the suggestion it should be part of the 
> RDF core,
> because I don't see the necessity for it to be there.
> The formal semantics for RDF does tell us one thing, though:  
> in a given
> interpretation of an RDF graph (document, or collection of documents
> considered together), a given URI must always denote the same single
> thing.  So we can't have a graph in which a URI sometimes 
> denotes a car and
> elsewhere simultaneously denotes a picture.
> #g
> -------------------
> Graham Klyne
> <GK@NineByNine.org>
> -- 
> --- peterd
> Sr Security Architect
> Neustar, Inc.		smtp:   peter.davis@neustar.biz
> (571) 434 5516		jabber: 
> peter.davis@checkov.neustarlab.biz
> <Quote type="random">
> The pursuit of perfection often impedes improvement.
> <Author>George F. Will</Author>
> </Quote>
> PGP Fingerprint:
> 8994 8774 B682 3A04 B304  C4A2 D9DD 7E5B 8AAC 2D00

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC