[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [xtm-wg] XTM processing model issues
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC