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] Can subjectIdentity elements gua


Ivan

The identity endless story, part 23617 ...
Maybe your input would be of interest for Published Subjects TC, 
and I jump on the occasion to recall that all that's going on in that 
TC is on-line :))

http://www.oasis-open.org/committees/tm-pubsubj/index.shtml

Now to your point:
... two topics with identical subjectIdentity/resourceRef elements ...
<snip/>

1. If authors use <resourceRef> it should be clear to them and the 
users of their TM, 
that the resource *is* the subject. See XTM 1.0 / 3.6.2. The topic 
subject is the image 
bla.jpg itself in its addressable image bank, not whatever it 
represents, means etc. 
Using <resourceRef> here means that you are about exactly that 
image and not 
another one. Full stop. Nothing to do with whatever is represented 
or meant or hidden, 
whatever, on this image. And using it in different contexts and topic 
maps, one 
knowing that is it encrypted, and the other not being aware of it, is 
not a problem.
I can use the same image of the moon in an astronomy context or 
in an esoteric 
context. But if I want to retrieve this image from an image bank, 
this is not a problem. 
And using <resourceRef> is no more that pointing the right image 
in the right image 
bank. No more, no less.

If now C merges those two topic maps A and B, maybe he makes 
a mistake, because 
that merging does not make sense. The mistake is not made by A 
nor by B, it's made 
by C. You denounce the "automatic merging" stipulation in the 
specification. Maybe 
something has to be cleared off here. The merging is automatic as 
long as *someone 
has decided to process and merge*.  But my view is that merging 
is a decision that 
should not be made automatic and blind.

2. Now if authors use <subjectIndicatorRef>, BTW an eventuality 
that you don't seem 
to explore, that means they somehow tranfer the responsibility of 
identity to another 
party. For example, if I use <subjectIndicatorRef> to point to :

http://antwrp.gsfc.nasa.gov/apod/image/9702/cartwheel1_hst_big.jp
g

... that means I trust people who built the telescope, get the image, 
processed it and 
put it on line, to represent what I *mean* by that topic, i.e. an <instanceOf> "colliding 
galaxies". If that image is in fact an encrypted Ben Laden message, that might mean 
my trust was misplaced. There is nothing you can do in principle against that kind of 
events occurring, so you must assume the whole information system involved here, 
including telescope makers, astronomers, image processors, webmasters, etc ... is 
grounded at every level on a common background of expertise and trust ...

To make it short, I don't think you point at a flaw in the specification. There are some 
subtle (and potentially dangerous if not correctly understood) distinctions to be made 
by topic maps authors and users, and there are risks generic to any information and 
communication system, that topic maps won't get rid of by some peculiar magic. If not 
grounded in communities of agreement and trust, topic maps can and will be used very 
efficiently like any other communication tool, to spread out false identities, hoaxes, 
distorted news, misleading assertions, confusing descriptions, unwanted or deliberate 
brainwashing, etc ... 

Hope that helps

Bernard


***********************************
Bernard Vatant - Consultant
bernard.vatant@mondeca.com
Mondeca - "Making Sense of Content"
www.mondeca.com
***********************************


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


Powered by eList eXpress LLC