Re: A shot back at #rdfms-resource-semantics

Brian, Dan (et al),

Well, I guess I need to apologize to the group for this morning's
efforts -- after I've recovered from the frag-cannons. I didn't actually
think I was necessarily introducing new issues (not further than the
fascinating sequence on rdf-tracking/#mime-types-for-rdf-docs which
certainly was considering aspects of truth and (possibly legal)
commitment... and was possibly shocking for that.) It was intended to
provide angles. In particular, as you'll see, I'm concerned with
identity. Identity, in the real world, brings in the concept of
signing.  But leave that all for now: so much for my unfocussed
approach.


I understand the charter (I hope) and RFC2396 (I think).

Brian: `For example, RFC 2396 is quite clear that a resource
is NOT the bit sequence (or actual atoms).'

RFC2396 (This is from http://www.ietf.org/rfc/rfc2396.txt):
      `Resource
         A resource can be anything that has identity.  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.  Not all resources are network
         "retrievable"; e.g., human beings, corporations, and bound
         books in a library can also be considered resources.'

A resource has identity which it preserves over time - hence the need to
locate it again once RDF is asserted about it.

A URI is a name (`A URI can be further classified as a locator, a name,
or both.'). That's how we locate the resource a second time...

The glossary in the M&S: 
`Resource
An abstract object that represents either a physical object such as a
person 
or a book or a conceptual object such as a color or the class of things
that
have colors. Web pages are usually considered to be physical objects,
but the 
distinction between physical and conceptual or abstract objects is not 
important to RDF.'

Here a resource is an abstract object that represents a physical object
-- or another abstract object with well-defined persistent identity.

So we have URI which `identifies' a resource which is either the thing
with `identity'... or something that represents it.

If the phrasing of RFC2396 means that this `identity' which is the
defining property of a resource *is* the URI, this would make the
document somewhat self-serving and identity means very little. But it
would be the basis on which you can say `r1.uri == r2.uri <=> r1 == r2'
without any further discussion of the application of URIs to the real
world. I don't think you can.

RFC2396 also suggests that resources not only map well to entities but
are entities (but for a trivial 1-to-1 mapping).

In this case our issues are settled as you imply. The resource is the
entity (the sequence of bytes or atoms) or at most a trivial mapping.
And URI equivalence is guaranteed by definition.

If we use the M&S glossary entry (which I think we need to clean up), we
have an abstract object which represents the entity. This is indeed a
mapping (Brian's D). This allows multiple representation: two resources
can indeed represent the `same' entity (D(r1)==D(r2)).

RFC2616 is clearer but at the cost of defining resource as `A network
data object or service' and entity as its retrieval: this ignores the
problems of fixing identity without a formal retrieval process (the
`musings' are TimBL's in this case). A personal resource may not have a
physical identity but a functional one: am email address can represent a
time-varying set of physical entities.

On question 2----------------------------------------------------------

Brian McBride wrote (concerning his working model):

>   There is a set of resources R.
> 
>   Each member of R is identified by a URI by which I mean:
> 
>     r1.uri == r2.uri <=> r1 == r2
> 
>   i.e. two resources are identical if they have the same URI.
>   two resources with different URI's are different resources.
>

Dan Connolly wrote:

Can two different URI's name the same resource? 

but I think it can actually be reduced to a test case:

... test case removed ...

If we decide that subClassOf works like conventional subset
then we can conclude from the above that (the absolute
forms of) #Car and #Automobile denote the same resource.

I suggest the answer is: yes.

(and it's independent of fragment identifier issues;
use uuid:2l3kj23lkj32lkj3 in place of #Car above
and the questions remain the same.)

--------------------------------

I may be misunderstanding these cases but it seems that an argument from
definition says no and an argument from application says yes. This
suggests we're not applying the definitions.


OK. The M&S says that RDF asserts facts about resources and that
`resources are always named by URIs plus optional anchor ids'. That
doesn't define resources but the glossary says that `resources represent
entities'.

I'm concerned by the notion of identity behind all this because I think
it's the underlying issue. An entity is a set of properties some of
which will get expressed in RDF: hopefully the set of persistent
properties which are the entity's identity contains the set of
properties asserted by the RDF. A resource can represent it (apparently
only for the momentary purpose of RDF assertion (hence my following of
the previous conversation)), and that representation is possibly a tool
of the RDF process. Two resources can represent the same entity as Dan
says it can happen by a process of identification over a sub-space of
properties (certainly if the entities are abstract as here).

I suggest:

a definition of entity which addresses a practical view of identity
preservation which can include a consistency of retrieval status if such
is feasible (the `200 OK HTTP' or equivalent). It should be stated that
the identity of the entity is a vital qualification of the assertion of
RDF statements.

a definition of resource that can acknowledges its status as an abstract
representation (thus avoiding the need to describe a resource's physical
characteristics) -- the point in geometry -- and its use as part of the
RDF process..

a definition of the proper use of a URI to map to a resource with
maximum specificity (following RFC2396 as much as possible) (possibly
(to avoid Dan's sleight of hand) to within an identification of a
sub-space of properties -- I don't know how to express Dan's process in
general...)

Issue part 1 (resource is sequence of bytes) delivers a no
Issue part 2 (two URIs for same resource) delivers no but two resources
can represent the same entity (and this should be said).

I trust that's focussed enough this time. I think it firms up the base.
It's just my opinion of course...

-- 
Martyn Horner <martyn.horner@profium.com>
Profium (former name Pro Solutions), Les Espaces de Sophia,
Immeuble Delta, B.P. 037, F-06901 Sophia-Antipolis, France
Tel. +33 (0)4.93.95.31.44 Fax. +33 (0)4.93.95.52.58
Mob. +33 (0)6.21.01.54.56
Internet: http://www.profium.com

Received on Tuesday, 8 May 2001 11:32:10 UTC