Re: Using TM to help define the future of XML

Hi guys,

On Wed, Dec 1, 2010 at 11:45 PM, Andrew S. Townley <[email protected]> wrote:
> My current belief is that Topic Maps provides the necessary identity
> foundation and conceptual model (in the TMRM) for representing
> anything you want to say about anything using the physical representation
> of your choice.  The rest of the Topic Maps may just be extremely useful
< commentary on those fundamental points.
>
> Why not share the love? :)

Why not, indeed. If I get you correctly, you're talking about
something that probably has hit a lot of Topic Mappers over the years;
that the TM soup, the kool-aid drink on offer once you understand both
the TMDM and the TMRM, it actually works! It actually solves a
bucket-loads of problems that most other technologies still struggles
with. Not only does it work in my one use case, usually my current
one, but pretty much all of them and probably all of the future ones
as well, and if the world only spoke some TM format I reckon we can
move forwards in spades.

In other words, a *lot* of the stupid crap I've put up with being a
software developer for years and years comes together beautifully in
Topic Maps, especially when it comes to the harder problems of
representation, modeling and conceptual interchange.

So, WTF? Why aren't people understanding this? Perhaps every time they
whine about the stupidity and direction of the current technology
stack (and in Andrew's example there's not much love for XML by the
hard-core XML crowd), and perhaps some effort should be made to make
them understand that if only they had used TM, or at least parts of
it, things wouldn't be so sucky?

You know, it might happen if only one bigger service provides a TM
interface to their data, it wouldn't require more than that. One
little Groupon or Mint or - heaven help us! - Google or Microsoft,
release an important interface using TM, and it will spread like
crazy.

But of course it won't happen.

* First hindrance; parlance. The language used in the TM world (and
I'll include the RDF world in this one) differs quite a lot from the
language of normal developers. When I say Topic, they say Item, Thing,
Record, and when I say Association, they say Relation, Link,
Suggestion, and so on. And Occurrence? Well, that concept doesn't even
exist in their world. This may not seem like much of a problem, but it
is when you're explaining these concepts to normal people. The
language is so alien they won't *get* it, and will return to whatever
they know. Should we create a version of TM that speaks their
language?

* Second hindrance; concept. People may well understand, more and
more, that most problems revolves around models, yet very few
understand that there's more to models than entities and constraints,
and how this explicitly is bound up in the next point ;

* Third hindrance; identity management. People tend to think that
generating UUIDs bloody everywhere is enough without any understanding
that *shared* identities need /management/ and a great degree of
control. Nor does anyone seem to really get that whole identifier /
indicator / locator conundrum.

* Fourth hindrance; we're not W3C. T-B Lee doesn't use TM. Google
doesn't. No one really does. It's just us, us happy few, tinkering
with our systems, our happy few systems. They're cool systems, mind
you, and some of them solve real hard problems, but it's just us. Here
in Australia I know of two people with any real understanding of Topic
Maps, and I'm one of them. There's no projects. There's no progress.
People want to use technology that is used by the main forces of the
development world. If it's "Semantic" technology (what a crap name),
if it isn't RDF, then it's a no-go. Applicability isn't as valuable as
tick-boxing and a false sense of information exchange through RDF.

So, back to the XML list. What comes up there from time to time is
real people's frustrations with standards-based technologies (XML
related, in this case) and how the committee often inhibits the
creation of something that solve problems better. It may be good
enough for most things, but things like namespaces being poorly
implemented, that XSD creates more trouble than it solves, that the
dataset is hard to pin down, xml:id(s) not emphasized enough (or
enforced enough), and so forth. And I think Andrew is right that all
of these problems point to something people are trying to do with the
technology, and I also think he's right in saying that a lot of these
problems, based on our own experiences, are often solved by looking
straight to Topic Maps.

So perhaps there's a false trichotomy between the technology you
choose, the model at the core of your problem and identity management
that binds it, where a specific technology (here' XML) is measured on
its own rather than as part of that glorious trifecta called
"solution."

And perhaps another collaborative round of Topic Mappers joining
various discussions could happen, so everybody, drop your projects and
start prozelyting!

:)


Regards,

Alex
-- 
 Project Wrangler, SOA, Information Alchemist, UX, RESTafarian, Topic Maps
--- http://shelter.nu/blog/ ----------------------------------------------
------------------ http://www.google.com/profiles/alexander.johannesen ---