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

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

>TimBL
>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
>document.

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

Pat
-- 
---------------------------------------------------------------------
IHMC					(850)434 8903   home
40 South Alcaniz St.			(850)202 4416   office
Pensacola,  FL 32501			(850)202 4440   fax
phayes@ai.uwf.edu 
http://www.coginst.uwf.edu/~phayes

Received on Friday, 15 February 2002 16:53:43 UTC