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

[Robert Barta]

On Fri, Apr 18, 2003 at 09:06:29AM -0400, Patrick Durusau wrote:
> >This is a perfectly valid while arbitrary
> >decision. If my goal would be to create a generic infrastructure for
> >Topic Map based information and I plan, of course, to allow queries
> >against the infrastructure, then my choices might be (and will be)
> >totally different.
> >
> Question: In what way would you choose differently, based on your 
> current understanding of N393 vs. N396?

Patrick,

OK, both SAM and TMM are for me 'deserialisation techniques'. This
means that if I have an instance X in XTM (or some other
serialization/syntax) that both """""models""""" (mind the quotes :-)
define ANOTHER syntax, this time an abstract syntax. The structure is
defined via a set of constraints.  These, for instance, define that a
topic might have a number of characteristics together with a scope.

This has NOTHING to do with semantics yet. The structure yet is like a
Rorschach test: Everyone can look at it and can guess what it means.
It is like the relational DB example we discussed earlier: If I give
you a table definition

  +-----------+----------+
  | FirstName | LastName |
  +-----------+----------+
  |           |          |

then maybe *you* think that I have a DB about people. I fooled you,
actually I store XY coordinates about my next bomb targets. Clever, is
it not? This is exegesis where people guess from names and prose text.

Only if I define operations on this structure, then I introduce formal
semantics. Both models do this to a certain extent as they define what
a "fully merged map" should look like. So both implicitely define an
operation:

   "fully merged map" + "new topic" -> "another fully merged map"

*This* introduces the meaning of the structure to a machine and this
can be used for implementation: "All implementations have to behave
the same in this respect".

But this is only for implementing a 'deserialisation'. Did you see
anything about querying or constraining? To do that, the
"""""model""""" would have to define another operation:

   "fully merged map" * constraint -> {yes, no, maybe}

or

   "fully merged map" * query      -> "query result"

Neither of the deserialisation standards have this and this was
obviously not their goal.

> Sorry, need to know a little more about how you are using "semantics of 
> the data structure." In my use of "semantics" I could certainly define 
> the "meaning" of data in a location in the table, the "key" field for 
> example, without resorting to update or retrieval functionality.

This may be the way to "indicate" a meaning to a human who is used to
all sort of things on this planet. If you simply introduce a field X
of type integer into a DB schema this has no meaning at all except
that the values have to be integer. We humans - and especially the XML
world - is using tags (=labels) to indicate an "intended
semantics". This is good enough for a programmer but worthless for a
formal treatment.

> (We may be seriously missing each other here, as is common in 
> discussions of semantics and syntax. If so, let's try again.)

For me (probably biased by a rather mathematical education)

  syntax:     arrangement of symbols to build expressions, structures
              (XML, CXTM, LTM, AsTMa=, 90% of SAM and TMM)

      e.g. the string "2 + (3 - 1)"

  semantics : operations (or equality constraints) on the expressions
              (10% of SAM and TMM)

      e.g. "a + b     is the same as     b + a"
            1 + 1     is the same as     2"

> Hmmm, I would agree that relational calculus defines operations (I read 
> that as expressions) but that may or may not be semantics. You could be 
> using relational calculus to define valid expressions, which I take to 
> by a syntax issue. Does not say what the expression means (semantics) 
> but rather that it has the proper form (syntax).

The relational _calculus_ (it is actually rather outdated) also
defines the _meaning_ of the operations _relative_ to the
expressions. So, for example,

  project_A ( project_B (T) ) = project_B ( project_A (T) )

says that it does not depend on the sequence how projection (selecting a
column from a table T) is done. Other rules describe the outcome of

  selection_predicate (T) = .... is table with blabla selected ....

> As I noted in my first post and above, the TMM (N393) was never intended 
> to build the framework you are seeking but to lay down the rules for 
> building such an infrastructure. It defines the semantics of topic maps 
> and provides a syntax that allows conversation with great precision 
> about those semantics.

Yes, you precisely rephrase my earlier statement.

> For the TMM (N393) you would have to be saying that it does not allow 
> the construction of the infrastructure you are seeking. In order to 
> evaluate or respond to that statement, it would be necessary to know 
> what sort of infrastructure you are seeking to build.

Let's turn the question around:

What infrastructure does TMM offer to define a language which qualifies
against the requirements

   http://www.isotopicmaps.org/tmql/
   http://www.isotopicmaps.org/tmcl/

? Or more specific: Have a look at the formal semantics based on
maplets in

   http://astma.it.bond.edu.au/astma!-spec.dbk?section=4

Can you find TMM concepts in there? You earlier said that all this is
a "TMA" and is outside the scope (= orthogonal) of TMM. You see my
problem? (Hope this somehow makes sense).

I have only vague ideas how this can be done, but - as I said - I did
not spend any thinking on that yet.

\rho