Re: basic decisions underlying DAML-ONT

   [jim hendler]
   Actually, we did want to include defined classes in this release, but 
   there were some problems we couldn't resolve right away, so they are 
   on a TO-DO list (which is a good idea, thanks Peter).  The key 
   problem was that a goal of DAML as a language is to allow things to 
   be stated, but not necessarily to force one particular inference 
   model on things.  Consider the case which Ian Horrocks and I 
   discussed of "expensive-printer" -- we want to have a defined class 
   for this that says a printer is an expensive printer if it costs more 
   than $500.
     Easy to express, we would say there is some
      DefinedClass (expensive-printer)
	type printer
	cost >$500
   notice this is different than the primitive class "printer" because 
   we want it to be inferred that some printer is in this new class when 
   we learn that its cost is greater than $500.
     But here's the problem - remember the new game! We're on the web, so 
   someone somewhere defines something as a printer, some catalog 
   somewhere defines its cost as $1000.  Is the system inconsistent if 
   we don't return that printer as an expensive printer???  That is, can 
   we insist that there must exist a distributed mechanism that will 
   somehow find these two facts (which are likely on different pages, 
   maybe even pointing to different name spaces that in turn point to 
   other things that eventually both share the same DefinedClass)??

I don't quite understand the danger here.  The fear seems to be that
we might have a set of facts represented and a consequence of those
facts which is not explicitly represented (or easily inferrable on
demand).  Surely this is inevitable, regardless of whether the facts
are scattered around the web or located in one place.

                                             -- Drew

Received on Thursday, 12 October 2000 13:19:45 UTC