RE: [xtm-wg] Modified diagram for Association Template

[Daniel Rivers-Moore <daniel.rivers-moore@rivcom.com>]

The association template construct described in the Conceptual Model within
the XTM 1.0 Review Specification of 4 December, and in my draft mapping of
that model to the (slightly revised) syntax, does allow the roles to be
specified, and the classes of permitted players of those roles. It does not
provide a mechanism for saying how many players there may be for each role,
however, except by the indirect route of saying that the permitted player of
a role is a "set of x to y people", for example.

I would model Holger's rather complex "meeting" structure through multiple
association templates: one for the meeting-meetingroom association, where
the role of meeting must be played by an instance of the class "meeting" and
the role of meetingroom must be played by an instance of the class "room";
one for the meeting-participant association, where the role of meeting must
be played by an instance of the class "meeting" and the role of participant
must be played by an instance of the class "person", and so on. These are
all binary associations, and the fact that there may be many players of the
participant role, and zero players of the minutes role, for example, is not
specified by the template.

A ternary association might be "employment", in which an employer employs a
person to fulfil a job function. I could model this as follows:

<topicMap>

<!-- Association Template -->

	<association id="employment">
		<role id="employer">
			<player>
				<topicRef xlink:href="#person"/>
			</player>
			<player>
				<topicRef xlink:href="#organization"/>
			</player>
		</role>
		<role id="employee">
			<player>
				<topicRef xlink:href="#person"/>
			</player>
		</role>
		<role id="employed-as">
			<player>
				<topicRef xlink:href="#job-function"/>
			</player>
		</role>
	</association>

<!-- Derived Association -->

	<association
id="drm-employed-by-rivcom-as-director-of-new-technologies">
		<associationSpec>
			<topicRef xlink:href="#employment"/>
		</associationSpec>
		<role>
			<roleSpec>
				<topicRef xlink:href="#employer"/>
			</roleSpec>
			<topicRef xlink:href="daniels-employer"/>
			<player>
				<topicRef xlink:href="#rivcom"/>
			</player>
		</role>
		<role>
			<roleSpec>
				<topicRef xlink:href="#employee"/>
			</roleSpec>
			<topicRef
xlink:href="rivcoms-director-of-new-technologies"/>
			<player>
				<topicRef
xlink:href="#daniel-rivers-moore"/>
			</player>
		</role>
		<role>
			<roleSpec>
				<topicRef xlink:href="#employed-as"/>
			</roleSpec>
			<topicRef
xlink:href="daniels-job-function-at-rivcom"/>
			<player>
				<topicRef
xlink:href="#director-of-new-technologies"/>
			</player>
		</role>
	</association>
</topicMap>

The association template tells me that there must be a class-instance
association between person or organization and rivcom (that is, RivCom must
either be an organization or a person, since only things of those types may
play the employer role in the employment association); there must be a
class-instance association between person and daniel-rivers-moore (that is,
Daniel Rivers-Moore must be a person, since only persons may play the
employee role in the employment association); and there must be a
class-instance association between job-function and
director-of-new-technologies  (that is, Director of New Technologies  must
be a job function, since only things of that type may play the employed-as
role in the employment association).

I believe this is a good "starter set" of constraints for version 1 of XTM.
Certainly, it would be desirable to develop and extend the richness of the
templating and constraint definition mechanisms as we proceed to later
versions of XTM. However, we NEED at least a minimal templating mechanism
such as this in order to allow the class-instance and topic-occurrence
associations to be defined, and these are needed to give meaning to the
<instanceOf> and <occurrence> elements, which are essential to the basic
Topic Map functionality. Anything more is a further enhancement, and can
wait till later versions.

(Note that the draft "Mappings between the XTM Conceptual Model and the XTM
Interchange Syntax" document that I submitted yesterday describes how the
instanceOf and occurrence elements need to map to the corresponding
association templates. The nature of the associations involved in the
"variant" structure within baseName also needs to be spelled out, but I am
not so clear about this aspect, not having been a member of the Interchange
Syntax subgroup which developed this construct.)

I hope this helps to clarify. I believe this view is consistent with that of
other members of the group that developed the templating construct within
the conceptual model. I'm sure they will say if they disagree!

Best regards

Daniel. 


-----Original Message-----
From: Hans Holger Rath [mailto:hhr@step.de]
Sent: 09 January 2001 13:56
To: xtm-wg@egroups.com
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

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

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