- From: Lee Jonas <ljonas@acm.org>
- Date: Fri, 13 Apr 2001 06:38:44 +0100
- To: <www-rdf-interest@w3.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 UTC