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

Re: National Identification Number URIs ( NIN URIs )

From: Peter Ansell <ansell.peter@gmail.com>
Date: Tue, 9 Mar 2010 07:16:38 +1000
Message-ID: <a1be7e0e1003081316n33c8a0d5vd203aac8b69f09ba@mail.gmail.com>
To: Bernhard Schandl <bernhard.schandl@univie.ac.at>
Cc: Hugh Glaser <hg@ecs.soton.ac.uk>, Kingsley Idehen <kidehen@openlinksw.com>, Aldo Bucchi <aldo.bucchi@gmail.com>, Linked Data community <public-lod@w3.org>
On 8 March 2010 22:19, Bernhard Schandl <bernhard.schandl@univie.ac.at> wrote:
> Hi,
>
> On Mar 8, 2010, at 10:28 , Peter Ansell wrote:
>
>>> Can you explain in more detail what the problem is with using DOI/URN/...-based identifiers internally, and expose them as de-referenceable HTTP URIs on-the-fly? One can even include a reference to the "plain" URN and thus map distinct datasets to each other based on URNs.
>>
>> To fulfill Linked Data principles you would have to link your HTTP URI
>> directly to the other server's HTTP URI. Linked Data is designed to
>> avoid the issue in your example.
>
> Which issue do you mean?

The issue is that your server doesn't know about the existence of the
statement on the other server. It isn't Linked Data if the two servers
share a URI that is not dereferenceable. Currently, HTTP is the only
directly dereferencable version that Linked Data recommends, but if
there are other protocols that enable metadata to be retrieved then
they could also be Linked Data IMO.

It is a good thing that the subject URI is an HTTP URI available from
your server but that is only the start of the story. The rest of the
story needs other servers to give your data more context.

>> In your example the fact that there
>> is a link can only be figured out using some external service that
>> knows about both data sources.
>
> Sure. Before I can add a link to any data set, I have to detect it using some heuristics. Shared URN/DOI/... identifiers seem a valid approach for this -- think of ISBN numbers.

Sharing identifiers is a good idea, but it isn't Linked Data as yet...

>> If your server was Linked Data and not
>> just an HTTP URI based RDF database then it would link out using HTTP
>> URI's and both servers could be directly explored without some
>> external service.
>
> Once the link has been detected, I can of course add it to both data sets. Well, the owner of the datasets can.

This is Linked Data, when the dataset owners discover the mutual
references and link out from their HTTP URI's to the other datasets
HTTP URI's. It was enabled by sharing the property, and then having
others discover it. Just sharing the URN property isn't Linked Data as
people have no way of resolving the URN that is referenced to more
information.

It could also have been shared in another way using Inverse Functional
Properties (IFP) so that the URN scheme need not have been created.

<http://myserver.org/isbn:1232-1232132-X>
<http://purl.org/net/myontology/hasISBN> "1232-1232132-X" .

where http://purl.org/net/myontology/hasISBN is an IFP that many
people use for the same purpose.

It neatly avoids making up a new URN scheme, and has similar benefits
as far as I can tell.

There is no automatic HTTP based way of knowing which datasets may
have relevant links in either case, so serving up the statements on
your dataset is very useful for discovery, I wasn't meaning to say
that was a bad thing. Just emphasising the full story for Linked Data.

Cheers,

Peter
Received on Monday, 8 March 2010 21:17:11 UTC

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