Re: Summary of 18 March TAG teleconference - identity and resources

Reading this TAG summary, a couple of thoughts occurred to me:

(1) Larry Masinter posted an Internet Draft [1] a while back proposing a 
urn:tdb:<URI> form of URI, where 'tdb' might be read "that described 
by".  DanC's TAG telecon comments (about retrieving a _representation_ of a 
resource) made me wonder if all URIs were really in some sense 'tdb' 
URIs;  even those that identify Web documents.

(2) We've been kicking around some ideas of URIs and fragment identifiers 
in RDF.  Pat Hayes pointed out that in RDF usage, e.g., there is not 
necessarily an expected part-of relationship between:


If such a relationship exists, its because some RDF document has defined 
it.  Otherwise they denote completely independent values, and the 
similarity of their names is purely accidental.  Against this background, 
DanC's comment makes me think some:

>    [DanC]
>           one way to say it: doc#name refers to whatever
>           doc means by name.



>    [Ian]
>           IJ: I will take it as soon as TB says "Take it."
>           ------------------------
>           *
>           * What does a URI identify?: NW and SW
>    [Stuart]

>    [Ian]
>           -semantics
>    [DanC]
>           Bray: "an addressable unit of information or
>           service"
>    [Ian]
>           TB: I like definition of Resource: " An
>           addressable unit of information or service"
>           DO: Isn't that circular?
>           TB: I don't care that it's circular. It works.
>           :)
>           TOPIC: Define "resource"

>    [Ian]
>           TBL: In URIs and RDF used differently.
>    [TimBray]
>           Iput it there... but I stole it from somewhere
>    [Ian]
>           From WCA terms
>           Resource
>           The URI specification describes a resource as
>           the common term for "...anything that has
>           identity. Familiar examples include an
>           electronic document, an image, a service (e.g.,
>           "today's weather report for Los Angeles"), as
>           well as a collection of other resources. Not all
>           resources are network "retrievable"; e.g., human
>           beings, corporations, and bound books in a
>           library can also be considered resources..."
>           (see also the term Web Resource).
>           TimBL: You can't make a representation of a
>           telnet session. Or a mailbox. I think it's
>           useful to distinguish documents from other
>           things.
>           TimBL: HTTP has architecture of representations.
>           DC: Representations are documents. But what they
>           represent is not constrained, is it?
>           TimBL: If something were to give me a
>           representation of a telnet resource, it would
>           miss the nature of the telnet resource.
>           TB: My definition with service covers that.
>           DC: Resource is like "point" in geometry. You
>           don't define. They just are.
>           CL: Yes, it's defined.
>           DO: If we agree that we want a circular
>           definition, then we should acknowledge that
>           they're circular (and rationale why).

>    [Ian]
>           TimBL: Valid questions:
>           - Can a car be a resource?
>           DC: Yes, n'est-ce pas?
>           TimBL: By RDF definition, yes. By URI
>           definition, no.
>           CL: You can provide a URI to a photo of a car,
>           but not a car.

>    [DanC]
>  <-
>           that identifies my car.
>    [Ian]
>           TimBL: In RDF, you can write a thing that
>           describes a car.

>    [ChrisL]
>           The World is the Universe of Resources. The Web
>           is the Universe of Network Acessible Resources
>    [Dave]
>           Ian, you missed my point
>    [Stuart]
>           \me just dereferenced Dan's car :-)
>    [TimBL]
>           Sorry, the requested resource does not exist <-
>           dan's car

>    [DanC]
>           no! please let's all lear to stop saying that
>           resources can be retrieved. *Representations* of
>           resources can be retrieved
>    [Ian]
>           NW: I am surprised that we are having this
>           discussion. I'm not sure what to think about us
>           contesting the point about URIs pointing to
>           real-world objects.
>           NW: In response to URIs being network
>           addressable, namespace URIs are specifically
>           required to not be necessarily net addressable.
>           SW: None of the definitions I've seen are
>           closed.
>           "As in: This thing cannot be a resource."
>    [TimBL]
>           (The RDF URI#frag being different comes from the
>           web architecture .. function of mime type)
>    [Ian]
>           SW: I would prefer to not make the distinction
>           between an HTTP-type resource and an RDF-type
>           resource.
>    [ChrisL]
>           realworld://connolly/dan/car/20020318/
>    [Ian]
>           SW: ...maybe definition of resources is
>           expanding.
>           DC: Everyone please don't say "Resources can be
>           retrieved." No. representations can be
>           retrieved.

>    [Stuart]
>           From RFC2396 defn of Resource: "Not all
>           resources are network
>           "retrievable"; e.g., human beings, corporations,
>           and bound
>           books in a library can also be considered
>           resources.

>           TimBL: In RDF, fragment identifier is used to
>           identify abstract concepts.
>           TimBL: The way I saw getting over this dichotomy
>           between two definitions is to say:
>           - Without the "#", an HTTP URI is restricted to
>           talk about documents.
>           - You bootstrap yourself into the real world by
>           defining the connection in the format.
>           TimBL: I have a home page that has a URI. It was
>           born in 1991. I was born in 19XX.

>    [Ian]
>           TimBL: I want to be able to distinguish the car
>           from the document about the car.
>           TimBL: HTTP doesn't give us the ability to
>           separately ask about the car and the document
>           about the car.

>    [Ian]
>           TB: One could probably built a consistent set of
>           mathematics about what a resource is. What turns
>           out to be more interesting? I could see a world
>           where a car has a URI. But not clear to me what
>           you would build there.
>           TB: Seems like a deep distinction between a
>           resource that exists as an electronic object and
>           something that doesn't exist.
>           DO: This is the bits v. atoms discussion.
>    [TimBL]
>           (IMO, A car could have a URI, but not a http URI
>           given HTTP 1.1)
>    [Ian]
>           TB: Perhaps a resource is something you get
>           representation of. The representation is always
>           electronic. Perhaps that's a useful place to
>           start building the superstructure: a resource is
>           something that has at least one electronic
>           representation.
>           DC: I dispute TBL's assertion that there was a
>           contradiction. I agree that it's unwise to use
>           the same identifier for two things (since you
>           can't tell them apart).
>           TBL: My interpretation is that HTTP 300, 200,
>           and 404 responses all talk about documents.
>           ...anytime you dereference the URI, you get
>           documents. And documents and cars are distinct.
>           DC: You haven't shown the contradiction in my
>           assertion that "This URI identifies my car."
>           CL: Why is fragment identifier in RDF not "part
>           of a resource" as in other formats?
>           TimBL: "Fragment" is unfortunate term since not
>           always identifying a subpart. Meaning of what is
>           identified is language-dependent.
>    [DanC]
>           one way to say it: doc#name refers to whatever
>           doc means by name.

Graham Klyne

Received on Tuesday, 19 March 2002 11:07:54 UTC