[tmcl-wg] comments regarding TCML requirements draft

[Robert Barta]

Hi all,

Mary: thanks for the effort you are putting into this. I realize that
this is not exactly a trivial task. Below are some comments/ ideas/
complaints/ whinings :-)

----

general comments:

  - I ignored the typos

  - all things which are N/A should be deleted. While starting off
    with a generic requirements structure is good, we will have to
    adapt it to the problem at hand.

  - all references to XTM, AsTMa*, LTM, ... should be moved into
    an annotation form (another font, bracket)

1.1: Reformulate

SAM....constraints there inherent to define the Topic Map paradigm.

....TMCL will provide language means to express domain specific and
application specific constraints on topic maps.

Goals twofold:

   1) express constraints that can be applied to existing topic maps

       validation: a map or a set of maps is valid relative to a constraint

       filtering: a map can be filtered with a constraint; result is the
              (biggest) sub map which is valid relative to the constraint

   2) express constraints which can be used to derive a form-driven map
       authoring process

1.1.1: Reformulate

...will define (at least) one syntax for notating constraints...

...will define a rigorous semantic definition when a map is valid against
a (set of) constraint(s). This definition must be (directly or indirectly)
based on SAM

1.1.1: I do not quite understand the last sentence. Maybe not mention
any serialisation format at all?

1.1.2.1: 

I do see the question whether there should be a

  TL (template layer), and a
  EL (expression  layer)

independent whether the can be morphed into XML or not.

The "fully-fledged" will be also "down-to-earth", I hope.

1.1.2.2: What is exactly the 'model' of the language?

1.1.2.3:

ad merging schemas:

   If we assume that a schema is a template then merging of
   templates means merging of constraints.

   I could see two mergings: 'OR' and 'AND'

   But then merging is NOT specific to templates and works for any constraint.

1.1.2.4:

I would not simply see classes as isolated, maybe this helps:

  - taxonomy (T)

    constraints about classes and subclass relationships between them

  - structural consistency (S)

    constraints covering the internal consistency of topics and
    associations, how topics of a particular kind must/should
    look like

  - application specific (A)

    well, application specific

  - application specific, derived (D)

    same as above, but rules which are added in a redundant way
    to add knowledge

    Look at (T), (D), (S), (A) in

       http://astma.it.bond.edu.au/project-use-case.dbk?style=printable

    to see examples.

1.1.2.6:

I would see data types as optional module. Not all people will use it
as the dreadful XML schema discussion shows us.

1.1.2.7:

please delete 'operational'.

IF(!) we adopt the strict/loose/non-valid distinction then it should
go into a separate section.

ad strict: What sense does it make to restrict again to templates?

strict/loose/non-valid:
Graham tried to explain it but this still does not make sense for me.

It is completely up to the application when and which part of the set
of constraints will be applied to a map.

      An editing system, for example, can apply rigorous checking
      on all, what is already committed into the DB and has a loose
      view on the rest which the user has flagged as 'incomplete'.

If the concern is to specify a constraint in such a way that there
are no constructs in a map which do NOT conform to it, then we could
simply define this as additional constraint:

   # closed world constraint
   forall $t [ *  ] # whatever topic you have in this map
     => exists $t [ * (elephant) ] # either this is this
        OR
        exists $t [ * (mouse) ]    # that

Only because a TL is not expressive enough for that this does not
mean we have to explicitely define that.

ad loose) If the concern is to publish a vocabulary, then we simply
define that "a vocabulary by itself does not do any constraining, but
is a valid constraint":

# my constraint
#-----------------------------------------
elephant (animal) # has PSI  urn:x-rho:elephantus-maximus

mouse (animal)    # has PSI  urn:x-rho:mousus-minimus
#-----------------------------------------

This can be applied to any map, but does not do any filtering. Any
map conforms to it.

What I am saying, is that the distinction seems superfluous.

2.2:

Instead of trying to classify the possible constraints, I would simple
use here a list of use/test cases. Classifying can be pretty hard and
there is little value in that, IMHO.

2.2.1:

what are 'valid scopes'?

cardinalities are _everywhere_, not only here!

2.3:

It is difficult to argue at this stage about limitations. If we define
a list of test cases, then it is implicitely clear _WHAT_ the language
should cover. All other things might be 'nice to have'.

We could use a higher order logic to describe this, but then
validation and queries would not perform (or even terminate).
Consequently, the test cases create a low bar and the language should
cover this (modulo abstraction), but nothing more.

3.2*:

They do not seem to fit here.

3.2.1.3:

I am unsure about these constraint templates.

This seems to me as a generic mechanism to define constraints first
without mentioning specific topic types, ... And in a second phase
constraints are instantiated from these generic constraints.

This is all useful, but this has nothing to do with TMCL. I can
imagine that some software is offering it as a nice commodity (very
nice actually), but a semantic model of this is completely separate to
that of TMCL.

The last paragraph is about implementation, maybe use a different font
to distinguish it for the time being.

My understanding of constraint templates is something like

  "all topics of type composer should have at least one URL
   and must have ...."

And that's it.


Somewhere we need a part which specifies that the TL and the EL have
to be connected semantically. Everything which can be expressed in TL
can be expressed in EL, but not necessarily vice versa.

[ The RDF people will frown at that, though. ]


3.5:

I think, a test suite is a MUST. It allows us to benchmark (a) the
languages and (b) the implementations. A test suite is not part of the
requirements specification, only of the standard.

--

\rho