Representations of Resources and Precision of Denotation (was Re: TB16 Re: Comments on arch doc draft)

On 2002-07-03 20:49, "ext Paul Prescod" <paul@prescod.net> wrote:

> 
> Patrick Stickler wrote:
>> 
>> ...
>> 
>> A picture of a rock is not an HTTP representation of the rock.
> 
> Well, this is the core issue of the debate. Fielding claims that was his
> intent:
> 
> "The key abstraction of information in REST is a resource. Any
> information that can be
> named can be a resource: a document or image, a temporal service (e.g.
> “today’s weather
> in Los Angeles”), a collection of other resources, a non-virtual object
> (e.g. a person), and
> so on. In other words, any concept that might be the target of an
> author’s hypertext
> reference must fit within the definition of a resource. A resource is a
> conceptual mapping
> to a set of entities, not the entity that corresponds to the mapping at
> any particular point in
> time."

Sorry, but I interpret this as meaning a rock is a resource and a
textual description of a rock is a resource, and those are two different
resources. The former cannot be retrieved -- no representation is available.
The latter potentially can be retrieved -- one or more representations may
be available.

I've never understood any of the HTTP or REST materials as saying that
a textual description of a resource is a representation of that resource.

I'd very much like to know if I'm wrong (or at least a minority ;-) on
that point.

>> ....
>> Web applications do not have access to the actual resource, no, but
>> a representation of the resource is analogous to getting the actual
>> resource. For that to happen, the resource has to be digitally
>> encoded in some fashion.
> 
> The word "analogous" does not give me a warm and fuzzy. Either you can
> get the real resource or you cannot. HTTP says you cannot.
> 
> The resource could be something concrete like an XML file.
> It could be something transient, like the result of a database query.
> It could be something abstract like a person.

Ahh, but for the first two, you are not getting the actual file or
query results. You are getting a representation of them, which may
be one of many variants considered to be an acceptable analog of
the original -- given a limited number of variables, such as language,
encoding, character set, etc.

HTTP *never* returns the original. It's always a copy of some sort,
which may not be bit-for-bit identitical with the original (which
itself may simply be a set of variants and not even a single "file").

> If Web clients *cannot* tell the difference because the resource is
> hidden, then why is it useful to make the distinction architecturally?
> 
>> A rock (at least for the moment) cannot be digitally encoded, and therefore
>> is not web-accessible.
> 
> No. A representation of it is.

You are using the word "representation" too broadly. It is not
possible (with current technology) to create an HTTP representation
of a rock.

Yes, in English, we say that a photo provides a kind of representation
of the rock, but that's not what HTTP means by "representation".

>> A picture of a rock is not the rock. A prose description of a rock
>> is not the rock. Yet the picture, the description, and the rock all
>> may be separately denoted by URI.
>> 
>> If you use the same URI to denote the rock and the picture of the
>> rock, how do you say anything about either without ambiguity? You
>> can't.
> 
> Let's change the language above:
> 
> "An XHTML representation of an XML file is not the XML file. A
> Formatting Objects representation of an XML file is not the XML file....
> 
> If you use the same URI to denote the XHTML representation and the
> formatting objects representation, how do you say anything about either
> without ambiguity? You can't."
> 
> This goes back to Noah's point. Semantic web languages should have ways
> of saying whether you are asserting something about the resource or some
> particular representation. If the language does this then the appearance
> of overloading disappears.

Quite so, but this is a matter of resolution. I give unique URIs
to both resources and their variants, but as each variant is
a valid realization/representation of the resource, content negotiation
is free to return a variant *as* the resource -- which it is.

Content management requires that variants be named uniquely. But
that does not mean that one must name a specific variant when
referring to the resource itself.

But again, we're talking about HTTP representations, not
English representations of resources. Any HTTP representation
variant is considered functionally equivalent to the
resource itself -- not necessarily bit-for-bit equivalent.
And only digital resources have representations on the Web.

I would even go so far as to assert that a digitization of
a paper photo is not an HTTP representation of the photo, i.e.
not the actual photo itself.  The photo itself could be e.g.
an antique paper photograph by a famous photographer worth
tens of thousands of dollars -- and GETing a representation
of the digitization of that photo is not GETing the photo
itself.

In short, the Web -- which is meant for and caters to (usually)
intelligent humans -- has a long way to go before it can provide
the precision of identity required by software agents, for it
to become the Semantic Web.

This concept of a photo of Paris being a representation/variant
of Paris itself -- while workable for humans surfing the web -- is
simply not going to work on the Semantic Web.

>>>> ...
>>>> A schema is not a representation of a vocabulary. Sorry. Nope. It's
>>>> something that uses the terms of a vocabulary, but the vocabulary itself
>>>> is abstract, just as are the terms.
>>> 
>>> Why not?
>> 
>> A vocabulary is an abstract set of terms with associated semantics.
>> 
>> A schema is a document that describes vocabulary terms.
> 
> Yes I see the difference. But it it is totally irrelevant. Things that
> are representations of other things are *always different* otherwise why
> bother with the representation?

In the case of HTTP, it may be better if we speak of 'variant'. It
is unfortunate that the term 'representation' was chosen, since it
clearly confuses alot of folks (it certainly confused me at first).

If we talk of variants, then surely you don't consider a textual
description of a rock and a rock to be two variants of the same
thing. No?

Dispite all the retoric about the Web and URIs being intended to
identify "anything in the universe that can be named" the reality
is that the Web was designed for *digital* resources, and the semantics
and functionality of HTTP is focused on *digital* resources, and
thus using the terminology of HTTP to discuss non-digital resources
is often times simply meaningless.

> You might as well say that "An HTML entity is not a representation of an
> XML entity" because XML and HTML entities are different.

I might, or might not. Depending on whether the HTML and XML 'entities'
are variant representations of the same resource.

>> ...
>> And, e.g. an XML Schema does not define a vocabulary.
> 
> Nobody said that an XML Schema defines a vocabulary. I said that it
> *represents* a vocabulary as an HTML rendition is a lossy representation
> of an XML original.

An XML Schema definitely does not represent a vocabulary, because
a vocabulary says nothing about document structure. Vocabularies
are sets of terms with (potentially) associated semantics.

The fact that there can exist different XML Schemas which define
different document structure (content models) for the same
vocabulary term proves this to be true. XHTML is only one example.

Schema != Vocabulary


Regards,

Patrick

--
               
Patrick Stickler              Phone: +358 50 483 9453
Senior Research Scientist     Fax:   +358 7180 35409
Nokia Research Center         Email: patrick.stickler@nokia.com

Received on Thursday, 4 July 2002 03:33:52 UTC