> It's not saying that an object type
> is the same thing as a general concept.

I was absolutely wrong when I tried to match "general concept" to an ORM object
type.

Actually, now I think a better approximation to the interpretation of ORM is the
concept "extension":

Page 40. extension definition: totality of objects [every thing] to which a
concept corresponds

The reason is that, in ORM, both object types and fact types are treated as
sets. However, I realize that by introducing this concept your metamodel may
change significantly.

On the other hand, the main goal of an ORM metamodel is to enforce the notation
semantics. This can be done without SBVR, as you have already proved.
Introducing explicitly the SBVR terms in the metamodel may help to mapping from
ORM to SBVR and vice versa, but it's not indispensable since the two methods are
formal. This also would contribute to the understanding of the interconnection
between the methods. Perhaps a major benefit would be to facilitate the
interoperability among the fact oriented modeling tools.

Let me ask you a question. From your perspective, what are the implications of
radically changing the metamodel for the sake of a full conformity with SBVR?


--- In information_modeling@yahoogroups.com, Clifford Heath <clifford.heath@...>
wrote:
>
> On 12/06/2009, at 12:12 AM, jportalfraga wrote:
> > What about using "GeneralConcept" instead of "Concept" for better
> > matching with SBVR?
> >
>
> I assume you're using the diagram at the start of SBVR section 8.1
> (snapshot below for those who don't have it open). The definition of
> "general concept" in section 11.1.2.3 is in the context of
> specialization.
> The diagram in section 8.1 shows that each "object type" is a general
> concept in the sense that individual concepts of an object type are
> specializations of that object type. It's not saying that an object type
> is the same thing as a general concept. That is, the concepts "my dog"
> and "your dog" are specializations of the object type "dog"; dog as an
> object type is a general concept for those individual concepts.
>
> Now to justify my use of the term "Concept" for object type, I need
> to show that the other SBVR subcategories of concept aren't
> necessary in my metamodel, either because they're outside my
> UoD, or because they are inside but don't have sufficient overlap
> with object type to justify a common superclass (general category).
>
> Referring to Figure 8.1, there are two subcategories of SBVR's
> concept, and four subcategories of noun concept. I'll deal with
> noun concept first. The first subcategory is "individual concept".
>
> My model uses "Instance" for "individual concept" (despite maybe
> confusing an instance of Instance with the actuality it represents).
> All Instances are regarded as just being conceptual representations
> of the actualities implicitly, without the need to classify Instances as
> Concepts. In other words, when I populate an Instance of "Dog", it's
> apparent that the Instance is a record of some particular dog, not
> the dog itself. There are no common roles between Instance and
> object type, so no reason for them to share a general category.
>
> Similarly, SBVR's "fact type role" characterises the collection of
> instances (individual instances in SBVR) that play the related role
> in the collection of fact instances (called Fact in my model) of that
> fact type. To continue the example for the above dog, if I populate
> the instances of "Dog has Colour hair" to indicate the hair colours
> of a collection of dogs, the colour "brown" likely plays the fact type
> role for colour, but it's unlikely that "green" does. Thus the "fact
> type
> role" is the category of "all colours that dog hair may be", as a
> restriction on the category of all possible colours. In my metamodel,
> I have no need for this category as a separate concept. That might
> change if I try to create a formal semantics for fact type derivation,
> but at present I don't see that happening.
>
> The final subcategory of "noun concept", is "role". In SBVR as in
> ActiveFacts, a Role is the part played by a Concept in a FactType.
> As before, we need to consider the roles that a Role plays in the
> metamodel (to see which are shared with NounConcept), and to do
> that, I'll refer to the CQL language. In CQL, a designator of a role
> may take one of three forms:
>
> * The name of an object type (including of an objectified fact type)
> * The name of an object type discriminated using new adjectives
> * A role name, defined using (as <some-name>)
>
> Any of the three forms may be used within the immediate context as
> a reference to that role. However, these designations have very limited
> availability as general syntactic elements *outside* that context, i.e.
> having global meaning within the whole vocabulary. Consider for
> example a fact type "Person attended Meeting", when invoked as
> "Person (as Attendee) attended board-Meeting" as one clause in the
> context of a fact type derivation:
>
> * "Person" is used to match the fact type from readings available in the
> vocabulary. Because it adds a role name (Attendee, not used in matching
> the fact type in the vocabulary), any reference to this role from
> elsewhere
> in the derivation must use the role name. Any other use of "Person" will
> invoke a different role of the object type, not to this role.
>
> * The name "Meeting" cannot be used to refer to its role, unless also
> accompanied by the adjective "board". That is, a reference elsewhere
> in this derivation to "board Meeting" will be a reference to this role,
> and any reference to just "Meeting" will be to the object type (i.e. a
> different role of Meeting). This rule is relaxed in some contexts such
> as constraint definitions where a different role cannot be introduced,
> and then the adjective does not have to be used. [I don't really like
> the
> fact that this relaxation seems ad-hoc, but it's necessary to increase
> the number of NORMA models that can be converted to CQL.]
>
> * The name "Attendee" has limited scope within this fact type
> derivation.
> Normally, a role name applies to a role - which means that anywhere
> that fact type may be referred to, the role name is available. This is
> different from a role designation that uses an adjective, the
> adjective is
> part of the designation (RoleRef in my model). When a derived fact type
> is defined using a reading that uses a role name, that role name
> becomes globally accessible for use in invoking that derived fact type.
> But here, the role name occurs within the body of the derivation, and
> only has local relevance, being available for use in reference to the
> role
> of the fact type elsewhere invoked.
>
> It cannot be used outside this derivation, unless it's also used within
> the reading text for the derived fact type. In the current
> implementation
> of CQL, this enlarged scope for role names isn't implemented, due to
> the discussion I had with Terry about disallowing role names from
> conflicting with object type names. See the discussion we had in this
> Information Modeling list around November 2007. Essentially, I see
> the role name in this context as introducing Attendee as a subtype of
> Person, where the relevant role that makes subtyping useful is the
> fact that this Person plays the role of Attendee. This subtype then
> should have a name that is in the global namespace. However, if
> desired, an explicit subtype can always be created to play this role,
> in CQL: "Attendee is a kind of Person; Attendee attended Meeting".
>
> So, to finish my coverage of roles as a category of noun concept, the
> ability to generalise roles as "noun concepts" isn't a sufficiently
> useful
> thing to do, at present.
>
> Note that although this sounds a rather contingent or subjective way
> to treat it, remember that the process of modeling is a *design*
> process,
> not descriptive, and the formulation of a general category is useful
> in a
> design only where that category encapsulates roles that all
> subcategories
> share. In my meta-model, there is not sufficient commonality between
> the roles of instances (individual concepts), object types, and fact
> type
> roles, to make the generalisation useful.
>
> I should now argue why "fact type" shouldn't be a subcategory of
> "concept". To generalise "fact type" and "noun concept" as "concept"
> (as SBVR does) is a useful thing in defining the set of shared ideas of
> a semantic community. The semantic community shares these noun
> concepts and those fact types; collectively, they share these concepts.
>
> However I don't have a need to do that. Instead I define a vocabulary,
> which designates a speech community. Each vocabulary includes
> terms that designate its concepts, and readings that designate its
> fact types. Thus the set of concepts and fact types of a semantic
> community are the sets denoted by the terms and readings used by
> users of the vocabularies of that community. There's no need to
> *name* a general category that encompasses noun concepts and
> fact types. If a fact type needs to play any of the roles of a noun
> concept, it can be objectified as one (such as in the CQL statement
> "Attendance is where Person attended Meeting").
>
> This leaves only one of SBVR's concept sub-categories (object type),
> and I so call that just "concept".
>
> > It could also be used "FactTypeForm" instead of "Reading".
> >
>
> It could, but I prefer to use less formal language where possible,
> or language that is at least more memorable to a layperson once
> they've learnt it. I also prefer single words where possible, and
> not create artificial aggregate terms.
>
> In CQL, a term must contain no spaces, though there is no technical
> reason why I couldn't relax this in future and have multi-word terms
> as in SBVR. The implementation problem is the same one that currently
> prevents me using more than a single adjective before and/or after
> a term.
>
> You'll note that although my Readings are composite objects, I don't
> actually show the decomposition, as SBVR does in section 8.3.4.
> Instead I use placeholders by incorporating the ordinals of each
> RoleRef into the reading text encased in curly brackets as NORMA
> does (e.g. "{0} has {1}").
>
> > I prefer to define the has synonym- relationship at the term level.
> >
>
> My use of the word Synonym is incorrect, as you point out.
>
> I wanted to have just a single fact type "Term designates Concept",
> but that can't provide an identifier for Concept (even if you objectify
> it as Designation and add "Designation is primary"), and I don't want
> to use a surrogate identifier (ConceptId). So instead I have a primary
> designation and AlternateDesignation. I've changed the readings to
> show that.
>
> Your Synonym fact type is derivable from these two. I prefer not to
> include derived fact types on the diagrams though. In fact, neither
> NORMA nor CQL currently handles the relational mapping correctly
> if you do. Also, your constraints on Synonym were insufficient.
> If instead I drop AlternateDesignation and add Synonym, several
> new constraints are needed to make it work correctly. It's simpler
> the way it is.
>
> > It's possible that a term neither designates a concept nor a role.
> >
>
> I believe that would be an error - unless we define new things that
> can be designated by a Term. You might want to do that of course,
> but them we'd revise the model. However, to make that possible, I'll
> remove the mandatory aspect and leave exclusion.
>
> > A term might have no synonyms.
> >
>
> Yes. Or a concept might have no alternate designations, same thing.
>
> > Additional textual rules must be added to enforce that a term and
> > its synonyms must belong to at most one vocabulary
> >
>
> No - the whole idea here is to allow terms from more than one vocabulary
> to designate the same concept. This is how multi-lingual and overlapping
> vocabularies are defined. This is not just for translation; in some
> organisations
> customers might be referred to as users or as clients, by different
> groups
> of people.
>
> > I think is better to derive the fact type Term has synonym-Term, if
> > it is useful.
> >
>
> Yes, I agree. But I won't show the derivation on my version of the
> diagram,
> if you don't mind. It's hard enough to read already, without that! The
> fragment
> I have now is as shown below.
>
> Clifford Heath, Data Constellation, http://dataconstellation.com
> Agile Information Management and Design.
>

On 12/06/2009, at 12:12 AM, jportalfraga wrote:
> What about using "GeneralConcept" instead of "Concept" for better
> matching with SBVR?
>

I assume you're using the diagram at the start of SBVR section 8.1
(snapshot below for those who don't have it open). The definition of
"general concept" in section 11.1.2.3 is in the context of
specialization.
The diagram in section 8.1 shows that each "object type" is a general
concept in the sense that individual concepts of an object type are
specializations of that object type. It's not saying that an object type
is the same thing as a general concept. That is, the concepts "my dog"
and "your dog" are specializations of the object type "dog"; dog as an
object type is a general concept for those individual concepts.

Now to justify my use of the term "Concept" for object type, I need
to show that the other SBVR subcategories of concept aren't
necessary in my metamodel, either because they're outside my
UoD, or because they are inside but don't have sufficient overlap
with object type to justify a common superclass (general category).

Referring to Figure 8.1, there are two subcategories of SBVR's
concept, and four subcategories of noun concept. I'll deal with
noun concept first. The first subcategory is "individual concept".

My model uses "Instance" for "individual concept" (despite maybe
confusing an instance of Instance with the actuality it represents).
All Instances are regarded as just being conceptual representations
of the actualities implicitly, without the need to classify Instances as
Concepts. In other words, when I populate an Instance of "Dog", it's
apparent that the Instance is a record of some particular dog, not
the dog itself. There are no common roles between Instance and
object type, so no reason for them to share a general category.

Similarly, SBVR's "fact type role" characterises the collection of
instances (individual instances in SBVR) that play the related role
in the collection of fact instances (called Fact in my model) of that
fact type. To continue the example for the above dog, if I populate
the instances of "Dog has Colour hair" to indicate the hair colours
of a collection of dogs, the colour "brown" likely plays the fact type
role for colour, but it's unlikely that "green" does. Thus the "fact
type
role" is the category of "all colours that dog hair may be", as a
restriction on the category of all possible colours. In my metamodel,
I have no need for this category as a separate concept. That might
change if I try to create a formal semantics for fact type derivation,
but at present I don't see that happening.

The final subcategory of "noun concept", is "role". In SBVR as in
ActiveFacts, a Role is the part played by a Concept in a FactType.
As before, we need to consider the roles that a Role plays in the
metamodel (to see which are shared with NounConcept), and to do
that, I'll refer to the CQL language. In CQL, a designator of a role
may take one of three forms:

* The name of an object type (including of an objectified fact type)
* The name of an object type discriminated using new adjectives
* A role name, defined using (as <some-name>)

Any of the three forms may be used within the immediate context as
a reference to that role. However, these designations have very limited
availability as general syntactic elements *outside* that context, i.e.
having global meaning within the whole vocabulary. Consider for
example a fact type "Person attended Meeting", when invoked as
"Person (as Attendee) attended board-Meeting" as one clause in the
context of a fact type derivation:

* "Person" is used to match the fact type from readings available in the
vocabulary. Because it adds a role name (Attendee, not used in matching
the fact type in the vocabulary), any reference to this role from
elsewhere
in the derivation must use the role name. Any other use of "Person" will
invoke a different role of the object type, not to this role.

* The name "Meeting" cannot be used to refer to its role, unless also
accompanied by the adjective "board". That is, a reference elsewhere
in this derivation to "board Meeting" will be a reference to this role,
and any reference to just "Meeting" will be to the object type (i.e. a
different role of Meeting). This rule is relaxed in some contexts such
as constraint definitions where a different role cannot be introduced,
and then the adjective does not have to be used. [I don't really like
the
fact that this relaxation seems ad-hoc, but it's necessary to increase
the number of NORMA models that can be converted to CQL.]

* The name "Attendee" has limited scope within this fact type
derivation.
Normally, a role name applies to a role - which means that anywhere
that fact type may be referred to, the role name is available. This is
different from a role designation that uses an adjective, the
adjective is
part of the designation (RoleRef in my model). When a derived fact type
is defined using a reading that uses a role name, that role name
becomes globally accessible for use in invoking that derived fact type.
But here, the role name occurs within the body of the derivation, and
only has local relevance, being available for use in reference to the
role
of the fact type elsewhere invoked.

It cannot be used outside this derivation, unless it's also used within
the reading text for the derived fact type. In the current
implementation
of CQL, this enlarged scope for role names isn't implemented, due to
the discussion I had with Terry about disallowing role names from
conflicting with object type names. See the discussion we had in this
Information Modeling list around November 2007. Essentially, I see
the role name in this context as introducing Attendee as a subtype of
Person, where the relevant role that makes subtyping useful is the
fact that this Person plays the role of Attendee. This subtype then
should have a name that is in the global namespace. However, if
desired, an explicit subtype can always be created to play this role,
in CQL: "Attendee is a kind of Person; Attendee attended Meeting".

So, to finish my coverage of roles as a category of noun concept, the
ability to generalise roles as "noun concepts" isn't a sufficiently
useful
thing to do, at present.

Note that although this sounds a rather contingent or subjective way
to treat it, remember that the process of modeling is a *design*
process,
not descriptive, and the formulation of a general category is useful
in a
design only where that category encapsulates roles that all
subcategories
share. In my meta-model, there is not sufficient commonality between
the roles of instances (individual concepts), object types, and fact
type
roles, to make the generalisation useful.

I should now argue why "fact type" shouldn't be a subcategory of
"concept". To generalise "fact type" and "noun concept" as "concept"
(as SBVR does) is a useful thing in defining the set of shared ideas of
a semantic community. The semantic community shares these noun
concepts and those fact types; collectively, they share these concepts.

However I don't have a need to do that. Instead I define a vocabulary,
which designates a speech community. Each vocabulary includes
terms that designate its concepts, and readings that designate its
fact types. Thus the set of concepts and fact types of a semantic
community are the sets denoted by the terms and readings used by
users of the vocabularies of that community. There's no need to
*name* a general category that encompasses noun concepts and
fact types. If a fact type needs to play any of the roles of a noun
concept, it can be objectified as one (such as in the CQL statement
"Attendance is where Person attended Meeting").

This leaves only one of SBVR's concept sub-categories (object type),
and I so call that just "concept".

> It could also be used "FactTypeForm" instead of "Reading".
>

It could, but I prefer to use less formal language where possible,
or language that is at least more memorable to a layperson once
they've learnt it. I also prefer single words where possible, and
not create artificial aggregate terms.

In CQL, a term must contain no spaces, though there is no technical
reason why I couldn't relax this in future and have multi-word terms
as in SBVR. The implementation problem is the same one that currently
prevents me using more than a single adjective before and/or after
a term.

You'll note that although my Readings are composite objects, I don't
actually show the decomposition, as SBVR does in section 8.3.4.
Instead I use placeholders by incorporating the ordinals of each
RoleRef into the reading text encased in curly brackets as NORMA
does (e.g. "{0} has {1}").

> I prefer to define the has synonym- relationship at the term level.
>

My use of the word Synonym is incorrect, as you point out.

I wanted to have just a single fact type "Term designates Concept",
but that can't provide an identifier for Concept (even if you objectify
it as Designation and add "Designation is primary"), and I don't want
to use a surrogate identifier (ConceptId). So instead I have a primary
designation and AlternateDesignation. I've changed the readings to
show that.

