What is assumed?

Pat,

Some thoughts on your comments about flower traders are below.  I also note 
that your latest semantics draft addresses some of points I mention.

At 02:32 PM 7/26/01 -0700, pat hayes wrote:
>>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.
>
>Well, no. Of course programs rely on such things all the time, but my 
>point is that in cases like this the information is NOT being conveyed as 
>a 'logical difference', ie in this context, in the RDF, but in some other 
>way that is invisible to an RDF processor. Which is fine, as long as we 
>face up to that. In the meantime, however, I am assuming that what we are 
>supposed to be focussing on here is what can be said in RDF.

OK, it's not a *logical* difference.

>>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.
>
>If we were programming local computations in a limited, known context, 
>then we could rely on all kinds of assumptions. But RDF is supposed to be 
>publishable on the Web, right? What 'context' can be assumed between a 
>publisher of a web page and a reader of that web page, beyond the 
>protocols used to transfer the information?
>
>>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.
>
>If there are any global assumptions then by all means let us build them 
>in. In the strawdog, for example, I assume that literals have a fixed 
>global interpretation which never varies, so anyone using a literal can 
>assume that any reader will have the same interpretation. We can have 
>fixed interpretations for things like rdf:subject (in fact for anything 
>starting rdf: or rdfs:). But how do we establish globally fixed meanings 
>for things like wholesaleSupplierOfRoses ?

I think that a possible difference of RDF/DAML/etc from traditional 
maths/logic is that the names used (URIs) do have a globally fixed meaning, 
even if we don't know what they are...

I came into this whole area from the direction of content negotiation 
between software systems (in particular, between email user agents).  I 
have all along held a view that the mechanisms of content negotiation (i.e. 
form of description of content handling features, rules for selecting data 
that can usefully be transferred, etc.) and at this level I fully concur 
with your view of finding universal mechanisms that don't make any 
assumptions (e.g. about the features being negotiated).  But to actually 
use this in practice, particular features have to be assigned names for use 
in the negotiation process, and a user agent must be imbued with knowledge 
of what capabilities it has: how they are identified and what they mean in 
terms or utilizing the software and/or hardware capabilities of the 
agent.  Such instance knowledge about an agent cannot be captured in the 
theory of negotiation.

So, I think there are two parts to a system for content negotiation:  the 
common rules of negotiation which are based on explicitly defined 
knowledge, and the implicit knowledge (human-defined, hand-coded, etc.) 
that systems have of the symbols for things that they deal with (which you 
describe above as being "invisible to an RDF processor").  I see a  goal of 
our work being to maximize the explicit element, so it can be re-used 
across a widest possible range of applications.  This corresponds to things 
described by a model theory.  But I find I cannot conceive of a practical 
system that can completely dispose of implicit knowledge (which I think 
corresponds to a particular interpretation).

Returning to the 'wholesaleSupplierOfRoses', and Brian's example, the 
knowledge of buying and selling of roses is implicit.  Further, I don't 
think it is possible to come up with any example of a practical, useful 
system that does not depend on some level of implicit knowledge.

But with RDF, used as intended, the implicit knowledge associated with any 
URI symbol does not depend on the particular context, because URIs are 
defined to be globally unique.  In model theoretic terms, I suppose this 
means that there is only one interpretation for an expression, even if a 
processor may not know what it is.

>>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.
>
>I thought that was the central point of RDF. It certainly is for DAML+OIL.

I do not view the boundary between explicit knowledge and implicit as 
fixed:  in a sense, much of maths, and computing practice, has been about 
finding ways to codify and generalize specific knowledge and apply the 
results more widely.  I view RDF/DAML/etc as pushing that boundary, but I 
don't see the goal of completely eliminating implicit knowledge 
(assumptions) as being achievable.

#g


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

Received on Sunday, 29 July 2001 12:51:33 UTC