Re: URIs / URLs

Lee Jonas <lee.jonas@cakehouse.co.uk> wrote:

>> Resources do not evolve -- their representations (or network entities) do.
> My interpretation is: resources are things that can evolve, representations
> are distinct "snapshots" of a particular resource state, conceptually taken
> at the point of access (this then includes representations of resources
> provided by CGI scripts, etc).  A W3C Working Draft evolves, the html doc
> retrieved from its "latest version" URL gets a representation of the latest
> version of the Working Draft.

Sorry. You're right -- of course resources evolve. I think what I really
meant to say was that the definition of a resource does not evolve.

>>> The first issue could have been addressed more formally (and hence
>>> consistently) with a simple versioning scheme.
>> What about ETags?
> I am not familiar with these.  Can you give me some pointers?

They're a part of HTTP/1.1:

http://www.w3.org/Protocols/

>>> This would have alleviated the problem of instantly breaking third party
>>> links (or invalidating metadata semantics) when you change a resource.  Yes
>>> your links must change to reflect new versions of things you reference, but
>>> these changes could be a graceful migration, not an abrupt crash.
>> How do versions fix changes in resources? It seems they just break things
>> for the 94% (as previously cited) of links that actually work correctly.
> They don't fix changes in resources (and hence changes to their
> representations), they make it less destructive for others to have links to
> fragments in your documents, which you may subsequently change / delete.

I guess I just don't see how the versioning system will work.

> I am not proposing any changes to URL.  This is more of an argument for
> using URNs to identify resources (in a more abstract fashion), where
> appropriate.  Then the mapping to a URL locating a specific representation
> can be performed dynamically.

I guess I don't see what the benefit of using a URN.

>> Why should things without a "location" use a URN? They can still be
>> described can't they. Folks! Just because it's a URN doesn't mean it's
>> anything special. It still represents a resource, even if it's in the
>> Fooawackyak scheme.
> Reserving URLs to identify things that you can access representations of has
> certain advantages.  Not least is keeping at least 94% of them vancable.  It
> seems like a simple distinction to me.  In an ideal world, URLs are always
> vancable, URNs may be so, but not necessarily.

OK, but we don't live in an ideal world. Even if we did, what would be the
benefits of this system, since nothing clear is gained from use of a URN.

>>> These are compounded with the fact that the resource can be one of many
>>> formats and there is no clear way to distinguish them from the URL iself. A
>>> resource such as http://mydomain/mypic.png may safely be assumed to be a png
>>> graphic, but what about the resource at the end of http://mydomain/mydir/ ?
>> Resources don't usually have formats. That's why there's content
>> negotiation.
> Although it would sometimes be unavoidable, wouldn't it be nice to find out
> the type of a representation without having to negotiate every time?

I thought the point of content negotiation was to _choose_ the correct
format, not to discover it.

>>> 3) Data quality will be poorer if it is hard for software to detect a
>>> resource change.  Transience is bad news if you are going to store facts
>>> about something that subsequently changes.
>> Yes, RDF does not deal with time very well, but this is, IMO, an RDF problem
>> not a URI one.
> It is a fundamental aspect of the way URLs are defined to be used.  They
> *locate* (note I did not say *identify*) representations (snapshots of
> state) of underlying resources, not the resources themselves.  When
> resources change, new representations may appear at the same and/or
> different locations.

Sure, but this doesn't stop you from making a URI for a version of the
resource, if it doesn't have one already. Here's an example in RDF/XML:

<rdf:Description rdf:ID="version2">
    <s:date>2001-04-12</s:date>
    <s:item rdf:resource="http://example.org/page">
</rdf:Description>

With proper definitions of the s: scheme, I have now created a URI for the
version of that page on today's date.

> The only way RDF could satisfactorily deal with this
> is if it described the resources directly by using URN identifiers, which
> could be subsequently mapped to a URL locating an appropriate
> representation.

Err, I don't see how this solves the problem. You've just shifted it -- now
the problem is that the URN points to the wrong URL, instead of the URL
returning the wrong representation.

Cheers,

-- 
[ Aaron Swartz | me@aaronsw.com | http://www.aaronsw.com ]

Received on Thursday, 12 April 2001 17:44:47 UTC