Your Synonym fact type is derivable from these two. I prefer not to
include derived fact types on the diagrams though. In fact, neither
NORMA nor CQL currently handles the relational mapping correctly
if you do. Also, your constraints on Synonym were insufficient.
If instead I drop AlternateDesignation and add Synonym, several
new constraints are needed to make it work correctly. It's simpler
the way it is.

> It's possible that a term neither designates a concept nor a role.
>

I believe that would be an error - unless we define new things that
can be designated by a Term. You might want to do that of course,
but them we'd revise the model. However, to make that possible, I'll
remove the mandatory aspect and leave exclusion.

> A term might have no synonyms.
>

Yes. Or a concept might have no alternate designations, same thing.

> Additional textual rules must be added to enforce that a term and
> its synonyms must belong to at most one vocabulary
>

No - the whole idea here is to allow terms from more than one vocabulary
to designate the same concept. This is how multi-lingual and overlapping
vocabularies are defined. This is not just for translation; in some
organisations
customers might be referred to as users or as clients, by different
groups
of people.

> I think is better to derive the fact type Term has synonym-Term, if
> it is useful.
>

Yes, I agree. But I won't show the derivation on my version of the
diagram,
if you don't mind. It's hard enough to read already, without that! The
fragment
I have now is as shown below.

Clifford Heath, Data Constellation, http://dataconstellation.com
Agile Information Management and Design.

What about using "GeneralConcept" instead of "Concept" for better matching with SBVR? It could also be used "FactTypeForm" instead of "Reading".

I prefer to define the has synonym- relationship at the term level.

It's possible that a term neither designates a concept nor a role.

A term might have no synonyms.

Additional textual rules must be added to enforce that a term and its synonyms must belong to at most one vocabulary and have at least one common concept designated (they share a meaning, so they are synonyms within a vocabulary).  Other case  is two terms from different vocabularies that designate the same concept.  In this case  one term is the translation of the another. I think is better to derive the fact type Term has synonym-Term, if it is useful.

model fragment 

Regards, Josue

--- In information_modeling@yahoogroups.com, Clifford Heath <clifford.heath@...> wrote:
>
> On 09/06/2009, at 5:55 AM, jportalfraga wrote:
> > Therefore, the word "Concept" has the same meaning as ORM2 ObjectType
>
> For a concept to have "the same meaning", it must play exactly the same
> set of roles. Please re-read my definition of "meaning" from my previous
> message. My "Concept" is not the same as in either SBVR or ORM2's
> ObjectType. In ORM2, an ObjectType has exactly one name, and I'm
> moving my metamodel to separate *naming* from Concept.
>
> I *intend* "Concept" to mean something much closer to SBVR's meaning
> than to ORM2's meaning, so I think that the term is correct. It does
> carry
> the natural English meaning as well - a "term in a vocabulary denotes a
> concept" - objectified as Denotation if you wish.
>
> The existing (Compromise) and the new (Term) model fragments are
> attached as images. I've uploaded them to the Yahoo files area also:
>
> http://tech.groups.yahoo.com/group/information_modeling/files/Clifford%20Heath%27s/
>
> The fragment I'm currently using:
>
>
>
>
> The revised fragment: each Concept has one definitive Term (a Name in
> a Vocabulary),
> and any number of synonyms. This version has been sitting in my
> project files for a
> while, and I keep incorporating new features from it; but not yet these:
>
>
>
>
>
>
> I tried having a single fact type objectified as "Denotation" joining
> Term
> and Concept, but that requires a surrogate key for Concept, and I avoid
> those (see below).
>
> > , and it doesn't denote the same thing as SBVR "Concept" term at all.
>
> Again, I intend it to mean almost the same thing as SBVR - however as I
> argued before, to treat a *role* as a concept requires objectifying an
> un-named
> subtype of the role player. I think this is an error - the role player
> is not always
> objectified in this way. Objectification only applies when a role name
> applies.
> See for example Director in my CompanyDirectorEmployee model. By
> applying
> this role name, the role player is objectified as a subtype of Person,
> and *becomes*
> a concept. On the other hand, the role of "Company" in the same fact
> type does
> not have a role name and does not represent a separate (subtype)
> concept.
>
> However, this argument has not convinced Terry - see the discussion in
> the list
> archives around role naming and hyphen-binding from Nov 2007. So ORM2
> remains different from both CQL and SBVR in this respect. CQL takes
> the middle
> path, and I believe it's closest to the correct one.
>
> Furthermore, the corrected model fragment above allows a concept to
> bear a
> synonym from any Vocabulary (including one in another language).
> However,
> this fragment does not indicate how fact type readings may be
> customised in
> that way, which is necessary and is explicitly allowed by SBVR. Any
> fact type
> may have any number of readings, including many for one reading order
> (RoleSequence), but though the metamodels do not yet show a Reading as
> belonging to a Vocabulary, that is intended, and won't have other
> impacts.
>
> > the use of the word "Concept" may look unfamiliar to other members
> > of the ORM Community.
>
> I intend that. It is different.
>
> > For the time being, I can't see the necessity for the model element
> > Feature.
>
> You're using the version of the Metamodel from http://dataconstellation.com
> ,
> which is slightly out of date; the version in the http://github.com/cjheath/activefacts
> source code repository is always the most recent published version.
> The recent
> version has eliminated Feature. I had used it for two reasons that
> don't exist in
> ORM2: Aliases (synonyms), and as a place to attach "business context
> notes" for
> use in requirements management. I've reworked both using a different
> method,
> but haven't integrated the changes through my code yet; see below.
>
> > Some ORM2 model elements, like Concept (ObjectType) and Role may be
> > named.
> > This means one can use words (symbols) to make reference to them.
>
> Role names in ORM2 are not unique, and may duplicate ObjectType names.
> Thus they're not useful as references. I think this is an error, but
> it's an error I've
> retained for now, until further discussion can resolve it. See my
> revised metamodel
> below however.
>
> > The words belong to vocabularies (set of symbols).
>
> Sets of Terms that denote Concepts, yes.
>
> > An ORM model element is more a matter of meaning.
>
> No. An ORM2 Object Type is a named concept. A Role name is a convenience
> for column-name generation during relational mapping, and little more.
>
> > I wouldn't include one of them in a vocabulary and wouldn't use
> > their names as primary references either, since it's possible more
> > than one symbol, even in the same vocabulary, denotes the same
> > meaning.
>
> You'll see I've already been thinking along the same lines. I'm not
> entirely free
> to immediately correct the error, as these diagrams are crucial parts
> of the
> *source code* of ActiveFacts, and require changes must be followed
> through.
>
> > I would also like to see the element Model in the metamodel.
>
> Not my view, and your Model doesn't add any capability that doesn't
> already
> exist.
>
> In my view, a Model is self-contained, whereas a Vocabulary contains
> terms
> that denote a set of concepts relevant within some semantic space. These
> semantic spaces (defined as per SBVR being the shared concepts of a
> semantic community) *overlap*, and the union is potentially infinite.
> A Model
> is where someone chooses a limited set of vocabularies, which creates
> a closed-world around them; and this model can thus be translated to an
> SQL schema.
>
> At present, this idea of "Model" is thus an *implementation* specific
> thing,
> not a semantic thing. It may be that this coincides with your use of
> "Model",
> and we can add it; but I see it as being outside the core metamodel.
>
> > I couldn't attach a file to this group.
>
> I don't know why not. Any member who signs in to Yahoo and visits the
> Files
> page should be able to create a directory for themselves and add files:
> <http://groups.yahoo.com/group/information_modeling/files>
>
> > I'm sending an email with your metamodel little changed. It opens
> > with NORMA.
> > Please, see the page 'discussion'. ModelElement and
> > ModelNamedElement were taken from NORMA Core metamodel.
>
> I understand why you're suggesting these things, but I don't think
> they are
> * well-named
> * all necessary
> * naturally-structured.
>
> My model already incorporates the semantic concepts of ORM2 as
> implemented
> in NORMA, without any of the implementation ones. In particular:
>
> * My comments about Model above,
>
> * "ModelElement" exists as a place to hang the geometry rules for the
> diagram
> layouts, which is an implementation thing, not a semantic thing;
> and unnecessary
> in any case.
>
> * "Name" is already used wherever NORMA can use a name (an ObjectType
> or Role)
>
> * NORMA doesn't denote object types by any "symbols" other than Names
> so the
> change of terminology is unnecessary.
>
> * Since ORM2 doesn't have any relationship between ObjectType names and
> RoleNames, the proposed ModelNamedElement supertype doesn't actually
> exist in any reality. It's as redundant as my (better-named!)
> "Feature" was.
>
> * Role Names in ORM2 don't (unfortunately) to belong to a Vocabulary.
> This is
> reflected still in my metamodel, and that needs to change. A role
> name should
> be a Term, even though that would disallow any ORM model that re-
> uses a
> Concept's term as a role name (a good thing, in my view). That's
> fixed in my
> revised metamodel, though not yet in my code.
>
> * Your proposed "Meaning" is a dangling object having no meaning.
> "Meaning"
> in a semantic model is not described in paragraphs or by an ID, but
> by the *roles*
> that the concept plays; and your "Meaning" has only two roles (one
> played by ID,
> and one played by ModelElement). Neither of these role really
> *means* anything.
>
> * You use a lot of "id" reference modes. I avoid them wherever a
> "natural" identifier
> exists. Thus "Vocabulary" has a name, and Concept is identified by
> a primary Name.
>
> > I would like to propose you first to agree on these basic terms (ex.
> > vocabulary), as we did with "Concept". Then we'll be able to proceed
> > the discussion on the rest of the metamodel.
>
> I hope you'll see my latest proposed metamodel incorporates the
> capabilities you
> want. It's uploaded as "Metamodel 2009-06-09.orm" in the group files.
> This file
> also contains incomplete support for business context notes.
>
> Finally; I intend "Vocabulary" to play additional roles, such as one
> denoting the
> natural language in which it's expressed. These aren't modelled yet,
> and neither
> is the details of vocabularies incorporating completely, or borrowing
> from, other
> vocabularies (despite the "Imports" that were in earlier models).
>
> Clifford Heath, Data Constellation, http://dataconstellation.com
> Agile Information Management and Design
>

On 09/06/2009, at 5:55 AM, jportalfraga wrote:
> Therefore, the word "Concept" has the same meaning as ORM2 ObjectType

For a concept to have "the same meaning", it must play exactly the same
set of roles. Please re-read my definition of "meaning" from my previous
message. My "Concept" is not the same as in either SBVR or ORM2's
ObjectType. In ORM2, an ObjectType has exactly one name, and I'm
moving my metamodel to separate *naming* from Concept.

I *intend* "Concept" to mean something much closer to SBVR's meaning
than to ORM2's meaning, so I think that the term is correct. It does
carry
the natural English meaning as well - a "term in a vocabulary denotes a
concept" - objectified as Denotation if you wish.

The existing (Compromise) and the new (Term) model fragments are
attached as images. I've uploaded them to the Yahoo files area also:

http://tech.groups.yahoo.com/group/information_modeling/files/Clifford%20Heath%2\
7s/

The fragment I'm currently using:

The revised fragment: each Concept has one definitive Term (a Name in
a Vocabulary),
and any number of synonyms. This version has been sitting in my
project files for a
while, and I keep incorporating new features from it; but not yet these:

I tried having a single fact type objectified as "Denotation" joining
Term
and Concept, but that requires a surrogate key for Concept, and I avoid
those (see below).

> , and it doesn't denote the same thing as SBVR "Concept" term at all.

Again, I intend it to mean almost the same thing as SBVR - however as I
argued before, to treat a *role* as a concept requires objectifying an
un-named
subtype of the role player. I think this is an error - the role player
is not always
objectified in this way. Objectification only applies when a role name
applies.
See for example Director in my CompanyDirectorEmployee model. By
applying
this role name, the role player is objectified as a subtype of Person,
and *becomes*
a concept. On the other hand, the role of "Company" in the same fact
type does
not have a role name and does not represent a separate (subtype)
concept.

