Re: What if an URI also is a URL

Am Donnerstag, den 13.09.2007, 18:54 +0200 schrieb Richard Cyganiak:
> On 13 Sep 2007, at 10:32, Reto Bachmann-Gmür wrote:
> > e.g.
> > <http://Example.org/weather/ch/Bern/archive/2007-09-13> is probably  
> > not
> > identifying the same resource as <http://Example.org/weather/ch/Bern>
> > even if (today) you would get the same representation.
> 
> Well, I'd say that the content provider acts against his own  
> interests if he publishes the same representation at both these URIs.

We're starting to look at it from the other end now, don't we?

The one thing is: If *I* need to coin a URI for something, which one
should I choose. In this context, the question was about which URI to
choose for a site/web service like a blog: it's main page (which is an
information resource iself, so this would be ambiguous) or some
303-style URI or thelike (which turns out to feel right, but doesn't
work well with established practices).

The swiss weather-example seems different to me:
>From an author's perspective (author=the guy who first uses this URI to
identify something in the RDF he writes), it's pretty clear which one to
choose, even if both URIs should bring up the same document at a given
date. 
>From a RDF-application's point of view, it's even more simple:
The URI is what the RDF data says it is. Both URI might point to the
weather in Bern, Switzerland, represented as HTML. Still, if all the RDF
data in my triple store say that <http://Example.org/weather/ch/Bern> is
a red truck and <http://Example.org/weather/ch/Bern/archive/2007-09-13>
is a female human named Agnetha, well, then thats what it is. It might
be an error, yes, but until I find out myself that clouds in Bern can't
sing "The Winner Takes It All", it will remain this way.


The main trouble with URIs is not finding out what they identify when
you stumble across them in some RDF... thats trivial, even machines can
do it.
The trouble is finding the right ones for RDF you write yourself.
"Right" in this context means there's a chance of other's using the same
URI for the same thing, which *should* be easier for things 'on the web'
than in general. Or so I thought before...

Oskar



> It's a good practice to explain the nature of the resource somewhere  
> within the representation. So somewhere in the first one from your  
> example there might be the text
> 
> “This is the archived weather report of 13 September 2007 for the  
> city of Bern, Switzerland.”
> 
> while in the second one we might find
> 
> “This is the current weather report for the city of Bern, Switzerland.”
> 
> Or some equivalent RDF triples if we talk about Semantic Web content.
> 
> In the absence of such an explanation, an agent has little hope to  
> find out what he's looking at. He cannot use the URI to reliably  
> refer to anything, because he doesn't know what it will return  
> tomorrow. Bookmarking it, linking to it, or passing it on to someone  
> else, becomes a perilous affair. After all, I'd really like to know  
> if I'm looking at today's or yesterday's weather report. A weather  
> report that doesn't give me that information won't be popular.
> 
> Thus, both content consumer and content provider benefit from  
> representations that explain the nature of the resource.
> 
> A second, less helpful choice would be external information about the  
> resources. For example, there might be an RDF file or HTML file at  
> <http://Example.org/weather/> that tells us what all the individual  
> URIs refer to.
> 
> Richard
> 
> 
> >
> > Cheers,
> > Reto
> >
> 
> 
>

Received on Thursday, 13 September 2007 22:02:03 UTC