W3C home > Mailing lists > Public > www-tag@w3.org > January 2003

Re: RDF & fragment ids; what breaks?

From: Miles Sabin <miles@milessabin.com>
Date: Thu, 23 Jan 2003 08:51:30 +0000
To: www-tag@w3.org
Message-Id: <200301230851.30410.miles@milessabin.com>

Mark Baker wrote,
> On Thu, Jan 23, 2003 at 12:06:27AM +0000, Miles Sabin wrote:
> > Exactly _what_ would that break?
> I'm not sure "break" is the right word.

In the context of my reply to Tim Bray's mail, I think "break" is 
exactly the right word.

Abstract Resources are ... abstract. If they were to all vanish in a 
puff of existential smoke tomorrow no code that was working properly 
before would stop working properly afterwards.

> It would certainly reduce visibility into the message by HTTP
> components that relied on the assumption that the URI in the HTTP
> request line identified the resource being interacted with.

I don't believe it would.

I think that the property you're after is more a result of designing 
network systems with a particular mindset or methodology. It's 
perfectly legitimate to hypothesize abstract Resources if that helps 
you get your job done ... you could think of Resources as RESTs 
equivalent of Newtons frictionless euclidian planes: idealizing 
fictions which act as an organizing principle. Or, for that matter, 
like objects in OO, or functions in functional programming.

But it's absolutely not legitimate to insist that that mindset or 
methodology is the only way of obtaining that useful property, or to 
insist that it's privileged to the exclusion of all else. That _does_ 
break things (in this case RDF), at least politically, by effectively 
ruling out other equally useful approaches.

To make this last claim a little more concrete: RDF needs to have 
mechanisms for disambiguating URIs; but it's close to impossible for  
anyone argue for the addition of those mechanisms if the Web 
Architecture document says that URIs are by definition unambiguous so 
no disambiguation is necessary.


Received on Thursday, 23 January 2003 03:52:02 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:32:36 UTC