No arguments here ;-p (01)
THis is a great summary and I have to admit, I too changed my personal
views on this. During the XML days there was also a lot of confusion
about using URI's or URL's as namespace qualifiers for XML elements. This
confused a lot of people. (02)
Duane
***********************************
Technoracle Advanced Systems Inc.
Consulting and Contracting; Proven Results!
i. Neo4J, PDF, Java, LiveCycle ES, Flex, AIR, CQ5 & Mobile
b. http://technoracle.blogspot.com
t. @duanechaos
"Don't fear the Graph! Embrace Neo4J" (03)
On 2012-11-16 10:30 AM, "Ed Barkmeyer" <edbark@xxxxxxxx> wrote: (04)
>
>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.
>
>--
>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
>
>"The opinions expressed above do not reflect consensus of NIST,
> and have not been reviewed by any Government authority."
>
>
>> 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
>>
>>
>
>
>
>_________________________________________________________________
>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
> (05)
_________________________________________________________________
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 (06)
|
