Hi Clifford
Thanks for posting my reply.
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.
We plan to allow many different styles for distinguishing object
type names. Capitalization typically works well in English, but not so
in some other languages such as German. One alternate style we have long
planned to support is underlining, as used in SBVR.
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?
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.
I look forward to see how your CQL tool can interoperate with
NORMA.

Cheers
Terry
===============================
Dr. Terry Halpin
Professor and VP Conceptual Modeling
Neumont University
10701 S. River Front Parkway #300
South Jordan, UT 84095
USA
e-mail: terry@...
phone: +1 801 302 2820
fax: +1 801 302 2811
web: www.orm.net


-----Original Message-----
From: Clifford Heath [mailto:clifford.heath@...]
Sent: Tuesday, November 06, 2007 6:19 PM
To: information_modeling@yahoogroups.com
Subject: Re: Hyphen binding and role names

On 07/11/2007, at 5:03 AM, Terry Halpin wrote:
> As usual, I'm snowed under with work. If this quick reply fails
> to make it to the group, please post it for me.

Thanks Terry, I've done that.

> ... I don't like your proposed changes ... I don't see what
> benefits they offer

I guess I should have given more context.

I'm trying to produce a grammar that allows creation of all
aspects of an ORM2 model using only text. Among my goals
are:

* to allow a natural language feel as far as possible (which
means fewest keywords and open syntax rules),

* to identify object types by requiring them to be pre-declared,
rather than rely on them being capitalised (though I'm using
capitalisation in my examples for clarity),

* to minimise re-iteration by allowing role names (as well as
the most common cases of mandatory and uniqueness
constraints) to be specified in the initial fact type declaration,

* integration with a query language to define derived fact types.
Some query clauses look very like fact type declarations...

All that produces a difficult parsing problem. In summary, your
focus in readings is to produce the best verbalisations as output,
and mine is to structure the verbalisations to be suitable input
from which readings, role names, and some constraints may be
extracted.

I'm also looking at the IBL query language by Adrian Walker,
which is a very powerful open-vocabulary English query tool,
that writes a logic program that's largely translated into SQL.
I don't like his query language much (it's limited by not having
the ability to define the underlying fact model), so I'm trying to
improve on it. It's at <http://www.reengineeringllc.com>, see
<www.reengineeringllc.com/
Oil_Industry_Supply_Chain_by_Kowalski_and_Walker.pdf>.

However, I think I can back away from the restrictive approach
I mentioned yesterday, by distinguishing an inferred role name
from a declared one. For example, in either of "Event starts at
some start Location", and "Event starts at start-Location", the
column name default to "StartLocation", not just "Location".

If that doesn't work, my grammar also allows "as X" to provide
a role name: "Person as Mother is mother of Person". Here
the fact type being declared is "Person is mother of Person",
but with a role name on the first Person. The "as" form is more
necessarily used in queries to separate multiple variables of the
same object type.

If there is more than one reading, I need to decide when to infer
a role name (and which...), and I also need to separate such
inferred role named from one declared using "as".

> (e.g. our technique allows you to use more than one adjective anyway).

I didn't realise that NORMA allowed more than one adjective,
thanks for that. I'll have to support that too.

Also the trailing hyphen-binding... there doesn't seem to be an
equivalent to the "some" form that could provide that. It'd be
nice to see examples that would show whether an inferred role
name would work here too.

I'm very close to being able to dump NORMA models into my
CQL model definition language, except for the advanced
constraint types, so you'll all be able to see how it looks shortly.
Hopefully I can show examples of derived fact types as well.

Clifford Heath.