[sc34wg3] Topic Maps land and SAM land

Jan Algermissen sc34wg3@isotopicmaps.org
Wed, 12 Feb 2003 19:03:02 +0100


Lars Marius Garshol wrote:
> 
> * Jan Algermissen
> |
> | A 'processing model' in terms of the RM is a 'deserialization
> | specification' in terms of the SAM.
> 
> Looking at the current RM draft I see that you are right. That
> disappoints me a little (I would have liked us to use consistent
> terminology, and at least have a discussion before we change parts of
> the terminology we have in common), as MB and SRN agreed to drop that
> term in Berlin, but I'll make that part of my formal comments on the
> RM and we can discuss it in that context.

Speaking only for myself, I must say that I like 'syntax processing model'
more than 'deserialization specification' (partly due to ease of typing ;-)
but I would not mind to use the latter. It also expresses (IMHO) more clearly
what is meant.

> 
> | So, all the RM is saying is this: For every syntax that a TM Model
> | defines there must be a deserialization specification that defines
> | how the syntax is to be interpeted in terms of the semantics of the
> | model.
> 
> Hmmm. This sounds strange to me. Models are models, and they are
> independent of any particular syntax. Syntaxes are syntaxes, and may
> have mappings to multiple models. So I don't really see that this
> restriction is meaningful in any way.
> 
> I guess part of the confusion here is about how the RM is intended to
> be used. It's beginning to sound rather like a set of guidelines for
> creating identity-based standards families. Is that right?

>From the Introduction:

"This Reference Model for ISO 13250 Topic Maps (RM4TM) provides a
 framework for the definitions of Topic Map Applications (TM Applications)"

I am not exactly sure what you mean by "identity-based standards families"
but I think we are somehow close. 

In the back of my head I sometimes think of the RM as 'providing a 
formalism (or language) to express all aspects of a TM model definition"
[this is clearly only my POV, but propably that helps]

The RM consist to a large part of defining that formalism (nodes, arcs etc.)
but that does not mean that the RM is 'just some graph model'. I think
that it is a good idea to focus on sections 4 and 5 because that's 
where the purpose of the RM is most explicit (I think).


> Even if it
> is I think a rule like this will have to be defined more clearly, and
> even so can't possibly be a "hard" rule, since its application will
> depend on subjective judgement.

I don't understand what you are saying, can you explain?

> 
> | I suspect that the word 'defines' causes the wrong impression that
> | the syntaxes are an essential part of the TM Model. What is really
> | meant is that in order to deserialize the information that is
> | contained in instances of a particular syntax into an instance of a
> | particluar TM Model a deserialization specification (aka processing
> | model) is to be defined.
> 
> But isn't that tautological? I mean, how could anyone fail to satisfy
> that criterion?

I think that this is (besides the naming) propably not an issue any
more. If a syntax is to be used to transfer instances of a model, 
a specifications needs to exists how to deserialize that syntax.

> 
> | I assume that this POV is not different from the SAM's, yes?
> 
> In one sense not, and in another sense it is. SAM doesn't say
> *anything* about syntaxes; it's not even aware that they exist. 
> So if
> a syntax wants to declare a mapping from itself to the SAM, that's
> fine, and if it does not, that's fine, too.

Yes, the same would hold fro the SAM expressed in RM terms. That
should be made clear in the RM I think.

> SAM is a tool that allows syntax definitions to say what they want,
> but so long as they do not violate the structural rules of the SAM
> they can say what they want.
> 
> * Lars Marius Garshol
> |
> | Well, I'm not sure the RM needs to concern itself with syntax. The XTM
> | syntax spec already does that job,
> 
> * Jan Algermissen
> |
> | Do you mean XTM 1.0?
> 
> No, I mean this document:
>   <URL: http://www.y12.doe.gov/sgml/sc34/document/0328.htm >

Ah, I missed that. Thanks.

> Which, according to the plan in N0323, is going to replace the XTM 1.0
> specification.
> 
> * Lars Marius Garshol
> |
> | I'm not sure what you are saying here. Are you saying that a SAM
> | expressed in RM terms would also need to have the XTM syntax
> | specification in it?
> 
> * Jan Algermissen
> |
> | No, no! But I agree that the RM might cause this expression and
> | should seperate the issue of TM Model and desrialization
> | specifications.
> 
> I'm still lost, sorry. The "RM might cause" what? 

Argrrrg. I just meant to say:  The current wording of the RM might
cause that *im*pression and that the prose should be changed to be
more clear.

Sorry for the typo.

Jan



> And doesn't it
> already consider a TM model to be something different from a
> deserialization specification? I'm not trying to be difficult, but you
> assume I know more about what the thinking behind the RM is than I
> actually do.
> 
> --
> Lars Marius Garshol, Ontopian         <URL: http://www.ontopia.net >
> GSM: +47 98 21 55 50                  <URL: http://www.garshol.priv.no >
> 
> _______________________________________________
> sc34wg3 mailing list
> sc34wg3@isotopicmaps.org
> http://www.isotopicmaps.org/mailman/listinfo/sc34wg3

-- 
Jan Algermissen                           http://www.topicmapping.com
Consultant & Programmer	                  http://www.gooseworks.org