Re: P.S. Re: Model Theory

At 2:52 pm -0600 3/1/02, Dan Connolly wrote:
>Amen to this:
>On Thu, 2002-01-03 at 13:14, Ian Horrocks wrote:
>>  It might also be worth adding that in the early days of DAML+OIL the
>>  group wasted a lot of time discussing/arguing about the meaning of
>>  RDFS constructs, such as range and domain, whose semantics was (then)
>>  only informally specified. I would suggest that we don't want to
>  > repeat that mistake with OWL.
>>  Moreover, formalising the semantics of range and domain made it clear
>>  to all concerned that the most obvious reading of the informal
>>  specification had unintended and undesirable consequences. The RDF WG
>>  has since fixed this problem, but they may never have known about it
>>  without the formalisation.
>>  Ian
>At the end of the day, we want a document that causes this
>technology to get deployed. Experience (as noted above) has
>convinced me that a model theory (and/or axiomatic semantics...
>I'm still studying both approaches) is cost-effective
>in persuit of that goal.

I don't think anybody can deny that some kind of formal specification 
is very useful to understand representations.  For instance I have 
found Fikes and McGuinness axiomatic semantics for RDF(S) and 
DAML+OIL <<very, very useful>> (indeed, crucial!) to understand these 
representations.  However, as Lynn was saying we should be pragmatic 
about this. For me pragmatism means that from time to time we ought 
to remind ourselves that KR is an engineering activity and semantics 
is an important support, but   not an end in itself.  In other words, 
a formal semantics is a desirable property for a KR language but it 
is not a sufficient condition to come up with a good language.  So, 
what does it mean in practice? I would like to propose to the WG the 
following two 'pragmatic' guidelines:

1) Different ways of providing semantics exist, so we should be 
pragmatic about how we go about specifying semantics

2) Some 'KR programming cliches' are useful in practice but are 
tricky to formalise in a model theory (e.g., reification, defaults, 
etc..). Now, taking a 'pragmatic' approach means that we do not 
<<automatically>> discard these constructs, simply because we do not 
know how to write the model theory.  Maybe an alternative approach to 
specification can be used, or maybe we simply state algorithmically 
how intepreters will deal with these constructs. Of course, not 
everything will be in OWL, but the rationale for leaving things out 
should be primarily based on KR utility and computational efficiency.

- Enrico

Received on Monday, 7 January 2002 06:38:19 UTC