Re: More on distinguishing information resources from other resources

Patrick Stickler wrote:

>
>
> On Jun 28, 2005, at 21:32, ext Roy T. Fielding wrote:
>
>>
>> Please join me in a chant of "It just doesn't matter."
>
>
> It just doesn't matter.
> It just doesn't matter.
> It just doesn't matter.
>
> ;-)
>
>>
>> We could spend a great deal more time trying to precisely define
>> the meaning of "information resource", and yet doing so solves
>> no known problem in the architecture.
>
>
> +1

+1

(it might solve other problems, but this is I think
moving into the space of choosing amongst ontologies,
rather than core architecture)

>> The goal of the resolution
>> is to provide a way to supply information about a resource that
>> is not actually "representable" on the Web, where representable
>> is entirely dependent on what the owner of that URI intends it
>> to identify, and yet do so in a way that would allow the
>> Semantic Web to distinguish between the resource identified by
>> the URI and the other resource providing the description.
>>
>> In short, it licenses the Semantic Web to consider a 200 response
>> to GET to be indicative of a representable resource, whatever
>> that means, while describing how to provide information about a
>> non-represented resource at minimal extra cost to the old Web.
>> Whether this distinction actually turns out to be needed or not
>> is besides the point -- simply defining it solves the semantic
>> problem at minimum cost and allows us to get back to describing
>> how the system works rather than what resources mean.
>
>
> And the extent to which sw agents will trust the response code
> as a reliable indicator of class membership will depend on
> the degree to which folks follow the best practice outlined
> by the TAG.
>
> But, again, it should be made clear in the TAG's resolution
> that it is *not* an error if an existing web application
> returns a 200 response for a URI which does not identify
> an information resource. The TAG's resolution might make
> legacy systems non-optimal, but it should not make them
> broken.

The degree of strictness the TAG takes on the question
of 200 vs redirect ought to be proportional to the
level of care, careful definition and community review it
invests in defining some class of "Information Resource".

Right now, webarch has something pretty loose and evocative:
eg http://www.w3.org/TR/webarch/#id-resources
"Although it is possible to describe a great many things about a car or
a dog in a sequence of bits, the sum of those things will invariably be
an approximation of the essential character of the resource."

...on this basis, I think FRBR's notion of an abstract Work
might also be rejected, since the bitstream manifestation
of expressions of some Work is also generally just an approximation. Yet
it is (to me) non-obvious that
frbr:Work and tag:InformationResource are mutually
disjoint classes.

http://www.ifla.org/VII/s13/frbr/frbr1.htm#3.2

[[
3.2.1 Work
The first entity defined in the model is work: a distinct intellectual
or artistic creation.

A work is an abstract entity; there is no single material object one can
point to as the work. We recognize the work through individual
realizations or expressions of the work, but the work itself exists only
in the commonality of content between and among the various expressions
of the work. When we speak of Homer's Iliad as a work, our point of
reference is not a particular recitation or text of the work, but the
intellectual creation that lies behind all the various expressions of
the work.

Because the notion of a work is abstract, it is difficult to define
precise boundaries for the entity. The concept of what constitutes a
work and where the line of demarcation lies between one work and another
may in fact be viewed differently from one culture to another.
Consequently the bibliographic conventions established by various
cultures or national groups may differ in terms of the criteria they use
for determining the boundaries between one work and another.
]]

cheers,

Dan

Received on Wednesday, 29 June 2005 15:21:38 UTC