RE: Chainsaw?

Hi Graham,

One or two thoughts on this interesting question.

If I understand correctly, you are trying using
contexts to represent fixed property values for
an object.  I think it would certainly be
instructive to see how this is handled in OIL and
DAML.

I'm wondering whether this idea might help:

 [FordEscort] --ist-->
    {
    [anon:body] ----type------> [body]
    [anon:body] ----style-----> "hatchback"
    [anon:engine] --type------> [engine] 
    [anon:engine] --fueltype--> "petrol"
     :
    (etc.)
    }

Basically this is saying that in the context of FordEscort
all resources of type body have the style hatchback and all
resources of type engine have fueltype petrol.  Here I've
assumed the forAll can be implied by the context (sic)
- you might want to represent the forAll explicitly - see
earlier discussion.

You have to add type statements to the model of your car:

 [MyCar] --isa--> [FordEscort]
 [     ] --ist-->
    {
    [TheBody] ----type------> [body]
    [TheBody] ----colour----> "Red"
    [TheEngine] --type------> [engine]
    [TheEngine] --capacity--> "1600"
     :
    (etc.)
    }

Now I think you can deduce the properties you want.

Brian


> -----Original Message-----
> From: Graham Klyne [mailto:GK@Dial.pipex.com]
> Sent: 18 October 2000 15:44
> To: RDF interest group
> Subject: Chainsaw?
> 
> 
> There's an old Internet saying:  "when the only tool you have is a 
> chainsaw, everything starts to look like a tree".  I'm 
> wondering if my 
> musings on contexts are in danger of falling into this trap.  
> No mind, the 
> problems I am trying to tackle are real enough, and if the 
> best solution is 
> something else then that's fine by me.
> 
> I'm trying to capture in RDF the following kinds of idea, 
> currently using 
> contexts (and, in particular, the idea of a 
> context-as-language, with its 
> own binding of names-to-things).
> 
> Example:  I want to describe "My car", by reference to a make 
> and model, 
> but with local option selections.  Using a context to contain 
> a collection 
> of statements that describe my car:
> 
> [MyCar] --isa--> [FordEscort]
> [     ] --ist-->
>    {
>    [TheBody] ----colour----> "Red"
>    [TheEngine] --capacity--> "1600"
>     :
>    (etc.)
>    }
> 
> I am using here the notation "[<context>] --ist--> 
> {<StatementSet>}" to 
> capture the idea of a collection of statements whose reifications are 
> asserted to be true in the subject context.
> 
> But there is far more to know about my car than its colour and engine 
> size.  More than I could possibly know, so I want to use a 
> reference to a 
> description (presumably from Ford) that can contain all this 
> information.  This is represented by the link "--isa--> 
> [FordEscort]".  The 
> resource [FordEscort]  is, in turn, a context containing a 
> collection of 
> statements about this kind of car:
> 
> [FordEscort] --ist-->
>    {
>    [TheBody] ----style-----> "Hatchback"
>     :
>    [TheEngine] --fuelType--> "Petrol"
>     :
>    (etc.)
>    }
> 
> My problem is this:  when [FordEscort] refers to [TheBody] 
> and [TheEngine] 
> in reference to my car, how can I infer that these statements 
> refer to 
> parts of my car rather than some other person's Ford Escort 
> car?  I had 
> been thinking to tackle this using the association of language 
> (specifically, binding of names to things) with a context, 
> the idea of 
> referencing one context from another creating a nesting of 
> contexts (along 
> the lines of "ENTER Context1" then "ENTER Context2" from the 
> McCarthy/Guha 
> descriptions), and with some lifting rules allowing names to 
> be scoped from 
> a referencing context to a referenced context.
> 
> This seems to be at odds with using URIs to identify specific 
> things.  But 
> it seems to have some resonance with Brian's and DanB's discussion of 
> anonymous resources.
> 
> Finally, I have wondered if I may be going over well-trodden 
> ground of 
> frames and ontology work here.  If this has already been 
> tackled for RDF, 
> I'd appreciate some pointers to relevant work.
> 
> #g
> --
> 
> ------------
> Graham Klyne
> (GK@ACM.ORG)
>

Received on Sunday, 22 October 2000 05:13:37 UTC