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

Tue, 1 Apr 2003 16:13:31 +0200

Mary

Late answer again ...

I try to make me more explicit on an example (use case or scenario, I don't know).

I want to express, in an university topic map, the following constraint

"Professors are allowed to teach Courses."

Let's say "Professor X teaches course Y"
is represented by an association of type "teaching-course",
with role types "teacher" and "taught-course",
and "Professor" is a topic representing a class

Solution C1 (constraints attached to the class)

- Instances of class "Professor" are allowed to play a role of type "teacher" in an
association of type "teaching-course".

Solution C2 (constraints attached to the association type)

- Role type "teacher" can be played by an instance of class "Professor".

The two solutions look somehow equivalent, but ...

In C1, it is implicit that the association type is pre-defined, and that property
(constraint) of the class "Professor" is using it. This is non-intrusive on the
association type. Another TM using a different ontology  can use the same association type
(defined by a PSI somewhere) for different classes. The association types are not
dependent on the ontologies using them.

In C2, it is implicit that the class "Professor" is pre-defined, and the association type
is somehow using it in its definition. I would call this constraint "ontology-driven"

Note that neither of the above excludes the eventuality of e.g. instances of class "Chimp"
teaching courses. So maybe we want to express something more restrictive:

"Only Professors are allowed to teach Courses."

Using C1, and a default setting for any association type, like "In any association, a
topic playing a given role type must be an instance of a class that explicitly allows that
role type for that specific association type".
- Instances of class "Professor" are allowed to play the role type "teacher" in an
association "teaching-course"
- No other class in the ontology has this same property.

Using C2:
In an association of type "teaching-course", a (the) topic playing the role type "teacher"
must be an instance of the class "Professor".

There again, using C2 makes the association type ontology-driven, which means it will not
support any ontology where the class "Professor" is not defined, and/or where chimps or
other folks would be allowed to teach :)

That's why I was inclined in the below message to use C1 rather than C2, because it
provides more flexibility and modularity, by making the association types able to support
various ontologies.

And the allusion to Tommie's "it does not matter means it matters" was to be understood
here by:
If equivalent constraints can be expressed as well by C1 than by C2, and there is no
specific reason to choose one, the choice should be made by the specification, not by the
users. And my concern was about potential conflicts, or even sheer impossibility to merge
constraints expressed using C1 in a given TM schema, with constraints using C2 in another
one.

Does that clarify?

Bernard

----- Message d'origine -----
De : "Mary Nishikawa" <nisikawa@fuchinobe.oilfield.slb.com>
À : <tmcl-wg@isotopicmaps.org>
Cc : "'Jean Delahousse'" <jean.delahousse@mondeca.com>; "'Frederic Delahaye'"
<frederic.delahaye@mondeca.com>
Envoyé : vendredi 21 mars 2003 11:41
Objet : [tmcl-wg] Overlapping, matching, conflict between constrains: CALL for Usage
Scenarios

> 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
>
> _______________________________________________
> tmcl-wg mailing list
> tmcl-wg@isotopicmaps.org
> http://www.isotopicmaps.org/mailman/listinfo/tmcl-wg
>