However, this argument has not convinced Terry - see the discussion in
the list
archives around role naming and hyphen-binding from Nov 2007. So ORM2
remains different from both CQL and SBVR in this respect. CQL takes
the middle
path, and I believe it's closest to the correct one.

Furthermore, the corrected model fragment above allows a concept to
bear a
synonym from any Vocabulary (including one in another language).
However,
this fragment does not indicate how fact type readings may be
customised in
that way, which is necessary and is explicitly allowed by SBVR. Any
fact type
may have any number of readings, including many for one reading order
(RoleSequence), but though the metamodels do not yet show a Reading as
belonging to a Vocabulary, that is intended, and won't have other
impacts.

> the use of the word "Concept" may look unfamiliar to other members
> of the ORM Community.

I intend that. It is different.

> For the time being, I can't see the necessity for the model element
> Feature.

You're using the version of the Metamodel from http://dataconstellation.com
,
which is slightly out of date; the version in the
http://github.com/cjheath/activefacts
source code repository is always the most recent published version.
The recent
version has eliminated Feature. I had used it for two reasons that
don't exist in
ORM2: Aliases (synonyms), and as a place to attach "business context
notes" for
use in requirements management. I've reworked both using a different
method,
but haven't integrated the changes through my code yet; see below.

> Some ORM2 model elements, like Concept (ObjectType) and Role may be
> named.
> This means one can use words (symbols) to make reference to them.

Role names in ORM2 are not unique, and may duplicate ObjectType names.
Thus they're not useful as references. I think this is an error, but
it's an error I've
retained for now, until further discussion can resolve it. See my
revised metamodel
below however.

> The words belong to vocabularies (set of symbols).

Sets of Terms that denote Concepts, yes.

> An ORM model element is more a matter of meaning.

No. An ORM2 Object Type is a named concept. A Role name is a convenience
for column-name generation during relational mapping, and little more.

> I wouldn't include one of them in a vocabulary and wouldn't use
> their names as primary references either, since it's possible more
> than one symbol, even in the same vocabulary, denotes the same
> meaning.

You'll see I've already been thinking along the same lines. I'm not
entirely free
to immediately correct the error, as these diagrams are crucial parts
of the
*source code* of ActiveFacts, and require changes must be followed
through.

> I would also like to see the element Model in the metamodel.

Not my view, and your Model doesn't add any capability that doesn't
already
exist.

In my view, a Model is self-contained, whereas a Vocabulary contains
terms
that denote a set of concepts relevant within some semantic space. These
semantic spaces (defined as per SBVR being the shared concepts of a
semantic community) *overlap*, and the union is potentially infinite.
A Model
is where someone chooses a limited set of vocabularies, which creates
a closed-world around them; and this model can thus be translated to an
SQL schema.

At present, this idea of "Model" is thus an *implementation* specific
thing,
not a semantic thing. It may be that this coincides with your use of
"Model",
and we can add it; but I see it as being outside the core metamodel.

> I couldn't attach a file to this group.

I don't know why not. Any member who signs in to Yahoo and visits the
Files
page should be able to create a directory for themselves and add files:
<http://groups.yahoo.com/group/information_modeling/files>

> I'm sending an email with your metamodel little changed. It opens
> with NORMA.
> Please, see the page 'discussion'. ModelElement and
> ModelNamedElement were taken from NORMA Core metamodel.

I understand why you're suggesting these things, but I don't think
they are
* well-named
* all necessary
* naturally-structured.

My model already incorporates the semantic concepts of ORM2 as
implemented
in NORMA, without any of the implementation ones. In particular:

* My comments about Model above,

* "ModelElement" exists as a place to hang the geometry rules for the
diagram
    layouts, which is an implementation thing, not a semantic thing;
and unnecessary
    in any case.

* "Name" is already used wherever NORMA can use a name (an ObjectType
or Role)

* NORMA doesn't denote object types by any "symbols" other than Names
so the
    change of terminology is unnecessary.

* Since ORM2 doesn't have any relationship between ObjectType names and
    RoleNames, the proposed ModelNamedElement supertype doesn't actually
    exist in any reality. It's as redundant as my (better-named!)
"Feature" was.

* Role Names in ORM2 don't (unfortunately) to belong to a Vocabulary.
This is
    reflected still in my metamodel, and that needs to change. A role
name should
    be a Term, even though that would disallow any ORM model that re-
uses a
    Concept's term as a role name (a good thing, in my view). That's
fixed in my
    revised metamodel, though not yet in my code.

* Your proposed "Meaning" is a dangling object having no meaning.
"Meaning"
    in a semantic model is not described in paragraphs or by an ID, but
by the *roles*
    that the concept plays; and your "Meaning" has only two roles (one
played by ID,
    and one played by ModelElement). Neither of these role really
*means* anything.

* You use a lot of "id" reference modes. I avoid them wherever a
"natural" identifier
    exists. Thus "Vocabulary" has a name, and Concept is identified by
a primary Name.

> I would like to propose you first to agree on these basic terms (ex.
> vocabulary), as we did with "Concept". Then we'll be able to proceed
> the discussion on the rest of the metamodel.

I hope you'll see my latest proposed metamodel incorporates the
capabilities you
want. It's uploaded as "Metamodel 2009-06-09.orm" in the group files.
This file
also contains incomplete support for business context notes.

Finally; I intend "Vocabulary" to play additional roles, such as one
denoting the
natural language in which it's expressed. These aren't modelled yet,
and neither
is the details of vocabularies incorporating completely, or borrowing
from, other
vocabularies (despite the "Imports" that were in earlier models).

Clifford Heath, Data Constellation, http://dataconstellation.com
Agile Information Management and Design

Thanks Clifford,

Therefore, the word "Concept" has the same meaning as ORM2 ObjectType, and it
doesn't denote the same thing as SBVR "Concept" term at all. I have no problem
with this. My only observation here is that the use of the word "Concept" may
look unfamiliar to other members of the ORM Community.

For the time being, I can't see the necessity for the model element Feature.

Some ORM2 model elements, like Concept (ObjectType) and Role may be named. This
means one can use words (symbols) to make reference to them. The words belong to
vocabularies (set of symbols). An ORM model element is more a matter of meaning.
I wouldn't include one of them in a vocabulary and wouldn't use their names as
primary references either, since it's possible more than one symbol, even in the
same vocabulary, denotes the same meaning. I would also like to see the element
Model in the metamodel. I couldn't attach a file to this group. I'm sending an
email with your metamodel little changed. It opens with NORMA. Please, see the
page 'discussion'. ModelElement and ModelNamedElement were taken from NORMA Core
metamodel.

I would like to propose you first to agree on these basic terms (ex.
vocabulary), as we did with "Concept". Then we'll be able to proceed the
discussion on the rest of the metamodel.

Regards, Josué


--- In information_modeling@yahoogroups.com, Clifford Heath <clifford.heath@...>
wrote:
>
> jportalfraga wrote:
> > Regarding Data Constellation ORM Metamodel
> > http://www.dataconstellation.com/ActiveFacts/examples/ORM/Metamodel.orm
> > Does the term 'Concept' stand for SBVR Concept?
>
> To be perfectly flippant, "Concept" means exactly what the model says it
> means ;-). That is, this model *defines* its own meaning for Concept.
> It's in the nature and intent of a semantic model that a concept is
> defined *only* by the roles it plays, and by nothing else. In particular,
> the natural-language meanings for words aren't definitive. Choice of
> names is a design decision for the purpose of illustration.
>
> However, to be more particular, Concept is what ORM2 calls an ObjectType.
> That is, a ValueType or an EntityType, including the objectification of a
> FactType, but not including a non-objectified FactType.
>
> I understand this to be congruent to the SBVR definition of "Noun Concept",
> which defines a class of "things". A fact type becomes a "thing" when it's
> objectified, i.e. when it becomes an EntityType. However, SBVR considers
> all fact types to be concepts, whether or not they're objectified.
>
> Refering to SBVR Rev 1.0 page 19, you'll see that the class of concepts is
> divided into noun concept and verb concept. The latter is what ORM2 calls a
> fact type. An objectified fact type consists of a noun concept (entity type)
> that "nests" or objectifies a verb concept (fact type). I don't know whether
> SBVR separates a fact type and its objectification in this way.
>
> In ORM2, an entity type that plays a role in a fact type is designated as a
> "role player", which is a descriptive term only. In SBVR, this is designated
> as a "fact type role" which is a subcategory of "noun concept".
>
> In ActiveFacts, I take a middle line between these. A Role in a FactType is
> played by a Concept, but the readings of that fact type are built of RoleRefs
> (role references) which may contain leading and/or trailing adjectives. The
> combined "adjective/concept-name" form (referred to in some places as an
> "adjectival form") is exactly what SBVR designates a "fact type role".
> However, unlike in SBVR, the adjectival form has only local scope, that is,
> the adjectives are used only to choose between fact types having the same
> players and the same predicates; the combined adjectival form doesn't have
> global scope.
>
> For example, take the two fact types:
>
> Person has given-Name;
> Person has family-Name;
>
> The predicate in both cases is "has", and the role players are the same
> (Person and Name). The adjectives must be used to indicate which fact type
> is intended, wherever that may be uncertain. Note also that in CQL, the
> hyphen is required (but only once in a given statement, see examples below)
> and need not have a white space following (for a leading adjective) or
> leading (for a trailing adjective). Unfortunately this means that hyphenated
> words like semi-trailer cannot be concept names as in ORM2. A future version
> of CQL might relax this restriction.
>
> If the same fact type must be invoked twice in the same query, CQL provides
> two alternative methods, of which only one is currently implemented.
> Consider a query that wants to find all Persons who have both John and Richard
> as given names. The fact type "Person has given-Name" must be invoked twice in
> the same query, where the Person is the same instance but the names are
> different.
>
> The first alternative (not implemented) is to use a local adjective:
>
> Person called john and richard is where
>     Person is called given-Name 'John',
>     Person is called other- given Name 'Richard';
>
> This is shorthand for the full query:
>
> Person called john and richard is where
>     Person is called given-Name,
>     given Name = 'John',
>     Person is called other- given Name,
>     other given Name = 'Richard';
>
> This defines a new unary fact type played by Person, having the predicate
> "called john and richard". It does this by introducing the two role names
> "given Name" and "other given Name". However, the CQL parser cannot yet
> resolve this latter role naming, where more than two words are involved.
> You see the need for this resolution in the extended form, though it's
> also needed in the condensed form in order to identify the "given Name"
> fact type. Note that the adjectival form "other given Name" only has local
> meaning within the derivation of this unary fact type.
>
> The second alternative is to use a role name:
>
> Person called john and richard is where
>     Person is called given-Name,
>     given Name = 'John',
>     Person is called given- Name (as otherName),
>     otherName = 'Richard';
>
> In this case, there is no need to resolve a three-word identifier.
>
> A query for all Persons having both names can now be formulated as simply:
>
> Person called john and richard?
>
> I was unable to convince Terry that the adjectival forms "given Name" and
> "family Name" (or for that matter a role name) should be a unique identifier
> for that role within that vocabulary (ORM2 schema or model). So as it is,
> Name might play the same "family-Name" role in two different fact types,
> such as "Person is called family-Name" and "Family is called family-Name".
> In my view, this shouldn't be allowed. Likewise, Terry says he often uses
> a role name that exists as a name elsewhere in the model. The role name is
> used merely to derive a more useful SQL column name or for illustrative
> purposes, but in my view, that shouldn't overrule the possible confusion
> from re-using such names. The problem doesn't really exist in ORM2, but it
> does in a plain-text language like CQL.
>
> Clifford Heath, Data Constellation, http://dataconstellation.com
> Agile Information Management and Design.
>

jportalfraga wrote:
> Regarding Data Constellation ORM Metamodel
> http://www.dataconstellation.com/ActiveFacts/examples/ORM/Metamodel.orm
> Does the term 'Concept' stand for SBVR Concept?

To be perfectly flippant, "Concept" means exactly what the model says it
means ;-). That is, this model *defines* its own meaning for Concept.
It's in the nature and intent of a semantic model that a concept is
defined *only* by the roles it plays, and by nothing else. In particular,
the natural-language meanings for words aren't definitive. Choice of
names is a design decision for the purpose of illustration.

However, to be more particular, Concept is what ORM2 calls an ObjectType.
That is, a ValueType or an EntityType, including the objectification of a
FactType, but not including a non-objectified FactType.

I understand this to be congruent to the SBVR definition of "Noun Concept",
which defines a class of "things". A fact type becomes a "thing" when it's
objectified, i.e. when it becomes an EntityType. However, SBVR considers
all fact types to be concepts, whether or not they're objectified.

Refering to SBVR Rev 1.0 page 19, you'll see that the class of concepts is
divided into noun concept and verb concept. The latter is what ORM2 calls a
fact type. An objectified fact type consists of a noun concept (entity type)
that "nests" or objectifies a verb concept (fact type). I don't know whether
SBVR separates a fact type and its objectification in this way.

In ORM2, an entity type that plays a role in a fact type is designated as a
"role player", which is a descriptive term only. In SBVR, this is designated
as a "fact type role" which is a subcategory of "noun concept".

In ActiveFacts, I take a middle line between these. A Role in a FactType is
played by a Concept, but the readings of that fact type are built of RoleRefs
(role references) which may contain leading and/or trailing adjectives. The
combined "adjective/concept-name" form (referred to in some places as an
"adjectival form") is exactly what SBVR designates a "fact type role".
However, unlike in SBVR, the adjectival form has only local scope, that is,
the adjectives are used only to choose between fact types having the same
players and the same predicates; the combined adjectival form doesn't have
global scope.

For example, take the two fact types:

Person has given-Name;
Person has family-Name;

The predicate in both cases is "has", and the role players are the same
(Person and Name). The adjectives must be used to indicate which fact type
is intended, wherever that may be uncertain. Note also that in CQL, the
hyphen is required (but only once in a given statement, see examples below)
and need not have a white space following (for a leading adjective) or
leading (for a trailing adjective). Unfortunately this means that hyphenated
words like semi-trailer cannot be concept names as in ORM2. A future version
of CQL might relax this restriction.

If the same fact type must be invoked twice in the same query, CQL provides
two alternative methods, of which only one is currently implemented.
Consider a query that wants to find all Persons who have both John and Richard
as given names. The fact type "Person has given-Name" must be invoked twice in
the same query, where the Person is the same instance but the names are
different.

The first alternative (not implemented) is to use a local adjective:

