Questions About The List Argument of Properties Like "unionOf"

I have recently been doing some design work on a DAML+OIL reasoner, and
have come upon some issues about the DAML+OIL language on which I need
clarification.  Here is one that I would like feedback on from the
language design committee:

The issue has to do with the list that is the value of the "unionOf" and
"intersectionOf" properties.  I know that the standard usage of those
properties would involve specifying the items of an anonymous list as
their value, as in:

   <daml:Class rdf:ID="CommonPet">
     <daml:unionOf rdf:parseType="daml:collection">
       <daml:Class rdf:about="#Dog"/>
       <daml:Class rdf:about="#Cat"/>
     </daml:unionOf>
   </daml:Class>

However, I don't see anything that would prevent one from using a named
list as the value.  So, it seems one could include the following in a
DAML+OIL knowledge base (I am using RDF statement syntax here rather
than markup):

(type L List)
(_1 L "#Dog")
(_2 L "#Cat")
(unionOf CommonPet L)

My first question is whether the value of "unionOf" in a statement can
be a named list.

If not, is that restriction stated somewhere in the spec?

If so, then what happens if one adds an item to the list?  

For example, that could occur if one had a DAML file that included an
ontology containing the definition of CommonPet given above, and the
file contained the statement "(_3 L "#Elephant")".  The class CommonPet
as used in this file would include elephants, whereas CommonPet included
only dogs and cats in the ontology used in that file.  Statements that
change the contents of a list that is the value of unionOf are
essentially nonmonotonic additions to the knowledge base, since one
could prove that Clyde the elephant was not a common pet before the
statement above is added and that conclusion would be false after the
statement is added.

So, my second question is whether such changes are allowed to the value
of "unionOf" and to the values of other properties that are used to
define nonprimitive classes.

If not, is that restriction stated somewhere in the spec?

If so, what about the apparent problems such changes could cause?

Richard

Received on Wednesday, 18 April 2001 00:07:12 UTC