Luis J. Martinez
28 Apr 2003 11:38:03 -0400
> 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.
I don't think I use the term "data model" on my post, because I don't
know what data model means. All I am concern with is a Model, an
absraction of the concept of Topic Maps and its semantics.
> So for example,
> function topicNames(t , n) ; which matches or returns names belong to a
> 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
> The Model defines certain 'contracts of access' or 'contracts of model
> navigation' that must be supported in an implementation.
By your response above, it tells me that conformance to the model is
absolutely required. Lars, does that convinces you too that
conformance to the model is absolutely required?
Now, the issue that the SAM clearly and unambiguously define what are
Topic Maps in general terms is something else. Statements like
"Applications and users are therefore free to merge topics as they see
fit." worries me because it seems under specified. It should be clear
what has to merge. Also, there are some parts that do not seem to be
part of Topic Maps, like Locators and the SAM's use of
"reification". They seem to me like a particular solution to a
requirement. Can Topic Maps be implemented without implementing
Locators and "reification"? I think so.
Luis J. Martinez