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.
>