[Sigia-l] Topic maps and IA

[Jonathan Broad]

On Mar 26, 2004, at 4:02 AM, Listera wrote:

> "Jonas Höglund" wrote:
>
>> Does anyone have any input to this?
>> * Is it doable?
>> * Is the technologies and the methods behind them developed enough?
>> * Is there enough of skills and tools developed?
>
> Depends on where you're coming from.
>
> If you're new to relational databases and creating data structures, you
> might think all this stuff was invented in the last few years.
>
> The basic notion of creating a virtual abstraction layer to have 
> disparate
> systems talk to each other indirectly has been around for many, many 
> years.
> A lot of this stuff is old hat to folks who have been doing virtual
> file/storage systems, data mining, system integration through virtual 
> APIs,
> etc.
>
> Terminologies may be different but the fundamental notions of relating 
> and
> intermediating data structures is pretty ancient, hence my earlier 
> comment
> about not reinventing the wheel if IAs want to build bridges to other
> professionals.
>

With all due respect, OWL and topic maps are not the same kind of thing 
as a relational database.  They're all data abstractions, true, but 
they function at a fundamentally different *level* of abstraction.  
Also--let's give Lars credit, at least, for making quite a good effort 
for using the decades old language of thesauri in an effort to explain 
the significance of TMs and ontologies (which have quite a history in 
their own right).

I think your point, which is well taken, is that there isn't anything 
you can do with topic maps/ontologies (treating them the same at the 
moment) that you can't do with relational algebra or custom data 
structures.  That's true.  Well, I think there are some things you can 
do with a proper constraint language like OWL that you can't do with 
relational algebra, but my predicate logic skillz are too feeble to 
prove it.   But by that same token, you can do anything with a series 
of flat files that you can do with a full-blown RDBMS, given enough 
custom programming.

Just as an RDBMS sits on top of a set of flat files and imbues them 
with the magic of seamless complex joins, so too a TM system can sit on 
top of a RDBMS and manage the schematic and semantic relationships of 
the underlying data.  Topic maps are in that way like SQL, which served 
to standardize the *model* which RDBMSs should conform to, while 
leaving implementation up in the air.  SQL is data-oriented.  Topic 
maps (and RDF/OWL) are 
information/knowledge/please-don't-nit-pick-oriented.  I think that, 
should Topic Maps ever 'catch on', they will be to IAs what RDBMSs were 
to data managers in the 70s--not because they were impossible in the 
60s, but because they were too freakin' expensive to custom-build and 
maintain.

The most commonsensical benefit to Topic Maps that I've been able to 
come up with (in conversation with DBAs) is that TMs allow you to alter 
relationships without having to touch the data (destroying and 
recreating tables with a new schema), and allows you to maintain 
multiple "views" of the data without needing to duplicate the data with 
different schemas.  RDBMSs couple the handling of data definition and 
data manipulation under the hood.  This is great, for one kind of use 
of data (where schemas are quite fixed).  It's just not as helpful when 
you want more complex and various access to the data, which is often 
the case when the data is actually human-oriented information.

This is my understanding, anyway.  The terminology you object to isn't 
new, it's probably the longest part of the history of artificial 
intelligence research. I'm just excited because, at long last, we may 
be nearing practicable systems for managing knowledge, not simply data.

Jonathan