[tmcl-wg] Overlapping, matching,
conflict between constrains: CALL for Usage Scenarios
Robert Barta
tmcl-wg@isotopicmaps.org
Mon, 07 Apr 2003 12:44:50 +1000
On Tue, Apr 01, 2003 at 04:13:31PM +0200, Bernard Vatant wrote:
> I try to make me more explicit on an example (use case or scenario,
> I don't know).
As not many have picked up this (heavy) ball, I'll try.
> I want to express, in an university topic map, the following
> constraint
>
> "Professors are allowed to teach Courses."
OK, Bernard, what _exactly_ should this mean? You say that an "open"
interpretation of this
> Note that neither of the above excludes the eventuality of
> e.g. instances of class "Chimp" teaching courses.
does not really constrain anything as in such associations anything
can play the role of teacher:
(teaching-course)
teacher: $t # can be anything
course : some-course
>From a logical point of view I cannot see the value of a constraint
which does not constrain anything. I can only assume that something
like this is meant:
"It is suggested that professors teach courses, but
chimps are ok"
This constraint is now more directed towards authoring environments
and is not used for validation:
forall [ (teaching-course)
teacher: $t ]
=> suggested exists [ $t (professor) ]
> So maybe we want to express something more restrictive:
>
> "Only Professors are allowed to teach Courses."
This "closed" interpretation should of course be captured in a TMCL
solution analogous to
forall [ (teaching-course)
teacher: $t ]
=> exists [ $t (professor) ]
> Solution C1 (constraints attached to the class)
> Solution C2 (constraints attached to the association type)
> 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 :)
I cannot see any difference: If you want the above constraint, then
you HAVE to name 'teaching-course' and 'professor' in the
constraint. If you want the constraint to be compatible with something
else, then you have to say so. You can relax the conditions so that
there is more room for other maps:
forall [ (teaching-event)
teacher: $t ]
=> exists [ $t (academic-entertainer) ]
So you simply use abstraction to allow for merging. Or, even more so
forall [ (teaching-event)
teacher: $t ]
=> exists [ $t (person) ]
Please note, that in my understanding the idea is that the constraints
DEFINE THE ONTOLOGY (which means they also contain topics and assocs
like a normal map to define a vocabulary and type system). The
current requirements document does not mirror this view, though.
\rho
> ----- 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
> >
>
>
> _______________________________________________
> tmcl-wg mailing list
> tmcl-wg@isotopicmaps.org
> http://www.isotopicmaps.org/mailman/listinfo/tmcl-wg
>