[tmcl-wg] comments regarding TCML requirements draft
Bernard Vatant
tmcl-wg@isotopicmaps.org
Thu, 27 Feb 2003 11:50:48 +0100
Well, in fact, even on Yahoo archives I can't find any reference to the
document Robert is commenting on ... what did I miss, and where is it?
All I have is=20
http://www.y12.doe.gov/sgml/sc34/document/0226.htm
Which seems outdated and not under discussion here ...
Thanks to redirect me, I'm lost.
Bernard
_____________________________________
Bernard Vatant
Senior Consultant - Knowledge Engineering
www.mondeca.com
_____________________________________
| -----Original Message-----
| From: tmcl-wg-admin@isotopicmaps.org [mailto:tmcl-wg-
| admin@isotopicmaps.org] On Behalf Of Bernard Vatant
| Sent: jeudi 27 f=E9vrier 2003 11:27
| To: tmcl-wg@isotopicmaps.org
|=20
|=20
| Mary
|=20
| Could you re-post to tmcl-wg@isotopicmaps.org a summary of the
documents
| that are under discussion now, and pointers to them. All that
| information was posted to the yahoo list, but people going directly to
| http://www.isotopicmaps.org/mailman/listinfo/tmcl-wg
| and following down to Robert's message
|
http://www.isotopicmaps.org/pipermail/tmcl-wg/2003-February/000008.html
|=20
| can find nowhere a reference to the document(s) under discussion :(
|=20
| Thanks!
|=20
| Bernard
| _____________________________________
|=20
| Bernard Vatant
| Senior Consultant - Knowledge Engineering
| www.mondeca.com
| _____________________________________
|=20
| | -----Original Message-----
| | From: tmcl-wg-admin@isotopicmaps.org [mailto:tmcl-wg-
| | admin@isotopicmaps.org] On Behalf Of Robert Barta
| | Sent: jeudi 27 f=E9vrier 2003 11:04
| | To: tmcl-wg@isotopicmaps.org
| | Cc: rho@bigpond.net.au
| |
| | 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/
|=20
| | 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=3Dprintable
| |
| | 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
| | =3D> 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
| | _______________________________________________
| | tmcl-wg mailing list
| | tmcl-wg@isotopicmaps.org
| | http://www.isotopicmaps.org/mailman/listinfo/tmcl-wg
|=20
|=20
| _______________________________________________
| tmcl-wg mailing list
| tmcl-wg@isotopicmaps.org
| http://www.isotopicmaps.org/mailman/listinfo/tmcl-wg