**From:** pat hayes (*phayes@ai.uwf.edu*)

**Date:** 10/16/00

**Next message:**Dan Connolly: "Re: Some questions/comments on the DAML draft (no operators)"**Previous message:**Zanger Daniel: "Re: Some questions/comments on the DAML draft"**In reply to:**Dan Connolly: "Re: Some questions/comments on the DAML draft"**Next in thread:**Dan Connolly: "Re: Some questions/comments on the DAML draft (no operators)"**Reply:**Dan Connolly: "Re: Some questions/comments on the DAML draft (no operators)"**Messages sorted by:**[ date ] [ thread ] [ subject ] [ author ] [ attachment ]**Mail actions:**[ respond to this message ] [ mail a new topic ]

>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 >ambiguous? 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 > http://www.sds.lcs.mit.edu/Larch/handbook/RelationOps.html >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 phayes@ai.uwf.edu http://www.coginst.uwf.edu/~phayes

**Next message:**Dan Connolly: "Re: Some questions/comments on the DAML draft (no operators)"**Previous message:**Zanger Daniel: "Re: Some questions/comments on the DAML draft"**In reply to:**Dan Connolly: "Re: Some questions/comments on the DAML draft"**Next in thread:**Dan Connolly: "Re: Some questions/comments on the DAML draft (no operators)"**Reply:**Dan Connolly: "Re: Some questions/comments on the DAML draft (no operators)"**Messages sorted by:**[ date ] [ thread ] [ subject ] [ author ] [ attachment ]**Mail actions:**[ respond to this message ] [ mail a new topic ]

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