What are the behaviors of `Disj[T]` and `Conj[T]`?

[mrmechko]

It seems that Conj[T] would require an Ordering which sorts elements by hierarchy precedence and then a simple override combination operator, which is in turn a monoid. Specifically, Conj[T](T1, T2, T3) results in a potentially new value T4.

Disj[T] is a little less clear to me:

Given Disj[T](T1, T2, T3), is the value of Disj[T] is one of T1, T2, T3 or is it some T4 which is a combination of T1, T2, T3?

[wdebeaum]

OK, first let me make sure I've got the terminology/notation straight:

• T is a variable denoting a type (programming language type, not ontology type)
• Conj[T] and Disj[T] are generic types with T as a parameter
• T1-T3 are variables denoting values of type T
• Conj[T](T1, T2, T3) denotes a value of type Conj[T], which is in some sense the conjunction of the values T1-T3, and which you are also calling T4 even though it's not a T... Though I guess in the specific case of DSL's concept type and its subtypes, I did say that Conj[T] and Disj[T] were subtypes of T. But there are also Disj[Symbol]s, which are not necessarily Symbols.
• Ordering[T] is essentially Scala's way of saying "the type of ways to put values of type T in order relative to each other". It's unclear to me whether that's required to be a total order or just a partial order, but in this context I'm guessing you're going for total order.
• A monoid is a set with an associative operator that has an identity element.

I don't think you need to worry so much about sorting the things being Conj'd together (which I'll call "conjuncts")... in the TRIPS ont/lex the conjuncts are generally different subtypes of concept, responsible for different slots, so you just take the value of each slot from the conjunct that actually has it. But you're right, there needs to be something like an operator for combining concepts, that forms a monoid with the set of concepts, and handles overriding. Though I'm not sure how important it is that it's a monoid... associativity and identity are nice properties but I don't immediately see how it helps to know that they hold for this operator.

This is an area that I never really finished writing the Lisp library code for. I wasn't really thinking about it in terms of operators and monoids, but I think I did start out thinking I should be merging concepts together to produce some merged concepts of the same type (or some least-common-subsumer type). But I'm not as sure about that now. It might be better to just preserve the logical structure unmerged, until it's time to spit out the relatively flat list of features that goes into the Parser. Then it's more like a tree traversal over that logical structure.

There is another situation where actual merging would be appropriate, which I forgot about until just now when I looked at the FIXME comment I left about it. When we're loading a concept, and have thus already created an object for it and maybe filled some slots and associated the object with the concept name in the database, we can run across an alias that says this is actually the same concept as is already represented by another object in the database. Then we have to merge the new concept into the old one, or vice versa, and then update all references to one of the objects so they point to the other one. But I guess you don't have to worry about this because the TRIPS lex/ont doesn't have aliases; that was just a feature I added to DSL to support importing other ontologies that do have multiple names for the same concept.

Re: Disj, the result of Disj[T](T1, T2, T3) is more like a unification variable that's constrained to have one of the given values. It could be any of T1-T3, but you don't know yet. In fact, in the original TRIPS Lisp format, you're required to name that variable, even if you don't use it elsewhere in its scope (and its scope is kind of implicit... there's no for-all or there-exists or let to make it explicit). So for example, the word "alert" (ONT::inform) can use one of two different prepositions for its formal role: "about" or "to". I would represent this as (or about to), but in the original it's (? ptp w::about w::to). The (? ...) syntax says "hey, this is a variable", and ptp is the variable name (short for "preposition(al phrase) type").

When the disjuncts are concepts, I think I still represent it as just (or T1 T2 T3), but notionally what you're doing is creating a new concept that subsumes all of the disjuncts. That's sort of symmetric with Conj, in that there you have a new concept that is subsumed by all the conjuncts. The new concept's extension is the intersection (union) of the extensions of the conjuncts (disjuncts). So there are no overrides among sibling conjuncts; if two of them conflict, then the resulting interesected extension is the empty set. Overrides only come into play when dealing with inherit relations (which is why it's not called subtype-of).