[tmcl-wg] comments regarding TCML requirements draft

[Mary Nishikawa]

Robert,

Thanks for your feedback. I agreed with your general comments (cut from 
here) and will reply to your more specific statements here to see if we 
have agreement here with the changes I will make

>*Robert Barta
>1.1: Reformulate
>
>SAM....constraints there inherent to define the Topic Map paradigm.

Yes, I will add that.


>....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

I will add this too.


>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 What 
it should specify


>...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.


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

agreed. It is really not needed, I think.


>1.1.2.1:
>
>I do see the question whether there should be a
>
>   TL (template layer), and a
>   EL (expression  layer)

I need to hear feedback on this. I will set up a separate thread on this one.


>independent whether the can be morphed into XML or not.
>
>The "fully-fledged" will be also "down-to-earth", I hope.

Of course :)


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

I was not sure myself. Comments appreciated. I was wondering if the prose 
defining the language will be written in the prose of SAM with 
informatitive UML diagrams perhaps.

Maybe Graham can say what he thinks about this.


>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.

OK, I will add this. Robert, I will ask you to take a look at this after I 
rewrite this section.


>1.1.2.4:
>
>I would not simply see classes as isolated, maybe this helps:
>
>   - 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.

Please correct me if I am wrong.


>     constraints about classes and subclass relationships between them

I will add this. I do not see this strictly related to taxonomy. So please 
explain what you mean.


>   - structural consistency (S)
>
>     constraints covering the internal consistency of topics and
>     associations, how topics of a particular kind must/should
>     look like

This looks as if I should give it a section in its own right, so i would 
number it 1.1.2.5 for example


>   - 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.

I think that I will add these 4 as separate sections. Comments?


>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.

I will change *shall* to *may*


>1.1.2.7:
>
>please delete 'operational'.

agreed. Does not add to the meaning.


>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.

I need more explanation too. This needs elaboration. I think I will leave 
this section for Graham to describe.

Comments here welcomed too.


>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.

This was left in from the previous draft. Take it out? Leave it in? Opinions?

I think that we need a section that describes the core requirements in 
abbreviated for. It should be all of the combinations as they are described 
here. This is not exhaustive and there are more.


>2.2.1:
>
>what are 'valid scopes'? (I understand this to mean to define the use of a 
>topic to be used only as a scope and nothing else.


Comments?  (Steve this is from your previous draft-- what did you mean by this?)


>cardinalities are _everywhere_, not only here!

OK. I won't remove it here, but please tell me where I should add it.


>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!!



>3.2*:
>
>They do not seem to fit here.

Do you mean the three layers?

Schema or class template layer, constraint template layer and constraint 
expressions layer? Please explain. Do you mean that we should ditch this 
entire section?


>3.2.1.3:
>
>I am unsure about these constraint templates.

I guess same comment as above.


>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.

Which paragraph?


>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.

>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.

Comments please, but I am unclear what you mean. This document is 
specifying requirements for the standard defining the tmcl. Yes, it is a 
must but it has not been within the work item for SC34 for any of the 
languages so far. This is probably within the scope of an OASIS TC. I will 
make this clear then.


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


Cheers,
Mary