W3C home > Mailing lists > Public > public-lod@w3.org > March 2010

Re: National Identification Number URIs ( NIN URIs )

From: Hugh Glaser <hg@ecs.soton.ac.uk>
Date: Mon, 8 Mar 2010 12:34:54 +0000
To: Kingsley Idehen <kidehen@openlinksw.com>
CC: Aldo Bucchi <aldo.bucchi@gmail.com>, Linked Data community <public-lod@w3.org>
Message-ID: <EMEW3|7a541f03abab57172fdd06d4b967ce2am27CYv02hg|ecs.soton.ac.uk|C7BA9F6E.109C9%hg@ecs.soton.ac.uk>
Hi Kingsley,


On 08/03/2010 12:23, "Kingsley Idehen" <kidehen@openlinksw.com> wrote:

> Hugh Glaser wrote:
>> Hi.
>> 
>> On 08/03/2010 01:15, "Kingsley Idehen" <kidehen@openlinksw.com> wrote:
>> 
>>   
>>> Aldo Bucchi wrote:
>>>     
>>>> Hi,
>>>> 
>>>> All countries have a National Identification Number scheme ( NIN ).
>>>> http://en.wikipedia.org/wiki/National_identification_number
>>>> 
>>>> Also, all countries have code points in different schemes.
>>>> 
>>>> So, can't we combine both to create a de-facto URI for people based on
>>>> country ids?
>>>> 
>>>> For example: http://dbpedia.org/nin/cl/14168212
>>>> That would be me based on my Chilean NIN.
>>>> 
>>>> Is there some namespace for this already?
>>>>   
>>>>       
>>> Don't use DBpedia namespace in this manner.
>>> 
>>> Why not encourage people to do this:
>>> 
>>> urn:country.person.id.{national-id}
>>>     
>> Although superficially a nice idea, for me the answer to your question would
>> be that it would not longer be Linked Data.
>> Design Issue Number 2 (http://www.w3.org/DesignIssues/LinkedData.html) says:
>> "Use HTTP URIs so that people can look up those names."
>> I wholeheartedly agree with this statement.
>> doi, urn suck.
>> It is hard to work out what they mean (resolve), and even if I can it is not
>> a distributed (web) system.
>>   
> Hugh,
> 
> Wow! How on earth can you take such a simplistic view of my comments? Do
> I really make comments that are so inherently contradictory, bearing in
> mind my timeless passion for open data access (pre- and post- Linked
> Data era)?
Must admit I was puzzled :-)
> 
> I am basically saying:
> 
> 1. Don't get bogged distracted or bogged down with the "Authority"
> component of HTTP scheme based Data Object Identifiers at this stage
> 2. Give each Data Object and Identifier using URNs
> 3. Load the data into an RDF database
> 4. Publish as Linked Data via Re-write Rules i.e. make a mapping layer
> based on Generic HTTP URIs such  that the Data Objects Relationship
> graph is navigable via HTTP.
Maybe I am still misunderstanding, but I think that you rare still saying
that a urn/doi approach is compatible with Linked Data, or at least is not
harmful.
I think differently.
urn/doi is harmful - once it comes into existence, it is very hard to avoid
the problems of people using them, and then you have to start working out
where the server might be.
I am quite happy with people passing round http://foo.com/bar/urn:baz.quex,
as this is resolvable; I just don't want things that don't use http.

I think Bernhard's questions suggest that your comments might have been
misinterpreted by him as I did, that urn: is acceptable as a Linked Data
URI.
Were you saying that?
> 
> Steps 1-4 delivers a safe mechanism for delivering Linked Data Objects
> via Views. Remember, Views functionality is intrinsic to any DBMS realm,
> which includes Linked Data.
>> But I do agree that subverting dbpedia for this would not be a good thing to
>> do.
>> 
>> Maybe okkam or another project/company wants to step into the gap?
>>   
> My suggestion fills the gap, the Data Objects, their Relations, and any
> other relevant information will be HTTP accessible as per any other
> piece of Linked Data. Most important of all, we negate "Authority"
> issues re. HTTP URIs.
> 
> urn:country.person.id.{national-id} can be published from a Linked Data
> Space hosting the Data Objects as:
> <http://<cname>/country/person/id/{national-id}> (slash terminated) or
> <http://<cname>/country/person/id/{national-id}>#this (# terminated).
> 
> Virtuoso's in-built Linked Data Deployment functionality can handle the
> above, ditto products like Pubby. Its not a big deal at all.  This is
> just about SPARQL DESCRIBE (or CONSTRUCT) as part of the implementation
> details for deployment.
> 
> We have Linked Data and HTTP based Linked Data via this approach  :-)
Sorry to be purist, but I can't seem to distinguish between Linked Data and
HTTP based Linked Data - it just isn't Linked Data if it isn't http.
Best
Hugh
> 
> 
> Kingsley
>> Best
>> Hugh
>>   
>>> The data can then live in an RDF store that can make de-referencable
>>> URIs via re-write rules when it comes to the Linked Data publishing.
>>> This also means the data can ultimately live in a place controlled by
>>> the Chilean govt. without much hassle, when its ready etc..
>>>     
>>>> When you have real world problems, like we have now in Chile, it is
>>>> simple solutions like these that would make integration easier.
>>>>   
>>>>       
>>> Yes, but do it right from the onset as per tip above :-)
>>> 
>>> Kingsley
>>>     
>>>> For example, we have assigned a NS for chilean IDs. But some of the
>>>> missing people here are tourists and we the only IFP we have is their
>>>> national ID ( not emails ).
>>>> 
>>>> Thx,
>>>> A
>>>> 
>>>> 
>>>>   
>>>>       
>> 
>> 
>>   
> 
Received on Monday, 8 March 2010 12:35:42 UTC

This archive was generated by hypermail 2.3.1 : Sunday, 31 March 2013 14:24:25 UTC