Re: Person Identifier

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
http://doi.yourdomain.tld/somePath/resource/foo

This could satisfy both opinions.

Regards,
Andy

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
http://www.langegger.at

Received on Monday, 21 April 2008 10:03:05 UTC