W3C home > Mailing lists > Public > www-rdf-interest@w3.org > April 2001

Re: URIs / URLs

From: Lee Jonas <ljonas@acm.org>
Date: Fri, 13 Apr 2001 06:38:44 +0100
To: <www-rdf-interest@w3.org>
Message-ID: <PJEHIGCEAMAHEAPOOFBEOEJBCBAA.ljonas@acm.org>
Aaron Swartz <aswartz@swartzfam.com> wrote:

>Lee Jonas <lee.jonas@cakehouse.co.uk> wrote:
[snip]
>>>> 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.

Fair point.

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

Yes, you can describe versions via metadata. I expressed a wish that it was
done more fundamentally, but this was not something I have been thinking
about (or scrutinising) for any period of time.  If it wasn't so academic,
it might be worth some effort investigating further, maybe just to show that
it probably would be unworkable anyway.

In its absense I may yet define an RDF schema for representing resource
versioning and relationships amongst resource version representations.

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

Consider DHCP.  An identifier, such as "www.w3.org" could map to IP address
212.68.103.12 one day, and to 212.72.1.18 the next.  If you refer to the
resource using www.w3.org, it gets dynamically resolved to the currently
valid address.

In the same way, vancing the URN urn:sadfsadfasdfsafas could be dynamically
resolved to return 'mailto:ljonas@acm.org' or
'mailto:lee.jonas@cakehouse.co.uk' - it provides an extra level of
indirection that shields users of identifiers from changes to the "location"
of representations of the same resource.

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

regards

Lee
Received on Friday, 13 April 2001 01:36:37 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:51:48 GMT