[tmcl-wg] comments regarding TCML requirements draft

Bernard Vatant tmcl-wg@isotopicmaps.org
Thu, 27 Feb 2003 16:39:03 +0100


Now that I found back the document ... :)

... I would like to comment on a specific point that we happen to have
currently also in internal discussion at Mondeca, which is using
constraints on topic types vs constraints on association types (See
sections 2.2.1 and 2.2.2. BTW the use of type vs class should be made
consistent at least with SAM prose, but I assume "topic type" here means
"topic class")

I'm concerned with overlapping, matching, conflict between constraints
like the two following ones:

C1. (on topic type)
"Topic of type X may (must) play role type R in association of type A"

And

C2. (on association type)
"Association of type A may (must) use topic of type X for role type R"

Those are clearly two ways to achieve quite similar objectives, from two
viewpoints (although not exactly equivalent). Which is the best way?
Should we provide ways to do both? Does it matter? Came back to my mind
Tommie Usdin excellent (as usual) presentation in Montr=E9al Extreme =
2002.


When "It Doesn't Matter" means "It Matters"
http://www.idealliance.org/papers/extreme02/html/2002/Usdin01/EML2002Usd
in01

I think it is a very useful reading in this context.=20

1. If TMCL supports both types of constraints, it would be nice to make
it clear what are the use cases and scenarios for each one.
2. If one schema uses C1 and another one (or the same one) uses C2,
checking consistency at editing or merging time seems to be tricky.=20
3. Building a model using at the same time constraints of types C1 and
C2 will be highly complex, with a learning curve certainly steeper than
frame-based ontology editing. And building engines able to cope with all
those constraints together will be even trickier.=20

I am more and more inclined towards using rather C1 than C2, although
until a few months ago I was thinking the other way round (including in
my Baltimore paper). Why?

- The definition of association templates should make them flexible,
modular and reusable in various ontology contexts. Topic types are more
likely to be defined locally in vertical taxonomies. Otherwise said, the
template layer is likely to be wide and shallow, and the topic typing
narrow and deep. It makes it then difficult and even not wise to define
association types in a way that would anticipate its various vertical
uses (C2). In other words, it's easier to expand a taxonomy of topic
types with constraints using predefined association templates (C1), than
the other way round.=20

- People used to frame-based ontologies will buy it more easily, since
it's more similar to their way of thinking: properties are attached to
classes. Of course an association type is also a class in some sense,
but this is more difficult to grasp. Think about people using =
Prot=E9g=E9,
and how they can move into using TMCL, and think about the migration of
frame-based ontologies into a TM form. Class properties can quite easily
be turned into C1 constraints, it's not obvious how they can be turned
into C2.

Of course, we want TMCL to be more expressive than frame-based
ontologies. But a requirement IMO should be the interoperability with
that kind of legacy, the same way topic maps being more expressive than
Thesaurus must not prevent the ability for TM to integrate easily
Thesaurus structures.=20

IOW, the global strategy against existing tools should be:

"We can do all what you do, in a very similar way, but we can do more"=20
	rather than:
"Forget about what you did before, we have found a better way"


My 0.02 of the day

_____________________________________

Bernard Vatant
Senior Consultant - Knowledge Engineering
www.mondeca.com
_____________________________________