Person called john and richard is where
     Person is called given-Name 'John',
     Person is called other- given Name 'Richard';

This is shorthand for the full query:

Person called john and richard is where
     Person is called given-Name,
     given Name = 'John',
     Person is called other- given Name,
     other given Name = 'Richard';

This defines a new unary fact type played by Person, having the predicate
"called john and richard". It does this by introducing the two role names
"given Name" and "other given Name". However, the CQL parser cannot yet
resolve this latter role naming, where more than two words are involved.
You see the need for this resolution in the extended form, though it's
also needed in the condensed form in order to identify the "given Name"
fact type. Note that the adjectival form "other given Name" only has local
meaning within the derivation of this unary fact type.

The second alternative is to use a role name:

Person called john and richard is where
     Person is called given-Name,
     given Name = 'John',
     Person is called given- Name (as otherName),
     otherName = 'Richard';

In this case, there is no need to resolve a three-word identifier.

A query for all Persons having both names can now be formulated as simply:

Person called john and richard?

I was unable to convince Terry that the adjectival forms "given Name" and
"family Name" (or for that matter a role name) should be a unique identifier
for that role within that vocabulary (ORM2 schema or model). So as it is,
Name might play the same "family-Name" role in two different fact types,
such as "Person is called family-Name" and "Family is called family-Name".
In my view, this shouldn't be allowed. Likewise, Terry says he often uses
a role name that exists as a name elsewhere in the model. The role name is
used merely to derive a more useful SQL column name or for illustrative
purposes, but in my view, that shouldn't overrule the possible confusion
from re-using such names. The problem doesn't really exist in ORM2, but it
does in a plain-text language like CQL.

Clifford Heath, Data Constellation, http://dataconstellation.com
Agile Information Management and Design.

Hi all,

Regarding Data Constellation ORM Metamodel
http://www.dataconstellation.com/ActiveFacts/examples/ORM/Metamodel.orm

Does the term 'Concept' stand for SBVR Concept?

Regards,

Folk,

Just a quick status message to revive this email/NTTP channel.
You might be reading this because of your subscription on Yahoo,
or using the NNTP feed from gmane.org.

ActiveFacts continues to make excellent progress. I'm completing
a few missing features of the data definition parts of CQL now,
while making progress on new code for the database adapters.

The Metamodel is being tweaked to prepare support for multi-lingual
vocabularies, and to form a solid basis for some extensions,
including business context notes (why we did something this way, etc)
business process models and diagram layout.

Installation instructions for the open-source ActiveFacts system,
including the CQL information modeling language, is on the website.

Clifford Heath, Data Constellation, http://dataconstellation.com
Agile Information Management and Design.

Folk,

Over the weekend, I implemented RMap - the part that chooses
which object types will be tables in a third-normal-form database.
I had previously identified all possible absorption paths, so it's
now a small step to emit columns, either foreign key fields where
the referenced object is a table, or all absorbed fields where not,
and using that, to emit SQL.

My example models are all emitting mappings that are either
identical or superior(*) to those of NORMA. There may be cases
that still fail, but I believe I have almost all possibilities covered,
even the weird ones.

I was able to do this without resorting to binarizing the model, so
the roles that are listed in my join paths are in all cases the same
role objects that are covered by constraints, role references for
readings, etc - which makes it much easier to incrementally adjust
the mappings and to correlate operations between the relational
and elementary forms. It also means that it's easy to emit constraint
enforcement for all constraints that are mappable.

I can do this from either NORMA files or the CQL files that I can
generate from them, though a couple of "known problems" with
the CQL parser means that not all my models compile properly
yet. I'll address those soon.

My metamodel so far has no indicator that a subtype should be
partitioned, so that's not implemented, though subtype absorption
or extension is possible using the "independent" role. Partition will
also require the identification of subtype exhaustion. Anyhow, that's
a small step.

My main next step is to emit SQL, for at least a couple of databases,
and to annotate the generated Ruby so that the objects know how to
construct queries. That should take me up to my presentation at the
OSDC conference on Dec 3.

(*) NORMA will sometimes absorb an AutoCounter field into a table
that already has one, or will absorb the same field into more than
one place, which leads to processing errors. It also sometimes
chooses the wrong end of a one-to-one, such as when it creates
a "Name" table instead of an "Author" table in my Blog model. My
implementation of Rmap doesn't have these errors.

Clifford Heath, Data Constellation.
Agile Information Management and Design.

Folk on the information_modeling list (and others).

Just a quick update so you know what I've been doing with
ActiveFacts recently. When I last wrote, I was nearly done
with defining the CQL data definition language. I can dump
any model (including one imported from NORMA) into CQL.
Work on CQL is continuing - I still have to make some final
decisions on which of several syntaxes to use for external
constraints. You can read the examples with the CQL here:
<http://activefacts.rubyforge.org/svn/examples/>. But in the
meantime...

Metamodel:

I've completed a metamodel in NORMA, and I can dump that
to CQL. You can read the metamodel in PDF, PNG images, or
CQL here:

PDF: <http://activefacts.rubyforge.org/svn/examples/pdf/Metamodel>
PNG: <http://activefacts.rubyforge.org/svn/examples/images/Metamodel>
CQL: <http://activefacts.rubyforge.org/svn/examples/CQL/Metamodel.cql>

Note that you'll need to save the PDF and PNG files before
opening them. A text file listing my outstanding issues is posted here:
<http://activefacts.rubyforge.org/svn/docs/MetamodelIssues.txt>.
Comments and review is welcome.

Runtime API:

Now, my interchanges with Matthew Wilson have inspired me
to jump ahead to start defining the Ruby runtime API to be
used in programming an ActiveFacts application. I wrote a
preliminary design document which any Ruby people especially
are welcome to comment on; it might not make much sense to
others. I've also explored and solved issues with the dynamic
programming required to implement it. The document is here:
<http://activefacts.rubyforge.org/svn/docs/API.txt>

As the runtime implementation progresses, I'll also construct a
generator, which can dump any model as a runtime API definition.
In fact I've hand-crafted an instance of a runtime API for the
CompanyDirector model, for use in checking the API.

New base API?

This raises an interesting possibility. Since I have a metamodel,
and I will have an API generator for any model, I should be able
to dump the metamodel as an API, and use that as a new base
API to replace my hand-crafted one. This is likely to resolve some
consistency issues with the old API, and is also a very real test
for the ease of programming with the new API. In the fullness of
time, it'll also provide relational persistence, so I can use it in my
Rails applications, and even APRIMO.

Upcoming work:

Once I have the runtime API roughed-out and a generator for it,
I'll finish both the external constraint syntax and the backend of
the CQL parser, potentially making it work to the new base API
generated from the metamodel.

The metamodel doesn't support queries yet, and the base API
won't yet enforce constraints, so those will be the next goals
before working on adding the relational persistence layer. At the
moment I think I'll use the Sequel Ruby module to access the
various database engines.

So that's about the size of things. The project is proceeding well,
and I expect to have some useful artefacts pretty soon now.

Clifford Heath, Data Constellation.

At 12:41 PM +1100 12/31/07, Clifford Heath wrote:
>> Nits:
>> ... specification, design  and implementation.
>>                    design,
>
> Why is this correct (a comma before "and"), when the following
> isn't?  Is it because it's a list?
>
>> ... so evolution is costly, and the database ...
>>                     costly

Kind of.  The serial comma is used in cases where there are three
or more items in a list, as:

   A, B, or C
   D, E, and F

Tom Christiansen, of Perl fame, likes this egregious example
as a way to show the perils of leaving out this comma:

   I'd like to thank my parents, God and Mother Teresa.


The second case, in contrast, has the structure:

   A, so B and C.

If it had the structure

   A, so B, C, and D.

a comma would be appropriate (but breaking up the sentence
might be a better solution :-).

-r


P.S.  Although I've worked as a technical writer and editor,
       my formal training in grammar and punctuation is a bit
       spotty.  Follow any advice at your own risk...
--
http://www.cfcl.com/rdm            Rich Morin
http://www.cfcl.com/rdm/resume     rdm@...
http://www.cfcl.com/rdm/weblog     +1 650-873-7841

Technical editing and writing, programming, and web development

Rich (and other information_modelers),

Thanks. I had picked up one or two typos, but your detailed
review is very valuable. I'll apply the changes soon.

My Treetop grammar for the core of CQL is checked-in to SVN
for ActiveFacts, though it needs the current edge (not the Gem)
of Treetop that has my patches in it - and also my Polyglot gem.
Treetop is *magic* at resolving this grammar, which needs a lot
of back-tracking. Such a language was infeasible before the
invention of PEG (packrat) parsers.

You can use bin/read_norma.rb -C to dump a NORMA model in
CQL.

The semantic backend of the CQL parser is still missing, but I'm
making progress on that at the moment. I also have a collaborator
who's interested in working on APRIMO with me, so that should
see some progress too.

I'll probably do a naive Relational Compositor soon, using the
6NF mapping directly, so I can make a start on executing
queries. That'll give a framework for testing a more sophisticated
Compositor.

I also need to make a start on the runtime API. At the moment,
I think that Value Types should be represented using the base
Ruby data types (Strings, etc), perhaps Struct for entities, both
augmented with an extra method for each role, and a "derivation"
or "origin" method to tie back to the query or DDL construct, by
way of reflection. Your thoughts? I need to do a detailed review
of the DotNET 3.5 Entity Framework, which is attempting similar
goals.

I also have a more complicated question regarding queries to
answer. It'll take some work to phrase the question though, so
I'll leave it for now. Basically it's about how to handle query
parameters - whether to provide bindings (values) for any query
variable, or to write each query parameter using a transient fact
type, for which a transient fact pool (population) is invoked. The
latter is easier, supports generation of stored procedures, and
matches the Rails session concept, but is less flexible. If that
question makes sense to you without further explanation, you
might share your thoughts.

> Nits:
> ... specification, design  and implementation.
>                    design,

Why is this correct (a comma before "and"), when the following
isn't? Is it because it's a list?

> ... so evolution is costly, and the database ...
>                     costly

Clifford Heath.

Folk,

A reasonably current description of the ActiveFacts project and
status has
been uploaded to <http://dataconstellation.com/ActiveFacts/>.

The Constellation Query Language is mentioned but not described,
though an early version of the NORMA to CQL converter is available, so
that you can see what your NORMA models might look like in textual form.

The CQL parser (not yet released) is implemented using Treetop, a PEG
(parsing expression grammar, a pack-rat parser generator), and is
passing
all language recognition tests. I'm working on adding complex
constraints
and the semantic back-end of the language. Using a pack-rat parser
allows
efficient backtracking to handle the ambiguity of a near-natural
language.
The semantic back-end will come in two phases; model definition, and
query
definition.

APRIMO, a semantic modeling IDE written as a web application in
Rails, is
also not yet released. I think I'll release this first as an online
service.

Clifford Heath.

On 12/12/2007, at 4:26 PM, pitcat_regime wrote:
> The following is purely speculative and incomplete :)
> http://www.paste2.org/p/10458
>
> There may no doubt be more a transparent and succinct syntax, but it
> was a useful exercise, and raises some questions....

Certainly... like:

"how is a business analyst supposed to verify this?",
"what's with all the : => { } symbols?",
"what's a module, a class, an attr_accessor?".

You see, it just doesn't even begin to address the problem that
semantic modeling exists to solve. That's why I gave up pursuing
that path. You'd be better off just dumping the structures as YAML.

It'd certainly be feasible to come up with such a language that you
could convince some programmers to use... or you could just use
ActiveFacts to dump the NORMA model to the CQL below, then
use the new parser (based on Treetop) to convert it into runtime
model objects. I think you'll agree that the CQL is easier to read.

Here's the full dump from my version of the NORMA model using AF.
This passes through the parser, though I'm lacking syntax for a couple
of constraints. All the entities here use simple reference modes, so you
only see the syntax for that style of identification. The parser
supports
multi-part identification, and also supports conceptual queries.

Since you've bent your mind to this problem, perhaps you'd like to
suggest consistent plain(-ish) language syntax for the remaining
constraints (in a C-style comment at the bottom).

Clifford Heath, Data Constellation.

// Model Orienteering
Accessibility = FixedLengthText(1) restricted to {'A'..'D'};
ClubCode = VariableLengthText(6);
ClubName = VariableLengthText(32);
ControlNumber = UnsignedInteger(32) restricted to {1..1000};
Course = VariableLengthText(16) restricted to {'A'..'E', 'PW'};
EntryID = AutoCounter();
EventID = AutoCounter();
EventName = VariableLengthText(50);
FamilyName = VariableLengthText(48);
Gender = FixedLengthText(1) restricted to {'M', 'F'};
GivenName = VariableLengthText(48);
Location = VariableLengthText(200);
MapID = AutoCounter();
MapName = VariableLengthText(80);
Number = UnsignedInteger(32) restricted to {1..100};
PersonID = AutoCounter();
PointValue = UnsignedInteger(32);
Position = UnsignedInteger(32);
PostCode = UnsignedInteger(32);
PunchID = AutoCounter();
Score = SignedInteger(32);
ScoringMethod = VariableLengthText(32) restricted to {'Score',
'Scatter', 'Special'};
SeriesID = AutoCounter();
SeriesName = VariableLengthText(40);
StartTime = DateAndTime();
Time = DateAndTime();
Year = UnsignedInteger(32) restricted to {1900..3000};

Club = entity(Code);
Entry = entity(ID);
Event = entity(ID);
Map = entity(ID);
Person = entity(ID);
Punch = entity(ID);
Series = entity(ID);

Event is called at most one EventName;
EventName is name of at most one Event;
Map is map for Event,
          Event uses exactly one Map;
Location is where Event starts,
          Event starts at exactly one start Location;
ClubName is name of at most one Club
      Club has exactly one ClubName;
Map has exactly one MapName,
          MapName is of at most one Map;
Event is held on exactly one StartTime;
Person has exactly one FamilyName,
          FamilyName is of Person;
Club (as Owner) owns Map,
          Map is owned by exactly one CLub;
Visit = Punch was visited by Entry at Time (as VisitTime);
Series has exactly one SeriesName (as Name),
          SeriesName (as Name) is of at most one Series;
Map has at most one Accessibility;
Person has exactly one GivenName,
          GivenName is name of Person;
Person is of at most one Gender;
Person was born in at most one Year (as BirthYear);
Person has at most one PostCode;
Person is a member of at most one Club (as MemberOfClub);
Entry received at most one Score;
Entry finished in at most one finish Position;
EventScoringMethod = ScoringMethod is used for Course of Event;
ControlValue = ControlNumber for Event has at most one PointValue;
PunchPlacement = Event has Punch at at most one ControlNumber;
Event is in at most one Series;
Event has at most one Number;
Club runs Event,
          Event is run by exactly one Club;

