Re: National Identification Number URIs ( NIN URIs )

Hugh Glaser wrote:
> 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 am saying Naming in the purest sense is compatible with Linked Data.

I am also saying Linked Data as per TimBL meme is about HTTP based graph 
traversal i.e. HTTP browsable data.
> 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 think you are not picking up the following vital points:

1. We are creating records in a database
2. We want to make the records and their relations (across Attribute and 
Relationship dimensions) HTTP browseable as an access and general 
interaction option (Forms and Views are intrinsic to any DBMS realm 
offering)
3. We want to make the underlying graph scheme agnostic (yes, HTTP 
browsing is great, but it simply isn't the canonical level re. the 
records in the DBMS).

> 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.
>   
The data will be published with Generic HTTP Identifiers re. HTTP based 
Linked Data oriented access (browsing etc..). This is really the 
fundamental function of a Linked Data Server (e.g. Virtuoso, Pubby, and 
I suspect others I may be unaware of etc..).
> 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?
>   
Of course not :-)

I am talking about how you build a database under emergency 
circumstances where HTTP based Identifiers cannot be the starting point. 
They come into play when providing access to the data via HTTP networks.

>> 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.
>   
In most DBMS systems, Data is actually Linked. This is really an 
important point when using the term: Linked Data, loosely.  I can assure 
you, the term: Linked Data, didn't come into existence as a result of 
TimBL's meme. Hence, my tendency to qualify as: HTTP based Linked Data, 
since that's the essence of his meme, specifically.


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


-- 

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:51:50 UTC