[sc34wg3] Conformance

[Graham Moore]

Hi Luis,

The SAM doesn restrict you to any one kind of implementation. As you say its
the data model for topic maps. This can be implemented in many ways - and
has been. What the model conveys is that regardless of how you store or
provide access to the topicmap model there are functional constraints. The
model communicates what those functional constraints are.

So for example,

function topicNames(t , n) ; which matches or returns names belong to a
topic

is expressed in the SAM by saying using the infoset notation that a Topic
has many names.

The SAM defines what relationships extist between things in the model.
Comformant applications must honour those relationships. It doesnt matter
how they do it.

There are some other things like,

The Model conveys that if you pose the question 'give me all the names
associated with a topic' that there wont be any occurrences in the result
set.

The Model defines certain 'contracts of access' or 'contracts of model
navigation' that must be supported in an implementation.

gra

--------------------

Graham Moore, Ontopian               <URL: http://www.ontopia.net >
GSM: +44 (0) 7769658611             moore@ontopia.net

----- Original Message -----
From: "Luis J. Martinez" <luisjm@luisjm.com>
To: <sc34wg3@isotopicmaps.org>
Sent: Monday, April 28, 2003 1:18 AM
Subject: Re: [sc34wg3] Conformance


>
>
> * Jan Algermissen
> ...
>
> > Clearly, there are portions of both, N0393 and N0396 that do make sense
> > to constrain applications (e.g. merging behaviour, value equality...),
> > but what is the purpose of the conceptual data model? We need it, sure,
> > but what for?
>
>
> I think the purpose for a model for Topic Maps is to describe what is
> the abstract structure of Topic Maps, a description to all components
> of Topic Maps, and to describe the functional properties of Topic
> Maps, period.
>
> The main point is to clearly describe what valuable functionalities
> Topic Maps provide. The implementation specification is not necessary
> under the standard process. Implementation details should be completely
> left up to developers. That is way it is so important to describe
> clearly the abstract structure of Topic Maps and it semantic
> properties in general terms.
>
> For example. The abstract data structure binary search tree can be
> implemented as a double link list instead of a tree structure as long
> as it follows the prescribed semantics for a binary search tree. My
> point being that as long as the operation results are correct, it does
> not matter what the implementation looks like. Of course, it is useful
> to have a standard interface, but that is just a convenience detail.
>
> I think that the SAM is distracted with specifying implementation
> details. If the SAM purpose is to derive interfaces like XTM, HyTM,
> TMAPI, then fine, no need to conform to the SAM. Just those
> interfaces. But the implementations behind the interfaces have to
> conform to the semantics of Topic Maps. I think those Topic Maps
> semantics should be specify independently of interfaces. I think the
> SAM is try to accomplish two goals simultaneously.
>
> I think the Model should answer "What is Topic Maps and what value it
> provides?" not "How to represent Topic Maps with a particular
> technology?"
>
> Luis
> _______________________________________________
> sc34wg3 mailing list
> sc34wg3@isotopicmaps.org
> http://www.isotopicmaps.org/mailman/listinfo/sc34wg3
>