[sc34wg3] N0391-0394: New SAM/XTM documents
Robert Barta
sc34wg3@isotopicmaps.org
Mon, 21 Apr 2003 17:05:33 +1000
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