OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

topicmaps-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: [xtm-wg] Modified diagram for Association Template


Hi,

Daniel Rivers-Moore wrote:
> 
> Attached is a modified graphic for the conceptual model of Association
> Template.
> 
> It is structurally identical to the previous diagram. However, it renames
> some of the elements to make it clearer that the association template is
> itself and association, the role constraints are themselves a role in the
> template association. An alternative approach would have been to add
> subtype-supertype arrows from the left and middle boxes in the top row to
> the corresponding boxes in the bottom row. However, this makes for a
> cluttered diagram which is less easy to understand, and results in a larger
> number of named object types in the conceptual model and therefore more to
> do in the mapping between the model and the syntax.

I miss in all models I have seen so far the possibility
to control the number of roles in an assoc.

E.g. the assoc template "meeting" has these roles:
-	meeting room (exactly 1)
-	participant (minimum 2, maximum - let's say - 35)
-	chair person (min 0, max 1)
-	minutes (min 0, max 1)

We could express this by metadata assignments 
(= resourceData occurrences) to the template roles.


I am also missing the possibility to control the
possible scope values of an assoc. The mechanism
should be the same as the one for the role player 
classes.


Another issue related to assoc templates are
topic templates. Why not templating a topic?
Candidates to be controlled by a topic template 
are: 
- number and kind of topic names, 
- scope of names,
- number of occurrences of certain type,
- number and kind of names of occurrences,
- scope of occurrences, 
- association the topic instance has to play
a certain role in (e.g. every person in the map 
has to play the "person" role in the "birth" assoc).


Furthermore I would like to see a statement in the spec
that a topic (= player instance) could be of the class of 
the player or "of one of its direct or indirect subclasses" 
(the subclass is defined by the predefined superclass-subclass 
assoc). This would extremely reduce the number of necessary assoc
templates and role templates.

E.g. I define the "birth" assoc template with the
roles
-	location (player class = "geo-object")
-	person (player class = "person")

The derived assoc brings together 
-	Richard Wagner (type = "composer")
-	Leipzig (type = "city")

city is subclass of geo-object and
composer is subclass of artist and artist is
subclass of person


The subperclass-subclass issue brings me to the point
that we need a way to define association properties
like "transitivity". Or did I missed that and it is
in the spec already? I am not asking to define just
transitivity but to define a general mechanism for
property assignment and then defining at least the
important transitivity prop. as one example.


Cheers,
--Holger

-- 
H. Holger Rath <holger.rath@empolis.com>
empolis Content Management GmbH
Technologiepark, Pav. 7, 97222 Rimpar, Germany
http://www.empolis.com/ -- mobile: +49.172.66.90.427
phone: +49.9365.8062.63 -- fax: +49.9365.8062.66

To Post a message, send it to:   xtm-wg@eGroups.com

To Unsubscribe, send a blank message to: xtm-wg-unsubscribe@eGroups.com



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC