[tmcl-wg] Updates [was: Another TMCL use case]

[Dan Corwin]

* Dan Corwin

> > I can and do assume TMCL, in some independent process, will
> > help confirm all those details of a TM someone has had the
> > foresight and diligence to pre-declare within a schema file,
> > and that such processes, by being used, will help to reduce
> > errors in (some of) the XTM files I import or create.
> 
> > That is nice, but still weak - not a compelling benefit.

* Robert Barta
 
> Well, it depends what this "pre-declared schema" includes, so it may
> be weak but it may also include all the necessary semantics.
> 
> If you look at the use case
> 
>    http://astma.it.bond.edu.au/project-use-case.dbk?style=printable
> 
> then this may significantly impose restrictions on various maps.

Robert, please understand me.  The constraints AsTMa! can add
are indeed compelling, and I'm most impressed with all I read at
your site.  I'd be happy to make use of it, *if* it can migrated
into a form where the things I need are more accessible to me. 

What I find *not* compelling is the batch-mode use case.  It has
a place, but for my goals, it over-encapsulates your logic.

That makes it of little help for bulk updates to a topic map, 
as in this first additional TMCL use case am suggesting:

> > Case A) This involves a batch file of simple commands run as a
> > script to mutate a TM in limited ways.  I want the script to stop
> > work with a good explanation *before* it violates any constraint,
> > yet not slow down obnoxiously (over x 3) due to the added burden
> > of constraint validation.
> 
> If I understand that correctly:
> 
>   - map is loaded
>   - script information is extern or in the map?
>   - interpreter walks over the map and fires the scripts?
>   - scripts do something with the map?
> 
> and you want to make sure that you only operate on a sane map (for
> your definition of sanity, that is).

Correct.  Assume the scripts are outside of the map, and 
change *only* the Strings in occurrences or the Roleplayers in
associations - things expected when you populate a data base 
table or update it from an import file.

They do not, for example, try to adjust any ontology topics,
or create/destroy types, and they certainly leave the map a 
valid map (under normal TM rules) at all points in time.

This use case would test, among other things, the speed of 
TMCL validation.  Simple benchmarks help.

*  Jim Mason's Ferret system scans 2,000 words/second on a PC.
*  I'd guess a simple update script is maybe 3-5 times faster.

To avoid being obnoxiously slow, TMCL cannot be much slower.
That means it must perform at least a thousand tests/second.

I do not believe a complete TM could be validated that fast,
especially in a remote batch process.  It might come closer
in the embedded version I cited in "Selectors"...

  http://www.isotopicmaps.org/pipermail/tmcl-wg/2003-May/000089.html

.. but even this would fail for large maps or big schema, as
the run-time needed would be proportional to both sizes.

For speed reasons at least, TMCL must therefore check updates 
in a more linear-time fashion, using logic specific to each 
proposed change.

I'll deal separately with the issue of non-destructive tests
and how this more focused sort of logic might handle them.

Here, I just want to establish Updates as an extra TMCL use 
case, distinct from the use case of global map validation.

Cheers,
Dan Corwin