/*
Constraints not yet converted:
          CompetitorHasDistinctName: each combination
(PersonHasGivenName.GivenName, PersonHasFamilyName.FamilyName) may
occur at most 1 time
          OnlyOneScoringMethodForEachEventAndCourse: in
EventScoringMethod, each combination (Course, Event) may occur at
most 1 time
          InternalUniquenessConstraint10: in Entry, each combination
(Person, Event) may occur at most 1 time
          EqualityConstraint EqualityConstraint1 between
EventIsInSeries(Event), EventHasNumber(Event)
   */

Hi
The following is purely speculative and incomplete :)
http://www.paste2.org/p/10458

There may no doubt be more a transparent and succinct syntax, but it
was a useful exercise, and raises some questions....

HTH?

Mark,

You mentioned having done a rogaine in Perth. Are you
an Aussie, and if so, where located? I'm in Melbourne.

Clifford Heath.

Thanks again Clifford!
Seem to be saying that alot lately :)

<snip>

> >> The problem with DRYSql's method is that a relational database
> >> has already had most of the semantic information removed. The
> >> SQL meta-schema simply isn't rich enough to support it.
> >>
> >> Similarly, Og is based on defining objects, and mapping those to
> >> relations. Again, although the objects contain more semantic
> >
> > Og currently implements an SQLStore, which is a specialization of a
> > generic Store, so one would expect to write a CQLStore.
>
> Og exists to save and retrieve objects. Objects are about "how"
> much more than they are about "what" and "why". No matter
> how you store your objects, they're still objects, and that's been
> done very well already. I don't plan to enter that competition.
> Too much of the IT industry's history has revolved around "how",
> yet the pre-eminent cost of failed IT projects is from specification
> error - failing to manage "what" and "why".
>
> Semantic modeling is about capturing the "what" and "why". In
> the process, the relationships (fact types) between entities must
> be enumerated, as do the constraints over those fact types. The
> *result* allows the derivation of objects (in the Og, Ruby, O-O
> sense), and also allows derivation of efficient physical storage using
> relations. But if you go straight to those, and avoid the semantic
> stuff, you lose sight of the "roles" of each entity type and the ability
> to explain in plain language what those roles mean, and to use that
> language to query them.

Yes, I see what you mean - I started to draft what I thought
OrienteeringRegistration.png might look like.  the book hasn't arrived
yet but your the png image, tutorial, the .orm file and give some
clues about what is involved.

If you like I'll post what I end up with, though it is likely
imperfect/incomplete, and will no doubt be old hat to you.
It is a very interesting, and eye opening exercise :)

> Terry's book covers all the static aspects of an information model,
> but not yet a language for derived facts (queries). He has always
> intended to specify dynamic constraints as well, but there's not
> much published in that area. CQL covers fact derivation, but for
> dynamic constraints, I have a slightly different tack, which is to
> model processes, and process constraints. An example of a process
> constraint might be in a situation where you have a Warehouse
> containing Products, and Fruit is a subtype of Product, a constraint
> might be that "no Fruit may be stored in any Warehouse for more
> than one week". It's a business rule, but it doesn't tell you how the
> process will work to ensure the rule is kept. The point is that a rule
> doesn't have to be directly executable to be important.

OK have you seen story-runner? It is (when I last looked) part of the
RSpec project, if they don't accomodate exactly what you need they may
have done some heavy lifting?

> > (If
> > Ruby's flexibility is not enough to generate CQL then the AF exercise
> > seems moot?).
>
> Every programming artefact should be expressed in the language
> that best suits that artefact. Ruby is not equally suitable for
> expressing
> all imaginable artefacts, though it's obviously possible to.
>
> >  Form some later remarks I'm left
> > with the impression that there is something fundamentally incompatible
> > with Ruby and O/RM - such that information required for O/RM can't be
> > expressed by or interrogated from Ruby objects.
>
> O/RM is Object/Relational Mapping, not Object Role Modeling.
> The slash goes between because that's what the mapping
> does, it goes between. But no, there's nothing fundamentally
> incompatible. However would you choose to use Ruby to express
> a wiring diagram for a house? There are better languages for
> that, even though you could technically do it.

Yes you are right - apologies for the rant.
Not being a full-time programmer, and working alone, I tend to find it
more efficient to invest heavily in as few technologies as possible,
individually they might not be optimal for a single task, but it
maximizes the time I have since what I learn of Ruby in say Og, is
portable to Ruby's EventMachine, or a messaging package.  Of course
for serious asynchronous work you'd probably use MPI, and I have, but
given the time constraint... The MPI set-up/refresher curve is more
expensive than firing up x instances of an evented Ruby script and
feeding it to a simple Condor batch queue.

I take the points you make below.
While it is preferable to write CQL descriptions it seems that there
is nothing lurking in the background that makes a 'translation' of
Ruby to CQL impossible - but possibly might be inelegant and/or
obscure comprehension.

dying to see the book arrive in the mean time - back to
OrienteeringRegistration.  BTW I did a 24 Rogain in Perth - once was
enough :)

Mark

> >  but a Ruby
> > class can be 'enchanted' (Og's term for the meta-programming...
>
> I'm quite familiar with meta-programming in Ruby. My Chattr gem
> does a bit of it, for example. But that's not the point. CQL is not a
> Ruby-only solution. What it does is needed also in Java, and it
> needs to be built into the database products as a replacement for
> SQL. I don't have much interest in charming people with my Ruby
> meta-programming fu. It's just not what I'm about here. I might yet
> do it, but it's not the point.
>
> > Ouch.  But interesting.
>
> Ouch maybe, but it's horses for courses. At my last job we used C#,
> Perl, Ruby, C++, Java, and several custom-made DSLs for which
> we had processors to emit each. For internationalised text catalogs,
> we had one, for configuration variable hives another, for tracing
> classes another, and most importantly, one to represent the database.
> The data can obviously be represented in all those languages, but the
> DSLs were more suitable, and targeted all of them. They also got
> generated into >400 pages of high-quality printed documentation,
> all from the one set of source files. You think we should have just
> used Ruby instead of full-custom DSLs?
>
> > OK, I've never used AR or Rails - cross fingers that won't change.
> > From what I could tell they hid too much of Ruby - you end up with a
> > large amount of non-transferable/non-extensible knowledge.
>
> That sounds like a knee-jerk response. They're both very good at
> solving the problems they address. Not perfect, but very good.
>
> >> No, because Og doesn't allow modeling at the right level. Rather you
> >
> > I think Og permits modeling at the level Ruby does, so in fact this is
> > a more important observation:  Ruby doesn't allow modeling at the
> > right level - correct?
>
> Objects are aggregate forms. The aggregation from the elementary
> facts requires judgement, and the standard practice is not to attempt
> to even write down the elementary facts. Instead, you read the spec,
> question the client, and get as many of the facts into your head as you
> can, then you start making judgements - writing code. When the
> requirements change, as they invariably do, someone has to get their
> head around all the relevant facts before they can even consider
> refactoring. The process is flawed because the original facts are only
> stored in the form of the working code. Semantic modeling is an attempt
> to address that problem, by providing a way to write down what it was
> you originally wanted, and why.
>
> >> No. You write your CQL file, or use my Rails app "APRIMO" to do that,
> >> and then you can require it in a Ruby program and create & query the
> >> DB using the Ruby classes that were created by the CQL parser.
> >
> > I'll keep watching AF with interest.  However, purely from a end users
> > perspective: the requirement to know CQL to use AF (write the CQL
> > file) is no more attractive than the requirement to know SQL to use
> > DrySQL (create the database).
>
> I think on the contrary that you'll find it a good deal more attractive.
> Writing CQL isn't the only way of making a model, and the whole
> point of capturing all the semantic information is to make comprehension
> a breeze. That makes possible for example end-user query tools that
> are amazingly simple to pick up and use. I hate to say it, but Microsoft
> is way ahead of everyone else, and is doing this right now in their
> Reporting Services. You use the Model Designer to wrap a semantic
> model around (part of) an existing database, and then end-users with
> almost no knowledge can construct reports using drag and drop. In
> five minutes a novice can learn to create an SQL query that'd make a
> seasoned DBA scratch his head for an hour.  I have some simple
> demos of this sort of thing...
>
> Clifford Heath.
>

On 04/12/2007, at 3:45 PM, pitcat_regime wrote:
> Thanks for a fascinating exchange, I will get the Halpin book.  Work
> might get in the way of concerted study but hopefully over time I'll
> work through it.

He's working on a new edition, but the existing one is juicy enough
to be more than worth the price :-).

>> The problem with DRYSql's method is that a relational database
>> has already had most of the semantic information removed. The
>> SQL meta-schema simply isn't rich enough to support it.
>>
>> Similarly, Og is based on defining objects, and mapping those to
>> relations. Again, although the objects contain more semantic
>
> Og currently implements an SQLStore, which is a specialization of a
> generic Store, so one would expect to write a CQLStore.

Og exists to save and retrieve objects. Objects are about "how"
much more than they are about "what" and "why". No matter
how you store your objects, they're still objects, and that's been
done very well already. I don't plan to enter that competition.
Too much of the IT industry's history has revolved around "how",
yet the pre-eminent cost of failed IT projects is from specification
error - failing to manage "what" and "why".

Semantic modeling is about capturing the "what" and "why". In
the process, the relationships (fact types) between entities must
be enumerated, as do the constraints over those fact types. The
*result* allows the derivation of objects (in the Og, Ruby, O-O
sense), and also allows derivation of efficient physical storage using
relations. But if you go straight to those, and avoid the semantic
stuff, you lose sight of the "roles" of each entity type and the ability
to explain in plain language what those roles mean, and to use that
language to query them.

Terry's book covers all the static aspects of an information model,
but not yet a language for derived facts (queries). He has always
intended to specify dynamic constraints as well, but there's not
much published in that area. CQL covers fact derivation, but for
dynamic constraints, I have a slightly different tack, which is to
model processes, and process constraints. An example of a process
constraint might be in a situation where you have a Warehouse
containing Products, and Fruit is a subtype of Product, a constraint
might be that "no Fruit may be stored in any Warehouse for more
than one week". It's a business rule, but it doesn't tell you how the
process will work to ensure the rule is kept. The point is that a rule
doesn't have to be directly executable to be important.

> (If
> Ruby's flexibility is not enough to generate CQL then the AF exercise
> seems moot?).

Every programming artefact should be expressed in the language
that best suits that artefact. Ruby is not equally suitable for
expressing
all imaginable artefacts, though it's obviously possible to.

>  Form some later remarks I'm left
> with the impression that there is something fundamentally incompatible
> with Ruby and O/RM - such that information required for O/RM can't be
> expressed by or interrogated from Ruby objects.

O/RM is Object/Relational Mapping, not Object Role Modeling.
The slash goes between because that's what the mapping
does, it goes between. But no, there's nothing fundamentally
incompatible. However would you choose to use Ruby to express
a wiring diagram for a house? There are better languages for
that, even though you could technically do it.

>  but a Ruby
> class can be 'enchanted' (Og's term for the meta-programming...

I'm quite familiar with meta-programming in Ruby. My Chattr gem
does a bit of it, for example. But that's not the point. CQL is not a
Ruby-only solution. What it does is needed also in Java, and it
needs to be built into the database products as a replacement for
SQL. I don't have much interest in charming people with my Ruby
meta-programming fu. It's just not what I'm about here. I might yet
do it, but it's not the point.

> Ouch.  But interesting.

Ouch maybe, but it's horses for courses. At my last job we used C#,
Perl, Ruby, C++, Java, and several custom-made DSLs for which
we had processors to emit each. For internationalised text catalogs,
we had one, for configuration variable hives another, for tracing
classes another, and most importantly, one to represent the database.
The data can obviously be represented in all those languages, but the
DSLs were more suitable, and targeted all of them. They also got
generated into >400 pages of high-quality printed documentation,
all from the one set of source files. You think we should have just
used Ruby instead of full-custom DSLs?

> OK, I've never used AR or Rails - cross fingers that won't change.
> From what I could tell they hid too much of Ruby - you end up with a
> large amount of non-transferable/non-extensible knowledge.

That sounds like a knee-jerk response. They're both very good at
solving the problems they address. Not perfect, but very good.

>> No, because Og doesn't allow modeling at the right level. Rather you
>
> I think Og permits modeling at the level Ruby does, so in fact this is
> a more important observation:  Ruby doesn't allow modeling at the
> right level - correct?

Objects are aggregate forms. The aggregation from the elementary
facts requires judgement, and the standard practice is not to attempt
to even write down the elementary facts. Instead, you read the spec,
question the client, and get as many of the facts into your head as you
can, then you start making judgements - writing code. When the
requirements change, as they invariably do, someone has to get their
head around all the relevant facts before they can even consider
refactoring. The process is flawed because the original facts are only
stored in the form of the working code. Semantic modeling is an attempt
to address that problem, by providing a way to write down what it was
you originally wanted, and why.

>> No. You write your CQL file, or use my Rails app "APRIMO" to do that,
>> and then you can require it in a Ruby program and create & query the
>> DB using the Ruby classes that were created by the CQL parser.
>
> I'll keep watching AF with interest.  However, purely from a end users
> perspective: the requirement to know CQL to use AF (write the CQL
> file) is no more attractive than the requirement to know SQL to use
> DrySQL (create the database).

I think on the contrary that you'll find it a good deal more attractive.
Writing CQL isn't the only way of making a model, and the whole
point of capturing all the semantic information is to make comprehension
a breeze. That makes possible for example end-user query tools that
are amazingly simple to pick up and use. I hate to say it, but Microsoft
is way ahead of everyone else, and is doing this right now in their
Reporting Services. You use the Model Designer to wrap a semantic
model around (part of) an existing database, and then end-users with
almost no knowledge can construct reports using drag and drop. In
five minutes a novice can learn to create an SQL query that'd make a
seasoned DBA scratch his head for an hour.  I have some simple
demos of this sort of thing...

Clifford Heath.

A big Ooops... I misread the sentence as containing a negative

<snip>

> > There are only a very few that know what a fact-based, or elementary,
> > or semantic model is. There is a number of projects trying to make
>
> I know, I'm one of them :)

I know, I'm _not_ one of them

:)

Mark

