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>
------------------------------------------------------------