[sc34wg3] Individual contribution on the U.S. N.B. position o nthe progress ion of Topic Map standards

[Robert Barta]

On Sat, Apr 03, 2004 at 01:52:43PM +0200, Jan Algermissen wrote:
> Robert Barta wrote:
> 
> > I appreciate the approach many people have to first define a data
> > model to somehow capture the information they have in mind. This is
> > what RM/SAM/TMDM all try to do with varying degree of ... elegance.
> > But to define what a data structure really "is", it's meaning, the
> > whole gist of it, you can _only_ do with ..... operations.
> > 
> 
> IMHO, the data model is what enables you to reason about operations.
> If you do not know about the notion of 'topic' and that topics may have
> properties (no matter whether TMDM or RM) there is no way to talk about
> operations on topics and properties.

Jan,

No. A 'thing' can also be defined solely via its interaction with the
environment, not by its internal structure. Maybe as a C, Java,
etc. programmer one is trained to think in data structures at an early
stage, but in the formal specification world things like process
algebras or abstract data types are exactly that: abstract.

   http://en.wikipedia.org/wiki/Abstract_data_type

> In your stack example, the data model is (in a broad sense) object
> orientation:

No, no object orientation involved. No hidden strings. No fluff.
No rabbit in my hat :-)

> you know you can represent a stack as an object and that you can invoke 
> methods on it. You know that objects have identity etc.
> So, no operations without a data model.

Nope, not true, unless you regard expressions like

   pop (push (S, a))

as a data model (which it sort of is).

> What I think (and I think this is what you actually refer to) is
> that there must not be anything in the data model that goes beyond
> the basics that enable to talk about the 'operations'.

As I said, formally I do not need a specific data model to define what
a TM is. I appreciate, though, that for that army of programmers out
there a data model is something they can clinge to. And splitting something
it more manageable parts also may be helpful.

I agree with you that this data structure should not be in the way of
defining operations, so should stay abreast from too much (implicit or
explicit) 'semantics'. After all, a data model itself is nothing else
than a syntax anyway. A multi-dimensional syntax with a lot of more or
less strange rules which constrain it.

That there are occasionally 'properties' which allow nothing else than
to be read or written to, does not tell me anything _what_ the whole
thing is.

> [1] Off thread (trying to explain rather to start a fight): These
>     additional or inherent semantics are exactly the difference between the
>     two camps (RM vs TMDM). IMHO, the semantics are harmful because they
>     complicate the model and hide the structural essence that the RM is
>     trying to find (or hopefully has found). 

Yes, for an agnostic the discussion between catholics and protestants
may be rather mute :-)

\rho