Re: A use case for anon nodes - action from telecon

At 12:19 PM 7/26/01 -0700, pat hayes wrote:
>I think this example has been valuable because it illustrates a much 
>bigger and more important point than the one we started with. The implied 
>meaning to an English speaker is *completely irrelevant* here. RDF is 
>supposed to be used by software agents, not English speakers (if we could 
>rely on the native savvy of English speakers, we could do it all in HTML). 
>So the only content that any piece of RDF (or DAML, or KIF, or any of 
>these 'formal' languages for capturing content) actually contains is what 
>some mechanical agent could infer from it (together with whatever other 
>pieces of RDF it is able to glean from various sources, of course.)
>
>If you apply that criterion to Brian's example, and if you take it to be 
>an assertion, then all that you could possibly infer is that four things 
>exist and a few relations are true between them. If this is supposed to 
>convey the fact that one of these things is a 'service' and therefore that 
>it implies that a lot of other things exist (eg batches of roses which are 
>available for sale or purchase -I've lost track of whether we are selling 
>them or buying them), then something needs to say that.  Nothing in 
>Brian's example seems to say that, however, so there is no basis for 
>anything to be able to conclude it. (I would hazard a guess that the only 
>way to say what needs to be said here is to use a universal quantifier, by 
>the way.)

Yes... I think that the examples were incomplete in that a definition of 
specific symbols used (to be guessed at from the names used) was 
needed.  Without this, there was no logical distinction between the buyer 
and seller examples (modulo a small change of quantity values).

But, at some point, a computer program has to interface with the real 
world.  Maybe the only difference between the buyer and seller processes is 
that the results of invocation of the service are delivered to different 
printers.  It may happen that one printer is in a warehouse with a staff 
that reads the requested quantities and other details, picks the desired 
roses off the shelf and puts them in a van for delivery to the stated 
address.  That would be the seller service.  Another printer might be 
serviced by a staff who pick up the details and send their van to a 
designated address to collect some roses.  That might be the buyer service.

How much of this external-world difference do we need to encode in the 
computer program?  It may be that the only difference between the buyer and 
seller, as far as the program is concerned, is an associated port address 
that selects an appropriate printer to receive the service instruction.  So 
if the previous examples were augmented with something like:

    buyer usesPrinterPort "1" .

    seller usesPrinterPort "2" .

that states a logical difference between the services.  But the context 
within which the services are deployed (defining an interpretation?) is 
part of the situation in which we care about the results of the computation.

Maybe this goes against normal practice for model theory.  I notice that 
you said in your strawdog note that common model theory practice is to make 
the available domain of interpretation as general as possible.  I suppose 
that the vital thing we need is for programs to exchange information that 
is  constructed using the same assumptions about the interpretation.  The 
fewer such assumptions, the less room there is for a communication to be 
misinterpreted.  But I'm pushed to see how we can make a useful program 
without many assumptions about the environment it communicates with.

#g


------------------------------------------------------------
Graham Klyne                    Baltimore Technologies
Strategic Research              Content Security Group
<Graham.Klyne@Baltimore.com>    <http://www.mimesweeper.com>
                                 <http://www.baltimore.com>
------------------------------------------------------------

Received on Thursday, 26 July 2001 16:35:58 UTC