W3C home > Mailing lists > Public > www-tag@w3.org > September 2004

RE: "information resource"

From: <Patrick.Stickler@nokia.com>
Date: Thu, 9 Sep 2004 12:00:02 +0300
Message-ID: <1E4A0AC134884349A21955574A90A7A50ADCB3@trebe051.ntc.nokia.com>
To: <timbl@w3.org>
Cc: <michael@neonym.net>, <www-tag@w3.org>

> -----Original Message-----
> From: ext Tim Berners-Lee [mailto:timbl@w3.org]
> Sent: 08 September, 2004 20:12
> To: Stickler Patrick (Nokia-TP-MSW/Tampere)
> Cc: michael@neonym.net; www-tag@w3.org
> Subject: 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.

Well, then I'm at a loss to see how the model you use corresponds
to either (a) what is explicitly specified/recommended by AWWW,
and (b) what many (if not most) folks working on semantic web
applications are doing.

If you can, please show me in AWWW, and/or in any of the existing
W3C or IETF specifications that I am "wrong" to use a URI (not
URIref) to denote a particular dog.

I appreciate that you, personally, may prefer things to be done
in a particular way, but I think it is fair to presume that the
specifications themselves, arising from a majority concensus of
the community, based on common needs and applications, should take
precidence over your own personal preferences, insofar as what
is dictated as required or best practice.

> 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.

I have no problem with the concept of "web page" or even of
"information resource" and saying that a "web page" is a kind
of "information resource".

I do, however, have a problem with saying that any resource
denoted by a URI which has web-accessible representations is
an "information resource" -- i.e. similar in nature to a 
web page.

Now, to be clear, AWWW does not IMO actually say that. The
definition in AWWW seems to be synonymous with "resource with
web-accessible representations" and no more. But I think that the 
possibility of folks reading into the AWWW definition due to the 
linguistic properties of the term chosen will result in that 
more restrictive interpretation; and hence produce confusion.

If you want to talk about web pages, information resources or
any other class of resource, fine, just define some RDF Classes and
publish triples till the cows come home. Great.

But insisting that just because some resource has web accessible
representations, that it must constitute some abstract body of
information, is (a) contrary to existing, widespread practice,
and (b) not born out in AWWW (at least, not explicitly or clearly),
and (c) not born out in any of the RDF or OWL specs.

> 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 appreciate the concerns over this confusion, and the need/desire
to resolve it.

But the resolution of that confusion need not posit any claims or
constraints about the inherent nature of the resource itself, only
about the accessibility of representations of that resource.



"resource"         Anything that can be referred to, named, described, 
                   talked about, etc.

"web resource"     A resource which has web accessible representations 
                   (i.e. is significant to the web machinery). 
                   "web resource" is a subclass of "resource".

"representation"   An octet stream (entity) returned by a server which 
                   reflects the state of a resource. A representation is 
                   also a resource, which can be denoted by a distinct 
                   URI. A representation of a representation (resource) 
                   corresponds to a bit-equal copy of itself.
                   "representation" is a subclass of "web resource".


IMO, the above three definitions should be sufficient to clarify the 
confusion between what a resource is and what resources are relevant to 
the web and why,  and how representations (the "atomic" resources of 
the web) relate to the broader set of web resources -- many of which 
correspond to abstract "bodies of information" such as web pages.

Nowhere above is it necessary to say anything about the inherent nature
of resources or of web resources, or to posit any kind of class of 
"information resources" in order to describe the behavior and architecture
of web servers and clients (aside from the atomic, binary nature of

> I think that the document is clearer.

It certainly isn't to me, since I don't see that it explicitly
supports your interpretation, and hence perpetuates the confusion
that this new term was intended to resolve.

> 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)

Sorry. With all due respect, I do not believe you can back up this claim 
with any reference to any explicit specification. If you can, please do.

You appear to be simply reflecting your personal preference/methodology, 
and *not* a fundamental requirement or feature of the semantic web
architecture as reflected by any existing standards.

I know this is how you would *like* things to be, but far, far too
many existing semantic web applications do not conform to this 
particular naming methodology and trying to force people to do 
things this way is one of the things that continues to fuel this
debate and confusion.

> I think from what you have said in the past you have a different 
> architecture in mind, 

Yes. I do.

Though one could also say, rather, that you have a different architecture
in mind from the majority of folks working on semantic web applications,
who do not subscribe to the view that only URIrefs can be used to denote
resources which do not correspond to something akin to a "document".

> 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.

Well, (a) it is already considered a best practice that there be consistency
in the representations provided via a given URI, and (b) as representations
are also resources which can be named by URIs, you could simply bookmark
the URI of the particular representation if you want tighter personal 
control over consistency of which representation you get.

My issue here is not with your personal preferences or practices, or
what you personally find useful or not -- but with what the concensus
is about the web architecture and how the web architecture relates
to the semantic web architecture; and, forgive me for saying so, I don't
find that your personal preferences coincide with the majority view
and that AWWW is being bent out of shape to accommodate two conflicting,
unreconcilable views, which continues to result in confusion.

The very fact that a literal reading of AWWW must lead to the conclusion
that the above referenced URI denoting a dog *is* an "information resource"
(since (a) there is no restriction against using a URI to denote a dog,
and (b) any resource having a representation is an "information resource")
and yet that you contest that conclusion, simply illustrates this continuing

If you were to attempt to have AWWW explicitly state that you cannot use
a URI (without fragid) to denote e.g. a dog, a planet, the color "red", etc.
then I'm quite sure you'd hear a major outcry and see a substantial backlash
from alot of folks (and I'm sure that's why AWWW has never explicitly stated
any such thing). Yet it is clear to me that such a view continues to be
accomodated for and hidden between the lines of AWWW by artful wording and 
sufficiently vague definitions.

I must honestly question whether the TAG trully wishes to *resolve* this
issue, rather than simply keep everyone (or noone) happy.



> 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 Thursday, 9 September 2004 09:00:37 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:32:43 UTC