Re: How to capture modeling information in WOL

From: Frank van Harmelen <Frank.van.Harmelen@cs.vu.nl>
Date: Sat, 29 Dec 2001 00:31:57 +0100
Message-ID: <3C2D00ED.9B27229@cs.vu.nl>

```Dieter wrote:

> > I recall many discussions on how to deal with modeling information in
> > a logical framework. Lets take a simple example. A statement like
> >
> >       (1) a & b
> >
> > should be treaded completely equal to a statement
> >
> >       (2) b & a
> >
> > at a logical level. However, at a modeling level you may want to know
> > whether a person wrote (1) or (2) because it may reflect the fact that
> > b is more "important" to him.

Ian replied:

> On the web we often wont know who (or what) said what, or in what
> order. Machine processing may mangle syntax. Users may have widely
> divergent backgrounds and cultures. All these considerations (and
> probably others) suggest that it would be dangerous to make
> assumptions based purely on one interpretation of the meaning of a
> given ordering.

Ian,

I agree with you that Dieter's examples were not very well chosen, but I think the point still stands: there are logically equivalent statements which carry a different "pragmatics", or "intention" or "modelling style" or whatever one wants to call it.

Of course it is risky to write about this, because it is by definition soft fluffy stuff, but nevertheless quite important to many people (exclusing logicians, perhaps).

Alternative examples could perhaps be:

- "a -> b" is equivalent to "~a V b" but I've seen many good modellers preferring one over the other in certain situations. The first says something like "whenever a is true, b must also be true", the second says something like "at least one of these two is true". (And yes, of course I know the truth-tables of FOL, but still).

- "~(a & b)" is equivalent to "~a V ~b", but many people would prefer the first if they want to express a constraint to the effect that a and b cannot be true simultaneously. (and yes, I know that the 2nd form says that at least one of them must be false, so that's the same thing, but still. I'm observing, not defending).

- (more from the ontology world): given 3 classes c1,c2,c3 and a relation r, the following two are equivalent:
- stating that r(x,y) holds for all pairs (x,y) in (c1,c2), (c2,c3) and (c1,c3)
- stating that r(x,y) holds for all pairs (x,y) in (c1,c2) and (c2,c3) plus the fact that r is transitive
Nevertheless, they two statements "feel different" because in the second case the transitivity of r is enforced as an explicit property, while in the first case it just "happens to be the case". When extending the model with a class c4, and r holding for all (x,y) in (c3,c4), I would probably have different expectations about r w.r.t. c4 in the two formulations. (No, there would be no logical basis for such expectations, but still).

Also, even in the design of OILed, I've heard you and/or Sean Bechhofer say that is very hard to recover the user's original modelling-intention from a list of logical axioms that we know to be logically equivalent to that intention, but without any further structure.

Thus, I think it is very important that OWL does not only focus on "logical equivalence" of statements (something that DAML+OIL has focussed on exclusively), but that it is possible to capture something like the "modelling style" or the "syntactic form" of logically equivalent expressions.

(Yes, I know this is shakey grounds, non-monotonicity is lurking, etc, but still).

(Actually, I don't think this is something that needs to be part of the language definition, but something that should be possible to be captured by tools such as editors. The language needs to give sufficient infrastructure for them to do this. DAML+OIL does not give sufficient infrastructure for this).

I'm not at all convinced that Dieter's proposal on using RDF-entailment for reasoning about the syntactic structure makes sense, but I would support the general desire to make such distinctions in some way or other.

I would like to hear what others in the group think on this.

Frank.
----
```
Received on Friday, 28 December 2001 18:34:50 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:56:40 UTC