Re: [Tm4j-developers] svg and question

[Kal A. <ka...@te...>]

At 10:15 15/02/2002 +1100, Smith, Tim wrote:


>&-----Original Message-----
>&From: Kal Ahmed [mailto:ka...@te...]
>&Sent: Thursday, 14 February 2002 7:24 PM
>&To: Florian G. Haas; tm4...@li...
>&Subject: RE: [Tm4j-developers] TM4J 0.7.0 Features (Long)
>&
>&
>&At 18:56 13/02/2002 +0100, Florian G. Haas wrote:
>&>Kal,
>&>
>&>I very much like your ideas. Sound like a lot of work, but great ideas
>&>nevertheless! :-)
>&>
>&>Well, as for another feature, I realize I might be jumping
>&the gun a little
>&>bit, but while we're talking about dynamic, possibly XSLT-centered web
>&>applications, shouldn't we give an SVG front-end a thought?
>&Anyone up for
>&>that? (I realize this definitely sounds like a post-0.7.0 or
>&even post-1.0
>&>feature)
>&
>&That sounds way cool - actually, I saw a presentation on this
>&subject at
>&XML 2001 last year - the presenter had combined SVG graphics for
>&presentation with some statistically-based filtering which
>&"clusters" the
>&topic map into regions and subregions. Sounds like the kind of
>&interesting
>&thing which should be built on TM4J ;-)
>
>That sounds extremely cool... I may be the only one here wondering, but what
>is "SVG graphics" please?

SVG is an XML vocabulary for defining two-dimensional graphics (vectors and 
bitmaps) and text - it is quite a rich format, allowing grouping, 
transformations (such as rotation), clipping and so on. It is also possible 
to do Flash-style interactive animations with SVG.

>Also, can anyone help em with this:
>The people I work with all say
>"but couldn't everything you do with TMs be done with relational databases
>and a bit more work? Or maybe with a Semantic web?"
>I tell them that yes, everything in TMs can be done with relational
>databases (TM4J maps to Ozone, so I guess it is true) in much the same way
>that everything you do with C++ can be done in assembler.
>TMs add STANDARDISATION (an approved yet flexible specification), METAPHOR
>(the circle/association/occurence brain like diagrams work well) and
>EASE-OF-USE (should be a hell of a lot easier to build related TMs than
>innterrelate and maintain a host of seperate dbs).
>Am I wrong or missing anything?

You aren't at all wrong, IMHO - though I may be biased ;-).  See 
http://www.techquila.com/bcase.html for a paper I presented at XML 2001 - 
this paper doesn't talk about why people *should* use topic maps, it talks 
about why people *are using* topic maps - makes for a much more convincing 
argument, and as you will see, the arguments for topic maps break down into 
those three categories you have listed above.

Cheers,

Kal