[
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:
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@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
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@mediaone.net";) and
mailbox(?person,"mailto:jborden@attbi.com";)
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
|