> > SQL less unpalatable, but they're only addressing the syntactic
issues.
> > What I'm building has a different and higher-level semantics.
> >
> > >> I'm creating a new query language, the Constellation Query
Language.
> > >> CQL has many advantages over SQL, the most important one being
> > >> that queries written in CQL are immune to the most common kinds
> > >> of schema migration that occur, including attribute migration. The
> > >
> > > OK that sounds very interesting.  After emailing I looked at the
> > > ORM-Metamodel.pdf and it looked like trying to map a Ruby class
> > > to/from that schema there might be a better place to start.
> >
> > I've done that, twice actually. The ActiveFacts base API is an O-O
> > API that captures exactly what you see in relational form in the SQL
> > meta-model. I also have an ActiveRecord version of the same thing
> > which is inside a Rails app I'm building to edit semantic models. It's
> > not yet published, but it's very similar to the schema you've seen,
> > with just a few concessions to Rails cursed "opinions" (i.e. errors).
> >
>
> OK, I've never used AR or Rails - cross fingers that won't change.
> From what I could tell they hid too much of Ruby - you end up with a
> large amount of non-transferable/non-extensible knowledge.
>
> > >   Obviously
> > > I don't understand all the operation or relations flagged there, but
> > > it seemed that the Og decorations would be much simpler...
> >
> > You should definitely get a copy of Terry Halpin's book. It will quite
> > literally change forever the way you think about all this stuff.
All the
> > basic constructs are introduced in my example presentation to
> > which I gave the URL above.
>
> Yes I will, thanks.
>
> > > ... however, I was stumped on how you'd (simply) query field(s) :)
> >
> > In sixth normal form, you may only have one non-key attribute per
> > table. In that form, to access any attribute requires a join. This
is a
> > characteristic of the elementary form - every traversal of a fact type
> > is a join. So when I query the fact type "Person has given Name", I'm
> > doing a join. This query has two variables. When I execute it, I can
> > bind either variable to a value, and executing the query yields the
> > value(s) for the other variable. If I bind the Person variable, I
get
> > that
> > person's given name(s). If I bind the name, for example to "Fred", I
> > get all Persons called "Fred". I've given you no information about
> > whether a Person may have only one, or more than one, given Name,
> > and you didn't need to know. If more than one, there will be a join
> > table between Person and Name. If only one, givenName will be an
> > attribute in the Person table. But the point is that you didn't
need to
> > know that, and can *change* it, without the query being broken.
> >
> > This is a very simplistic example, obviously. If you "svn up"
> > ActiveFacts
> > to the most recent, and if you have NORMA (http://sf.net/projects/orm)
> > installed in Visual Studio, you'll see an oil industry supply model.
> > This
> > has Regions, which have an estimated Demand for Products in a
> > given Month, and Refineries, which have production commitments for
> > products. Within certain seasons, certain products may be substituted
> > for other products. Transport routes indicate which refineries can
ship
> > to which regions. A query in CQL can ask for the optimum orders for
> > appropriate products to fulfil the demand for a given region, or
> > potentially
> > even to optimise all orders over all regions - a pretty complex
task! So
> > you see that there's potentially huge computational power expressed in
> > quite simple queries. Building the engine to execute them will be
> > another
> > matter, of course... But so it was when SQL was first proposed.
>
> CQL does indeed sound intriguing!  The suspense is building :)
>
> > > So it sounds like the answer would be to construct the CQL using Og
> > > and hand-off the query generation to you CQL2SQL interpreter.
> >
> > No, because Og doesn't allow modeling at the right level. Rather you
>
> I think Og permits modeling at the level Ruby does, so in fact this is
> a more important observation:  Ruby doesn't allow modeling at the
> right level - correct?
>
> > include the CQL file, which defines classes, then you re-open those
> > classes to add code where needed.
> >
> > One of the operations on the model is to create a relational version
> > of it, and using that, to create the actual database - so in that
> > respect,
> > it's like Og, not DRYSql.
> >
> > > So it sounds like Og would need to create a CQL-model
> > > definition, then feed (save-require) that to polygot - correct?
> >
> > No. You write your CQL file, or use my Rails app "APRIMO" to do that,
> > and then you can require it in a Ruby program and create & query the
> > DB using the Ruby classes that were created by the CQL parser.
>
> I'll keep watching AF with interest.  However, purely from a end users
> perspective: the requirement to know CQL to use AF (write the CQL
> file) is no more attractive than the requirement to know SQL to use
> DrySQL (create the database).  The Rails app will fit an important
> niche, but leaves those situations where Ruby is put to some of it's
> best use - classes created and manipulated dynamically.
>
> > >  AF will mandate starting
> > > with a CQL definition - which is fine, Og, etc will probably
evolve to
> > > translate some decorated ruby class (or more perhaps a class
instance)
> > > to CQL,
> >
> > Not sensible. That would be like writing assembly code and trying
> > to work with the output of a reverse compiler. AF will have reverse
> > engineering tools available, but the output will be a starting point
> > to allow you to construct a semantic model; much of the interesting
> > stuff simply isn't present in a relational schema, or even in a object
> > DB language (like Og).
>
> Is it (doing the interesting stuff) available/possible in an object
> language like Ruby?  If so then it should be available to Og.
> I think you may misunderstand Og. A CQLStore would permit you to do
> whatever Ruby allows.  If however I cannot express things in Ruby that
>  the O/RM approach requires then that will be disappointing, and yes
> then CQL is the primary language end users should learn, and Ruby
> (AR/Rails, etc.) becomes a background helper script facility.
>
> > > All sounds very promising, do you have any feel for when the CQL
> > > definition/specification might be in public beta form
> >
> > I'm working at the same time on a parser and a CQL dump from a
> > base ActiveFacts model. You can get a peek at the CQL by using
> > ActiveFacts to convert NORMA model files to CQL, e.g.:
> >
> > ruby -I lib bin/read_norma.rb -C examples/norma/OilSupply.orm
>
> I've posted to this list and on Ruby forge about the errors I saw
> trying to run some of the examples, so thanks for providing the CQL
> output, the variable definitions look straight forward, however some
> of the entity qualification seem more elaborate, but systematic.
>
> I'll watch with interest!
>
> Thanks again
> Mark
>
> > which dumps (slightly incomplete CQL):
> >
> > // Model OilSupply
> > Month = VariableLengthText(3);
> > Product = VariableLengthText(80);
> > Quantity = UnsignedInteger(32);
> > RefineryName = VariableLengthText(80);
> > Region = VariableLengthText(80);
> > Season = VariableLengthText(6) restricted to {'Spring', 'Summer',
> > 'Autumn', 'Winter'};
> > Transportation = VariableLengthText();
> > Year = UnsignedInteger(32);
> > AcceptableSubstitutes = entity known by Product and Product and
Season:
> >          Product may be substituted by alternate Product in Season,
> >          alternate Product is an acceptable substitute for Product
in
> > Season;
> >
> > Refinery = entity known by RefineryName:
> >          Refinery has exactly one RefineryName,
> >          RefineryName is of at most one Refinery;
> >
> > RegionalDemand = entity known by Product and Year and Month and
Region:
> >          Region in Month of Year will need Product in at most one
> > Quantity;
> >
> > Month is in at most one Season;
> > TransportRoute = Transportation is available from Refinery to Region,
> >          Transportation is available to Region from Refinery;
> > ProductionCommitment = Refinery has committed by Month to produce
> > Product in Quantity,
> >          in Month Refinery has committed to produce Quantity of
Product;
> >
> > This still has a couple of errors, for example there is a missing
> > "alternate" in
> > the "known by" list of AcceptableSubstitutes. Also some constraint
> > types cannot
> > yet be converted, and I may need to change existing parts of the
> > schema to
> > accommodate them. The value types (data types) are as received from
> > NORMA,
> > and not natural to CQL. Reference Modes, which are common patterns of
> > identification of entities, are still not detected. They will reduce
> > many of the
> > entity definitions, for example, Refinery becomes: "Refinery = entity
> > (Name);".
> >
> > This is basically a complete schema, which can be transformed into
> > relational
> > form. For the same model, NORMA produces this (nearly-usable) SQL for
> > MySQL. I believe that the errors in NORMA's SQL generation are rapidly
> > being fixed. Either way, you can guess which syntax I prefer!
> >
> > CREATE TABLE `Month`
> > (
> >  monthValue VARCHAR(3)  NOT NULL,
> >  season VARCHAR(6) ,
> >  CONSTRAINT MonthUniqueness PRIMARY KEY(monthValue)
> > );
> >
> > CREATE TABLE TransportRoute
> > (
> >  transportation VARCHAR()  NOT NULL,
> >  refineryName VARCHAR(80)  NOT NULL,
> >  region VARCHAR(80)  NOT NULL,
> >  CONSTRAINT InternalUniquenessConstraint8 PRIMARY
KEY(transportation,
> > refineryName, region)
> > );
> >
> > CREATE TABLE ProductionCommitment
> > (
> >  refineryName VARCHAR(80)  NOT NULL,
> >  quantity  NOT NULL,
> >  product VARCHAR(80)  NOT NULL,
> >  `month` VARCHAR(3)  NOT NULL,
> >  CONSTRAINT InternalUniquenessConstraint10 PRIMARY KEY(refineryName,
> > quantity, product, "month")
> > );
> >
> > CREATE TABLE RegionalDemand
> > (
> >  region VARCHAR(80)  NOT NULL,
> >  product VARCHAR(80)  NOT NULL,
> >  `year`  NOT NULL,
> >  `month` VARCHAR(3)  NOT NULL,
> >  quantity  NOT NULL,
> >  CONSTRAINT InternalUniquenessConstraint17 PRIMARY KEY(region,
> > product, "year", "month")
> > );
> >
> > CREATE TABLE AcceptableSubstitutes
> > (
> >  alternateProduct VARCHAR(80)  NOT NULL,
> >  product VARCHAR(80)  NOT NULL,
> >  season VARCHAR(6)  NOT NULL,
> >  CONSTRAINT InternalUniquenessConstraint22 PRIMARY KEY
> > (alternateProduct, product, season)
> > );
> >
> > ALTER TABLE ProductionCommitment ADD CONSTRAINT
> > ProductionCommitment_FK FOREIGN KEY ("month")  REFERENCES `Month`
> > (monthValue)  ON DELETE RESTRICT ON UPDATE RESTRICT;
> >
> > ALTER TABLE RegionalDemand ADD CONSTRAINT RegionalDemand_FK FOREIGN
> > KEY ("month")  REFERENCES `Month` (monthValue)  ON DELETE RESTRICT
ON
> > UPDATE RESTRICT;
> >
>

Hi clifford,
Thanks for a fascinating exchange, I will get the Halpin book.  Work
might get in the way of concerted study but hopefully over time I'll
work through it.
Just a couple of points of clarification...

--- In information_modeling@yahoogroups.com, Clifford Heath
<clifford.heath@...> wrote:
>
> On 04/12/2007, at 9:54 AM, pitcat_regime wrote
> > Ok, I think this point comes up later - but I may misunderstand what
> > you mean in describing ploygot.
>
> > It is a point I to tried to make with the DRYSql author... AR and Og
> > are the same in terms of your use (persisting), but are opposites in
> > terms of where you 'start' - and that sometimes is not a choice one
> > has :)
> > No criticism of polygot or AF implied!
>
> The problem with DRYSql's method is that a relational database
> has already had most of the semantic information removed. The
> SQL meta-schema simply isn't rich enough to support it.
>
> Similarly, Og is based on defining objects, and mapping those to
> relations. Again, although the objects contain more semantic

Og currently implements an SQLStore, which is a specialization of a
generic Store, so one would expect to write a CQLStore.  Og will
pretty much allow you to do whatever Ruby allows (all the
meta-programming, reflecting etc.), so I'd think the functionality and
expressiveness of a CQLStore would limited to what Ruby permits (If
Ruby's flexibility is not enough to generate CQL then the AF exercise
seems moot?).
On top of the CQLStore you might write an ActiveFactsAdapter - or
maybe the other way around.  As far as the CQLStore or FactStore goes
you're starting with a blank page - what is written on that page is
whatever you need that Ruby permits.  Form some later remarks I'm left
with the impression that there is something fundamentally incompatible
with Ruby and O/RM - such that information required for O/RM can't be
expressed by or interrogated from Ruby objects.

> information than the relational schema, a lot is still lost. Objects
> are not elementary, but aggregate. That is, they are a cluster of
> ideas that revolve around a single entity. The elementary facts
> that drove the choice of that particular aggregation are lost.

I'll need to read the Halprin book more to understand this, but a Ruby
class can be 'enchanted' (Og's term for the meta-programming that goes
on) with an arbitrary number of methods, attributes, variables etc.
what information it gets given and what the CQLStore should do with
this information... that seems to be specified by the AF/CQL.

> So both a relational model and an object model is a lower-level
> construct than a semantic model. That's why a new language is
> needed. I tried to create one as a Ruby DSL, but Ruby's syntax
> got in the way too much.

Ouch.  But interesting.

> >> ActiveFacts doesn't yet take a model and transform it into a
> >> relational database design.
> >
> > OK its not clear if you mean a Fact based model, or a Ruby
> > AF-decorated-class model.
>
> Both are fact-based models, but I wasn't concerned with the syntax.
> It could come from a Ruby DSL, an ORM diagram, or from CQL.
> The transformation that's lacking is from the elementary form to the
> compound (relational) form. Look at the elementary and compound
> forms of the orienteering model here for an example:
> <http://dataconstellation.com/ActiveFacts/examples/>
>
> >> That's on the cards soon, and isn't terribly hard, but
> >> I'm otherwise occupied...
> >
> > There seems to be a large Ruby community interested in 'persistence',
> > there maybe enoguh people to help out on an initial effort?
>
> There are only a very few that know what a fact-based, or elementary,
> or semantic model is. There is a number of projects trying to make

I know, I'm one of them :)

> SQL less unpalatable, but they're only addressing the syntactic issues.
> What I'm building has a different and higher-level semantics.
>
> >> I'm creating a new query language, the Constellation Query Language.
> >> CQL has many advantages over SQL, the most important one being
> >> that queries written in CQL are immune to the most common kinds
> >> of schema migration that occur, including attribute migration. The
> >
> > OK that sounds very interesting.  After emailing I looked at the
> > ORM-Metamodel.pdf and it looked like trying to map a Ruby class
> > to/from that schema there might be a better place to start.
>
> I've done that, twice actually. The ActiveFacts base API is an O-O
> API that captures exactly what you see in relational form in the SQL
> meta-model. I also have an ActiveRecord version of the same thing
> which is inside a Rails app I'm building to edit semantic models. It's
> not yet published, but it's very similar to the schema you've seen,
> with just a few concessions to Rails cursed "opinions" (i.e. errors).
>

OK, I've never used AR or Rails - cross fingers that won't change.
From what I could tell they hid too much of Ruby - you end up with a
large amount of non-transferable/non-extensible knowledge.

