Re: DAML-ONT: the case for closedness

Jeff Heflin <heflin@cs.umd.edu> wrote:
>"Peter F. Patel-Schneider" wrote:
> >
> > If some other modeller wants to augment the
> > properties of a primitive class then I don't see why this should not be
> > allowed.  Of course this other modeller can get into trouble by adding
> > properties that should not be there, but I don't see that the goal of a
> > modelling language is to prevent modellers from doing wrong things, nor
> > do I see that there is any way of preventing such mistakes in any case,
> > even if that was desired.
> >
>
>True, there is no way to prevent modellers from doing wrong things, but
>it would be nice if we could prevent one modeller from screwing up the
>world for everyone else. We don't want some kid in the Phillipines to
>create an ontology that breaks or changes the meaning of the globally
>agreed to "E-commerce ontology," but if he needs to refine it to include
>rules and definitions to describe some particularly innovative product
>he's selling, then by all means we shouldn't restrict him. This is our
>conundrum. We want to prohibit poor or worse yet, malicious extensions,
>while allowing beneficial ones. Yet, how can a software agent determine
>which category a particular ontology falls into?

Well, one thing the agent can determine is the URI of the assertion, 
so it at least has a head start. The kid can say whatever he wants on 
his page, but unless the modeller's page refers to the kids page 
(presumably unlikely) then we can determinewho is commenting on who. 
I dont see that there is any danger here of the kid screwing anything 
up (except maybe for an agent who just naively believes everything it 
reads, but such an agent wouldnt be safe on the web in any case.) I'm 
ignoring genuine hacking here, of course, which is a different 
category of problem.

>This is one of the
>problems that I thinks makes KR on the Web more difficult and exciting
>than traditional KR.
>
>Jerome's idea of saying that a particular definition is "closed" is an
>interesting one and might be useful in certain situations. However, I am
>unsure how many definitions on the web can truly be closed. After all,
>most logical theories are just approximations and there are often rules
>that could be added to make the approximations more accurate.

Ontology languages have traditionally taken a rather different line, 
however, which is one of the main sources of difference between 
description logics and, er, real logics.

>As a
>result, you run the risk of people closing things that really shouldn't
>be closed, which could lead to fragmentation as other people generate a
>new term for the concept just so they can refine the definition in order
>to get a better model of the world.

Seems to me it would be fine to allow an iff-definition construct, 
but not to think of this as being in any sense a way to *prevent* 
someone else saying something else about the defined concept (in much 
the way that if I say P that doenst prevent someone else saying 
not-P). How one ought to interpret the meaning of such an 'illegal' 
addition remains open. A strict interpretation would be that to add 
meaning to a fully defined concept is just a contradiction; but it 
might be more constructive to allow a kind of 'unwrapping', where A 
asserts that P is iff-defined to be Q, but B can say that he only 
wants the if part of the definition, allowing B to consistently add 
extra conditions. while still being able to infer things from Q (and 
more significantly, to indicate that B is using the same concept that 
A is and intends them to be synonymous.) This is rather like B saying 
"I mean what A means by this, but I disagree with A's way of 
characterizing it". The upshot would be that A no longer could be 
taken to warrant all the inferences that follow from B's use of P. 
This is fine as long as everyone else can check whether a conclusion 
is warranted according to a particular source. As a third party who 
wants to refer to and use the P-concept, I can decide whether to 
point to A or to B, and depending which I choose, I'll be accepting 
different 'versions' of P (which will have different URI's, so will 
have different names in RDF/DAML.)

Pat Hayes

---------------------------------------------------------------------
IHMC					(850)434 8903   home
40 South Alcaniz St.			(850)202 4416   office
Pensacola,  FL 32501			(850)202 4440   fax
phayes@ai.uwf.edu 
http://www.coginst.uwf.edu/~phayes

Received on Thursday, 19 October 2000 14:32:53 UTC