[tmcl-wg] Overlapping, matching, conflict between constrains: CALL for Usage Scenarios

[Mary Nishikawa]

Bernard,

These are important, and I think some people may have missed your points 
since was posted at the beginning of the mail list move.
I am creating this as a new thread to illicit feedback. Only Robert 
commented but it would be good to get other opinions.

I am separating out your comment on *type* versus *class* which I will 
place in a separate thread.

The document we are discussing is here 
<http://www.isotopicmaps.org/tmcl/requirements.html>

At 16:39 03/02/27 +0100, Bernard Vatant wrote:


>*Bernard Vatant
>
>... 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.

</snip>

>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 Montreal Extreme 2002.

Bernard, can you please provide examples? It can be included in the usage 
scenarios. Thanks.


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

Yes, so this is a *CALL for Usage Scenarios*

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

Really need an example.

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


Please point us to the references. I don't have your paper or the CD of the 
conference.


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

This needs to be in the requirements, but where would be the best place to 
put it.

But I would still like some feedback on this.

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

Sorry Bernard, I am in the dark. What are frame-based ontologies? Can you 
define it?

>  Of course an association type is also a class in some sense,
>but this is more difficult to grasp.

See my post on  the term "class."

>Think about people using Protege
>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.

Please explain. Also, what do you mean by class properties? I am not 
familar with Protege. Please give us a definition.


>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.
>
>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"
>         rather than:
>"Forget about what you did before, we have found a better way"

Thanks Bernard. Please provide us with some background reading. This TMCL 
requirements gathering is a huge task. I need your help and the help of 
everyone here.

Cheers,
Mary