[sc34wg3] Documenting merging rules in TMDM .. and unmerging too

[Lars Marius Garshol]

* Michel Biezunski
| 
| I was referring to the distinction Bernard makes between declarative
| semantics (subject identification) and operations (merging, mapping,
| etc.)

I think that distinction is useful, especially from a conceptual point
of view, since it makes the discussion much clearer.

Personally, I think TMDM makes the declarative semantics clear through
specifying operations, though it does not *require* the operations to
be implemented as described.

The requirements on implementation happens only at the point where
some ancillary standard binds to TMDM. So CXTM, for example, requires
that you produce a single <topic> element for each TMDM topic item,
but how many objects/nodes/structs/rows/whatever that maps to inside
an implementation is none of our business.

So an implementation can still do what it wants.

Similarly when TMQL/TMCL are ready. The implementation will be
required to provide results based on the declarative semantics, but
again, how it does that is not our business.

So I think we already support both in TMDM itself. For TMAPI the
situation is less clear, but that's a TMAPI issue, not a TMDM issue.
 
| I am referring to the fact that Topic Maps is supposed to be an
| information standard helping information owners to describe what
| their information is about (subjects) and how various pieces of
| information are connected together (typing, associations,
| occurrences, scopes, etc.)
| 
| The purpose of the standard as I see it is to declare what
| the information is, and leave the possibilities wide open
| for any kind of processing to be performed. 

Ah, I see. Yes, I definitely agree that this is a goal that we should
aim for. I also think that the current TMDM draft meets this goal,
though I can't tell whether you agree or not.

| This is similar to SGML and XML which don't say what you should do
| with the information, but simply what the information is so that it
| can be used.

Yep.
 
| If we are able to make this distinction work for topic maps, I think
| we are heading for the long term. 

I agree.

| This means that the standard should be kept independent from any
| processing techniques applied on the pieces of information. 

Any specific techniques, yes, though I don't think that we can be
completely independent of *any* processing. That would be the same as
saying: "here's the syntax; do anything you want with it", which I
don't think is acceptable.

| For example, the constraint and query languages don't necessarily
| need to be present for an application to present itself as topic
| maps. Same thing as not requesting XSL or XQuery to be present to
| claim for XML compliance.  That's the kind of things I am referring
| to.

Oh, I fully agree, but the current draft doesn't say that either, nor
has anyone suggested that it should, as far I know.
 
| Let me know if this is clearer.

Definitely!

-- 
Lars Marius Garshol, Ontopian         <URL: http://www.ontopia.net >
GSM: +47 98 21 55 50                  <URL: http://www.garshol.priv.no >