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: [topicmaps-comment] Can subjectIdentity elements guarantee topicidentity?


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.

The point about reification is that a topic will 'selectively reify' or 
'reify and interpret', in other words a topic map developer will not 
necessarily reify a subject in its objective entirety (this may be 
impossible in principle), but only the aspects of the subject which 
they're interested in or aware of.

This obtains no matter how detailed or complete is the resource being 
reified: different developers can always reify differently.  In fact, 
the richer the resource, the more the reifications can diverge - even to 
the extent of being mutually exclusive.  I am not being a postmodernist: 
imagine reifications of the subject 'Osama bin Laden', one at the 
Pentagon, the other at www.alQaeda.net.  The heterogeneity of knowledge 
is not a technical problem; knowledge is 'human, all too human'.

As long as people are free to develop their own topic maps the 
subjectIdentity rules will be unenforceable.  In practice, 
subjectIdentity elements will become mnemonics to guide developers in 
merging and expanding their topic maps.  A more unpleasant possibility 
is that large corporations will develop their own knowledge banks of 
copyrighted 'published subject indicators',a fee being payable when any 
map references their topics (this won't stop the topic maps breaking of 
course, but some people do pay money for badly designed software that 
doesn't work properly).

The spirit behind the subjectIdentity rules - of specifying a topic's 
denotation - seems similar to work on constraints on topic map elements, 
for example in tmcl and tmpm4.  Like those constraints, 'identity' is 
not an accidental property of the topic: subjectIdentity and constraints 
both address intensional (i.e. necessary, defining) aspects, while names 
and occurrences address extensional (i.e. contingent) aspects.

Some final suggestions:
- mergeMap creates associations between elements and does not delete topics.
- as it stands, the subjectIdentity element is actually a privileged 
kind of occurrence.  Perhaps it should be represented as such.
- work on subject identity - how a topic relates to the thing it reifies 
- is rightly placed within work on topic constraints.

Comments welcome.

Ivan

Ivan Uemlianin, PhD

Head of Topic Map Development
Jura Technology Limited

6 Tai Seion
Llanddeiniolen
Caernarfon
Gwynedd LL55 3AF
Wales, UK

Head Office:
35 Norroy Road
Putney
London SW15 1PQ
UK




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


Powered by eList eXpress LLC