On 08/11/2007, at 3:00 AM, Terry Halpin wrote:
> I agree with all your goals -- we are planning similar
> functionality, so I hope we can somehow unify our work or at least get
> good interoperability.

Certainly - that's what the metamodel forum (RIP) was meant to be about.

> We plan to allow many different styles for distinguishing object
> type names.

I plan to avoid the need to distinguish them. When a term has been
defined in a model, it becomes a reserved word that may not be
used except where that definition is indicated. The important thing is
to avoid cluttering the vocabulary, by restricting the true reserved
words, and by partitioning imported vocabulary into right-sized pieces.

> One alternate style we have long
> planned to support is underlining, as used in SBVR.

Underlined text isn't really plain text, though I guess a lead could be
taken from email processors that highlight words having a leading
and trailing underscore.

> The use of an SQL-like as-clause to introduce role names is
> interesting (instead I have been using square brackets for this). One
> general issue with pseudo-reserved words is how to indicate when they
> are to be interpreted as reserved

> For example, in the fact type "Person
> is a parent of Person" I want "a" to be included simply as part of the
> predicate, while in the constraint "Each Person was born on a Date" I
> want "a" to be extracted as an existential quantifier. Similar issues
> arise with "as", "some" etc. For example, consider the unaries "Person
> is as happy as can be" and "Person has some reason for living". My
> current approach is to have the user indicate in context (e.g. by
> bolding) which word occurrences are to be treated as reserved. What is
> you approach here?

I have some liberty with this in most of the grammar, because when
it's known that a fact type reading is being set out (either in an
initial
declaration or as a clause in a derived fact query), most words that
are reserved elsewhere can be made available. The ANTLR parser
generator makes this possible easily enough, though I have to
maintain a list of keywords that are abstracted from their keyword
meaning in this context. So for example in the declaration of a value
type, the keyword sequence "restricted to" is reserved:

EntryClass = Char(2) restricted to {'A'..'E', 'PW'};

but "restricted" and "to" are both allowed in a fact type reading.

The remaining list of keywords that act as true keywords in readings
is quite short: "one", "exactly one", "at least one|N", "at most one|N",
"at least one|N and at most N", "some" and "as". The quantifiers that
get inserted during verbalisation can't be removed from this list (and
I use that to allow setting out constraints even in the initial use
of the
reading).

If it seems truly necessary to allow the use of "as", it could be
parenthesised without losing the natural English feel:

Person (as Mother) is mother of Person

Do you think this is preferable?

I decided not to enclose readings in a special context (like quotes,
parentheses, etc), which does make it harder to differentiate them
from comparison clauses while parsing queries. This might add
some further constraints on the content of readings. For example,
given the fact type "Person has some birth Date" (or alternatively,
"Person has birth- Date;"), and assuming a system function
"CurrentDate()", I can write the derived fact type:

Person is of Age at Time:
Person has birth Date,
Time - birth Date = Age;

Notice how the hyphen-bound prefix "birth" is re-iterated in the query
in both instances; "birth Date" here is a query variable. (I'm still
trying
to find a better way to handle time without having to include it
explicitly
in every time-deictic fact type.)

I'm still working with this grammar, so issues may yet arise, but so
far it's looking good.

> We are making great progress at last with NORMA now that we have
> live OIAL implemented, so you should see some major enhancements in
> the
> near future.

That's great news. I hope that some part that encapsulates your
relational
mapping can be abstracted to allow a command-line tool like a CQL
processor to use it on any platform... I guess that'll require Mono :-).
Otherwise I'd like to see an encapsulated mapping module that can
be translated to languages outside DotNET...

> I look forward to see how your CQL tool can interoperate with
> NORMA.

Of course. I will know I have the DDL finished when my converter can
export any NORMA model to CQL (and a few things of my own are
done, like units support). So far, I haven't made a serious start on the
"interesting" constraints, or subtyping. I'm not sure you'll like my
approach to objectification either. But I do have simple models being
exported already, and parsing. I'm still working in Ruby, of course, but
with IronRuby, that's available in DotNET as well.

Clifford.