[topicmapmail] Why reify associations?
Kal Ahmed
kal@techquila.com
15 Mar 2003 21:32:07 +0000
On Sat, 2003-03-15 at 18:48, G. Ken Holman wrote:
> At 2003-03-15 18:26 +0000, Kal Ahmed wrote:
> >You could also specify the nature of the individual's role on the
> >committee using the type (roleSpec) of the association member:
> >
> ><association>
> > <instanceOf><topicRef xlink:href="#group-membership"/></instanceOf>
> > <member>
> > <roleSpec><topicRef xlink:href="#chairman"/></roleSpec>
> > <topicRef xlink:href="#kgh"/>
> > </member>
> > <member>
> > <roleSpec><topicRef xlink:href="#group"/></roleSpec>
> > <topicRef xlink:href="#the-committee"/>
> > </member>
> ></association>
> >
> >I prefer this approach because the member is being used to specify more
> >precisely the nature of the role played by the individual in the group.
>
> But does the fact that his association is an instance of group-membership
> require me to also have me as a regular member? Or are there transitive
> qualities that I use "group-membership" for 11 of the 12, and
> "chair-membership" (instance of "group-membership") for me, that when I ask
> for all "group-membership" do I implicitly get all 12?
>
> >A parallel would be specifying the members of a band using roles such as
> >"vocalist", "guitarist", "drummer".
>
> Each as an instance of "band-membership" ... but again, would each
> instrument-membership relationship *automatically* infer band-membership
> that when I queried(? I know there is no query language ... lets say
> "followed") on "band-membership" I would implicitly get *all* members
> through their instrument-membership associations without having to
> explicitly instantiate band-membership associations?
>
> >Note that this approach does not prevent a person playing two roles in a
> >group, so if an individual is both treasurer and secretary, then you can
> >simply create two <member> elements with different <roleSpec> contents
> >but the same player <topicRef>.
>
> In the same association? As follows:
>
> <association>
> <instanceOf><topicRef xlink:href="#group-membership"/></instanceOf>
> <member>
> <roleSpec><topicRef xlink:href="#secretary"/></roleSpec>
> <topicRef xlink:href="#kgh"/>
> </member>
> <member>
> <roleSpec><topicRef xlink:href="#treasurer"/></roleSpec>
> <topicRef xlink:href="#kgh"/>
> </member>
> <member>
> <roleSpec><topicRef xlink:href="#group"/></roleSpec>
> <topicRef xlink:href="#the-committee"/>
> </member>
> </association>
>
> ... or as two associations:
>
> <association>
> <member>
> <roleSpec><topicRef xlink:href="#treasurer"/></roleSpec>
> <topicRef xlink:href="#kgh"/>
> </member>
> <member>
> <roleSpec><topicRef xlink:href="#group"/></roleSpec>
> <topicRef xlink:href="#the-committee"/>
> </member>
> </association>
> <association>
> <instanceOf><topicRef xlink:href="#group-membership"/></instanceOf>
> <member>
> <roleSpec><topicRef xlink:href="#secretary"/></roleSpec>
> <topicRef xlink:href="#kgh"/>
> </member>
> <member>
> <roleSpec><topicRef xlink:href="#group"/></roleSpec>
> <topicRef xlink:href="#the-committee"/>
> </member>
> </association>
>
That is an interesting question. I think I would prefer to see this as
two separate assertions. "Ken is treasurer of the committee", "Ken is
secretary of the committee". For that reason I would model this as two
separate associations.
> >While you *could* use this approach to specify all the members of the
> >committee with a single association, I prefer to specify any kind of set
> >of relationships which are not interdependent in their most atomic
> >form. i.e. because someone can join/leave the committee with out
> >affecting the structure of the rest of the group, I would model each
> >individual's membership of the group with a separate association.
>
> Whooops ... you just answered my question ... but how is the group
> structure impacted in the "one association" approach when someone leaves or
> joins the committee? I don't see the risk you are highlighting.
>
Actually, I would use subclassing of the association role types, rather
than duplicate roles. So that "chairman", "secretary" etc. are
subclasses of "group-member" - after all, if you playing one of the more
specific roles in the group, then you are also playing the more general
role of a "group member". I would just use multiple roles when the roles
are not subclassed - e.g. "secretary" and "treasurer".
This would also address your question about querying - one could query
for roles which are instances of "group member" or one of its subclasses
(depending on the features of your query language, this might be
implicit in the query against the base class).
The structure issue comes from the nature of the association. In the
HyTM spec, an association is a form of HyTime agglink - and represents a
collection of arcs. However, I tend to see things such as group
membership, many hierarchies and some part-whole relationships as being
a series of discrete relationships rather than an aggregate. The fact
that person A is a member of a group bears no relationship to the fact
that person B is a member of the group - hence the relationships have a
discrete nature and I feel more comfortable modelling them as such.
However, if all of my association roles are part of the same statement,
then I feel that they should not be separated. So if I want to say "Kal
plays the bass in the band", I could choose to model this using the role
"bass player" to denote my role in the band, or I could choose to model
this as a three-way relationship between the band, the band member and
the instrument played by that band member.
<association>
<instanceOf><topicRef xlink:href="#band-membership"/></instanceOf>
<member>
<roleSpec><topicRef xlink:href="#member"/></roleSpec>
<topicRef xlink:href="#kal"/>
</member>
<member>
<roleSpec><topicRef xlink:href="#band"/></roleSpec>
<topicRef xlink:href="#the-band"/>
</member>
<member>
<roleSpec><topicRef xlink:href="#instrument-played"/></roleSpec>
<topicRef xlink:href="#bass-guitar"/>
</member>
</association>
This is an example which you could not split in to two separate binary
associations and still retain the same information. "Kal plays bass
guitar in the band" is not necessarily the same as "Kal plays bass
guitar and Kal plays in the band" . After all, I could have been
relegated to drummer (or some other non-musical role ;-) in that
specific band.
Cheers,
Kal