Re: [topicmaps-comment] RE: OASIS vs W3C

[Tony.Coates@reuters.com]

On 24/09/2001 15:57:57 Bernard Vatant wrote:

>Although your remarks seem to be grounded in "business common
>sense", I will second Murray's view that those tools have basically
>different purposes. RDF is resource-centered, Topic Maps are
>subject-centered. Full stop. A clear-cut question could be : "do you
>want your information system to be resource-centered, or subject-
>centered?"

Again, this may be a clear-cut question to the readers of this list, but I can see the rest of the world asking "what's the difference?"

>Too formal question, too academic? Is the difference between
>subjects and resources really too difficult to explain to business
>people even from 30 000 ft? If I deal with products catalog,
>documentation, library or images bank, I would say I'm resource-
>centered, but if I deal with KM, Human Resources, Project
>Management, EIP, I would say I'm subject-centered. Maybe your
>examples at Reuters were less clear ...

I'm afraid I don't see a real distinction here.  One of the great things about topic maps is the way topics are used to reify subjects, which effectively means that URIs are assigned to the subjects (via the topics).  Add to that the fact that while RDF is nominally about resources, it really can be used with any URI, whether it corresponds to a resource or not.  What you have, then, is effectively one-to-one mapping between subjects and resources/URIs (and resources are subjects, after all).  So the distinction is not clear cut about which to use.  After all, can you really imagine me saying to someone "Oh, you have an image bank, you shouldn't use topic maps, you should use RDF instead."  I don't see that as an obvious or supportable thing to say, so how could get that from your example?  I wonder if there is an example that really says "I don't have a choice of which (out of topic maps or RDF) because the problem rules one of them out".

>"The best tool is the tool you know" ... sounds to me like a poor
>old argument in a business world where every other silly tool has
>driven people crazy as long as it was *new*. How did people shift
>from typewriters to computers, from paper mail to e-mail, from local
>files to networks and to cell phones and WAP?

I get bombarded with information about new tools every day.  There is no way we could (or should) buy and deploy all of those.  Along the way, we have to make decisions about which tools and/or technologies we will use, and which ones we don't need because we can achieve a similar result using something we already have.  The argument that you should use the best tool for the job is only applicable where that job is your full-time primary task.  For example, I routinely discourage people from using text editors for XML (if you can see the angle brackets, you haven't got the right tool), but if someone who edits one XML file per year told me that they wanted the most expensive XML editor on the market, I'd tell them to save their money and use Notepad or vi.  In a world where few people have the luxury of working on just one thing, there is a difficult balance to maintain between when you buy a new tool and retrain everyone, or when you "make do" with what you have and know.  Add to
that the number of times people have been burned by tools/technologies which did not turn out to be the panaceas that the marketing pap promised, and you might be able to imagine why buying and deploying the "best tool" may simply not be the "best business decision".

>OTOH practical today maybe unsustainable tomorrow. Is it out of
>being practical that enterprises keep on building up that non-
>interoperable legacy of billions of MS Word documents which could
>have been written as well as plain html documents through html
>editors easier to use than MS Word (not to speak of XML editors)?

Sure, I prefer to write HTML myself.  However, some people need reasonable printed output (because a lot of the world still uses paper), and HTML doesn't give you that.  Suddenly, everyone needs two tools and two sets of training, and we still haven't got rid of our dependence on a mainstream word processor.  You see, it just isn't that easy.

>Bottom line. Would not "best practices and benchmarking"
>approaches with more *users* viewpoint be more efficient than
>more technical liaisons and commissions and general architectural
>models and other variants of the Big Picture syndrom?

Well, my view is that the bottom line for companies is that they are looking for solutions to business problems.  Tools and technologies are only of interest if they provide a means to the end of solving some or all of those business problems.  If I talk to a vendor, and all they tell me is what their tool does, not what problem of mine it solves (at least generically, if not specifically), then that vendor is probably wasting my time, because what I am being told is that the tool has some functionality which I almost certainly cannot use unless we budget a lot of time and effort to write the glue code needed to integrate that tool with the rest of the world (integration rarely comes for free).  A focus on "what problem does this solve" and "why is this a better solution that the obvious alternatives" can force you to concentrate on issues that have practical benefits to users, rather than on issues which add no end-user value but are simply matters of making particular concrete
choices.

Enough said.

     Cheers,
          Tony.
========
Anthony B. Coates
(1) Content Distribution Architect - Project Gazelle
(2) Leader of XML Architecture & Design - Chief Technology Office
Reuters Plc, London.
Tony.Coates@reuters.com
========



-----------------------------------------------------------------
        Visit our Internet site at http://www.reuters.com

Any views expressed in this message are those of  the  individual
sender,  except  where  the sender specifically states them to be
the views of Reuters Ltd.