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.

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

>>  b) maintaining backwards-compatibility but
>>  c) lay the ground work for future WGs to fix this bug
> What bug?

The bug that RDF is incompatible with Web Architecture, as explained above.

<MikeM> seriously, RDF's use of frags has caused so many problems.. If RDF
needs something like it that badly then make it a new URI scheme that does
it _right_

-- 
[ "Aaron Swartz" ; <mailto:me@aaronsw.com> ; <http://www.aaronsw.com/> ]

Received on Thursday, 14 February 2002 21:26:35 UTC