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

["Wachob, Gabe" <gwachob@visa.com>]

Peter-
	Analyzing and expressing these gaps has been identified by myself
and others as the primary challenge we have in terms of communicating why we
are doing what we are doing, and what the value of our work will be. 

	I've specifically been following Sandro Hawke's RDF identifier
proposal - its interesting to see the attention being paid to the *meaning*
of particular URIs because its an area thats largely been assumed would be
"defined elsewhere" by the RDF folks. The problem is that some URI schemes,
especially HTTP, are being used for multiple purposes, perhaps to a fault,
because there is nothing better, and because there are compelling reasons to
reuse URI schemes as much as possible. I think we can communicate why our
requirements meet the relatively high bar for creating a new URI scheme. But
as you point out, we have to make this case to get any sort of credibility.
And I hope in the next few weeks we start to get there with the
requirements. 

	-Gabe

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