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
> (01)
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. (02)
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. (03)
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. (04)
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. (05)
-Ed (06)
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. (07)
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. (08)
--
Edward J. Barkmeyer Email: edbark@xxxxxxxx
National Institute of Standards & Technology
Systems Integration Division, Engineering Laboratory
100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528
Gaithersburg, MD 20899-8263 Cel: +1 240-672-5800 (09)
"The opinions expressed above do not reflect consensus of NIST,
and have not been reviewed by any Government authority." (010)
> Anyways, now on to the relevant part of why I am writing back. In
> verifying the correctness of the above, I stumbled upon some work at the
> W3C entitled "Cool URI's for the Semantic Web"
>
> http://www.w3.org/TR/2008/NOTE-cooluris-20081203/
>
>
> "The Resource Description Framework RDF allows users to describe both Web
> documents and concepts from the real world‹people, organisations, topics,
> things‹in a computer-processable way. Publishing such descriptions on the
> Web creates the Semantic Web. URIs (Uniform Resource Identifiers) are very
> important, providing both the core of the framework itself and the link
> between RDF and the Web. This document presents guidelines for their
> effective use. It discusses two strategies, called 303 URIs and hash URIs.
> It gives pointers to several Web sites that use these solutions, and
> briefly discusses why several other proposals have problems."
>
> I am still in the midst of digesting this.
>
> Duane Nickull
> Technoracle Advanced Systems Inc.
>
> On 2012-11-16 8:15 AM, "doug foxvog" <doug@xxxxxxxxxx> wrote:
>
>
>> On Thu, November 15, 2012 18:16, Duane Nickull wrote:
>>
>>> Actually, to be more specific, they are a parent class of pointer that
>>> are
>>> represented as strings that identify resources in the web.
>>>
>> This is true of URLs (uniform resource locators). John was referring
>> to URIs (uniform resource identifiers) which are a union of URLs and
>> URNs (uniform resource names) [See
>> http://en.wikipedia.org/wiki/File:URI_Euler_Diagram_no_lone_URIs.svg].
>>
>>
>>> URL's,
>>> commonly used on the web, have both a location and a protocol associated
>>> with them as minimal (http is default if you type in an IP address).
>>>
>> Yes, but this does not apply to the URNs which are not also URLs.
>>
>
>
>
> _________________________________________________________________
> 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
>
> (011)
_________________________________________________________________
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 (012)
|
