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]

> [Thomas B. Passin]
> > 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.
>
> Could you expand on this, perhaps giving an example in XTM format?  It
> sounds like exactly what's needed, though it also resembles manual
> reification.
>
Well, yes, it may be manual, but that depends on how the information gets to
the toic map engine, doesn't it?

An example, hmm...  OK, here is an example using my own (simplified)
notation.  A name with a double colon represents an element, a name with a
leading "@" denotes an attribute, and indentation denotes element nesting.
Otherwise text is character data.  Comments start with a leading semicolon.

BTW, I have a python parser that can turn this format into regular XML.
This way, it's easy to write and easy to read. A little massaging with an
xslt stylesheet and you have XTM (or you can write XTM directly this way,
but it's a bit less readable, what with all the xlink: fragments, etc.).

; All topics not defined are assumed to already exist in the map.
; The original association
association::
    @id::a-club-1
    member::
        roleSpec::
            topicRef::rt-club
        topicRef::t-club-med
    ; Here is a member you want to reify and refer to
    ; so give it an id
    member::
        @id::m-clubmember-1
        roleSpec::
            topicRef::rt-club-member
        topicRef::t-bob-smith
    member::
        @id::m-clubmember-2
        roleSpec::
            topicRef::rt-club-member
        topicRef::t-indiana-jones

; Reifying Bob Smith's membership (topic map sense)
topic::
    @id::t-reified-membership-bob-smith
    ; This topic is an instance of the "reified member" topic type
    ; (see remarks below)
    instanceOf::
        topicRef:tt-reified-member
    subjectIndicatorRef:m-clubmember-1
    baseName::
        baseNameString::Bob Smith's Membership

; Assigning a sponsor to Bob Smith
association::
    @id::a-sponsored-membership-1
    member::
        roleSpec::
            topicRef::rt-sponsored-member
        ; Here is our reified membership topic
        topicRef::t-reified-membership-bob-smith
    ; This membership was sponsored by Bob Smith's father
    member::
        roleSpec::
            topicRef::rt-sponsor
        topicRef::t-bob-smith-sr

Clear enough?  Of course, we have to know what a "tt-reified-member" topic
is, but that issue is pervasive, not just unique to this example.  Perhaps
we would use a PSI instead, but that simply shifts the burden - how does our
program learn what the PSI means?

It would be easier if members and such like were first class topics, then
you could refer to them directly without creating the reified topic.  Maybe
you could anyway by using a subjectIndicatorRef (Steve N or Steve P - what
about this?)

> > 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.
>
> Disclaimer:  I'm no RDF expert.  Could you not, in RDF, give a statement
> an ID, then refer to the statement through that ID as a resource, thus
> potentially using it as the subject of other statements?  Basically doing
> the same thing as you seem to be proposing above.
>

You can give an RDF statement an ID, but only after you reify it.  And then,
strictly speaking, you assign the ID to the reification, not to the original
triple.

> Also, I don't think TM pre-reifies its structures in the same sense as
> RDF.  After all, in RDF, a reified statement consists of 4 more nodes and
> 3 more statements that detail its structure.

Right, and in topic maps you create a topic whose subject is the association
(or whatever) - one topic, you don't need  separate statements or
associations that assert that each roleplayer belongs to that association
(like you would have to in RDF).  You get that automatically because the
entire association, member, or whatever IS the subject.

Consider if you stored RDF triples as rows in a relational database.  What
would be more natural then to assign a unique ID value to each row, as a
primary key?  Bingo, you have just reified every triple in the RDF-base.
But that's not in the RDF model as it stands, although some people are
talking about possibly extending RDF to use quads instead of triples.  If
you did this, I would call the RDF statements "pre-reified".  In this sense,
I think of the topic map structures as being pre-reified.  "Reified" in the
RDF sense, not the topic maps sense.

Cheers,

Tom P



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


Powered by eList eXpress LLC