Re: Some questions/comments on the DAML draft

From: pat hayes (
Date: 10/16/00

>pat hayes wrote:
> >
> > In DAML-ONT:
> >
> > </Property> <Property ID="disjointUnionOf">
> > <label>disjointUnionOf</label>
> > <domain resource="#Class"/>
> > <range resource="#List"/>
> > <comment>
> >
> > for unionOf(X, Y) read: X is the disjoint union of the classes in
> > the list Y: (a) for any c1 and c2 in Y, disjointWith(c1, c2),
> > and (b) i.e. if something is in any of the classes in Y, it's
> > in X, and vice versa.
> >
> > cf OIL disjoint-covered
> > </comment> </Property> <Property ID="intersectionOf">
> >
> > <! COMMENT: This isnt the usual notion of 'disjoint-union'. The 
>usual one is the union of two disjoint copies of the arguments. 
>Imagine replacing A and B by A' and B' where A' differs from A in 
>having all the elements of its intersection with B marked as 'first 
>copy', and similarly for B' but marked 'second copy', then the 
>disjoint union of A and B is the union of A' and B'. So for example 
>the disjoint union of a set with itself is a set with two copies of 
>everything in the original set. >
>Two copies? in a set? I don't understand.

Two *distinct* copies. Intuitive example: suppose one takes the set 
of all famous singers and the set of all famous painters, then their 
disjoint union has two copies of (at least) Tony Bennett, one as a 
singer and one as an artist. Their simple union only has one copy of 
him, of course.

>But perhaps something like "partitionedBy" would be less

Yes, that would indeed be clearer. But see the next comment.

> > <! QUESTION: what is the value of your disjoint-union when the 
>classes arent disjoint?>
>er... the same as the "value" of any other false assertion,
>such as 5<4.

Nah, but your disjoint-union isn't an assertion, its an operator. So 
what its value is when its ill-defined is not so easy to specify. 
Thats why I jumped on it, in fact: your definition is half assertion 
(the arguments are disjoint) and half operator/function (like union 
or intersection), so its neither fish nor fowl. One of the nice 
things about the classical operations like disjoint-product is that 
they are pure function, no assertion, so they always have a 
well-defined value.


> > <TransitiveProperty ID="ancestor"> <comment>@@need a property to 
>relate this to parent</comment>
> > <! This is actually quite tricky. What you want to say is that 
>ancestor is the transitive closure of parent, which means that 1. a 
>parent is an ancestor, 2. that ancestor is transitive, and 3. that 
>ancestor is the smallest (least true) property satisfying 1. and 2. 
>This last part is the trickiest part and is hard to state properly 
>even in full first-order logic. It might be a good idea to actually 
>have transitiveClosure in the language as a primitive if you really 
>think it is going to be used a lot, rather than try to define it.>
>Er... right... transitiveClosure is "a property
>to relate this to parent."
>as to being tricky to specify... I find the
>definition in the larch shared handbook
>fairly straightforward (after I puzzled over it a bit).
>I wonder if there's some
>built-in property of larch that hides the trickiness/

Im not intimately familiar with Larch, but indeed after rummaging 
around on that site I'd guess that 'generated by' (in boldface) is 
the part with the magic in it. Larch seems to just allow recursive 
type definitions without bothering to specify minimal interpretations 
explicitly, which is fine as long as one is open about it. No harm in 
having some magic built-in, but just make sure it really is built in 
and you don't set out to define it in terms that aren't magical.

Seriously: there is a genuine category difference between languages 
built on recursion (like a whole lot of 
programming/type-specification languages) and simple assertional 
logics which are basically subsets of first-order logic. Recursion is 
an inherently non-first-order notion, so if one has aspirations to be 
expressively modest (like OIL and CLASSIC) in order to take advantage 
of very rapid processing, then one shouldn't casually toss in 
recursive constructions as though they come for free, because in that 
world they don't. Drawing conclusions in Larch would be quite another 
kettle of fish.

>It would be in order, however, for you to suggest
>a better example for oneOf.

How about
  <Class ID="AgeGroup"> <oneOf parseType="daml:collection"> <AgeGroup 
ID="infant"/> <AgeGroup ID="child"/> <AgeGroup ID="adult"/> <AgeGroup 
ID="senior"/> </oneOf> </Class>

BTW, what does "parseType" mean, and when should we include it? (I 
know you guys mention this in the walk-through, but I can't 
understand what you say about it there.)

Pat Hayes

IHMC					(850)434 8903   home
40 South Alcaniz St.			(850)202 4416   office
Pensacola,  FL 32501			(850)202 4440   fax

This archive was generated by hypermail 2.1.4 : 03/26/02 EST