RE: Person Identifier

> From: Andreas Langegger
> [ . . . ]
> Another suggestion whould be to inject a protocol hint into the URI by
> the convention of a special sub-domain like
> http://doi.yourdomain.tld/somePath/resource/foo

> From: Andreas Langegger
> [ . . . ]
> What if we find a way to "optionally" make one to find out more about
> the resource and include the type in the URI?

That could be done.  The technique of defining a URI prefix is described here:
http://dbooth.org/2006/urn2http/

> [ . . . ]
> First I also disliked the idea that HTTP URIs should represent non-
> informational resources. The fact, that an URI is usually representing
> a web page is so deeply anchored in our thinking that it just sounds
> too obscure.

Yes, that is a disadvantage of HTTP URIs versus URNs . . . and nearly the *only* disadvantage.  This paper
http://dbooth.org/2006/urn2http/
provides an informal proof-by-construction that HTTP URIs can have greater capability than URNs in nearly all cases.

> I think the remaining argument against URIs everywhere + HTTP only is
> that you may have to do thousands of GET requests for a large KB,

But you are never *required* to do a GET.  The follow-your-nose convention gives you the *possibility* of finding useful information when you do a GET, but: (a) there is no guarantee that it will be successful; and (b) you are not required to try.  But even if you do want to GET useful information, the app can be smart about it, using caching and other techniques to avoid unnecessary GETs.



David Booth, Ph.D.
HP Software
+1 617 629 8881 office  |  dbooth@hp.com
http://www.hp.com/go/software

Opinions expressed herein are those of the author and do not represent the official views of HP unless explicitly stated otherwise.

Received on Monday, 21 April 2008 21:33:06 UTC