Topic Maps on SQL

[Charles Reitzel]

[I'll try to relate this to software...]

Tim Bray wrote:
>
> You know, this goes straight to the core of a deep issue.  Where
> I have often felt out of sync with the grove/property-set evangelists
> is that I perceive syntax as fundamental and any particular
> data model as ephemeral.  I guess I must admit that I don't believe in
> "information standards that are independent of lexical/syntax
> representation".

In general, I have to disagree.  In my experience, applications and syntax
come and go, but the data live on.  Mortgages last up to 30 years, life
insurance policies even longer.  Applications (and platforms!) have about a
3 to 10 year life cycle.  Databases can last much, much longer.  In fact,
databases are frequently converted to/from any number of formats (SQL to
SQL, csv, XML!, xBase, SQL*Loader, VSAM, IMS, WordStar, 1-2-3, ...).  Yes,
this is a pain in the neck - but not the biggest one.  The logical
relationships in the data are what determine if you can "get there from here".

Getting back to SQL for a moment, I think it is important to remember that
SQL specifies a few things: a handful of attribute data types, the
definition of entities as a fixed set of attributes and a set of operations
that can be performed on entities and attributes.  This last part is perhaps
the most important as the first two are trivial.  Because of the simplified
data types and relationships, a set of highly general operations can be
defined: sorting, searching, set operations, etc.  Network databases add
direct entity set relationships and navigation to the mix.  With relational
databases, all such relationships are ad hoc based on attribute values
(which is often a requirement).  No such base set of operations exists for
object databases.  Object databases provide great behavioral flexibility,
but you give up some of the power of the standard operations.

>From Paul Prescod's "Introduction to Groves and Property Sets":
>
>You can think of the grove as a meta-"data model" for media 
>applications. It is a data model for building data models. Or you 
>could think of it as providing the low-level primitives for 
>building high-level, media-specific models.

At first glance, Groves look like the DOM for SGML.  Is this right?  In
which case it can pretty much represent XML.  Certainly, it has sufficient
syntactic "degrees of freedom" to describe SQL entities and attributes, if
not SQL operations.  But I'm not sure what this buys you.  I certainly don't
see how you build a potentially large database of abstract nodes and
properties and query and update it.

I also didn't quite get from the intro *how* Groves can express links to a
frame in an MPEG video, a measure within a MIDI sequence or any other
arbitrary media as it intimates it can (the "intrinsic" properties seem SGML
oriented).  Depending on your document base, this capability might be an
important operation missing from standard SQL (although there are a number
of proprietary solutions available off the shelf).  Such a syntax would
eliminate one problem in the example I posted previously.  Things
participating in an association might not have to use generated sequence
numbers.  More general expressions could be used instead.  I'm not sure what
it looks like, though.

To summarize, I didn't think the problem was how to express links to XML or
SGML.  But rather, how to use XML to express and collect links to SQL, to
video, to VRML, to audio, to MIDI, and so forth?  The more I think about it,
document descriptions, authors, dates, publishers, and a collection of MIME
headers and a URL/HREF will do pretty well.  All of which is highly doable
using a SQL/Network database to emit XML w/ DTD.  Anything much fancier
probably needs OODBMS.

Regards,
Charles Reitzel
creitzel at mediaone.net


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)