Re: Person Identifier

On 21/04/2008, Mark Birbeck <mark.birbeck@x-port.net> wrote:
>
>  Hi Richard,
>
>  > [...]
>
> >
>  >  The problem with URNs is that applications need to be modified or rewritten
>  > before they can know what a URN identifies. That's quite a high cost, and is
>  > one of the main reasons why many URN schemes never caught on -- not enough
>  > developers bothered to hardcode support for them into existing applications.
>  >
>  >  Naming schemes that piggy-bank on HTTP don't have this problem, HTTP
>  > support is ubiquitous, and applications can learn that your URI identifies a
>  > person by making an HTTP request to retrieve a description of the identified
>  > thing.
>
>
> I'm afraid this is simply not true, and is actually to turn RDF on its head.
>
>  What a URI identifies has nothing to do with the protocol in 'pure'
>  RDF terms. In the following, my URI identifies a 'FOAF person',
>  regardless of anything that might be retrieved over HTTP:
>
>   <http://example.org> a foaf:Person .

It depends where your trust lies. RDF is quite up front about being an
open-world logic system, so applying closed world logic statements to
it will inevitably cause ambiguities if you are willing to accept
possibilities which were not in your narrow initial scope of
knowledge. If you retrieve the URL and find that it corresponds to a
web page with an explicit RDF type declaration that is "disjoint" with
your first known statement who do you trust? You have to accept one
statement or the other, as accepting neither statement isn't really
your goal.

URN's will have the same problems if you attempt to make them
discoverable. Unless you have a non-textual format for representing
RDF in then you *could* always say that resolving the identifier got
you a document or a data structure, but honestly who is going to be
that pedantic if they actually want to utilise RDF for useful
purposes. Do you accept that documents can be descriptions of real
world objects without ambiguities relating to the structure that the
document/data structure is in? Most of the current discussion is about
people getting descriptional data structures mixed up with the real
world things they are attempting to describe (and yes, there are
various ways to combat it but personally I like the rdf:type from a
trusted source to be the conclusive description without worrying about
the file format I happen to be looking at ;-) )

>  Now, if these URIs didn't also serve as a means for retrieving
>  documents, then that would be the end of the story. But of course we
>  know that it isn't, and that sometimes these URIs also identify
>  web-pages. Given this fact, you could quite reasonably argue that a
>  URN is better, because when you use a non-retrievable URI, there is no
>  ambiguity; i.e., it is simply impossible for a URI to represent both a
>  person and a web-page if it doesn't begin with "http:".
>
>  Which is why I say that getting the type of a resource by making an
>  HTTP request is to turn RDF on its head. It's to place a particular
>  problem caused by using one class of URIs (those that begin "http:")
>  right at the centre of RDF, when RDF itself is completely agnostic
>  about the detail of resource identifiers.

Why is it a problem to want to resolve URI's? And why are http URI
resolutions special?

>  In my opinion, it's not a great idea to build systems on the basis of
>  making a web request to check the 'type' of a URI. I think it's far
>  better to either use some non-HTTP scheme to identify the URI, or to
>  tack a fragment identifier on the end.

What does tacking a fragment identifier on the end of a URI *actually*
do? Are people embedded in web pages? Are web pages conglomerates of
people and text?


>  But of course, I understand that people do see the need for such an
>  architecture, and I also know that this debate will run and run. :)
>

Never doubted that! It is very vigourous discussion for a topic that
has been going around forever and a day though.

Peter

Received on Monday, 21 April 2008 22:11:48 UTC