[CLS Framework]

TTT Homepage
CLS Framework
Introduction
Section map
Overview
Applications:
  ·Representation   ·Design
  ·Sharing
ISO 12620 data categories
Downloads
XML information

Copyright © 2000
Translation Research Group
Send comments to comments@ttt.org
Last updated: January 27, 2001
Backward Contents Forward

MARTIF - Putting Complexity in Perspective


4. Negotiated Interchange vs. Blind Interchange—Multi-level Solutions


One ongoing concern in the MARTIF development team has been the question of normative rigor. As noted above, MARTIF was originally designed for so-called negotiated interchange, (MARTIF Level I), where partners examine each other's data before interchange and make decisions about preconditioning the data before importing it from the interchange format. This approach reflects the notion that an interchange format should be able to accommodate all or almost all-existing database structures without imposing standardization on specific systems. It places the primary effort for interchange on the import rather than the export level.

This approach allows for a high degree of freedom and flexibility in individual applications, which some standardizers find disturbing. They would rather displace the effort to the other end of the spectrum, imposing a higher degree of normalization with respect either to the source database structures or at least to the export product from these systems. In response to these concerns, researchers in the US development team have developed and successfully tested a full prototype for a blind interchange DTD based on the existing DTD for negotiated interchange. Testing involved developing a single routine for converting data to and from DANTERM, TERMIUM, and MultiTerm (Hardman 1996; Melby and Hardman 1996).

This second strategy for interchange would enable exchange partners who had agreed to conform to certain specific criteria to import each other's data without prior examination. Such a scenario would require that exchange partners subscribe to a stricter entry layout and, in the case of some data categories such as subject field, gender, etc., to adopt harmonized content options. The blind interchange option may even impose the requirement that database operators change their local data structures and content in order to participate in interchange. Concerns related to the development of a blind standard have been treated in other contexts and will not be the focus of this article (Wright 1996; Hardman 1996).

Experience derived from working with the provisional blind interchange DTD would indicate that, rather than dealing strictly with a bipartite system featuring negotiated interchange on the one hand and blind interchange on the other, it would be more productive to think of a differentiated approach whereby negotiated interchange represents one end of the spectrum and fully blind interchange the other extreme, with at least one other intermediate level featuring graduated degrees of relative "blindness". This scenario features three levels of MARTIF:

  • Level 1: negotiated MARTIF as defined m the current standard
  • Level 2: partially blind
    At this level certain imprecisions in the data category set would have to be resolved, specifically with regard to granularity, modeling variance, and the content of permissible instances. Cooperating work groups adopting MARTIF Level 2 would also specify the subset of MARTIF data categories used in their environment.

    Granularity indicates the degree of fine detail included in a database for a given data category. For example, in the case of abbreviated form of term, the current standard offers two options for reporting information, either to use the broader category <termNote type='termType'>abbreviated form</termNote> or to select the more specific permissible instances, i.e., abbreviation, initialism, acronym, short form, etc. At this level 2, one of these options would have to be specified as required.

    The current standard also provides for variation in data modeling practice. For instance, in the case of subject field, there is the possibility to use either <descrip type='subjectField'> or <descrip type='subjectFieldlevelx'> where "x" represents a number from 1 to 9. At Level 2, only the latter, more informative option would be allowed. In systems where only one subject field level exists, the notation would be <descrip type='subjectFieldLevel1'>.

    Here too, precise content of data categories not defined in ISO standards 12620 and 12200 would be specified. For instance, in the case of "grammatical gender", it is not enough to say that "masculine, feminine, neuter, other" are the acceptable values, but rather that specific forms of these values ate required, for example: m, f, n, o. At this level, no attempt would be made to normalize subject field, thesaurus, and classification systems.

  • Level 3: totally blind
    In addition to agreement on all items listed above, this level would require the use of specific subject field, thesauri, and classification systems either at a universal or domain-wide level. At this level, the only non-specified data fields would be free-text fields such as terms, definitions, contexts, and various kinds of notes. Example for universal classification: Universal Decimal Classification (UDC)

    Example for domain-wide thesaurus (medicine): SNOMED or MEDDRA

    For standardization at this level, a registration office should be established in order to; register domain-specific systems.

Further development of MARTIF exchange levels depends on detailed experimentation in the area of data interchange and continued cooperation among those interested in importing and exporting data. One important principle is that although terminology experts can offer solutions at the first two levels, only subject-area specialists will be able to agree on the systems required at Level 3. As evidenced by the example from medicine, the motivation for accepting a single classification model in any given field will no doubt be market driven and will reflect the urgency with which a given sector approaches the data exchange environment.

Backward Contents Forward

 

 

| Return to ttt homepage | Introduction | Section map | Overview |
| Applications: Representation; Design; Sharing |
| ISO 12620 Data Categories | Downloads | XML info |