W3C home > Mailing lists > Public > semantic-web@w3.org > April 2008

Re: Person Identifier

From: Andreas Langegger <al@jku.at>
Date: Mon, 21 Apr 2008 12:02:25 +0200
To: "Mark Birbeck" <mark.birbeck@x-port.net>
Message-Id: <B81DE7EF-2422-4F73-B246-C86E72A9AEF3@jku.at>
Cc: "Richard Cyganiak" <richard@cyganiak.de>, "Bent Rasmussen" <incredibleshrinkingsphere@gmail.com>, semantic-web@w3.org

hi there,

interesting opinions here. Both I can acquire taste for. I think the  
problem that I need an HTTP request first is less and less there from  
now on because of mobile access everywhere. The fact, that I can  
figure out anything about a thing by doing a simple GET request is  
very very appealing. I think it makes things really easier.

Another suggestion whould be to inject a protocol hint into the URI by  
the convention of a special sub-domain like

This could satisfy both opinions.


On Apr 21, 2008, at 11:44 AM, Mark Birbeck 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 .
> 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.
> 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.
> 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. :)
> Regards,
> Mark
> -- 
> Mark Birbeck
> mark.birbeck@x-port.net | +44 (0) 20 7689 9232
> http://www.x-port.net | http://internet-apps.blogspot.com
> x-port.net Ltd. is registered in England and Wales, number 03730711
> The registered office is at:
> 2nd Floor
> Titchfield House
> 69-85 Tabernacle Street
> London
> EC2A 4RR

Dipl.-Ing.(FH) Andreas Langegger
Institute for Applied Knowledge Processing
Johannes Kepler University Linz
A-4040 Linz, Altenberger Straße 69
Received on Monday, 21 April 2008 10:03:05 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 07:42:04 UTC