Lists Home |
Date Index |
- From: "Steven R. Newcomb" <email@example.com>
- To: firstname.lastname@example.org
- Date: Wed, 8 Mar 2000 12:33:38 -0600
> Ok... I'm finding the following statements *a little* contradictory.
> Topic Maps, as I understood the ISO/IEC 13250 standard to say, is a
> particular usage of Architecture Forms. It seems no different than,
> say, how Architecture Forms are just a particular usage of DTDs. The
> specification seems completely encouched in AF.
The Topic Maps DTD is a DTD, and, like all DTDs, it can be regarded as
a "base" (inherited-from) architecture -- a set of architectural
I can see why you might be confused: the examples in the back matter
of the ISO standard show how to declare the Topic Maps DTD as a base
architecture. However, the Topic Maps DTD can also be used in the
normal way, as a DTD, using a DOCTYPE declaration. If you do that,
you won't be able to customize it to meet additional requirements. If
you have no such additional requirements, then it makes perfect sense
to use the Topic Maps DTD as a regular DTD, and just ignore the
possibility of using it as a base architecture.
> Steven R. Newcomb said:
> >The Topic Maps spec, which seems to be newsworthy these days, is an
> >inheritable architecture. It's good that XLink has turned out to be
> >a set of architectural forms, because XML Topic Maps (among many
> >other applications) must inherit the extended XLink syntax and
> So... something doesn't jive - Topic Maps inherit from both XLink syntax
> and encouched in AF? Perhaps I'm missing some pieces here (I'm hoping!
> :-) ).
ISO/IEC 13250:2000, the Topic Maps standard, inherits "varlinks" from
the HyTime architecture. It's not a coincidence that HyTime varlinks
are almost identical to "extended" XLinks. The differences are
trivial, and they mostly amount to the "show" and "actuate" attributes
that XLinks automatically and inseparably have, while varlinks don't
automatically have them. Anyway, "show" and "actuate" have no
significance for the semantics of defined by the Topic Maps paradigm.
The current XLink draft might as well be a set of architectural forms.
Just as in the architectural forms paradigm, XLinks are to be
recognized by XLink engines *not* by means of their generic
identifiers (tag names), but instead by means of their other special
attributes. This is a good thing, because it allows XLinks to be
subtyped in a variety of ways. The Topic Maps paradigm, for example,
requires that there be two distinct kinds of hyperlink, one for
topics, and one for topic associations. If you use the Topic Maps
DTD directly, they have distinct generic identifiers. If you use the
Topic Maps DTD as a set of architectural forms (called in ISO jargon a
"meta DTD"), then you use those generic identifiers as the values of
special "architectural form name" attributes that you define when you
do the inheriting, in order to specify what each element type inherits
from each architecture. Let's say we do the latter thing. Each topic
link is then three things at once:
(1) It's an element of whatever type we decided to make it. It's
tagname could be "mytopic", for example.
(2) For topic maps purposes, it's a "topic" link. In order to allow
our Topic Maps Engine to recognize it as such, we could define an
attribute named, for example, "TopicMaps", whose value would
always be "topic".
<mytopic TopicMaps="topic" ...
(3) For hyperlink purposes, it's a HyTime varlink.
<mytopic TopicMaps="topic" HyTime="varlink" ...
(Or, if you prefer, it's an "extended" XLink instead of a HyTime
Our application can therefore use an XLink engine or a HyTime engine
to implement all the hyperlinking functionality, and a Topic Maps engine
to implement all the Topic Maps functionality. All we have to write
is the stuff that further specializes a "mytopic".
> - Is there an "XML-ified" version/spec of Topic Maps, and if so, where
> can I find it?
At least two proposals have been written, one by Martin Bryan, who is
one of the editors of the ISO standard, and one by Kal Ahmed and
Graham Moore. What is really needed, however, is industry consensus
on how to use Topic Maps in XML land, and *then* to translate that
consensus into a formal spec. To that end, IDEAlliance is now in the
process of founding a group, TopicMaps.Org, also known as XTM, for
that purpose. I think if you go to egroups.com, you can join the
mailing list for xtm-wg by registering there. There is also a draft
charter being considered by the founding Participating Members. I
think you'll find that any input you may have will be welcome.
> - If not, it seems odd that Topic maps, being newsworthy, needs and
> rides on top of AF, which seems to not be newsworthy (depending on
> viewpoints, but let's speculate for the moment). Any reasons?
Both HyTime and XLink hyperlinking uses AFs. The XLink spec doesn't
say so explicitly, that's all. We can only speculate as to why it
> I'm liking what Topic Map brings to the table in terms of drawing
> relations between topics, so if there is any work going on this area,
> I'd love a pointer, too.
There's nothing at www.topicmaps.org yet. As I said, TopicMaps.Org is
using the xtm-wg group at www.egroups.com, at least for now.
There is an interesting tandem mailing list called topicmapmail; you
have to write to email@example.com to get on that list.
The www.infoloom.com website is pretty interesting, as is
www.topicmaps.com (STEP GmbH).
I think the most impressive (and yet still quite simple) publicly
available example of a topic map is the QUID online encyclopedia
(www.quid.fr), which was created by InfoLoom using its unique Topic
Maps building methodology/technology. Over 70,000 topics. I think
that's the current record, but I could be wrong. Anyway, these are
still early days. I imagine that 70,000 topics will seem quite
trivial someday, even though it's pretty big news today.
Steven R. Newcomb, President, TechnoTeacher, Inc.
firstname.lastname@example.org http://www.techno.com ftp.techno.com
voice: +1 972 517 7954
fax +1 972 517 4571
7101 Chase Oaks Boulevard
Plano, Texas 75025 USA
This is xml-dev, the mailing list for XML developers.
To unsubscribe, mailto:email@example.com&BODY=unsubscribe%20xml-dev
List archives are available at http://xml.org/archives/xml-dev/