Elliotte Rusty Harold wrote:
> In the words of Clara Peller, "Show me the beef." I keep hearing people 
> say things like "semi-automated mapping of data fields from several 
> interface
>  standards onto DB fields" but I don't know what that means or why I 
> should care.

I'd like to tell a success story here, unfortunately, the whole
project didn't leave the prototype and rigged demo phase for the
last four years. What we do have is a bunch of message format
descriptions, or schema if you like, formulated in a custom XML.
There's also a kind of rule base (in another custom XML vocabulary)
and some XSL transformations which can be used to generate Java code
which in turn maps one kind of message onto another. The Java
classes can be plugged into a home grown message broker, which
currently uses mostly handcrafted code for transformations.
There are a few demos for getting format descriptions from DDL
and PL/I structures.

The XSLT mostly tries to match data fields by name, in some cases
by type for generating the mapping code. Current rate of success
is around 15% "sure" and another 15% "maybe", which includes
some data which requires splitting fields and a few other non-trivial
transformations, the rest of the generated code is just a bunch of
stubs. Even this already saves a lot of typing though and has been
used for bootstrapping hand written transformers. I can see the
possibility to improve upon this, that's what I meant with "use case".

I can also switch to RDF for the message format description, if
this provides any advantage. It's probably only a few days of work,
mainly search&replace in the XSLT and some de-hierarchilization, and
transforming the existing descriptions. XSD or another schema language
would be a possibility too, although I like the schema directed editing
of our current format description language, and most of the
descriptions are still manually made.

It may also be possible to use OWL for the rule base, I haven't
investigated this yet. The rule base includes Java code snippets
though, perhaps this will have to go into another file. OWL would
be an advantage if there were tools for editing, visualizing and
other processing. Any hints here?

J.Pietschmann