OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] URIs are simply names was: Re: [xml-dev] "Abstract" URIs

[ Lists Home | Date Index | Thread Index ]

John Cowan <jcowan@reutershealth.com> wrote:

> Jonathan Borden, or the avatar of him at 
jborden@attbi.com, 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: 

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


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 


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:


>  > 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 
> Again, fair enough.  But the use of "description" is 
an equivoque: the
> HTML you can GET from http://www.ccil.org/~cowan/ is a 
> 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@medione.net)
> 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@medione.net or jborden@attbi.net.
> 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 
> 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@mediaone.net";) and 
     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"



News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS