[
Lists Home |
Date Index |
Thread Index
]
Thanks Lars. That is a good explanation. I understand that
topic maps have many applications.
The model you present starts from topic map. Sometimes, when
building a data dictionary, one is both documenting an
existing database and creating a metadata set for a query
builder to that database. The database pre-exists so the
initial extraction is likely to be something where one
gets the tablenames from directory listings, then using
native database platform calls, dumps out the useful
properties (eg, field names, data types, widths, validation
expressions if any, null or not null, and so on). By this
point, one has a set of metadata tables and begins to add
the soft join information (eg, lookups that don't rely on
primary/foreign keys). Once one has that, the topic maps
would be useful at the user interface, but the essential
engine is still a Run SQL procedure tied to the names in the
GUI controls that the user enters as they use the data dictionary
to build the queries. At that point, the topic map is
equivalent to the named query.
So I see the use of the topic maps but it still seems to be
almost a stylistic preference. I'm still not sure if it
is better, worse, or about the same functionality.
len
-----Original Message-----
From: Lars Marius Garshol [mailto:larsga@garshol.priv.no]
* Claude L. Bullard
|
| The subject says it all. IOW, why use topic maps for systems that
| have implemented a data dictionary?
I would use topic maps to build the data dictionary. That would give
you an extremely flexible model to represent your dictionary in, and
one that could easily be connected to documentation, real data, and
anything else you might wish.
We recently did this in an XML project that was based on the ICH ICSR
DTD for reporting side-effects of drugs. From the DTD (and the
comments therein) we generated a topic map, using the DTD API of the
xmlproc parser. From that topic map we then generated an RDBMS schema
for storing the data, a Java object model for representing the data in
applications, and an implementation of the object model that stores
the data in the RDBMS. The last step was automatically generating a
SAX importer and an exporter for the XML format.
After we have built the user interface and the business logic on top
of this we will have the scripts add in the RDBMS schema and the Java
object model to the topic map, so that we can deliver the topic map to
the customer as documentation. And that will essentially be a data
dictionary, but one that's really been used.
In any case, topic maps have *much* wider applicability than just data
dictionaries. Your question is a little bit like asking "Why use XML
for systems that are happy with TeX?" Well...
BTW, you might also find this article enlightening
<URL: http://www.xml.com/pub/a/2002/08/21/topicmapb2b.html >
unless that's what made you ask the question in the first place. :-)
|
