Re: "information resource"

On Sep 2, 2004, at 12:43, <Patrick.Stickler@nokia.com> wrote:

>
>
>
> An explicit question:
>
> Given the URI http://example.com/someDog which I assert
> denotes a particular dog (an actual animal), if one is able to
> submit the request
>
> GET /someDog HTTP/1.1
> Host: example.com
>
> and in a successful response, one receives a JPEG image of
> the dog in question, does http://example.com/someDog denote
> an "information resource"?

The model I use is that you are wrong to say that it denotes a dog;
that it does denote an information resource.

For me, a dog is not an information resource.  Information resources
are abstract, and convey information.  They can, for example, often
be translated.  Dogs are animals, which are concrete.
Concrete and abstract things are distinct.
You can pick hairs or quibble, but the concept of a "web page" in common
parlance is an information resource.

The confusion raised in last call comments
in earlier copies of the document between
"resource" used sometimes as an unconstrained thing (Top class,
universal set, etc) and sometimes, often, for information resource
led to our introducing the two terms.

I think that the document is clearer.

I feel that the difference is that you actually are using words in a 
different ways and you actually have an architecture which is different 
from mine.  It doesn't make the same assumptions,

- The HTTP architecture creates a space of information resources 
(documents by any other name) with URIs. (1)
- An information is something which conveys information, and HTTP can 
allow a digital representation of that information to be acquired from 
the URI. (2)
- The URI architecture allows local identifiers in a document to be 
made global by prefixing with the URI if the document and "#" (3)
- The Semantic Web architecture provides a language (RDF) for talking 
about any  things and giving them local identifiers (4)
- By (3) and  (4) the Semantic Web architecture provides a language 
(RDF) for talking about any things and giving them URIs containing a 
"#" (5)

I think from what you have said in the past you have a different 
architecture in mind, in which the URI can be considered to identify a 
dog; the relationship "representation" can relate a dog to bits rather 
than just a picture to bits.   I don't find this alternative 
architecture so useful, because (for one thing) when I bookmark a 
picture of a dog and reuse the bookmark, I expect in general the same 
picture not just any document relating to the dog.

Tim BL

> --
>
> My reading of the latest draft of AWWW leads me to conclude
> yes, it does. The actual dog is, according to AWWW, an
> "information resource".
>
> (leaving aside the issue of whether such a conclusion will confuse
>  or disturb anyone, I wish to focus on another, deeper and more
>  serious point of confusion and tension that has been reflected
>  in this thread)
>
> TimBL seems to be arguing that no, it does not (or should not) be
> considered an "information resource", because a dog
> is not a document, or image, or similar kind of resource.
>
> The fact that both I and TimBL come to different conclusions
> based on the same document indicates that there is a problem
> with the definition of "information resource".
>
> And I would like to explore what I think is the source of this
> confusion and conflict.
>
> Originally, it seems that "resource" simply meant some
> "body of information" which might be encoded in various
> forms (document, image, sound bite, etc) and different
> formats (HTML, GIF, MP3, etc) and a URL denoted some
> body of information via which a representation of that
> body of information could be retrieved.
>
> Variant representations of the same body of information were
> expected to be true and correct expressions of that body of
> information, despite encoding differences. The nature and
> range of representations was originally quite narrow and
> specific, and the relationship between a resource and its
> representations was very tight; so tight, that often the
> resource and representation were (incorrectly) considered
> to be equivalent.
>
> Fair enough.
>
> But then folks started abstracting the model in order
> to achieve various disparate goals (including the SW)
> positing that a "resource" could be anything, and thus
> URIs could denote anything, and thus there could be
> representations of anything, not just bodies of information.
> This revised view of resources required a more open and
> generalized conception of representations and the relationship
> between resource and representation (in terms of their nature
> and inherent characteristics) broadened considerably.
>
> And then the problems began, because not everyone agreed
> just how wide things should be broadened, and different
> folks started drawing the line in different places as to
> what were and were not resources, and what the nature of
> those resources were, and their relationship to representations,
> yet all the while using the same terms and thinking they were
> all meaning the same things.
>
> One of the chief goals of producing AWWW is obviously an
> attempt to sort out this mess and provide a firmer foundation
> for future evolution of the web. Great. That's certainly
> welcome.
>
> But resolving conflicts of view and interpretation means that
> not everyone can be accomodated and not everyone will be happy.
> AWWW, however, seems to be trying to make too many folks happy
> and thus failing to sufficiently resolve these fundamental
> conflicts of view/interpretation.
>
> TimBL seems to be essentially opposed to the fully general view,
> where a resource can be anything and a URI can thus name anything;
> rather, sticking to the narrower view that "proper resources" are
> only those corresponding to "bodies of information", and only those
> should be considered "information resources" when having one or
> more representations, and only such resources should be denoted with
> URIs (rather than URI refs); i.e. things that are not bodies of 
> information
> should be denoted by URI references with fragment identifier and not a
> URI (i.e. they should be modeled as "secondary resources").
>
> While such a view can perhaps be seen as "truer" to the original Web
> design (and coming from TimBL, that's not surprising) such a
> view is far from optimal for those aiming to keep the Web and SW
> unified; as the SW is most certainly *not* constrained to
> resources which are merely bodies of information and the SW
> certainly *does* use URIs (without fragment identifiers) to
> denote any kind of resource, not just bodies of information.
>
> Attempts to force this narrower interpretation of what a resource
> can be and what a URI can denote on the masses have failed. Period.
> There are far, far too many resources which are not bodies of 
> information
> already long denoted by URIs (without URI references) to go back (even
> if a majority of folks wanted to -- and it seems the majority doesn't).
>
> While positing the concept of "secondary resources" seems
> reasonable, that does *not* mean that a majority of users
> agree that all resources not corresponding to "bodies of
> information" should be modeled as secondary resources. If
> TimBL and other like minded individuals prefer to do so, fine.
> But that does not mean that it is less acceptable for others
> not to -- and there are clear examples where use of URI refs
> limits potential functionality for interacting with resources.
>
> --
>
> The TAG needs to make a decision on this issue.
>
> Either "resources" (a) can be anything that can be named, including
> abstract concepts, astrological bodies, persons, etc. and URIs
> can denote anything or (b) they must be constrained to things that
> correspond to "bodies of information" which can be expressed in a
> digital form accessible via the web, and URIs can denote only such
> bodies of information.
>
> The latest draft of AWWW still attempts to accomodate both
> views, leaving far too much to interpretation -- and
> perpetuating the present chaos by allowing those holding view (a)
> and those holding view (b) to both reference the same document
> as supposedly supporting their view/interpretation and use the same
> terms as defined by that document -- yet *still* in actuality
> disagree about critically fundamental aspects of web architecture.
>
> The interchanges in this very thread illustrate this continuing
> ambiguity in AWWW and the very real conflicts of interpretation.
>
> AWWW should resolve these conflicts of view/interpretation, not
> perpetuate them by distilling the wording until either interpretation
> is possible.
>
> Continuing to accomodate the "resource = body of information" view,
> however implicitly hidden in clever wording, is simply going to
> perpetuate the confusion and prolong the pain...
>
> Respectfully,
>
> Patrick Stickler
> Nokia, Finland
> patrick.stickler@nokia.com
>

Received on Wednesday, 8 September 2004 17:11:34 UTC