[tmcl-wg] comments regarding TCML requirements draft

[Lars Marius Garshol]

* Bernard Vatant
|=20
| I'm concerned with overlapping, matching, conflict between constraints
| like the two following ones:
|=20
| C1. (on topic type)
| "Topic of type X may (must) play role type R in association of type A"
|=20
| And
|=20
| C2. (on association type)
| "Association of type A may (must) use topic of type X for role type R"
|=20
| Those are clearly two ways to achieve quite similar objectives, from
| two viewpoints (although not exactly equivalent). Which is the best
| way?

The approach taken by OSL is that you can constrain it from both
points of view. As it turns out, those two complement one another
nicely, and you actually need both.

Imagine the following:

  a) a rule states "all composers must play the role of 'creator' in
     at least one association of type 'created-by'",

  b) a rule states "all playwrights must play the role of 'creator' in
     at least one association of type 'created-by'", and

  c) a rule states "'created-by' associations must have one role of
     type 'creator' played by a 'person' and one role of type
     'creation' played by a 'work'".

Note how instances of the 'police constable' class are not required to
have created anything by rule c), although they are allowed to.

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

See above. :)

Or, actually, just look at the OSL schemas that come with the
Omnigator.  It should be pretty clear.

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


Well, I'm not sure you can achieve inconsistency, actually. C2 can
allow something C1 does not, but then C1 wins, and it need not be any
more complicated than that.

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

You need an ontology editor to help you out, basically. Given that I
don't think it need be very difficult at all.

| And building engines able to cope with all those constraints
| together will be even trickier.
=20
Not at all. Ours does it just fine, and it wasn't even hard.

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

Here I don't follow at all. What are you trying to say?
=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.=20

Bingo! The terminology used in OSL is that you define topic classes
and association classes.

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

Here I think you are pointing to a possible requirement:

  "It should be possible for users familiar with frame-based
  ontologies to understand TMCL easily."

or something like it.
=20
| 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.

I agree. So there you have another requirement in the same vein.

--=20
Lars Marius Garshol, Ontopian         <URL: http://www.ontopia.net >
GSM: +47 98 21 55 50                  <URL: http://www.garshol.priv.no >