Re: [topicmaps-comment] Re: RDF/Topic Maps: late/lazy reification vs.early/preemptive reification

[David Riegelnig <riegelnig@mondax.com>]

[Piotr Kaminski:]
> Thanks for a clear and accurate description of reification in TM and RDF.
> I agree with every technical point you've made.  However, I think your
> analysis missed an important point:  reification mechanisms differ not
> only in terms of early vs. late, but also in terms of the depth of
> reification permitted.
> 
> Let me explain with the help of an example. [1]  Suppose we wish to model
> a network of clubs and the membership of each.  The natural representation
> in RDF [2] is to have a number of club and person resources, and attach
> them appropriately with member-property arcs.  In TM, each club and person
> would be a subject, and we'd have one membership association per club,
> with the club playing the "organization" role, and the people playing the
> "member" role (one player per member).
> 
> So far, so good.  However, the clubs are very exclusive, and membership
> needs to be sponsored.  We, of course, wish to record the sponsor(s) of
> each member of each club.  Sponsorship is not a property of the club
> itself, since it has many members each with different sponsors.  It is
> also not a property of the people themselves, since each is a member of
> multiple clubs, probably with different sponsors.
> 
> In RDF, a natural way would be to reify each "member" statement, then
> attach the statement resource to the sponsors with sponsor-property arcs.
> This would unambiguously communicate the sponsors of each person's
> membership in each club.
> 
> In TM, the situation is far trickier.  People play roles in a membership
> association.  We'd now like to make statements about each "playing".
> Unfortunately, TM doesn't preemptively reify this relationship, and does
> not provide us with any special mechanism to do so. [3]
> 
> What can we do?  We can break apart the original membership association
> into a number of binary membership associations, one per
> member-organization pair.  I would argue that this is equivalent to
> performing a (late) manual reification in RDF; we're splitting up an
> existing association so that each "playing" relationship is represented by
> a separate (preemptively) reified association.  We now have the same
> problems:  either we delete the original association, or end up with
> duplicated representations of the same underlying information.
[...]


I would suggest the following solution to the problem:

To meet your (reasonable) request not to change the original membership
assocation (roles: club,member*), sponsorship-associations could be added,
one for each membership. Such association would have the following
role/roleplayer-pairs:
- sponsor role, played by a sponsor subject
- person role, played by a person subject (wich already plays a member role
in the original membership association)
- sponsored membership role, played by the subject representing THE MEMBER
ROLE of the original membership association.

Every sponsorship-association now reifies just the "sponsoring event" (like
"the buttering"...) 
- without any redundancies and
- without the necessity of rearranging the existing membership association.

[Piotr Kaminski:]
> Let me now generalize from this slightly contrived example.  While TM
> preemptively reifies all associations, it doesn't preemptively reify all
> primitive relationships implicit in the model (e.g. the "playing"
> relationships).  As long as we only want to make statements about the
> first level of reified relationships (associations), everything's fine and
> very convenient -- much more so than in RDF.  However, if we ever need to
> make statements about the relationships that make up an association, TM
> provides no mechanisms to do this transparently.
[...]

It seems to me that the solution given by Thomas and Murray to your "club
sponsorship problem" is probably an answer to the problem of "making
statements about the relationships that make up an association".

However, for the "club sponsorship problem", it seems to me this isn't the
point. As shown above, the representation of the sponsorship event does not
need a reification of an existing "arc", but comfortably uses a SUBJECT
(node) reified earlier.

Let's see whether Topic Maps make their way into the "early,arbitrary
depth"-camp.

David

winmail.dat