> >   Obviously
> > I don't understand all the operation or relations flagged there, but
> > it seemed that the Og decorations would be much simpler...
>
> You should definitely get a copy of Terry Halpin's book. It will quite
> literally change forever the way you think about all this stuff. All the
> basic constructs are introduced in my example presentation to
> which I gave the URL above.

Yes I will, thanks.

> > ... however, I was stumped on how you'd (simply) query field(s) :)
>
> In sixth normal form, you may only have one non-key attribute per
> table. In that form, to access any attribute requires a join. This is a
> characteristic of the elementary form - every traversal of a fact type
> is a join. So when I query the fact type "Person has given Name", I'm
> doing a join. This query has two variables. When I execute it, I can
> bind either variable to a value, and executing the query yields the
> value(s) for the other variable. If I bind the Person variable, I get
> that
> person's given name(s). If I bind the name, for example to "Fred", I
> get all Persons called "Fred". I've given you no information about
> whether a Person may have only one, or more than one, given Name,
> and you didn't need to know. If more than one, there will be a join
> table between Person and Name. If only one, givenName will be an
> attribute in the Person table. But the point is that you didn't need to
> know that, and can *change* it, without the query being broken.
>
> This is a very simplistic example, obviously. If you "svn up"
> ActiveFacts
> to the most recent, and if you have NORMA (http://sf.net/projects/orm)
> installed in Visual Studio, you'll see an oil industry supply model.
> This
> has Regions, which have an estimated Demand for Products in a
> given Month, and Refineries, which have production commitments for
> products. Within certain seasons, certain products may be substituted
> for other products. Transport routes indicate which refineries can ship
> to which regions. A query in CQL can ask for the optimum orders for
> appropriate products to fulfil the demand for a given region, or
> potentially
> even to optimise all orders over all regions - a pretty complex task! So
> you see that there's potentially huge computational power expressed in
> quite simple queries. Building the engine to execute them will be
> another
> matter, of course... But so it was when SQL was first proposed.

CQL does indeed sound intriguing!  The suspense is building :)

> > So it sounds like the answer would be to construct the CQL using Og
> > and hand-off the query generation to you CQL2SQL interpreter.
>
> No, because Og doesn't allow modeling at the right level. Rather you

I think Og permits modeling at the level Ruby does, so in fact this is
a more important observation:  Ruby doesn't allow modeling at the
right level - correct?

> include the CQL file, which defines classes, then you re-open those
> classes to add code where needed.
>
> One of the operations on the model is to create a relational version
> of it, and using that, to create the actual database - so in that
> respect,
> it's like Og, not DRYSql.
>
> > So it sounds like Og would need to create a CQL-model
> > definition, then feed (save-require) that to polygot - correct?
>
> No. You write your CQL file, or use my Rails app "APRIMO" to do that,
> and then you can require it in a Ruby program and create & query the
> DB using the Ruby classes that were created by the CQL parser.

I'll keep watching AF with interest.  However, purely from a end users
perspective: the requirement to know CQL to use AF (write the CQL
file) is no more attractive than the requirement to know SQL to use
DrySQL (create the database).  The Rails app will fit an important
niche, but leaves those situations where Ruby is put to some of it's
best use - classes created and manipulated dynamically.

> >  AF will mandate starting
> > with a CQL definition - which is fine, Og, etc will probably evolve to
> > translate some decorated ruby class (or more perhaps a class instance)
> > to CQL,
>
> Not sensible. That would be like writing assembly code and trying
> to work with the output of a reverse compiler. AF will have reverse
> engineering tools available, but the output will be a starting point
> to allow you to construct a semantic model; much of the interesting
> stuff simply isn't present in a relational schema, or even in a object
> DB language (like Og).

Is it (doing the interesting stuff) available/possible in an object
language like Ruby?  If so then it should be available to Og.
I think you may misunderstand Og. A CQLStore would permit you to do
whatever Ruby allows.  If however I cannot express things in Ruby that
  the O/RM approach requires then that will be disappointing, and yes
then CQL is the primary language end users should learn, and Ruby
(AR/Rails, etc.) becomes a background helper script facility.

> > All sounds very promising, do you have any feel for when the CQL
> > definition/specification might be in public beta form
>
> I'm working at the same time on a parser and a CQL dump from a
> base ActiveFacts model. You can get a peek at the CQL by using
> ActiveFacts to convert NORMA model files to CQL, e.g.:
>
> ruby -I lib bin/read_norma.rb -C examples/norma/OilSupply.orm

I've posted to this list and on Ruby forge about the errors I saw
trying to run some of the examples, so thanks for providing the CQL
output, the variable definitions look straight forward, however some
of the entity qualification seem more elaborate, but systematic.

I'll watch with interest!

Thanks again
Mark

> which dumps (slightly incomplete CQL):
>
> // Model OilSupply
> Month = VariableLengthText(3);
> Product = VariableLengthText(80);
> Quantity = UnsignedInteger(32);
> RefineryName = VariableLengthText(80);
> Region = VariableLengthText(80);
> Season = VariableLengthText(6) restricted to {'Spring', 'Summer',
> 'Autumn', 'Winter'};
> Transportation = VariableLengthText();
> Year = UnsignedInteger(32);
> AcceptableSubstitutes = entity known by Product and Product and Season:
>          Product may be substituted by alternate Product in Season,
>          alternate Product is an acceptable substitute for Product in
> Season;
>
> Refinery = entity known by RefineryName:
>          Refinery has exactly one RefineryName,
>          RefineryName is of at most one Refinery;
>
> RegionalDemand = entity known by Product and Year and Month and Region:
>          Region in Month of Year will need Product in at most one
> Quantity;
>
> Month is in at most one Season;
> TransportRoute = Transportation is available from Refinery to Region,
>          Transportation is available to Region from Refinery;
> ProductionCommitment = Refinery has committed by Month to produce
> Product in Quantity,
>          in Month Refinery has committed to produce Quantity of Product;
>
> This still has a couple of errors, for example there is a missing
> "alternate" in
> the "known by" list of AcceptableSubstitutes. Also some constraint
> types cannot
> yet be converted, and I may need to change existing parts of the
> schema to
> accommodate them. The value types (data types) are as received from
> NORMA,
> and not natural to CQL. Reference Modes, which are common patterns of
> identification of entities, are still not detected. They will reduce
> many of the
> entity definitions, for example, Refinery becomes: "Refinery = entity
> (Name);".
>
> This is basically a complete schema, which can be transformed into
> relational
> form. For the same model, NORMA produces this (nearly-usable) SQL for
> MySQL. I believe that the errors in NORMA's SQL generation are rapidly
> being fixed. Either way, you can guess which syntax I prefer!
>
> CREATE TABLE `Month`
> (
>  monthValue VARCHAR(3)  NOT NULL,
>  season VARCHAR(6) ,
>  CONSTRAINT MonthUniqueness PRIMARY KEY(monthValue)
> );
>
> CREATE TABLE TransportRoute
> (
>  transportation VARCHAR()  NOT NULL,
>  refineryName VARCHAR(80)  NOT NULL,
>  region VARCHAR(80)  NOT NULL,
>  CONSTRAINT InternalUniquenessConstraint8 PRIMARY KEY(transportation,
> refineryName, region)
> );
>
> CREATE TABLE ProductionCommitment
> (
>  refineryName VARCHAR(80)  NOT NULL,
>  quantity  NOT NULL,
>  product VARCHAR(80)  NOT NULL,
>  `month` VARCHAR(3)  NOT NULL,
>  CONSTRAINT InternalUniquenessConstraint10 PRIMARY KEY(refineryName,
> quantity, product, "month")
> );
>
> CREATE TABLE RegionalDemand
> (
>  region VARCHAR(80)  NOT NULL,
>  product VARCHAR(80)  NOT NULL,
>  `year`  NOT NULL,
>  `month` VARCHAR(3)  NOT NULL,
>  quantity  NOT NULL,
>  CONSTRAINT InternalUniquenessConstraint17 PRIMARY KEY(region,
> product, "year", "month")
> );
>
> CREATE TABLE AcceptableSubstitutes
> (
>  alternateProduct VARCHAR(80)  NOT NULL,
>  product VARCHAR(80)  NOT NULL,
>  season VARCHAR(6)  NOT NULL,
>  CONSTRAINT InternalUniquenessConstraint22 PRIMARY KEY
> (alternateProduct, product, season)
> );
>
> ALTER TABLE ProductionCommitment ADD CONSTRAINT
> ProductionCommitment_FK FOREIGN KEY ("month")  REFERENCES `Month`
> (monthValue)  ON DELETE RESTRICT ON UPDATE RESTRICT;
>
> ALTER TABLE RegionalDemand ADD CONSTRAINT RegionalDemand_FK FOREIGN
> KEY ("month")  REFERENCES `Month` (monthValue)  ON DELETE RESTRICT ON
> UPDATE RESTRICT;
>

On 04/12/2007, at 1:54 PM, pitcat_regime wrote:
> There seems to be a missing file/dependency in the AF gem?

"gem install chattr" is your friend.

Clifford Heath.

Hi Clifford,
There seems to be a missing file/dependency in the AF gem?

TIA
Mark

irb> require 'activefacts'
MissingSourceFile: no such file to load -- chattr
         from
/usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in
`gem_original_require'
         from
/usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `require'
         from
/usr/lib/ruby/gems/1.8/gems/activesupport-1.4.4/lib/active_support/dependencies.\
rb:495:in
`require'
         from
/usr/lib/ruby/gems/1.8/gems/activesupport-1.4.4/lib/active_support/dependencies.\
rb:342:in
`new_constants_in'
         from
/usr/lib/ruby/gems/1.8/gems/activesupport-1.4.4/lib/active_support/dependencies.\
rb:495:in
`require'
         from
/usr/lib/ruby/gems/1.8/gems/active_facts-0.1.0/lib/activefacts.rb:8
         from
/usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in
`gem_original_require'
         from
/usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `require'
         from
/usr/lib/ruby/gems/1.8/gems/activesupport-1.4.4/lib/active_support/dependencies.\
rb:495:in
`require'
         from
/usr/lib/ruby/gems/1.8/gems/activesupport-1.4.4/lib/active_support/dependencies.\
rb:342:in
`new_constants_in'
         from
/usr/lib/ruby/gems/1.8/gems/activesupport-1.4.4/lib/active_support/dependencies.\
rb:495:in
`require'
         from (irb):6

On 04/12/2007, at 9:54 AM, pitcat_regime wrote
> Ok, I think this point comes up later - but I may misunderstand what
> you mean in describing ploygot.

> It is a point I to tried to make with the DRYSql author... AR and Og
> are the same in terms of your use (persisting), but are opposites in
> terms of where you 'start' - and that sometimes is not a choice one
> has :)
> No criticism of polygot or AF implied!

The problem with DRYSql's method is that a relational database
has already had most of the semantic information removed. The
SQL meta-schema simply isn't rich enough to support it.

Similarly, Og is based on defining objects, and mapping those to
relations. Again, although the objects contain more semantic
information than the relational schema, a lot is still lost. Objects
are not elementary, but aggregate. That is, they are a cluster of
ideas that revolve around a single entity. The elementary facts
that drove the choice of that particular aggregation are lost.

So both a relational model and an object model is a lower-level
construct than a semantic model. That's why a new language is
needed. I tried to create one as a Ruby DSL, but Ruby's syntax
got in the way too much.

>> ActiveFacts doesn't yet take a model and transform it into a
>> relational database design.
>
> OK its not clear if you mean a Fact based model, or a Ruby
> AF-decorated-class model.

Both are fact-based models, but I wasn't concerned with the syntax.
It could come from a Ruby DSL, an ORM diagram, or from CQL.
The transformation that's lacking is from the elementary form to the
compound (relational) form. Look at the elementary and compound
forms of the orienteering model here for an example:
<http://dataconstellation.com/ActiveFacts/examples/>

>> That's on the cards soon, and isn't terribly hard, but
>> I'm otherwise occupied...
>
> There seems to be a large Ruby community interested in 'persistence',
> there maybe enoguh people to help out on an initial effort?

There are only a very few that know what a fact-based, or elementary,
or semantic model is. There is a number of projects trying to make
SQL less unpalatable, but they're only addressing the syntactic issues.
What I'm building has a different and higher-level semantics.

>> I'm creating a new query language, the Constellation Query Language.
>> CQL has many advantages over SQL, the most important one being
>> that queries written in CQL are immune to the most common kinds
>> of schema migration that occur, including attribute migration. The
>
> OK that sounds very interesting.  After emailing I looked at the
> ORM-Metamodel.pdf and it looked like trying to map a Ruby class
> to/from that schema there might be a better place to start.

I've done that, twice actually. The ActiveFacts base API is an O-O
API that captures exactly what you see in relational form in the SQL
meta-model. I also have an ActiveRecord version of the same thing
which is inside a Rails app I'm building to edit semantic models. It's
not yet published, but it's very similar to the schema you've seen,
with just a few concessions to Rails cursed "opinions" (i.e. errors).

>   Obviously
> I don't understand all the operation or relations flagged there, but
> it seemed that the Og decorations would be much simpler...

You should definitely get a copy of Terry Halpin's book. It will quite
literally change forever the way you think about all this stuff. All the
basic constructs are introduced in my example presentation to
which I gave the URL above.

> ... however, I was stumped on how you'd (simply) query field(s) :)

In sixth normal form, you may only have one non-key attribute per
table. In that form, to access any attribute requires a join. This is a
characteristic of the elementary form - every traversal of a fact type
is a join. So when I query the fact type "Person has given Name", I'm
doing a join. This query has two variables. When I execute it, I can
bind either variable to a value, and executing the query yields the
value(s) for the other variable. If I bind the Person variable, I get
that
person's given name(s). If I bind the name, for example to "Fred", I
get all Persons called "Fred". I've given you no information about
whether a Person may have only one, or more than one, given Name,
and you didn't need to know. If more than one, there will be a join
table between Person and Name. If only one, givenName will be an
attribute in the Person table. But the point is that you didn't need to
know that, and can *change* it, without the query being broken.

