Re: Best practices using URIs

On 13 Nov 2003, at 15:57, Nick Matsakis wrote:

>
> On Thu, 13 Nov 2003, Stefano Mazzocchi wrote:
>
>>   urn:isbn:0465026567
>>   http://www.iso.org/ISBN/0465026567
>>
>> even if treated as URI, ... the second *could* be used as a URL to
>> lookup and discovery information on that particular resource, while 
>> the
>> first does *NOT* include a methodology to do the above and it's left 
>> as
>> application dependent.
>
> Over and over I have seen RDF with "http:" URLs, and it is extremely 
> rare
> for such URLs to resolvable to anything besides '404 Document not 
> found'.
> The second URL you provide continues this trend.  This may be a losing
> battle, but it seems easier to design applications where the vast 
> majority
> of URIs were not resolvable, but the occasional one was. It would be in
> this case that your application could know it was appropriate to go 
> out on
> to the internet for more information.

Fair enough. At the end, it's a matter of choice.

Would be rather painful, though, in a future of dereferencable URIs and 
agents crawling them, finding yourself on the other side of the river 
because you trusted your present more than a potential future.

When discussing about this with TBL, I questioned the use of years in 
W3C reccommendation namespace URIs, suggesting that

  http://www.w3c.org/ns/xhtml/1.0

would have been better than the current

  http://www.w3c.org/1999/xhtml

and he replied "in a hundred years from now, xhtml could have a 
different meaning".

I admit I tought this was rather pretentious to say... but then thought 
about those COBOL programmers, in the 60's, using two chars for dates.

History shows rather evidently how decisions you make today can harm 
you decades from now.

> If you are creating a URI for a book, such as "urn:isbn:0465026567" it
> only takes one more statement to give a resolvable location for that 
> item.
> For example:
>
> urn:isbn:0465026567 :pdfVersionAt http://myserver.mydomain/...
>
> Most of the other metadata associated with the item, such as its title,
> page count, authors, etc. are in no way dependent on the fact that a
> version can be downloaded from a particular server at the moment.  If, 
> in
> the future, that version cannot be retrieved, the single statement can 
> be
> removed, leaving the rest of the metadata intact.

I (nor anybody, for that matter) never stated *what* should be located 
at the other side of that URI. This has been the most active debate in 
the XML community after the element vs. attribute religious wars.

My point is: if you don't dereference, a URN and an HTTP URI are just 
equal: unique strings.

With a URN you will *never* be able to dereference directly... or any 
dereferencing mechanism will be an HTTP clone.

With an HTTP URI, you will be able to dereference right away, would the 
need or uses emerge, with no need for another lookup and discovery 
architecture.

That's all.

--
Stefano.