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

[Robert Barta]

On Tue, May 20, 2003 at 01:56:03PM -0400, Dan Corwin wrote:
> Can TMCL be used to *prevent* invalid updates, instead of just 
> detecting them later?
....
> Said in simpler terms, while operating as in Use case A, TMCL 
> should be able to block all changes *unless licensed*:

Dan,

I hope this is somehow addressed by an earlier response.

> * Robert Barta
> 
> > You are now asking whether a constraint (set) C can be checked against
> > TM and F independently? Sure, but in general it DOES NOT hold:
> > 
> >    C |= TM + F      <=>    C |= TM  and   C |= F
> > 
> > where x |= y means "constraint x validates map y"
> 
> I know there are pitfalls of logic here, but I would not demand 
> rigor in this use case, nor would end users.

But end users sometimes want code to work as intuitively as possible.
If the user makes a harmless change and the system responds that the
consistency may or may not be harmed then this is not helpful to most
lusers.

> If limitations of testProp() and code like it were clearly
> explained, they could still be heuristics very helpful in catching
> edit errors.

Heuristics are great, but are difficult to argue with from the outside
(=user).

> Such limits seem more than balanced by the more fine grained
> testing such rules allow, and by the fact that no data within
> a loaded map must be modified to test them.

Right, tests are non-destructive.

> This means that related change-events need never be spuriously 
> triggered.  It also lets TMCL itself support new TM applications,
> such as validating updates to an independent database that was
> being modeled by a TM's embedded schema.

Could be.

I can even imagine that a clever TMCL checker precisely knows what
part of a map to check once the map is updated. Some updates are
completely local (e.g. changing the value of an occurrence where there
is NO constraint at all). Some modifications have effect on the map,
like the changing of a basename or the addition of a subject
identifier: Here merging has to be triggered potentially.

Some changes may have to be checked on a global basis: For instance,

   "for every course there have to be at least 50 students in
    that course"

> Overall for updates, I see a two-part TMCL mechanism extending
> a compliant TM engine.  Configured by embedded constraints that
> an end user might adjust, it can decide *before* each update is
> made if such updates were licensed by TMCL constraints:
> 
>   * if so, but specific details would be out of spec, complain
>   * if not, TMCL should then offer these two options (at least):
> 
>     Case A) the unconstrained value means any change is legal
>     Case B) it instead seems unexpected, so complain about it

>From the view of a TMCL enabled infrastructure, is not it just two
cases?

   - change would be allowed
   - change would conflict TMCL constraint

Whether ...

> In case B, TMCL has to let a user with special update rights 
> (like an admin or an ontology author) change a TM unimpeded.
> Everyone else would change it only in the ways pre-approved 
> by its author in an embedded schema.  And they might perhaps 
> be further fine-tuned by adjusting scopes for the occurrences 
> that hold the stored constraints.

...parts of the application override it then or not is completely
application specific. But, yes, you can do that.

\rho