Re: [topicmaps-comment] Can subjectIdentity elements guarantee topicidentity?

["Thomas B. Passin" <tpassin@home.com>]

This argument is a good illustration for the need to apply scopes.  A scope
for the first topic could be "art" or some such, and a scope for the second
could be steganography.  Scope are intended for exactly this purpose, to
provide the context in which a subject is to be considered.  Different
scopes would prevent the topics from being merged, or, if they were merged
anyway, would still allow you to disambiguate (that wonderful word!) the two
uses.

But it's also a good illustration of what Steve N was just arguing for a few
days ago.  These example topics are poorly formed, in that they are not
about one single clear idea pointed to by the subjectref.  If the first
topic is really about steganography, the the image would be an occurrance of
the topic, not the subject.  If the subject really were the image, then
steganography should be another topic with an association of some kind to
the the image.  Either way, these topics are poorly constructed.  Trying to
make the subject a contingent compound idea like "this image as an
illustration of steganography" is not a good idea.

But Ivan illustrates another important point.  Defining topics properly is
hard, as Steve N also said.  Consequently, in real life many maps will come
to contain poorly formed topics.  It seems to me that the main defence for
your own maps becoming infected by such topics would a liberal application
of scope antibody.

Cheers,

Tom P

[Ivan Uemlianin\
> Can subjectIdentity elements guarantee topic identity?
>
> I'd like to explore this issue, so I've framed the argument below
> assertively.
>
> The fact that two topics have the same subjectIdentity elements does not
> independently guarantee that the two topics are about (denote/refer to)
> the same thing (idea/notion/subject/whatever).  However, the topic map
> specs (i.e. iso 13250 and xtm 1.0) both stipulate that topics with
> identical subjectIdentity attributes/elements should be merged
> automatically (iso 13250 5.2.1; xtm 1.0 2.2.1.3 & 2.2.1.4).  This
> stipulation is not motivated by the syntax, by likely use or by broader
> theoretic consideration.  The stipulation is therefore an arbitrary
> barrier to topic map development, and it should be relaxed or it will be
> ignored.
>
> Here is a plausible example of use to demonstrate this: two topics with
> identical subjectIdentity/resourceRef elements.
>
> Here are excerpts from two XTMs developed independently at separate
> locations (the XTMs are fictional but the jpgs are real).
>
> <topicMap id="topicMap1">
> <topic id="abc123">
> <subjectIdentity>
> <resourceRef xlink:href="http://bla.jpg"/>
> </subjectIdentity>
> <!-- names and occurrences here -->
> </topic>
> <!-- more topics and associations -->
> </topicMap>
>
>
> <topicMap id="topicMap2">
> <topic id="xyz789">
> <subjectIdentity>
> <resourceRef xlink:href="http://bla.jpg"/>
> </subjectIdentity>
> <!-- names and occurrences here -->
> </topic>
> <!-- more topics and associations -->
> </topicMap>
>
> The .jpg file that both topics reify is an image of the Earth with some
> clocks floating about in space.  TopicMap1 is all about the artist who
> created this image, and the topic is associated with the artist, their
> other works and so on.  The developer of topicMap1 is unaware that
> bla.jpg contains an encrypted image of the B52 graveyard in Arizona.
> TopicMap2 is all about encryption and steganography and the topic is
> associated with the encrypted image, the news story around it (href?)and
> so on, with no mention of the artist and their other works.
>
> These topics *could* be merged into a more 'complete' reification of the
> subject, but the developers of topicMaps 1 & 2 could plausibly argue
> that the merged topic is a third topic, different from the other two,
> and does not replace them.  There would now be three reifications of the
> same subject which related in a particular way.  In other words merging
> is a kind of association rather than a copy-and-delete.
>
[...]