Re: removing constraints on 'resource' [024-identity]

As with all other discussions on this topic, the messages are
not being constructive to the issue at hand.  The question is not
whether resources can exist without being assigned URI, nor whether
a URI scheme can be defined that identifies abstract resources
through indirection.  Both of those issues are unaffected by the
change of wording that I made for draft 05. Nor, for that matter,
does this have any relation to httpRange-14 other than the fact
that it came up during a discussion of that TAG issue, and this
issue is not at all present in the discussion/diagrams we talked
about at the last TAG meeting.  Please, just focus your comments
on the change request that Dan made.

The question is: should the term "resource" apply to those things
that have not yet been named or described within any system?
This has no impact on URI technology because assigning a URI is
naming that thing, and thus anything assigned a URI would be a
resource under either definition.

The only real effect is that the current wording allows the editor
(i.e., me) to address complaints that either:

   1) "resource" as used does not correspond the language definition; or

   2) one cannot reference what has not been named or described, and thus
      no system can make use of such a thing directly (i.e., aside from
      aggregation as a named set of things), and thus it is not a 
resource.

On Monday, May 24, 2004, at 01:53  PM, Dan Connolly wrote:
> Regarding...
>
> "Anything that has been named or described can be a resource."
> -- http://www.gbiv.com/protocols/uri/rev-2002/rfc2396bis.html#overview

For context, the definition of draft 05, in full, is:

    Resource
       Anything that has been named or described can be a resource.
       Familiar examples include an electronic document, an image, a
       service (e.g., "today's weather report for Los Angeles"), and a
       collection of other resources. A resource is not necessarily
       accessible via the Internet; e.g., human beings, corporations, and
       bound books in a library can also be resources. Likewise, abstract
       concepts can be resources, such as the operators and operands of a
       mathematical equation, the types of a relationship (e.g., "parent"
       or "employee"), or numeric values (e.g., zero, one, and infinity).
       These things are called resources because they each can be
       considered a source of supply or support, or an available means,
       for some system, where such systems may be as diverse as the World
       Wide Web, a filesystem, an ontological graph, a theorem prover, or
       some other form of system for the direct or indirect observation
       and/or manipulation of resources. Note that "supply" is not
       necessary for a thing to be considered a resource: the ability to
       simply refer to that thing is often sufficient to support the
       operation of a given system.

> Based on discussion with TimBL and Roy and a few others,
> as well as review of this issue...
>
> 024-identity Resource should not be defined as anything that has
> identity
> http://www.gbiv.com/protocols/uri/rev-2002/issues.html#024-identity
>
> it seems more straightforward to just say
>
> 	A resource can be anything; familiar examples include an 	electronic 
> document, an image, a service (e.g., "today's weather
> 	report for Los Angeles"), and a collection of other resources,
> 	but there is no constraint on what is a resource.

So, the difference that Dan is asking for is that "resource" include
those things that have not yet been named or described.  Dan, is there
a significant reason why you changed tense from "A resource can be
anything" to "what is a resource" in the last sentence?

> Public discussion of http://www.w3.org/TR/webarch/ suggest that this
> unconstrained definition of 'resource', along with a separate term
> for a smaller set of "information resources" is a useful way to
> describe the role of URIs in Web Architecture.
> (we haven't finished the text yet, but you can see a
> diagram at
>   http://www.w3.org/2004/05/URI-space-small.png
>   http://www.w3.org/DesignIssues/diagrams/URI-space.svg
> and some notes on the discussion at
>   http://www.w3.org/2004/05/14-tag-summary.html#httpRange-14-1 )

A public discussion between Pat Hayes and various members of the
W3C TAG produced comments suggesting that Dan's use of the term
"resource" was a synonym for "thing" (not just that all things
can be resources, but all things *are* resources) and yet the
webarch document simultaneously describes resources as both
anything and as a constrained set of things that TimBL refers to
as "information resources".  One of Pat's earlier comments on the
webarch document was that the definition of resource, as obtained by
reference to rfc2396bis, is synonymous with "thing" and does not
correspond to the English definition of "resource".  Since I do
not view them as synonyms, something was amiss, and thus the
change from draft 04's

   "Anything that can be named or described can be a resource."

   "Anything that has been named or described can be a resource."

In other words, that there exists a set of things which are not
yet resources for any system, and thus comments to the effect
that "how can an unspecific particle of sand on some beach
be a resource?" are answered.

> The unconstrained definition of 'resource' is also what was imported
> into the RDF specification:
>
>   The things denoted are called 'resources', following [RFC 2396], but
>   no assumptions are made here about the nature of resources; 
> 'resource'
>   is treated here as synonymous with 'entity', i.e. as a generic term
>   for anything in the universe of discourse.
>     -- http://www.w3.org/TR/rdf-mt/ aka
> 	http://www.w3.org/TR/2004/REC-rdf-mt-20040210/

Here, I simply have to disagree.  RDF says that the things denoted are
called resources, which is equivalent to saying that the things named
or described by RDF are resources.  There is no difference between that
and what is defined in draft 05, so I do not see the conflict.  The
draft 05 definition does not, in any way, constrain the nature of
resources, since anything can be named or described.  It simply
differentiates between what has been named or described and those
things that have not.

In discussion on the telephone, my recollection is that Dan suggested
that all numbers within the Real number set must be resources.  I have
no idea why that needs to be the case, since mathematics has no such
requirement.  Real numbers as a set is a resource.  Any specific real
number that one might care to enumerate is a resource.  But, because
the set is non-numerable, the only way to refer to every number in the
set is to use existential qualifiers like "There exists ..." and
"For all ...".  Those qualifiers allow one to indirectly refer to
each/every member of a set by reference to the set itself.
I don't consider that sufficient to call each and every real number
a resource, at least not until someone creates a name or description
that distinguishes that real number from all others.  However, I may
just have misunderstood Dan's point.

In any case, I do not know of any system or specification that
breaks due to the draft 05 definition, nor of any description of
the Web or URI space that requires the set of all resources to be
greater than the set of named or described things.  I remain
unconvinced that changing it to "anything can be a resource" is
sufficient to address prior complaints that some things
are not resources (i.e., are not usable, referenced, or denoted
by any system).

I could add more disclaimers to the effect that this definition
does not affect the nature of a resource, since anything can
be named or described, but I'd like to know if that is sufficient,
or if it is actually folks intent to say that things which have
never been named or described are resources. [In that case, I'll
have to agree with Pat's assertion that such use of the term
resource is just plain confusing and should be defended by those
who think it makes sense.]

....Roy

Received on Monday, 24 May 2004 22:24:50 UTC