[sc34wg3] Conformance

[Robert Barta]

On Sun, Apr 27, 2003 at 03:43:34PM +0200, Jan Algermissen wrote:
> What I am up to is to find the purpose that this structure
> fulfills.

Jan, 

I think it is quite simple:

  1) you create some implementation of what you think is a TM
     implementation, in that you create your databases, internals,
     whatever

  2) to "prove" that your application is "SAM conformant" you simply
     define a mapping of concepts of SAM (and operations if we had
     those) onto your API (or your API concepts).

[ Hope I got it right in this abridged form ]

More technically speaking you define a homomorphism 

    SAM |-> (your API)

> Since it does not make sense to use it to constrain the
> internals (I could create an implementation that never actually
> performs a merge internally but makes it look as if it did from the
> outside)

True, but it will be more difficult to fool the outside if I ask your
application to round-trip an XTM document.

> then what is it good for (not the SAM as a whole, just the data
> structure)?  Is it purely a matter of providing a language to 'say'
> the important stuff (e.g.  merging rules)? Is it purely
> illustrative?

Here I may refer to the discussion we started at

   http://www.isotopicmaps.org/pipermail/sc34wg3/2003-April/001517.html

> To take this out of TM context: What purpose does the entity
> relationship model fulfill in RDBMS land?

[ Warning: academic discussion ahead, can be safely skipped ]

The ER-model plays the role of the "conceptual model" there. More
specifically it is a formalism which allows you to define statements
about your data:

  - this attribute has to be in this entity (maybe add a type)
  - this entity has that primary key (depends on the flavor of ER)
  - these entities have to have such-and-such n:m relationship

So the basic concepts are Es and Rs and the (application) designer is
using this vocabulary to formalize his data.  This comes with quite a
few limitations (people like limitations, actually, so this is maybe
the reason why it is so popular): You can't, for instance say,

  "for all time, changes in employee's salaries can only be positive"

or

  "the average salary of the group manager must always be at least
   as high as the taxable deduction according to...."

So it is a formalism, and limited.

TMM, or actually the concepts behind, could be such a model for TMish,
RDFish and other data. IF it has some more stringency (read
formalism). If not, then it may be a nice "data framework", but that's
about it.

\rho