Re: Primary and Foreign Keys

[Uche Ogbuji <uche.ogbuji@fourthought.com>]

> Ah, but if the first requirement is to work
> in the context of XML Schema, how will RDF
> fit with this for the key relationships?

The same way XLink would: at a level above.  Actually, in RDF, you can
also operate at a level below: you can model the Schema keys and keyrefs,
or you can refer to the RDF XML serialization in your Schema.

But I wasn't saying categorically that RDF would be appropriate: just that
whenever I think of "relationships" and "XML" I almost always think RDF
first.

> Consider a design in which the schema represents
> the data-centric approach and should be
> agnostic about what database implementation
> is used.  In other words, it starts out life
> as a relational database (really a hybrid
> because of the GUI layer with business logic,
> so a mid 90s design), then one wants to make
> the data available to different systems at
> different scales (big agencies, little agencies,
> tweeny agencies, sometimes using desktop
> interfaces, sometime handhelds).   That is
> where many of us are today.  We need to
> open our dbs up to different services and
> migrate the push models of delivery to
> pull models in the sense that most large
> reporting systems collate and send their
> data up to collection agencies that then
> regularize them and send them on to a central
> collection agency, like mountain, to stream
> to river to ocean with a data-centric schema
> as the cohesive force.

I don't see anything in all the above that excludes RDF.  Most of the
above are high-level process issues that have little to do with the
technology that must be used to implement the system.  All the original
four ideas you proposed, my own proposal, or even others might all fit
quite well.

What one needs is the logical character of the existing data and some of
the use-cases going forward to make a really informed choice.

> And add that the workflow for producing these
> can vary a lot among systems that have to
> produce valid data.  In other words, this
> design has to work at a lot of scales.

Again, this doesn't really tell enough to choose a technology.  "A lot of
scales" can mean a lot of things, and even if I make the assumption thta
you mean a lot of different granularities for the accreted and synthesized
data, this still doesn't really trim down the many choices.


-- 
Uche Ogbuji                               Principal Consultant
uche.ogbuji@fourthought.com               +1 303 583 9900 x 101
Fourthought, Inc.                         http://Fourthought.com
4735 East Walnut St, Boulder, CO 80301-2537, USA
XML strategy, XML tools (http://4Suite.org), knowledge management