RE: [xtm-wg] XTM processing model issues

["Jean Delahousse" <jean.delahousse@mondeca.com>]

Hello,

> 2) I am concerned that the descriptions of t-nodes, a-nodes,
> s-nodes etc are
> more about implementation than about meaning of information. I do not
> believe we should be standardising any particular implementation approach.

I agree with Daniel on that point. I didn't really understand the s-nodes. I
am ok on t-nodes and a-nodes that are both nodes but aren't of the same kind
and have some specific properties. But I believe s-nodes are just t-nodes
from an other level in the topic map.

For example "vocal music" is a t-nodes in the conceptual part of the topic
map. This topic may be related by an a-node to th t-node "lyric music". At
the same time the t-node "vocal music" is used as a theme for all the
t-nodes representing "records" with "vocal music" in a part of the topic map
where records, composers and interperters are related.

May be I missed a point, but I think it's easier to keep just t-nodes and
a-nodes and to make a clear explanation of the different levels you can find
in a topic map (see Bernard Vatant's paper on his web site), where t-nodes
from one level are also used to make classification of t-nodes on a lower
level.

Sincerely

By the way : Topic Navigator (avaible finally tomorrow for a 3 weeks testing
process) has collaborative editing features usable with a simple browser -
we'll work in january on the XTM output so we also can deliver and exchange
topic maps with the other products.

Jean Delahousse
CEO Mondeca
Mobile : +33(0)6 16 90 73 95
Tel : +33(0)1 47 46 18 89
Fax : +33(0)1 47 46 01 09
www.mondeca.com

> -----Message d'origine-----
> De : Daniel Rivers-Moore [mailto:daniel.rivers-moore@rivcom.com]
> Envoyé : mardi 19 décembre 2000 18:50
> À : xtm-wg@egroups.com
> Objet : [xtm-wg] XTM processing model issues
>
>
> I said I would provide some comments on the XTM Processing Model document.
> My main concerns are two:
>
> 1) The XTM processing model document states: "The XTM Processing Model
> requires that a topic map graph be constructed from a <topicMap> element,
> before any other processing is done."
>
> I believe this constraint is out of place. It places an unnecessary
> limitation on applications. "Lazy" processing *must* be allowed if TM
> applications are not going to be grounded by performance limitations.
>
> What needs to be specified is what the meaning of the information
> carried by
> an XTM instance is - not *how*, and still less *when*, an application must
> derive that meaning from the structure and cpontent of the instance.
>
>
> 2) I am concerned that the descriptions of t-nodes, a-nodes,
> s-nodes etc are
> more about implementation than about meaning of information. I do not
> believe we should be standardising any particular implementation approach.
>
> What we do need to do is explain rigorously how the syntax maps to the
> conceptual model, particularly where there is not a one-to-one
> correspondence between the constructs in each. This will include
> specifying
> the "merging rules" that determine when multiple elements in XTM instances
> represent a single topic, association, role etc. It will also include
> specifying what constraints result when an association is stated to be
> derived from an association template. But those constraints should not be
> described in terms of what should exist in the system after processing.
> Rather, it is a constraint on the information set itself.
>
> For example: if I have a template for marriage where the class of
> permitted
> players of the role "husband" is the "man" class, this means that
> there must
> exist a class-instance association between the husband in the marriage and
> the class of men. My XTM instance may or may not make that association
> explicit. If it is not explicit in my instance, I may wish the application
> to signal to the user that there is doubt as to the player of the role
> husband because he is not stated to be a man, or I may wish to allow the
> appication to infer that he must be a man and create the association
> automatically. These are application-dependent issues. The meaning of the
> information is what we should be stating in the specification, not the
> processing details or processing sequence.
>
> Having said this, it can be very useful to describe a processing
> model as an
> informative example of a possible and legitimate approach. My concern is
> that we should not state that using this processing model is a
> condition of
> XTM conformance. Such a description of a processing model should
> not be part
> of the XTM Specification itself, unless it is explicitly stated to be
> "informative" rather than "normative".
>
> On the other hand, I believe we do need a *normative* but
> *processing-neutral* description of the merging rules and template
> constraints, and I believe this has not yet been written.
>
> Do others have views on this?
>
> Best regards
>
> Daniel
>
>
> To Post a message, send it to:   xtm-wg@eGroups.com
>
> To Unsubscribe, send a blank message to: xtm-wg-unsubscribe@eGroups.com
>
>


-------------------------- eGroups Sponsor -------------------------~-~>
Big News - eGroups is becoming Yahoo! Groups
Click here for more details:
http://click.egroups.com/1/10801/0/_/337252/_/977260972/
---------------------------------------------------------------------_->

To Post a message, send it to:   xtm-wg@eGroups.com

To Unsubscribe, send a blank message to: xtm-wg-unsubscribe@eGroups.com