[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