Re: National Identification Number URIs ( NIN URIs )

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)?

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.

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  :-)


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
>>>
>>>
>>>   
>>>       
>
>
>   


-- 

Regards,

Kingsley Idehen	      
President & CEO 
OpenLink Software     
Web: http://www.openlinksw.com
Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca: kidehen

Received on Monday, 8 March 2010 12:23:39 UTC