[sc34wg3] N0391-0394: New SAM/XTM documents

[Robert Barta]

On Sun, Apr 20, 2003 at 09:33:55AM +0200, Jan Algermissen wrote:
> I still have a hard time to expand my understanding of syntax to include
> what you (and Jim Mason) have been talking about. Does it mean that
> any structure (including abstract ones) is syntax?
>....
> To be sure I get it: Is any graph neccessarily syntax then?

A graph G is a mathematical structure (yes, syntax so far):

  G = < V, E >

with V a set of nodes (vertices) and E <= V x V a set of tuples
interpreted as the edges between the nodes.

The reason why I write this definition is that a "set" is an algebraic
structure which ALREADY HAS a semantics. We know what the operations
are:

   SET + ELEMENT
   SET - ELEMENT
   SET1 union SET2
   ...

So sets are a structure but they have a semantics as they have well
defined operations. This also means that the graph (which is built
from sets) has some semantics, although it is not a very rich one.

What is necessary is for instance to define

   GRAPH + NEW_NODE = ???
   GRAPH - NODE     = ???
   GRAPH1 + GRAPH2  = ....

   GRAPH * GRAPH ....

The more operations an algebraic structure has the more 'semantics' it
has. (Well, hope my algebra professor is not reading that).

> Hmm, what matters is that (regardless of the actual structure) a system
> can provide a 'view' on the topic map that is equivalent to the one described
> in the TMM. But this is syntax too, right? (The fact that TMM describes an
> abstraction does not matter, yes?)

Yes, rightly so.

> Essentially a topic map (not only in TMM) consists of proxies for subjects
> and connections between them, so I guess a topic map is allways syntax, right?

So I think, yes.

> Now the question is for me, what is missing in TMM?
> 
> Right now, the TMM defines the semantics of all the components of
> a real-world relationship (the definition of the assertion structure).
> What else should it define regarding semantics?

   Given a TM and a constraint C: What is the result of applying the constraint?
   Given a TM and a query Q: What is the result of the application?
   Given a TM and another TM': What is the reuslt of merging?
   Given a TM and an update U: What is the result?

But this is - obviously - connected with what languages we will use
for this. And this is exactly my point: I cannot see how TMM/SAM can
host infrastructure for something where we have not decided what it
should do.

I might be wrong here, but my gutt feeling tells me that including
this into the discussion now would be to put the cart before the
horse. I would feel much better if we would concentrate on the (a)
'simple processing conformance' now and do a revisiting how SAM/TMM
correlate with the query processing model (b) later.

In many cases applications will only need (a) for the time being,
anyway, I would guess. And: The simpler (a) is, the better the chances
to harmonize it with (b).

\rho