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.