W3C home > Mailing lists > Public > public-lod@w3.org > May 2009

Re: URLs instead of URNs (Was URI lifecycle (Was: Owning URIs))

From: W. Orthuber <orthuber@kfo-zmk.uni-kiel.de>
Date: Thu, 21 May 2009 21:39:31 +0100
Message-ID: <004201c9da54$3f384490$14b2a8c0@nameffe5190f44>
To: "Kingsley Idehen" <kidehen@openlinksw.com>
Cc: "semantic-web" <semantic-web@w3.org>, "Linked Data community" <public-lod@w3.org>
Kingsley,

thanks for your email, i know that an URI can be an URL or an URN. In case of an URN the exact meaning is not at once clear, the 
definition is not at once accessible,
it is even possible (http://dbooth.org/2008/irsw/) that there are "competing definitions". This is not good for information 
transfer, so it is plausible
to reduce step by step the application of this concept.
It is better to use a *special* ULR (you may call this a "LURN": a "Linked URN" because it defines an object like a name using a
link) which points to (a file with pointers to)  (multilingual) definitions and further associated information.

A simple example: let "xxx-length" denote some URN. Then we may conclude, the following number describes the length of some object.
But we don't know the unit. So we need special knowledge or to search for the exact definition.
It would be much more efficient , if we have a link (e.g. "dn/xxx-length-info-pointer") to a file which at once allows you to find
the exact definition in your language (and templates for human readable representation, metrics for similarity search, as
mentioned).

In future more and more special application may be considered. For example in medicine you need a huge vocabulary. Immediate access
to exact definitions is highly desirable.

So it seems plausible to prefer step by step in future URLs (which are "LURNs") instead of URNs.

Wolfgang

----- Original Message ----- 
From: "Kingsley Idehen" <kidehen@openlinksw.com>
To: "W. Orthuber" <orthuber@kfo-zmk.uni-kiel.de>
Cc: "semantic-web" <semantic-web@w3.org>; "Linked Data community" <public-lod@w3.org>
Sent: Thursday, May 21, 2009 5:42 PM
Subject: Re: URLs instead of URNs (Was URI lifecycle (Was: Owning URIs))


> W. Orthuber wrote:
>> David,
>>
>>>> In short, although semantic web architecture could be designed to permit
>>>> unrestricted semantic drift,
>>>> I think it is a better design -- better
>>>> serving the semantic web community as a whole -- to adopt an
>>>> architecture that permits the semantics of each URI to be anchored, by
>>>> use of a URI declaration.
>>> Absolutement.
>> Yes, I think also, URIs should be well defined. Up to now I thought they are, but your article shows that URIs (which are not
>> URLs)
>> have not necessarily an unique definition! Moreover URI should be anchored; the best would be that they contain a link to all
>> their
>> definition and further bindingly associated information.
> A URI is a Uniform Resource Identifier. A global identifier mechanism network addressable data items. Its sole function is Name
> oriented Identification.
> A URL is a Resource Location Identifier. Its *typical* function is Resource Address/Location Identification combined with Data
> Access mechanism.
>
> David describes an HTTP based URI which by essence *can* embody both of the functions above -- subject to use of HTTP messaging
> heuristics (between user agents and servers) for disambiguating between the Identity/Name or Address/Access functions.
>
> Hope this provides clarity.
>
> I do agree that the definition and relationship between URIs and URLs remain a source of distracting confusion; especially, when
> speaking outside the Semantic Web community.
>
> Kingsley
>>
>> Why not prefer URIs which are (special "defining") URLs, which contain a link to a file which contains links to all defining
>> information (unambiguous
>> information, in multiple languages if wished)?
>> So the anchor would be at once accessible and there would be exactly one location for the decisive information.
>>
>> Best
>> Wolfgang
>>
>> ----- Original Message ----- From: "Hugh Glaser" <hg@ecs.soton.ac.uk>
>> To: "David Booth" <david@dbooth.org>
>> Cc: "semantic-web" <semantic-web@w3.org>; "Linked Data community" <public-lod@w3.org>
>> Sent: Wednesday, May 20, 2009 11:21 PM
>> Subject: Re: URI lifecycle (Was: Owning URIs)
>>
>>
>> Hi David,
>> On 20/05/2009 06:01, "David Booth" <david@dbooth.org> wrote:
>>>>
>>>> A last comment, which I know we have discussed, and you possibly disagree:
>>>> "Community expropriation of a URI"
>>>> Might have meant something else.
>>>> One of the problems is that many authors will not discharge their Statement
>>>> Author Responsibilities, but will assume that the URI is the one they want.
>>>> Over time, this may mean that the general SW uses a URI in a way other than
>>>> the URI owner intends, to the extent that it becomes irrelevant what was the
>>>> original meaning (there are many parallels for this in natural language, and
>>>> indeed it is the social process that causes language to change).
>>>> [ . . . ]
>>>
>>> Yes, that's a great topic for discussion.  It is clear that semantic
>>> drift is a natural part of natural language: a word that meant one thing
>>> years ago may mean something quite different now.  As humans we can
>>> usually deal with this semantic drift by knowing the context in which a
>>> word is used, though it can cause real life misunderstandings sometimes.
>>>
>>> However, I think our use of URIs in RDF is different from our use of
>>> words in natural language, in two important ways:
>>>
>>>  - RDF is designed for machine processing -- not just human
>>> communication -- and machines are not so good at understanding context
>>> and resolving ambiguity; and
>>>
>>>  - with URI declarations there is a simple, feasible, low-cost mechanism
>>> available that can be used to anchor the semantics of a URI.
>>>
>>> In short, although semantic web architecture could be designed to permit
>>> unrestricted semantic drift, I think it is a better design -- better
>>> serving the semantic web community as a whole -- to adopt an
>>> architecture that permits the semantics of each URI to be anchored, by
>>> use of a URI declaration.
>> Absolutement.
>> But your paper is not about architecture.
>> The architecture, as you say, permits the semantics of each URI to be
>> anchored.
>> The (one of the?) good thing about your paper is that it is about the stuff
>> that is not enforced by the architecture, but rather addresses what might be
>> called the social processes and what responsibilities might be.
>> And works hard to avoid confusion between them.
>> So if one was to envisage ways in which the consequences of failure to
>> adhere to the responsibilities might have a significant impact, and how that
>> impact might be accommodated or challenged, then I think it can be useful to
>> study it.
>> I happen to think that people and hence agents will simply assume they know
>> what URIs mean without checking the anchor, in the same way they use words
>> without checking the dictionary. If I was marking this email up in RDFa, I
>> would be much more likely to guess, or simply go and use the URIs you had
>> used to mark up your email, rather than check each one back at base - I
>> would never be able to do anything if I checked every word in the
>> dictionary.
>> In fact, how much of all the RDFa that is now being generated gets checked?
>> I do take your point that a lot of this is happening with machines, but even
>> they will make the same mistake when choosing a URI.
>> Best
>> Hugh
>>>
>>> For more explanation see: "Why URI Declarations? A comparison of
>>> architectural approaches"
>>> http://dbooth.org/2008/irsw/
>>>
>>>
>>> -- 
>>> David Booth, Ph.D.
>>> Cleveland Clinic (contractor)
>>>
>>> Opinions expressed herein are those of the author and do not necessarily
>>> reflect those of Cleveland Clinic.
>>>
>>>
>>
>>
>>
>>
>>
>
>
> -- 
>
>
> Regards,
>
> Kingsley Idehen       Weblog: http://www.openlinksw.com/blog/~kidehen
> President & CEO OpenLink Software     Web: http://www.openlinksw.com
>
>
>
>
>
Received on Thursday, 21 May 2009 19:41:13 UTC

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