[tmcl-wg] comments regarding TCML requirements draft

[Robert Barta]

On Sat, Mar 22, 2003 at 09:57:23PM +0900, Mary Nishikawa wrote:
> >1.1.1: Reformulate
> >
> >...will define (at least) one syntax for notating constraints...
> 
> So you are saying that this should be moved to the "MUST" category. Yes, I 
> agree. What the syntax will be based on, well will still be in 1.1.2

Well, we need at least one syntax.

Could also be a complete abstract syntax if we could not agree on a
particular flavour. From this various particular serialisations could
be derived. But I do not think that this is a problem.

> >...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
> 
> This sounds great, but I am wondering what it would be, this "rigorous 
> semantic definition" can you explain and also what you mean that it must be 
> based on SAM. Do you mean that the semantic definitions will be described 
> as SAM is? I really need clarification.

Well, defining a TMCL means that we have to tell developers what exactly
should happen if there is

  - one Topic Map instance, and
  - one set of constraints

Using the terminology of logic programming the topic map in question
is one element from the (infinite) set of topic maps and the set of
constraints are formulas in a particular logic.

The trick now is to define a relation which specifies _when_ a
particular map "satisfies" a formula.

For TMs this means that you need an formal abstraction of the
structure of a TM and define this validation relation on top of that.

> >The "fully-fledged" will be also "down-to-earth", I hope.
> 
> Of course :)

What I am saying is that we should not have this as the distinctive
label for 1.1.2.1.

> >   But then merging is NOT specific to templates and works for any 
> >   constraint.
> 
> OK, I will add this. Robert, I will ask you to take a look at this after I 
> rewrite this section.

Definitely :-))

> >  - taxonomy (T)
> I want to make sure that we are thinking about *taxonomy* in the same light.
> 
> I will add *taxonomy* definition to 1.2. I think that it needs defining.
> 
> Taxonomy in the strictest sense means the use of terms within a  defined 
> context; the class and subclass relationships are also strictly defined. Is 
> this what you mean? There are usually agreed within domains or vertical 
> markets, so I thought we wanted to steer clear of this.

We should stay out of particular domains, of course. Still, every
application has a vocabulary (simply a list of terms) and a taxonomy
(instanceOf/subclass relationships between these terms).

> >cardinalities are _everywhere_, not only here!
> 
> OK. I won't remove it here, but please tell me where I should add it.

Will look for this in the next version.

> >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.
> 
> There are always limitations, but at first it is usually not obvious. 
> Let's think about it. It is not easy for the language to be completely 
> flexible; the semantics of a particular ontology will limit the 
> application of the language perhaps.
> 
> I need help here!!

Do we have use cases aside from

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

> >3.2*:
> >
> >They do not seem to fit here.
> 
> Do you mean the three layers?

3.2 are the usage scenarios.

> >I am unsure about these constraint templates.
> 
...
> >The last paragraph is about implementation, maybe use a different font
> >to distinguish it for the time being.
> 
> Which paragraph?

That which starts with "We can create "on the fly"....
> 
> >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.
> 
> Where? Does everybody agree with these two layers instead of the three 
> mentioned in 3.2. I am a little confused here. I guess this is one of the 
> reasons I waited to comment. I needed to look over your work a little more.

Maybe in the beginning of 3.2.1.2 we could explain the two layers and the
relationships between them.

> Thanks Robert for your comments, and I look forward to many more.

Thank _you_ Mary. Writing this document is not exactly ... trivial.

\rho