W3C home > Mailing lists > Public > uri@w3.org > June 2009

Re: URI for abstract concepts (domain, host, origin, site, etc.)

From: Erik Wilde <dret@berkeley.edu>
Date: Sat, 27 Jun 2009 16:25:55 +0200
Message-ID: <4A462BF3.9030701@berkeley.edu>
To: Xiaoshu Wang <wangxiao@musc.edu>
CC: Dan Brickley <danbri@danbri.org>, Larry Masinter <LMM@acm.org>, "'Pat Hayes'" <phayes@ihmc.us>, "'Eran Hammer-Lahav'" <eran@hueniverse.com>, "'Dan Connolly'" <connolly@w3.org>, "apps-discuss@ietf.org" <apps-discuss@ietf.org>, "www-tag@w3.org" <www-tag@w3.org>, "'URI'" <uri@w3.org>

Xiaoshu Wang wrote:
> There should not be.  I have trying this many times.  A URI, fragmented 
> or not, denotes one thing and its returned representations another.  The 
> former is the content of the later.  The remedy is to define a URI 
> syntax for representation.
> A syntax that I have proposed is to insert a (mime-type) after the # sign.
> Thus,
> "http://danbri.org/foaf.rdf#danbri" denotes a person.
> "http://danbri.org/foaf.rdf#(application/rdf+xml)danbri" denotes an RDF 
> node.
> "http://danbri.org/foaf.rdf#(application/xhtml+xml)danbri" denotes an 
> HTML element ided "danbri

interesting. would that be specific for http-identified resources? if 
not, how would that be supposed to work with URI schemes that do not 
share HTTP's capabilities for transferring content metadata, and 
performing content negotiation? a simple example might be FTP, which is 
similar in nature to HTTP (access to hierarchically organized resources) 
but has no concept of media types.

another thing i am wondering about: aren't fragment identifiers as they 
are currently defined client-side only and specific to the media type 
anyway? that might indicate you are talking not about extending the URI 
syntax, but that of HTTP URI fragment identifiers? there were other 
approaches of doing this (with other goals), one of the issues was how 
to create some framework for fragment identifiers that would be 
uniformly applied to all fragment identifier syntaxes. that one never 
got anywhere, and the window of opportunity is probably closed by now. 
but there the idea was that instead of labeling fragments with the media 
type to which they should be applied (which seems to be what you're 
suggesting), they should follow some base syntax, and thus could be 
designed to be less brittle across media types. HTTP's idea of content 
negotiation (and thus dynamic media type assignment at access time) and 
URI fragment identifiers and their media type specificity always was one 
of the areas where web architecture certainly could need a bit of 


erik wilde   tel:+1-510-6432253 - fax:+1-510-6425814
        dret@berkeley.edu  -  http://dret.net/netdret
        UC Berkeley - School of Information (ISchool)
Received on Saturday, 27 June 2009 14:26:59 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:25:13 UTC