This is a very simplistic example, obviously. If you "svn up"
ActiveFacts
to the most recent, and if you have NORMA (http://sf.net/projects/orm)
installed in Visual Studio, you'll see an oil industry supply model.
This
has Regions, which have an estimated Demand for Products in a
given Month, and Refineries, which have production commitments for
products. Within certain seasons, certain products may be substituted
for other products. Transport routes indicate which refineries can ship
to which regions. A query in CQL can ask for the optimum orders for
appropriate products to fulfil the demand for a given region, or
potentially
even to optimise all orders over all regions - a pretty complex task! So
you see that there's potentially huge computational power expressed in
quite simple queries. Building the engine to execute them will be
another
matter, of course... But so it was when SQL was first proposed.

> So it sounds like the answer would be to construct the CQL using Og
> and hand-off the query generation to you CQL2SQL interpreter.

No, because Og doesn't allow modeling at the right level. Rather you
include the CQL file, which defines classes, then you re-open those
classes to add code where needed.

One of the operations on the model is to create a relational version
of it, and using that, to create the actual database - so in that
respect,
it's like Og, not DRYSql.

> So it sounds like Og would need to create a CQL-model
> definition, then feed (save-require) that to polygot - correct?

No. You write your CQL file, or use my Rails app "APRIMO" to do that,
and then you can require it in a Ruby program and create & query the
DB using the Ruby classes that were created by the CQL parser.

>  AF will mandate starting
> with a CQL definition - which is fine, Og, etc will probably evolve to
> translate some decorated ruby class (or more perhaps a class instance)
> to CQL,

Not sensible. That would be like writing assembly code and trying
to work with the output of a reverse compiler. AF will have reverse
engineering tools available, but the output will be a starting point
to allow you to construct a semantic model; much of the interesting
stuff simply isn't present in a relational schema, or even in a object
DB language (like Og).

> All sounds very promising, do you have any feel for when the CQL
> definition/specification might be in public beta form

I'm working at the same time on a parser and a CQL dump from a
base ActiveFacts model. You can get a peek at the CQL by using
ActiveFacts to convert NORMA model files to CQL, e.g.:

ruby -I lib bin/read_norma.rb -C examples/norma/OilSupply.orm

which dumps (slightly incomplete CQL):

// Model OilSupply
Month = VariableLengthText(3);
Product = VariableLengthText(80);
Quantity = UnsignedInteger(32);
RefineryName = VariableLengthText(80);
Region = VariableLengthText(80);
Season = VariableLengthText(6) restricted to {'Spring', 'Summer',
'Autumn', 'Winter'};
Transportation = VariableLengthText();
Year = UnsignedInteger(32);
AcceptableSubstitutes = entity known by Product and Product and Season:
          Product may be substituted by alternate Product in Season,
          alternate Product is an acceptable substitute for Product in
Season;

Refinery = entity known by RefineryName:
          Refinery has exactly one RefineryName,
          RefineryName is of at most one Refinery;

RegionalDemand = entity known by Product and Year and Month and Region:
          Region in Month of Year will need Product in at most one
Quantity;

Month is in at most one Season;
TransportRoute = Transportation is available from Refinery to Region,
          Transportation is available to Region from Refinery;
ProductionCommitment = Refinery has committed by Month to produce
Product in Quantity,
          in Month Refinery has committed to produce Quantity of Product;

This still has a couple of errors, for example there is a missing
"alternate" in
the "known by" list of AcceptableSubstitutes. Also some constraint
types cannot
yet be converted, and I may need to change existing parts of the
schema to
accommodate them. The value types (data types) are as received from
NORMA,
and not natural to CQL. Reference Modes, which are common patterns of
identification of entities, are still not detected. They will reduce
many of the
entity definitions, for example, Refinery becomes: "Refinery = entity
(Name);".

This is basically a complete schema, which can be transformed into
relational
form. For the same model, NORMA produces this (nearly-usable) SQL for
MySQL. I believe that the errors in NORMA's SQL generation are rapidly
being fixed. Either way, you can guess which syntax I prefer!

CREATE TABLE `Month`
(
	 monthValue VARCHAR(3)  NOT NULL,
	 season VARCHAR(6) ,
	 CONSTRAINT MonthUniqueness PRIMARY KEY(monthValue)
);

CREATE TABLE TransportRoute
(
	 transportation VARCHAR()  NOT NULL,
	 refineryName VARCHAR(80)  NOT NULL,
	 region VARCHAR(80)  NOT NULL,
	 CONSTRAINT InternalUniquenessConstraint8 PRIMARY KEY(transportation,
refineryName, region)
);

CREATE TABLE ProductionCommitment
(
	 refineryName VARCHAR(80)  NOT NULL,
	 quantity  NOT NULL,
	 product VARCHAR(80)  NOT NULL,
	 `month` VARCHAR(3)  NOT NULL,
	 CONSTRAINT InternalUniquenessConstraint10 PRIMARY KEY(refineryName,
quantity, product, "month")
);

CREATE TABLE RegionalDemand
(
	 region VARCHAR(80)  NOT NULL,
	 product VARCHAR(80)  NOT NULL,
	 `year`  NOT NULL,
	 `month` VARCHAR(3)  NOT NULL,
	 quantity  NOT NULL,
	 CONSTRAINT InternalUniquenessConstraint17 PRIMARY KEY(region,
product, "year", "month")
);

CREATE TABLE AcceptableSubstitutes
(
	 alternateProduct VARCHAR(80)  NOT NULL,
	 product VARCHAR(80)  NOT NULL,
	 season VARCHAR(6)  NOT NULL,
	 CONSTRAINT InternalUniquenessConstraint22 PRIMARY KEY
(alternateProduct, product, season)
);

ALTER TABLE ProductionCommitment ADD CONSTRAINT
ProductionCommitment_FK FOREIGN KEY ("month")  REFERENCES `Month`
(monthValue)  ON DELETE RESTRICT ON UPDATE RESTRICT;

ALTER TABLE RegionalDemand ADD CONSTRAINT RegionalDemand_FK FOREIGN
KEY ("month")  REFERENCES `Month` (monthValue)  ON DELETE RESTRICT ON
UPDATE RESTRICT;

Hi Clifford,

Thanks for the prompt and detailed response...

--- In information_modeling@yahoogroups.com, Clifford Heath
<clifford.heath@...> wrote:
>
> Mark,
>
> > I'm not a Object-Relationship-Model expert, more an end-user.
>
> Thanks for your inquiry. You need to be aware that there are two
> different (but overlapping) things that claim the acronym ORM.
> The original one is Object Role Modeling, which was created by
> Terry Halpin in the 1980's, see www.orm.net and ormfoundation.org.
>
> The newer and more widely known one is Object/Relational Mapping,
> which I write as O/RM. It means a data access layer that takes objects
> and persists them in a relational database. This is what ActiveRecord
> and Og do.
>

Thanks for the clarifiation.

> ActiveFacts will do that too, eventually, but first I'm working on the
> Object Role Modeling part, which supports the creation of fact-based
> models. Fact-based models are essentially sixth-normal form relational
> structures, with some higher-level constructs like subtyping etc, and
> most importantly, significant support for describing the data
> *semantics*.
> In fact, I'm using the term "semantic modeling" more and more, as I
> find that the important addition of semantics to information models also
> benefits process models and other system artefacts. However...
>

Ok, I think this point comes up later - but I may misunderstand what
you mean in describing ploygot.
It is a point I to tried to make with the DRYSql author... AR and Og
are the same in terms of your use (persisting), but are opposites in
terms of where you 'start' - and that sometimes is not a choice one has :)
No criticism of polygot or AF implied!

> ActiveFacts doesn't yet take a model and transform it into a relational
> database design.

OK its not clear if you mean a Fact based model, or a Ruby
AF-decorated-class model.

> That's on the cards soon, and isn't terribly hard, but
> I'm otherwise occupied...

There seems to be a large Ruby community interested in 'persistence',
there maybe enoguh people to help out on an initial effort?

> > DataMapper and Og differ from AR and DRYSql in that they start with
> > the Ruby class and try to map that to a DB.  Og does this with a
> > decorated class definition that otherwise behaves as a normal Ruby
> > class.
> > With that background it won't surpise you that I'm curios about the
> > state of, or intentions of 'translating' Ruby classes to DB's using
> > ActiveFacts?
> > From reading the tutorial and looking at the example/administration.rb
> > I'm wondering if the (decorated) Ruby-class -> AF-Model isn't the
> > preferred route?
>
> As you discovered, I thought about it, and decided it's a bad idea.
> Although it works ok for defining physical database models (3NF),
> the kind of language needed for an *elementary* model is just too far
> from the kind of syntax that's possible with a Ruby DSL. Instead...
>
> I'm creating a new query language, the Constellation Query Language.
> CQL has many advantages over SQL, the most important one being
> that queries written in CQL are immune to the most common kinds
> of schema migration that occur, including attribute migration. The

OK that sounds very interesting.  After emailing I looked at the
ORM-Metamodel.pdf and it looked like trying to map a Ruby class
to/from that schema there might be a better place to start.  Obviously
I don't understand all the operation or relations flagged there, but
it seemed that the Og decorations would be much simpler...

> queries are almost plain-language, meaning that they're easy to read.
> The difficulties that SQL's join syntax creates simply don't exist in
> CQL.
>
... however, I was stumped on how you'd (simply) query field(s) :)

> When CQL is done, you'll be able to define your information models in
> a few lines of text, and compile those down to a 3NF relational
> database.
> Queries will also be written in CQL, and dynamically translated into
> efficient SQL.

So it sounds like the answer would be to construct the CQL using Og
and hand-off the query generation to
you CQL2SQL interpreter.

> CQL will integrate with Ruby through my "polyglot" gem. With this,
> you'll be able to:
>
> require "cql"
> require "fred"
>
> and the cql gem will find the file "fred.cql", parse it, and create Ruby
> objects and classes from it. This works by "cql" requiring "polyglot"

OK, here is where Og differs from DrySQL - in Og's case when you
start-up the DB is empty (until you save data), this corresponds to
having an empty CQL file.
So it sounds like Og would need to create a CQL-model
definition, then feed (save-require) that to polygot - correct?

> and
> registering the filetype extension ".cql" with polyglot, which uses a
> modified "require". IOW, the "model" won't be created in Ruby, but
> *compiled to* Ruby at load time (and later, to other languages).

Hmm, A fair enough starting point.  It sounds like where DrySQL
mandated you start with a SQL definition, AF will mandate starting
with a CQL definition - which is fine, Og, etc will probably evolve to
translate some decorated ruby class (or more perhaps a class instance)
to CQL, and it sounds like that will be much simpler than the current
SQL - a big step forward :)

All sounds very promising, do you have any feel for when the CQL
definition/specification might be in public beta form - the sooner the
Og, etc groups can start working on it :)

Thanks again for all your efforts.

Mark

> > I'm less familar with DRYSql (though you can read an exchange I had
> > with the author on his blog), and have never used AR.
>
> I submitted patches to DRYSql to provide support for multi-part keys for
> use with AF's reflection capabilities.
>
> Clifford Heath.
>

Mark,

> I'm not a Object-Relationship-Model expert, more an end-user.

Thanks for your inquiry. You need to be aware that there are two
different (but overlapping) things that claim the acronym ORM.
The original one is Object Role Modeling, which was created by
Terry Halpin in the 1980's, see www.orm.net and ormfoundation.org.

The newer and more widely known one is Object/Relational Mapping,
which I write as O/RM. It means a data access layer that takes objects
and persists them in a relational database. This is what ActiveRecord
and Og do.

ActiveFacts will do that too, eventually, but first I'm working on the
Object Role Modeling part, which supports the creation of fact-based
models. Fact-based models are essentially sixth-normal form relational
structures, with some higher-level constructs like subtyping etc, and
most importantly, significant support for describing the data
*semantics*.
In fact, I'm using the term "semantic modeling" more and more, as I
find that the important addition of semantics to information models also
benefits process models and other system artefacts. However...

ActiveFacts doesn't yet take a model and transform it into a relational
database design. That's on the cards soon, and isn't terribly hard, but
I'm otherwise occupied...

> DataMapper and Og differ from AR and DRYSql in that they start with
> the Ruby class and try to map that to a DB.  Og does this with a
> decorated class definition that otherwise behaves as a normal Ruby
> class.
> With that background it won't surpise you that I'm curios about the
> state of, or intentions of 'translating' Ruby classes to DB's using
> ActiveFacts?
> From reading the tutorial and looking at the example/administration.rb
> I'm wondering if the (decorated) Ruby-class -> AF-Model isn't the
> preferred route?

As you discovered, I thought about it, and decided it's a bad idea.
Although it works ok for defining physical database models (3NF),
the kind of language needed for an *elementary* model is just too far
from the kind of syntax that's possible with a Ruby DSL. Instead...

I'm creating a new query language, the Constellation Query Language.
CQL has many advantages over SQL, the most important one being
that queries written in CQL are immune to the most common kinds
of schema migration that occur, including attribute migration. The
queries are almost plain-language, meaning that they're easy to read.
The difficulties that SQL's join syntax creates simply don't exist in
CQL.

When CQL is done, you'll be able to define your information models in
a few lines of text, and compile those down to a 3NF relational
database.
Queries will also be written in CQL, and dynamically translated into
efficient SQL.

CQL will integrate with Ruby through my "polyglot" gem. With this,
you'll be able to:

require "cql"
require "fred"

and the cql gem will find the file "fred.cql", parse it, and create Ruby
objects and classes from it. This works by "cql" requiring "polyglot"
and
registering the filetype extension ".cql" with polyglot, which uses a
modified "require". IOW, the "model" won't be created in Ruby, but
*compiled to* Ruby at load time (and later, to other languages).

> I'm less familar with DRYSql (though you can read an exchange I had
> with the author on his blog), and have never used AR.

I submitted patches to DRYSql to provide support for multi-part keys for
use with AF's reflection capabilities.

Clifford Heath.

Hi Devs,
Thanks for all the work that has gone into making Active Facts possible.
As well as thanks for making it freely available.

I'm not a Object-Relationship-Model expert, more an end-user.  In fact
I found my way here by looking for ORM's in Ruby.  So I'm familiar
with Og (having developed a little for it), DataMapper and Sequel.
I'm less familar with DRYSql (though you can read an exchange I had
with the author on his blog), and have never used AR.

DataMapper and Og differ from AR and DRYSql in that they start with
the Ruby class and try to map that to a DB.  Og does this with a
decorated class definition that otherwise behaves as a normal Ruby class.

With that background it won't surpise you that I'm curios about the
state of, or intentions of 'translating' Ruby classes to DB's using
ActiveFacts?

From reading the tutorial and looking at the example/administration.rb
I'm wondering if the (decorated) Ruby-class -> AF-Model isn't the
preferred route?

Regards
Mark

Hello,
        Its been a while since I have posted on this group. Hope
everyone is doing well. I have an opportunity to work on a Dot Net
project and was wondering what the folks here think of the ADO.NET
Entity Framework. From what I understand it looks very promising.
There is a conceptual model, a logical model as well as a mapping from
the conceptual model to the logical model and also provides for a
query language LINQ.
Anyone on this group who has used ADO.NET Entity Frameowork on a
project ?
Thanks and regards,
Aswin.

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.

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.

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.