W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > February 2002

Re: URIs vs. URIviews (was: Agenda for RDFCore WG Telecon 2002-02-15)

From: Pat Hayes <phayes@ai.uwf.edu>
Date: Fri, 15 Feb 2002 16:53:45 -0500
Message-Id: <p05101451b893327e77e5@[]>
To: Aaron Swartz <me@aaronsw.com>
Cc: w3c-rdfcore-wg@w3.org
>On 2002-02-14 3:08 PM, "Dan Connolly" <connolly@w3.org> wrote:
>>>  I really can't agree with this. It's our problem that RDF uses this
>>>  non-standard piece of Web architecture, and in doing so has incurred all
>>>  sorts of problems. If we're going to be the Resource Description Framework,
>>>  we need we're actually describing resources. My ideal resolution would look
>>>  like:
>>>   o The WG resolves that the use of absolute URIs with fragment IDs is a
>>>     to identify Web resources is relatively incompatible with current Web
>>>     architecture.
>>  ?????
>>  Er.. it's the very heart of web architecture:
>>  The principle that anything, absolutely anything, "on the Web"
>>  should identified distinctly by an otherwise opaque string
>>  of characters (A URI and possibly a fragment identifier) is
>>  core to the universality.
>>  -- http://www.w3.org/DesignIssues/Architecture
>RFC2396 would agree with you except for the "and possibly a fragment
>identifier" bit. Same with Roy Fielding's dissertation (which clearly
>explains the reasons why this was an explicity design decision) and probably
>the many people who have invested in URI syntax, and don't want to go back
>and fix their HTTP clients, proxies, servers or other software (and maybe
>hardware) to support this addition of fragment identifiers.
>>>   o We recommend that RDF users refrain from using '#' in their Resource
>>>     identifiers and namespaces. RDF developers and tool creators may present
>>>     a warning to the user when using resource identifiers with '#' in them.
>>  Why? rdf:type has a # in it, after all. How can they avoid it?
>>  Why would they?
>Perhaps I wasn't clear. I meant ones that they were creating (like if I
>wanted to come up with a namespace for my new vocabulary set, or my poodle).
>>  I don't see any explanation of a problem here.
>We've discussed it several times on and off list, but I could reitierate it
>for you. The issue is that:
>a) In the REST architectural model (which the TAG seems to be agreeing
>about) fragment identifiers only make sense within the context of an HTTP
>response (a bag of bits). They identify parts of a document, not general
>Resources like full URIs.

Wait a minute. Are you saying that every 'genuine' resource must be 
an document?? And that part of a document cannot be a resource??? 
That is an impossibly narrow view of 'resource'.

>b) Deployed code doesn't support fragment identifiers as first-class objects
>-- I can't ask an HTTP proxy about them, I can't query an HTTP server about
>them, etc.
>And this is by design...
><MikeM> fragmetns are client side thing.....
>  - in #rdfig
>Exactly! RDF has created this problem by taking what in Web Architecture is
>designed to be a client-side thing, the last step of resolution.

RDF hasn't done it. The entire SW effort needs this. DAML and OWL 
need this. We all need this.

>explained this at the first W3C technical plenary: "[an HTTP client] puts
>the fragment ID in its pocket".
>Also, in his Axioms of Web Architecture: The Web Model[1], Tim explains how
>a client holds on to the fragment ID so that it can pass it to the
>presentation object.
>[1] http://www.w3.org/DesignIssues/Model
>He's even got a nice diagram to explain it. I'm not sure how much clearer it
>can be that a fragment only makes sense in the context of presenting a

This is an impossibly narrow HTML-centric view  of the world. There 
are more things on the Web than just DOCUMENTS.

IHMC					(850)434 8903   home
40 South Alcaniz St.			(850)202 4416   office
Pensacola,  FL 32501			(850)202 4440   fax
Received on Friday, 15 February 2002 16:53:43 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:53:55 UTC