Re: [xtm-wg] [XTM-CMS] Is there no data model?

[Lars Marius Garshol <larsga@garshol.priv.no>]

* Lars Marius Garshol
|
| I'm glad to hear that. It really is my main concern that people share
| that sentiment. [the data model is crucial]

* Chris Angus
| 
| I believe that there are a core of people who do, but I certainly cannot
| answer for everyone.

That is reassuring to hear.
 
* Lars Marius Garshol
|
| It really is part of my point that that is precisely what I do not
| do.  I've seen the conceptual model and to me it does not look like
| an abstract data model.  It does not seem to give a lot of guidance
| to someone wanting to create, say, a relational database schema for
| storing topic maps.

* Chris Angus
|
| It is intended to be a conceptual or abstract data model in the
| sense that it is not intended to be the physical data model to be
| used for storing a topic maps, nor should it be. 

I agree that it should not be a physical data model, but I do feel
that it should provide useful guidance to someone seeking to create
such a model.

| Having said that, if I look at your EXPRESS model it's form is not
| so different to what I think that we will produce, except for better
| of worse we are using UML rather than EXPRESS-G.
 
I would tend to say worse, and would very much prefer to see something
similer to the approach taken by the XML infoset.  Or groves, for that
matter. 

However, if you intend to produce something less like the conceptual
models published so far and more like my EXPRESS model, then that
would make me very happy.

| One of the considerations being taken into account in the
| development of the model is 'how does this support topic map merging
| and how should we describe that process'.

Good! I feel that this is absolutely crucial and that it _must_ be
properly described if merging is to work predictably across
implementations. 
 
* Lars Marius Garshol
|
| What I have seen so far I can only describe as a conceptual model.
| What I want is a data model.  The two are not the same.
 
* Chris Angus
|
| If by 'data model' you mean 'the model that I will use for physical
| storage' then the two are certainly not the same and nor do I think
| that they should be. 

I don't mean that, and so we agree.

| I believe that the conceptual model shouold serve two main purposes.
| Firstly it should provide a framework that allows us to more
| formally define what a topic map is, what it consists of, how it
| maps to information resources, etc. and to assist in describing the
| concepts to a reader. 

This seems to match what I want from the model I call a data model,
but it is difficult to tell, since fine nuances make a lot of
difference here.

To me it seems important that the data model should simply disregard
facts such as names being privileged occurrences and types being
privileged associations. If not, I fear that we shall end up with a
soup-like model where everything is either a link or a resource and
everyone is left totally mystified as to how this thing is supposed to
be used.

Topic maps are useful because they take the joke Entity-Relationship
model of the universe that says 'generic entity with relationship to
other generic entities' and distinguishes certain kinds of entities
and relationships. 

So while the fact that topic maps on the most abstract level only
consist of links and (references to) resources is deeply true and
useful, it is what topic maps have made out of that starting point
that is really useful about them.

So it is my opinion that we need something in between the purely
abstract 'everything is a link'-model (which is how I would describe
the currently posted conceptual model) and the physical storage schema
(EXPRESS, RDBMS, OODBMS, whatever).

I suspect that this is what you would call a logical model, but I am
not absolutely certain.

| Secondly, we should be able to define operation (such as merging
| topic maps) in terms of elements of the conceptual model such that
| for any physical implementation of the model there should be a
| mapping from the elements of conceptual model to elements of the
| physical/logical data model that allows the operations to be
| directly and unambiguously mapped and verified in that context.

Here we seem to agree: the basic operations need to be specified in
terms of the underlying model. The disagreement (if there is any)
seems to be as to what that model should look like.
 
| I think that many people involved in data modelling have paid only
| 'lip service' to the notions of different forms and levels of data
| model as laid out by ANSI/SPARC, etc.  We see conceptual, logical
| and physical data models (or whatever other terms one cares to use)
| that are almost identical.  Much of my work tends to be with systems
| where the physical data model bears little structural resemblance to
| the logical data models that map to it or to the business data
| models that are being handled.  Systems of this nature have much
| simpler underlying physical and logical data models and are much
| more robust in the face of change.

This I found very interesting.  If you could expand on it as it
relates to topic maps I would be very interested.

--Lars M.


-------------------------- eGroups Sponsor -------------------------~-~>
Create your business web site your way now at Bigstep.com.
It's the fast, easy way to get online, to promote your business,
and to sell your products and services. Try Bigstep.com now.
http://click.egroups.com/1/9183/1/_/337252/_/973589432/
---------------------------------------------------------------------_->

To Post a message, send it to:   xtm-wg@eGroups.com

To Unsubscribe, send a blank message to: xtm-wg-unsubscribe@eGroups.com