[sc34wg3] Re: Public Interest and ISO WAS: [topicmapmail] <mergeMap> questions

[Kal Ahmed]

At 12:40 24/10/2001 -0500, Steven R. Newcomb wrote:
>[Kal Ahmed:]
>
> > I'm making the point (though obviously not clearly
> > enough) that topic maps will not succeed or fail
> > because it is "correct" as determined by ISO,
> > TopicMaps.Org or anyone else for that matter. It will
> > succeed if and only if the paying public decide that
> > there is value in it and invest accordingly.
>
> > If the success of topic maps is of paramount
> > importance,
>
>Here's that "public interest" problem again: Is the
>"success of Topic Maps" the goal of all the work we
>have done, or were Topic Maps invented to serve some
>other goal?  I've always thought so.  I've never
>thought that Topic Maps were some kind of end in
>themselves, and I was there at the very beginning.  I
>remember the reasons why the Topic Maps paradigm was
>conceived, and the reasons had nothing to do with the
>success of the brand name, "Topic Maps", or with the
>success of any document or product that bears that
>brand name.  It had to do with improving the
>productivity of human beings, by making existing
>knowledge more easily findable -- especially knowledge
>of where to find the knowledge you're looking for.

And I don't believe that I have ever stated that I think that the "success" 
of topic maps is an end in itself. I don't know where you got that 
impression from. However, if topic maps are a niche technology used by a 
few "in the know", no wider purpose will ever be solved. Making topic maps 
"successful" is a step towards achieving the wider goal of making 
information more accessible and providing an infrastructure for knowledge, 
opinions and facts to be freely interchanged.

> > then the people we should be listening to are the
> > users. Are topic maps "broken" because they cannot
> > represent multiple equivalent assertions with a
> > single Association "object", but instead have a model
> > in which you end up with multiple equivalent
> > assertions with a single scope each ? No, not unless
> > the user community says they are ...[snip]... [and]
> > there really isn't [a user community] yet.
>
>Correct me if I'm wrong, but you seem to be arguing
>that we should create a user community around something
>we know to be broken, and wait for them to wake up and
>realize it before we fix it.  Did I get that right?

No you didn't. I assert that there is nothing "broken" about the way in 
which ISO 13250 and XTM 1.0 regard associations as having a single scope. I 
am saying that the only thing that would convince me that this is broken is 
if people who have used topic maps in practical applications start to say 
"If associations could have multiple scopes, this would be so much easier".


>Is "the creation of a user community" the *primary*
>goal of all our efforts, here?  I hope not.  I hope the
>*primary* goal is to enhance the productivity of our
>user community, regardless of the size of that
>community.  If we succeed in that, we'll have the
>largest possible user community -- but that's just a
>side effect of doing the right thing for our users.
>Creating a large user community has never been the
>*purpose* of all this effort.  It's a mark of success,
>but it does not constitute success.

See my first comments.

> > Here is my core point coming round again.
>
> > I believe that more than anything, topic maps need a
> > period of stability to gain traction. Only when we
> > have real-life experience of topic map applications
> > and projects will we be able to say what parts of the
> > specification are broken. Tinkering with the model
> > like this, at this stage will at best set us back at
> > least 12 months. At worst, we will see vendor
> > interest drop off (why try to implement support for a
> > moving target) and topic maps fail.
>
>You seem to be saying that the interests of vendors are
>better served if the further development of the
>concepts that presumably serve as the basis of a
>standard are kept secret, so that the standard can
>remain unchanged.

I don't recall ever suggesting that anything be "kept secret". And I don't 
know why you have the opinion that I reflect the "interests of the 
vendors". I am not a paranoid, nor am I a vendor (at least not of topic map 
software - all my software with regards to topic maps is in the public 
domain, developed by myself and others on our free time - the TM4J project 
is *not* commercially driven in any way).

Let me turn the question around. Given the current nascent state of topic 
map technology, who's interest is served by making changes that have no 
basis in real-life user requirements ?

>It's discouraging that so many bright, well-intentioned
>people, like yourself, Kal, seem so intent on
>preventing the topic maps paradigm from being
>maintained in working condition.  Your proposal to
>allow topic map processing to be whatever someone
>interactively decides it should be, from time to time,
>is tantamount to saying, "The meaning of a topic map is
>ambiguous," which, in turn, is tantamount to saying,
>"If you want to interchange information reliably, don't
>use a topic map to encode it."  What, then, is the
>point of the standard?

You have snipped all of my postings, so I'm not sure what passage you are 
referring to when you claim that I propose that topic map processing should 
be "what ever someone interactively decides it should be". I hope that I 
haven't given that impression to every one. Actually I am strongly in 
favour of having a single, workable, scaleable topic map processing 
solution that will work in networked environments and that will allow 
processors to interact on a sliding scale with each other and with their 
users. But that is for another posting / paper.

