On 11/16/12 1:30 PM, Ed Barkmeyer wrote:
> Duane Nickull wrote:
>> Doug:
>>
>>
>> As a quick sanity check, I always understood that URI's are the more
>> generic resource identifier, whereas URL's are a type of URI that are a
>> locator and a URN is a name identifier. In short, URN = what, URL = where
>> and how. This seems to be in alignment with the diagram you point at
>> below. I did read that John was referring to URI's and not URL's.
>>
>> A URN is a URI
>> A URL is a URI
>>
> A URN is a particular kind of URI that does not involve a URL, but is
> nominally required to have a registered supporting agent who can relate
> the URI to a resource. The original idea of the IETF (but not
> necessarily W3C) was that a URN is an identifier and a URL is a locator,
> which are different ideas. A URI that is based on a URL, i.e., a URL
> followed by a "bookmark" (#...) or by a "service invocation" (?...),
> combines the two functions, by providing a direct web link to the
> supporting agent, using the URL part of the URI. A certain webheaded
> influence at W3C decided some time ago that if no web-addressable
> resource could provide the information, the URI wasn't worth having; so
> all URIs would be URL-based. (This had the added advantage of not
> having to go back to IANA to register a URN prefix.) When the obvious
> nonsense in that position became apparent, the rule that a URL-based URI
> actually had to be directly dereferenceable was relaxed (after a long
> war), partly because the practice was already ongoing, and partly
> because no one wanted to go back to IANA to register URNs, and partly
> because thinking of the URI as an actual locator, even when it was, was
> 1990s-think.
>
> The real problem with seeing the URI as The Pointer to a definitive
> resource is that there may not be one definitive Web resource. The
> definitive resource might be a 1890 publication that is in your public
> library but not on the Web, so at best the URI will lead you to a
> synopsis, or to a bookseller who can sell you a copy. Or, there may in
> fact be MANY contributing resources on the Web that, using good Linked
> Open Data practices, use the SAME URI for the same thing. (Imagine
> that!) The consequence is that seeing the URI as a "locator" is
> irrelevant, whether or not it locates anything. Its primary function is
> to be an identifier. What you really need is a service that knows how
> to find a/the set of resources that provide information related to the
> thing denoted by the URI. RDF itself facilitates this view with the
> rdf:about=<URI> construct, which allows a resource to explicitly supply
> additional knowledge about a thing that is nominally "defined" (i.e.,
> introduced) somewhere else.
>
> So Duane can publish his CV at <Duane's URL>#Duane_Nickull, and a friend
> of his can publish additional information about Duane's prowess on the
> local bowling team, by referring to <Duane's URL>#Duane_Nickull, on the
> PodunkBowlingAllStars website. And someone else can publish Duane's
> contributions to Habitat for Humanity on another website.
>
> This is the point that Kingsley was making. This kind of thing is
> already happening on resources like Facebook, where postings of hundreds
> of different people use the same URI, in this case, the Facebook URI for
> Duane Nickull. And the popularity of the Facebook site means that the
> H4H sites also often use the Facebook URIs. And Duane's Facebook page
> may or may not point to his private URL. The people links are being
> created using common URIs made common by Facebook; other things have
> URIs made common by a few other widely accepted Web resources, even when
> those accepted resources (e.g., Amazon.com) are not "definitive" resources.
>
> -Ed
>
> P.S. I have to admit that this is a change in my personal viewpoint.
> Back in 2000, I argued that the URL-based URIs should be 1-to-1 with an
> accessible Web resource, and the ones that weren't should be URNs, so
> that no one would be misled by "useless HTTP links" that returned error
> 404s. I have come to see that (in spite of the inability of certain
> highly visible pundits to express it) URIs as "HTTP links" are becoming
> a thing of the past. Built-in browser technologies per se still
> strongly depend on viable HTTP links, but many of the scripts they now
> run do not -- the scripts are, or know about, finder agents. Sir Tim's
> vision was that this kind of thing would happen, although I doubt this
> is the form he expected it to take.
>
> P.P.S. I offer no apology to Duane for ignoring "the relevant part" of
> his email. The relevant issue for the Forum is what technologies for
> the Web provide accessible semantics for terms, or semantic background
> for corpora, and what additional technologies could help in finding and
> integrating captured knowledge. If the thing on the other end of a URI
> is a Facebook page, the integration of whatever knowledge it contains
> depends on the intervention of a human agent as filter and interpreter.
> If the thing on the other end of a URI is an RDF script, an entirely
> different capability emerges. It may be that this is what John meant by
> "typing" URIs.
Ed, (01)
Great summary! (02)
I am cc'ing in some other lists where related conversations have
emerged, in recent times. (03)
-- (04)
Regards, (05)
Kingsley Idehen
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen (06)
smime.p7s
Description: S/MIME Cryptographic Signature
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/
To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J (01)
|