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: [topicmaps-comment] Re: RDF/Topic Maps: late/lazy reification vs.early/preemptive reification


[Piotr Kaminski]

> Steve:
>
> 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.  These
> issues were well explored in the original note, so I won't dwell on them
> further here.
>

I see two approaches, neither of which engages with these issues.

1) We finesse the situation by making the sponsorship an occurrence of the
person.  This is a little weak, but probably do-able.  Number 2) is much
better, however:

2) We make each of the member elements of the club association the subject
of a topic (thus reifying the member).  Now we can assert (using an
association) who the sponsor of that person for that club is, and we do not
have to dismember or change anything we already have in the map, unless it
is to make sure that we have one member arc per person, nor do we have to
change the meaning of the original "cluc" association.

Why is this different from RDF?  Because with topic maps, you get
pre-reified structures (reified in the RDF sense, that is) - associations,
members, etc.  This gives you power if the structures are the kind you need,
and it gives RDF flexibility in case they are not.

Cheers,

Tom P



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


Powered by eList eXpress LLC