[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: URIs are simply names was: Re: "Abstract" URIs


Re:  URIs are simply names was: Re:  "Abstract" URIs
John Cowan <jcowan@r...> wrote:

> Jonathan Borden, or the avatar of him at 
jborden@a..., wrote:
> 
>  > A URI is simply a name for a thing, whatever that 
thing may be.
> 
...
> 
> Anyhow, I too now have a URI:
> 
> 	http://www.ccil.org/~cowan/self.xtm#self

Properly this is a URI reference.

Particularly concerning REST and URIs: Roy Fielding's 
thesis says this: 
http://www.ebuilt.com/fielding/pubs/dissertation/evaluati
on.htm#sec_6_2

[[
REST accomplishes this by defining a resource to be the 
semantics of what the 
author intends to identify ...
]]

and

[[
Defining resource such that a URI identifies a concept 
rather than a document 
...
]]

so while you are (I assume) the authority on the type of 
the resource identified 
by:

http://www.ccil.org/~cowan/

and you are free to assert that it identifies a 
hypertext document, there is 
nothing that mandates this. Indeed you are also free to 
assert that this URI represents _you_ if you so choose. 
Just as I may assert the semantics of the 
resource identified by:

http://jborden.org


...
> 
>  > URIs are names. The point being made is that what 
they name is NOT the
>  > literal series of characters returned by a GET, 
rather the URI names a
>  > _resource_ which might be anything thing that has a 
name. What is
>  > returned by a GET is simply a description of the 
actual resource
>  > (other wording is a 'representation of the 
resource').
> 
> Again, fair enough.  But the use of "description" is 
an equivoque: the
> HTML you can GET from http://www.ccil.org/~cowan/ is a 
representation
> of a certain resource of type "hyperdocument".  It is 
not a
> representation of another resource of type "Homo 
sapiens".  It does not
> even, as it happens, very well describe that Homo 
sapiens instance.
> 

Right, but again if you so chose, the GET actually could 
describe, or return a representation of, "Homo sapiens".

The point is that URIs leverage the global naming and 
registration system to allow people to create URIs and 
define what these URIs represent.

>  > URIs are names.
> 
> The point is that names, to be truly useful, should 
not refer to
> distinct referents.  It is nothing but a nuisance 
that "James
> Carter" might refer to either a mathematician at UCLA 
or a former
> president of the United States.

What URIs bring to naming is an _attempt_ to be unique, 
yet fundamentally URIs are only unique with respect to a 
single point in time, and over time their meaning might 
change. Oh well.

The fact is, everything changes over time, even the 
meaning of strings such as "1 + 1 = 2". Perhaps not 
optimal, not perfect, but it is the universe we exist in.

> 
>  > Jonathan (note new email address -- which refers to 
the same person as
>  > jborden@m...)
> 
> Your two email addresses *refer* to distinct 
mailboxes: it is not all
> one (at least eventually, if not immediately) whether 
I send mail to
> jborden@m... or jborden@a....
> 
> They are *associated*, using any of a variety of 
properties such
> as "mailboxOf", "ownedBy", or "subjectIndicatorOf", 
with you
> yourself, Jonathan Borden.  What the URI of Jonathan 
Borden
> might be, we do not yet know.  If a topic for you 
appeared in some topic
> map, then we would have a URI for you (an XPointer 
into the
> topic map) and a criterion for determining if other 
such URIs
> also refer to you.
> 

in predicate logic:

for all ?person such that 
     mailbox(?person,"mailto:jborden@m...";) and 
     mailbox(?person,"mailto:jborden@a...";) 
  implies 
     name(?person, "Jonathan Borden")

(one can choose from among several syntaxes for 
representing the same formula)

Considering that such logics have been around and well 
characterized for many decades, I am not sure what topic 
maps bring to the table. I do think that I need 
something like a topic map to see how these concepts 
relate between TM, RDF, FOPL etc. The term "subject" is 
in grave danger of becoming as overloaded as "resource"

Jonathan

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.