As you have started from a false assumption, I cannot really respond to 
your points / questions

>Some people in our community seem to be thinking that
>the real point of the standard is the combination of
>ISO's imprimatur with the brand name, "Topic Maps",
>and that it doesn't matter what the brand name actually
>means.

I don't know who those people are. I don't think I have ever met any of 
them - but I tend to think the best of everyone....at first ;-)

>I would like to point out that there are many customers
>who don't give a damn whether the paradigm is standard,
>what the brand name is, or whether the way it works is
>known to the public or is kept secret.  They just want
>it to work.  It would be competitively advantageous for
>each of us to keep all our discoveries of the problems
>and their solutions secret, and just let the rest of
>the topic maps community, and all of its various
>projects, go off in all directions.

I agree.

>Even if that scenario makes the vendors happy, it makes
>me very unhappy.  It's self-defeating for all of us.
>Logically, it should *not* make the vendors happy.  It
>should only make the vendor with the deepest pockets
>happy, because in the absence of a central, shared
>vision of the ultimate purpose of the standard, and
>*rigid adherence to that central shared vision and
>purpose, come what may*, there is no basis for a level
>playing field on which vendors, both small and large,
>can compete with one another.

One of the goals of the TM4J project is to bring topic map technology into 
the reach of those with a little programming knowledge, a little enthusiasm 
and no cash. So I don't think we are a million miles apart on this.


>If we believe it's bad to fix the standard when we
>discover that it lacks something necessary for
>effective information interchange and information value
>preservation/exploitability, then the public interest
>will suffer, and the central claim of the topic maps
>paradigm becomes a lie.  Ultimately, the public will
>wake up and discover that its topic map assets really
>*aren't* consistently and reliably mergable with other
>topic map assets, and their topic maps really *aren't*
>protected from loss of value due to dependency on the
>technologies and methodologies espoused by particular
>vendors.

I have still not seen a convincing example of how a topic map paradigm with 
one scope per association *is* broken. So your "fixing" is my  "tinkering".

>I feel sorry for vendors who believe that they can
>exempt themselves from the necessity of adapting their
>products to a changing technical and business
>environment simply by pointing at the imperfect
>language of an imperfect standard, written by imperfect
>human beings, and saying, very loudly, "The standard
>doesn't say what do to about this, so whatever we have
>decided to do about it conforms to the standard, by
>definition."  That may be true, but it's a meaningless
>claim.  It begs the question, why would anybody buy
>their technology?  Certainly not on the basis of the
>technology's conformance to a powerful, well-maintained
>standard that actually serves the customer's interests.

And if the standard changes every 12 months because the standards committee 
has changed its mind about what is represented, and if those decisions 
about what topic maps are do not take into account what the majority of 
implementations are already doing, and if those changes mean that software 
has to be changed, and if those software changes cause maintenance and 
upgrade problems, and if the time taken to fix those problems is time not 
spent on developing new, more powerful applications base on the topic map 
standard. Well then I feel sorry for the users.

>I also feel sorry for the people who, like you and me,
>have spent years of their lives working to make a
>meaningful contribution to society by voluntarily
>creating and maintaining a publicly-available paradigm
>and related public standards in working condition, when
>system vendors take the attitude that the "success" of
>the standard has nothing to do with whether or not it
>actually works as advertised.

Please prove that it doesn't. This whole debate could be short-circuited by 
a few convincing examples of the standard not working "as advertised".


>At a time when worldwide terrorism has created a
>situation in which effective information management is
>essential to the maintenance of an "open" civilization
>in working condition, it's a very bad idea to try to
>slow our progress toward a scenario in which ordinary
>civilians can integrate their knowledge efficiently and
>reliably.  We need to make the advantages of "openness"
>as exploitable as possible, and as quickly as possible.
>Yes, that means being adaptable, and adaptation is
>always painful and expensive.  The expense and pain of
>adaptation is better than the alternative.

[WARNING - off-topic response ahead]

I truly do not believe that this has anything to do with the realisation of 
certain nations that terrorism is a real threat. Having lived in a society 
under constant terrorist threat for the whole of my life, I can honestly 
say that it hasn't made a blind bit of difference to what I have chosen to 
do or not to do.   I think you will find that the response to recent events 
at a national level will not be more open information, but less.

BTW - I find you mentioning terrorism and the recent objections to your 
proposal for multiple scopes on an association to be highly inflammatory 
towards myself and the others who have taken part in this discussion. I am 
hoping that it was unintentional.

Kal