Re: [ontolog-forum] "Cool URI's for the Semantic Web" (WAS Re: Webby objects)

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,

Great summary!

I am cc'ing in some other lists where related conversations have 
emerged, in recent times.

-- 

Regards,

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