Clearing the trees? (was: Chainsaw?)

Folks,

I'd like to thank those of you who responded to my earlier comments about 
using contexts to model classes of objects.  As a result of comments 
received, I'm feeling more confident about pursuing the idea of contexts 
(or statement sets) that are also classes.

However, I'm still having problems with finding a sufficiently flexible 
mechanism to bind "prototype" statements into an instance of some 
class.  The solutions I've seen posted so far assume that the statements 
apply directly to an instance of the class in which they are defined.  I 
think this is too restrictive for defining complex relationships and 
prototyping structures;  e.g. Tom (if Iunderstand correctly) has proposed 
something like:

    [FordEscort] --rdf:type---> [rdfs:Class]
    [          ] --bodyStyle--> "HatchBack"
    [          ] --fuelType---> "Petrol"

and

    [MyCar] --rdf:type--------> [FordEscort]
    [     ] --bodyColour------> "Red"
    [     ] --engineCapacity--> "1600"

to create a description meaning something like:

    [MyCar] --bodyStyle-------> "HatchBack"
    [     ] --fuelType--------> "Petrol"
    [     ] --bodyColour------> "Red"
    [     ] --engineCapacity--> "1600"

This simple approach works only when the properties defined in the 
[FordEscort] prototype are applied *directly* to an instance of that 
prototype.  In some of the modelling work we have tried to do, this kind of 
direct linkage of all properties to an instance of a type is too 
constraining to be practically useful.  This is one of my motivations for 
trying to use contexts, so that I can create a high-level description of 
MyCar and subsequently refine the parts:

    [MyCar] --rdf:type--> [FordEscort]
    [     ] --asserts--->
      {
      [TheBody] ----colour----> "Red"
      [TheEngine] --capacity--> "1600"
       :
      (etc.)
      }

(Using here the notation "[<context>] --asserts--> {<StatementSet>}" to 
capture the idea of a collection of reifications of statements that are 
asserted to be true in the subject context.)

This structure allows us to make statements about entities that may be 
directly or indirectly related to [MyCar], without necessarily having to 
know up-front the nature of that relationship.  It allows us to make 
statements about what we know, without having to make up arbitrary (and 
probably flawed) statements about what we don't know.  It is my conviction 
that enabling such an incremental approach to information modelling will be 
extremely powerful for dealing with complex relationships.

So, what's missing?  It comes back to defining ways to relate prototype 
statements to a specific instance of a class.  Brian has made an 
imaginative proposal, based on a "logic" of type matching between the 
prototype and the instance context.  I feel this is still to restrictive.

I am thinking about the discussion of "anonymous" resources, and also 
comments made by Pat Hayes on the RDF-logic list 
<http://lists.w3.org/Archives/Public/www-rdf-logic/2000Oct/0112.html>, 
<http://lists.w3.org/Archives/Public/www-rdf-logic/2000Oct/0122.html>.  I 
think Pat has it right:  that what is required is a way to introduce 
"proper names" that have a common (but unspecified) referent within some 
range of use (not lexically defined), and which may be bound to different 
globally unique names (URIs) in different contexts.

This would lead to my example becoming something like this:

    [FordEscort] --rdf:type---> [rdfs:Class]
    [          ] --rdf:Type---> [Context]
    [          ] --asserts---->
      {
      [Body] ----style-----> "Hatchback"
       :
      [Engine] --fuelType--> "Petrol"
       :
      (etc.)
      }

    [MyCar] --rdf:type--> [FordEscort]
    [     ] --asserts---> [FordEscort]
    [     ] --asserts--->
      {
      [Body] -------bindTo----> [TheBody]
      [Engine] -----bindTo----> [TheEngine]
       :
      [TheBody] ----colour----> "Red"
      [TheEngine] --capacity--> "1600"
       :
      (etc.)
      }

(The presentation is clumsy;  at this time I am merely trying to illustrate 
the idea of binding proper names used in one context to specific resources 
described in another.)

Here, the property 'asserts' with a context as its object is used to state 
that all statements asserted in the object context are also asserted in the 
subject context.  The 'bindTo' property is used to assert an equivalence 
between two names (within the context containing that assertion).

All this presupposes the introduction of a resource identifier form along 
the lines of "proper names", which may be regarded as a departure from 
conventional RDF/WEB thinking.

#g
------------
Graham Klyne
(GK@ACM.ORG)

Received on Thursday, 2 November 2000 07:36:20 UTC