W3C home > Mailing lists > Public > www-rdf-logic@w3.org > October 2000

Re: DAML-ONT: the case for closedness

From: Je'ro^me Euzenat <Jerome.Euzenat@inrialpes.fr>
Date: Wed, 18 Oct 2000 23:31:49 +0200
Message-Id: <p04310105b613bfb19438@[]>
To: pat hayes <phayes@ai.uwf.edu>
Cc: www-rdf-logic@w3.org

In his message (Re: DAML-ONT: the case for closedness) of 16/10/00,
pat hayes wrote:
>I previously wrote:
>>	However, it could be nice to allow users to close the meaning 
>>of a name so that no one can add to it.
>Well, seems to me that there is little point arguing about whether 
>or not it would be nice, because it is impossible. Once some content 
>is published on the web, there is absolutely no way to prevent 
>someone else from referring to it and maybe 'adding' to it on their 

I certainly was not clear enough. Of course, it is not conceivable to 
prohibit the reference and the reuse of ontology; this was not my 
But, it is not the same to say (not very well chosen example):
- "a car is a vehicle with four wheels" and nothing else can be said 
about cars (but if course you can have refinement of the car concept, 
but these are not all the cars)
- "a car is a vehicle with four wheels" and you can add many more 
assertions about cars in general which will restrict the meaning of 
that concept that I do not know to characterize more precisely and 
that you can refine depending on your needs.

	Currently DAML-ONT only permits to express the second. I 
suggested that in order to be trusted, ontologies must have some 
stable bases on which you know you can build. This might help 
adopters to feel safer with these ontologies and might contribute a 
bit to the web of trust.

>>In the first case, if someone adds new constraints, then you know 
>>that this does not have the approbation of the ontology authority, 
>>in the second case, the authority does not have to endorse the 
>>constraint but it is legitimate. This would be useful, for ontology 
>>designers to state what a name exactly means and to allow 
>>refinements (through subclassing) but no modification (through 
>The best we could do would be to have a restricted inference mode 
>which would refuse to recognize (or anyway to refuse to accept) any 
>assertional modifications which do not have the imprimateur of the 
>originating source. But we cannot guarantee that someone or 
>something will not draw a conclusion which uses resources other than 
>those we authorize.

Yes, but where is the imprimatur in DAML-ONT? Allowing to close the 
definition of a term (or to close its extension, or to close its 
refinements...) is just one way to say "Here, I have the 'complete' 
definition of what I consider to be X".
[For philosophical correctness, I should not say a complete in the 
intentional sense: i.e. "whatever can be said has been said" because 
we all know that in a language with negation it will be possible to 
add many statements to a definition which do not add restrictions. 
But you can take complete in an extensional sense, where I am sure 
that you cannot add true statements about the term which restrict its 

>The real challenge (for me) is to somehow make sense of these ideas 
>of 'authorization' and 'source' and integrate them into the semantic 
>theory.  A public ontology is a different kind of thing from a 
>private ontology, in much the same way that speech differs from 
>thought, and its theory of meaning will need to be extended to cope 
>with the social aspects involved.

Of course, this is a more ambitious challenge. My proposal was rather 
minimalist with regard to it.
  Jérôme Euzenat                  __
                                  /      /\
  INRIA Rhône-Alpes,            _/  _   _   _ _    _
                               /_) | ` / ) | \ \  /_)
  655, avenue de l'Europe,    (___/___(_/_/  / /_(_________________
  Montbonnot St Martin,       /        http://www.inrialpes.fr/exmo
  38334 Saint-Ismier cedex,  /          Jerome.Euzenat@inrialpes.fr
  France____________________/                Jerome.Euzenat@free.fr
Received on Thursday, 19 October 2000 04:06:52 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 2 March 2016 11:10:32 UTC