[Mirrored from: http://www.personal.u-net.com/~sgml/topicmap.htm]
In May 1996 the ISO committee responsible for SGML and its related standards approved a new work item to develop a set of architectural forms for the definition of topic navigation maps.
Work on topic navigation maps has been undertaken since 1994 by the Committee for the Application of HyTime (CApH). The CApH draft text has been taken as the basis for the first committee draft (CD) of this new ISO standard, which is currently being ballotted by national standards bodies. Annex B shows the text submitted for review. A revised draft of the text, based on the new HyLink architectural form is provided below.
While the CD issued with the new proposal on the development of SGML applications for the development of Topic Navigation Maps provides a starting point for work in this area The SGML Centre feels that there are a number of functions that need to be added to the specification before it becomes an approved standard. These include:
This standard provides a mechanism, based on techniques defined in ISO/IEC 10744:1992, for identifying information objects that share a common topic. It can also be used to define the relationships between sets of related topics. This standard can, for example, be used to define:
This standard provides facilities for creating, maintaining and interchanging topic-based navigational aids to large corpora of documents containing interrelated information. The standard makes a distinction between the highly concentrated and independent topic navigation maps -- sets of relations between the topics covered in a given corpus -- defined within this standard and the addresses of relevant information within the corpora themselves, which are defined using facilities provided by ISO/IEC 10744, which defines the Hypermedia/Time-based Structuring Language known as HyTime.
Topic navigation maps can improve the accessibility of information by facilitating, and to some extent automating, the task of providing, and imposing editorial consistency and maintainability on, navigational resources. Topic navigation maps are designed to simplify groupware-supported production of data for which navigational aids such as indexes, glossaries, tables of contents, lists and catalogs need to be generated. Topic navigation maps can also be used to enhance the navigability of very large information bases.
This standard provides an SGML architecture, defined according to the rules specified in the SGML Extended Facilities annex of ISO/IEC 10744, for creating and maintaining data that classifies information in documents according to topic, and classifies topics with respect to each other. The standard will help to increase consistency, and decrease redundancy, not only in navigational aids within documents, but also in navigational aids used with multiple documents, such as master indexes. The discipline that can be imposed by using the facilities provided in this standard will assist those who create and/or collect libraries of documents, and who wish to provide a given collection with a unified, consistent, and minimally redundant topic index.
The Standard Generalized Markup Language (SGML) defined in ISO 8879:1986 allows all kinds of documents to become databases. By providing ways to navigate data stores so that parts of documents that are relevant to a particular topic can be easily found and organized rapidly by machine, this standard augments the suitability of SGML for electronic document interchange. The number and complexity of indexable topics, and the relationships between them, greatly exceeds the number and complexity of relations normally represented in traditional databases or, for that matter, in the kinds of indexes normally found in books. The number of topic relationships that might usefully be represented with respect to any reasonably large collection of documents is, in fact, for all practical purposes limitless. Moreover, even in archived documents, new kinds of topic relationships can be expected to appear from time to time. This standard, therefore, is specifically designed to allow multiple topic maps to be created over a period of time for any collection of data,and to allow for different topic maps to be inter-related.
Creating and maintaining indexes can be a difficult and expensive proposition. Many indexes are indexes in name only. All too often, even when an index is well thought out, well constructed, and useful, little thought is given to its maintainability. When the time comes to create an updated or corrected index, the original documentation for the topic architecture of the index is no longer available. Indeed, it may never have existed or have been consciously expressed in any abstract way. Even an index on which enormous maintenance effort has been expended can quite easily become self-inconsistent, especially when the size of the indexing task dictates that it must be a cooperative effort, or when there have been changes in the responsible personnel.
An application-neutral, internationally understandable, rigorous, and yet flexible and open way to represent topical indexes, such as the one set forth in this standard, can help to make indexes easier to make, easier to maintain, and easier to use. Creating a topic navigation maps is a complex task, similar to planning and building a building, involving myriad assumptions and artistic decisions. As new relationships are discovered and included as part of a topic architecture, the architecture changes. Many specialists may have to collaborate and contribute, over a number of years, to an evolving topic navigation map, which at any given time must unambiguously and comprehensibly govern all maintenance activities. Unless those who are adding and/or maintaining anchors have clear guidance, the instantiation of that topic navigation map -- the index itself -- may become unsound and unsafe.
A topic navigation map defines both topics and the relations that they bear to one another. It must, therefore, permit:
to be represented, universally interchanged, processed, merged, and used for data navigation. An international standard for representing (among many other things) arbitrary relationships between arbitrary pieces of information wherever they are in situ, exists in ISO/IEC 10744. This standard uses a HyTime-based approach for linking topics with information, and an SGML architecture is defined that can support applications that provide:
Topic navigation maps are defined using TNM.SemanticAssignment-form elements whose roles are defined by the user, and TNM.TopicRelation-form elements that identify specific relations between topics. Categories of topics may be iteractively identified and described by linking suitable topics to other topics belonging to the category.
A topic map is created by linking, using HyTime hyperlinks, several pieces of information about a topic through a semantic assignment. Each semantic assignment has an anchor role (anchrole) attribute that defines the relationship between a topic and the references that are made to it. The first anchor role identified by the anchrole attribute provides a formal definition of the topic. This notion of definition is very general: a definition can be any portion of information (no specific internal structure needed) that describes the information being pointed to.
This clause formally defines the enabling architectures required to implement topic navigation maps. It is defined using the specification for Architectural Form Definition Requirements in the SGML Extended Facilities annex of second edition of ISO/IEC 10744:1992. The meta-DTD defined by this document starts, therefore, with a (non-processable) markup declaration of the form:
<!AFDR "ISO/IEC 10744:1992">
The SGML declaration accompanying a document containing a topic
navigation map shall include the token ArcBase in
its APPINFO field to indicate that details of the
SGML architectures for which support is required will be found
in processing instructions starting with the (default) ArcBase
keyword. If another name is required to identify applicable processing
instructions it can be specified, as part of the same token, by
using the form ArcBase=ArcUsed.
An SGML document type definition (DTD) that uses the facilities
defined in this standard shall contain, as near to the start of
the DTD as possible, a processing instruction coded using the
document's concrete syntax, whose contents are ArcBase TNM
HyTime where ArcBase is the name assigned
for identifying architectural bases in the APPINFO
section of the SGML declaration associated with the DTD, TNM
is a mnemonic used throughout this standard to identify components
of a Topic Navigation Map and HyTime is the name
of the base architecture from which topic navigation maps are
derived..
A DTD that uses the facilities defined in this standard shall contain the following SGML notation declaration and architectural support attribute definitions based on the template shown below, modified if necessary to conform to the concrete syntax defined in the associated SGML declaration:
<!NOTATION TNM PUBLIC "ISO 13250//NOTATION AFDR ARCBASE
Topic Navigation Map
Architecture Definition Document//EN"
-- A derived architecture used in conformance with the
Architectural Form Definition Requirements of
International Standard ISO/IEC 10744. -->
<!ATTLIST #NOTATION TNM
ArcFormA NAME #FIXED TNM
ArcVer CDATA #FIXED "ISO 13250:1997"
ArcNamrA NAME TNM-name
-- Can be used to assign locally
meaningful names to TNM attributes --
ArcDTD CDATA #FIXED "%TNM-DTD"
--Fixed within application DTD --
ArcDocN CDATA "TNM-hub" >
The DTD must also contain the following entity definition, which is referenced by the architecture support attributes:
<!ENTITY % TNM-DTD -- Meta-DTD for this DTDs instances --
-- THIS ENTITY IS NOT TO BE REFERENCED! --
PUBLIC "ISO 13250//DTD Topic Navigation Map meta-DTD//EN">
In addition support must be declared for at least a minimal set of HyTime functionaliy by including the following declarations:
<!NOTATION HyTime PUBLIC
"+//ISO/IEC 10744:1992//NOTATION
HyTime Architecture Definition Document//EN" >
-- A base architecture conforming to the
Architectural Form Definition Requirements of
International Standard ISO/IEC 10744. --
>
<!ATTLIST #NOTATION HyTime
-- Support attributes for all architectures --
ArcFormA -- Attribute name: architectural form --
-- lextype(ATTNAME) --
NAME #FIXED HyTime
ArcVer -- Architecture version identifier --
CDATA #FIXED "ISO/IEC 10744:1992"
ArcNamrA -- Attribute name: attribute renamer --
-- lextype(ATTNAME) --
NAME "HyNames"
ArcDocN -- Architectural form name: document element --
NAME "HyDoc"
ArcBridA -- Attribute name: bridge functions --
NAME "HyBrid"
ArcFacN -- Attribute names: architecture facilities --
-- lextype(ATTNAME*) --
NAMES #FIXED
"base locs links"
-- Support attributes for
Topic Navigation Maps only --
hyqcnt -- Highest quantum count ceiling --
-- Constraint: power of 2 >= 32 --
NUMBER "32"
base -- ArcFacil: Base module --
-- lextype(NMTOKENS) --
CDATA "" -- Default: no options --
locs -- ArcFacil: Location address module --
-- lextype(NMTOKENS) --
CDATA #IMPLIED -- Default: no support --
links -- ArcFacil: Hyperlinks module --
-- lextype(NMTOKENS) --
CDATA #IMPLIED -- Default: no support --
sched -- ArcFacil: Scheduling module --
-- lextype(NMTOKENS) --
CDATA #IMPLIED -- Default: no support --
rend -- ArcFacil: Rendition module --
-- lextype(NMTOKENS) --
CDATA #IMPLIED -- Default: no support --
manyaxes -- Maximum number of axes allowed in coordinate spaces --
NUMBER #IMPLIED -- Default: no limit --
>
<!--Questions for Eliot:
1) Why does this notation attribute list not have an entry for ArcDTD
in 10744?
2) How are you now supposed to indicate which facilities from the
SGML Extended Facilities annex must be supported for the
architecture to work (e.g. dvlist, lextype, context)?-->
<!ENTITY % HyTime -- Meta-DTD for this DTDs instances --
-- THIS ENTITY IS NOT TO BE REFERENCED! --
-- This example declares the HyTime facilities
that must be supported when a Topic Map is
being defined. --
SYSTEM CDATA HyTime [
hyqcnt=32
base="unparsed" --?is this still available?--
locs="anydtd anysgml grovplan grovedef
pgrovdef agrovdef HyLex exidrefs
multloc spanloc refctl query
coordloc pathloc relloc bibloc"
links="manyanch" -- but not ilink --
sched="dimref" --?should markfun and HyFunk be required?--
]>
Editor's Question: Is the above list too complex: should any options be removed (or added)?
A topic navigation map is necessarily a HyTime hub document. [Editor's Question: Is this necessarily true? For example, the TEI example in Annex A would suggest that there may be a case for allowing topic navigation maps to form part of a larger document.] As such the base document element of the topic map must be conform to the following architetural forms:
<!-- HyTime Topic Navigation Map Document Hub -->
<!entity % loc -- Location address architectural forms --
"bibloc|nmsploc|nameloc|treeloc|listloc|relloc|dataloc|proploc|queryloc"
>
<!entity % link -- Hyperlink architectural forms --
"hylink|agglink">
<!entity % resloc -- Resource architectural forms: location address module --
"grovedef|grovplan" >
<!entity % resorce -- Resource architectural forms: all modules --
"%resloc;"
--? is the retention of this parameter entity valid, or should we
simply change later references to %resorce to %resloc?--
>
<!-- ArcCFC: Architectural context-free content -->
<!-- %loc, %link, %resorce qualify but are used as
meta-inclusions rather than meta-proper-subelements
-->
<!entity % ArcCFC -- Architectural context-free content model --
"TNM.SemanitcAssignment|TNM.TopicRelation|SemanticTitle"
>
<!element TNM-hub -- Topic Navigation Map HyTime hub document element --
- O (%ArcCFC;)* +(%loc;|%link;|%resorce;) >
<!attlist TNM-hub
TNM NAME #FIXED "TNM-hub"
maxbos -- Bounding level of HyTime bounded object set when
document is a hub; overridable at run time --
-- Constraint: 0=no limit; 1=root; 2 to N --
NUMBER "0"
boslevel -- Default BOS level used by data entities
declared in hub document. --
-- Constraint: 0=no limit; 1=root; 2 to N --
NUMBER "0"
grovplan -- Grove plan for HyTime extended SGML document
grove --
CDATA #IMPLIED -- reference --
-- Default: HyTime default grove plan --
>
]]>
A semantic assignment (TNM.SemanticAssignment) is a specialized HyTime hyperlink (hylink) that connects the information objects sharing a common semantic. This group of objects is collectively called a topic. The located objects have the common property of being anchors of a semantic assignment element. Therefore, one can distinguish:
Editor's Note: In view of the ability to self refer that has been added with the new HyLinks option I have taken it on myself to suggest the Semantic Titles embedded within the contents of the Semantic Assignment element should be treated as the Topic anchor, rather than having it be a pointer to another element. Is this acceptable? (I realise that this is probably not the way the architecture was originally designed, but it does seem to fit in with the new philosophy of HyLinks.) Should we also allow users to point elsewhere (e.g. to an entry in an index, glossary or thesaurus) to locate a SemanticTitle? If so, what mechanism is there in HyTime (other than conloc) to say this anchor role is either Self or a reference to another element? Can we, for example, replace the Semantic Title by a location address for a Semantic Title? Given that location addresses are top level inclusions, can users associate locations with Semantic Titles that would provide more in-depth explanations than are currently possible using Semantic Titles, or should the model for Semantic Assignments be extended to allow more than just Sematic Titles to appear? In particular, the thesaurus example in Annex A suggests that data within the element could form the implicit contents of a Semantic Title? How should this be expressed without creating a mixed content model?
Common examples of topics are index and/or glossary entries: an index entry is a set of locations sharing common semantics described by the term that is displayed in the index; they are normally displayed in alphabetical order. A glossary entry is a topic that is associated with text that is considered to be its definition. This standard enables topics that play at the same time the role of index and glossary entries: one of their anchor roles identifies their definition; the others identifies occurrences of the topic.
The value of the HyTime anchrole attribute is user-definable and allows users to distinguish between different roles of occurrence sets. The only constraint imposed by this standard is that the first anchor shall identify the semantic assignment. This is the principal way to enable the link to be referred to. All other declared anchors shall be lists of anchors that identify occurrences of the topic.
Editor's Note: I have taken the sentence "This is the principal way to enable the link to be referred to" to mean that the Semantic Titles themselves are the principle ways of referencing the objects located by the associated anchors. This has led me to introduce the concept of the #SELF anchor. Is this a valid interpretation?
When a semantic assignment is instantiated, its anchrole values have to be explicitly defined. The role of each anchor specifies the nature of the occurrence where the information about a given topic is to be found. These lists of anchor addresses are called "occurrence roles". There is no limit to what can be represented and distinguished through occurrence roles, nor to the number of occurrence roles. In particular, the anchors for a given anchor role need not be prespecified, but can be ascertained through a HyTime query location. The only limitation imposed by this standard is that occurrence roles must be defined in the DTD for a given semantic assignment element type. It is entirely the realm of the application to decide what to do when all anchor roles are not filled in. (A "null" address could be interpreted as no occurrence, for example.) The purpose of differentiating between different kinds of occurrence roles is to help users distinguish between different kinds of targets and navigate with more precision in a large set of information objects.
The semantic assignment element type form can be used to instantiate as many element types as desired in a DTD, allowing for a finer distinction; each semantic assignment element type can have a different set of anchors described in the anchrole attribute.
Anchor role values can be associated, by the user, with anchor description (anchdesc) attributes that allow the application to display information that enhances the understanding of information to be found at the anchor. The first anchor description points to information whose purpose is to clarify a semantic title, without adding any extra structural level.
Editor's Note: I have a problem with this definition of the role of the first anchor description. A Semantic Assignment can be given a set of Semantic Titles. Suppose these titles represent the different titles used for the topic in a multilingual dictionary of terms. According to the current definition it would only be possible to associate a single description with the SELF anchor role: i.e. one definition for all the titles. This means that there would not be a mechanism for selecting one of the titles and asking for a definition of it. As it is quite likely that the definitions of the terms are not exactly synonomous across languages this could lead to difficulties. I would, therefore, prefer to see descriptions of terms associated with individual titles (via an extension to the model of the TNM.SemanticAssignment element type form) rather than with the Topic as a whole. The first of the anchor role descriptions could, then, become information about the relationships between the set of definitions chosen to define the topic.
The first anchor listed in the anchrole attribute, called the topic anchor, identifies the text associated with TNM.SemanticAssignment element as the title of the topic. Making the semantic assignment element one of its own anchors permits users to traverse from some other link to the semantic assignment, and thence to any of the semantic assignment's other anchors.
Each of the other anchors (collectively called occurrences) may identify any number of information objects. The full power of HyTime's information addressing facilities can be used to associate semantic definitions with literally any piece of information, identified by whatever structural, contextual, semantic properties, or other means, are convenient.
Note: More than one occurrence role can be specified only
if the HyTime manyanch option is
supported by the underlying HyTime engine.
The TNM-specific mnemonic attribute allows a brief single-token name to be given to the semantic definition.
Editor's Note: The comment associated with the id attribute in the formal specification suggests that the id should be used to identify the element in anchors pointed to by topic relation links. However, the definition of the anchrole attribute for TNM.TopicRelation elements suggests that it should be the value of the mnemonic attribute that should be referred to. This would only be valid if the mnemonic attribute was defined as a location attribute using the refloc facility (Eliot. How does this work?) This dichotomy needs to be resolved. At present the role of the id attribute is undefined for this architectural form definition. In the thesaurus example in Annex A I suggest that a possible solution would be to make the default value for the mnemonic attribute the contents of a required ID attribute.
The TNM-specific SemanticUniverses attribute specifies the semantic context(s) in which the definition is valid. The generic identifier of a semantic assignment element constitutes implicitely a universe. Other tokens may be added to the default one as values of the SemanticUniverses attribute, as there is no limit to the number of universes attached to any instance of an element.
Editor's Note: There are a number of problems with the above definition:
1) The second sentence implies the semantic-universe-name lextype should be mapped to GI rather than just NAME. However, this standard does not define an architectural form for defining universes, and I see no reason why it should.
2) The statement "Other tokens may be added to the default one" is confusing. The last CD had no default value. For the current definition #IMPLIED has been used, with a default value of the GI of the semantic assignment element, but this is unlikely to be what was originally intended. Was the intention to make the current file the "universe", or to assign a universe attribute to the TNM-hub element?
Editors Note: The following paragraph cannot be implemented until it is determined what the current mechanism for defining parsing context is and how this relates to grove plans. It needs to be determined in which circumstances a semantic-universe-name can or cannot be interpreted as something that controls parsing. According to the current definition grove plans can only be associated with HyDoc elements and location sources. It does not, therefore, make sense to try and associate a parsing context with a specific Semantic Assignment element. Nothing would be gained by moving this attribute to a TNM-hub. What might be useful would be to associate a grove plan with specific occurrence role locations, but this should be done on a location-by-location basis, not across a set of locations. As location sources can now have grove plans associated with them there seems to be little need to retain this paragraph. [[Depending on the application, the user can choose to constrain the tokens used in the semantic universes within a predefined list, shared by a community of users. The semantic universe can be described as a HyTime-defined parsing context (parsecxt). A TNM-aware application will allow users to filter those objects belonging to one, or several, universes, and discard remaining elements, as if they did not exist, using the omitprop attribute of the parsecxt definition. This feature helps authors and editors of hyperdocuments to create and maintain concurrent universes while giving users access to a known set of universes. The possibility of maintaining a unique hyperdocument while allowing several views on it should considerably enhance its maintainability.]]
An application that can process topic navigation maps is said to be a TNM engine. A TNM engine must be able to suppress an element with a particular value as one of its semantic-universe-name values in a SemanticUniverses attribute. A semantic assignment element is not processed in any context in which none of the universes specified by the token list [Editor's questions: Which token list? Is this still based on the concept of uniquely named parsing contexts? (If so it needs to be removed.)] is found in the value of the SemanticUniverses attribute, so that the element can be disqualified. The question of what it means, in any particular case, for information to be disqualified is entirely the realm of the application. In general, though, the purpose of disqualification by semantic universe is to avoid wasting the user's time and attention on irrelevant information. It is the responsability of the application to inform the TNM application whenever semantic universes become valid or invalid due to changes in user context; this minimizes transmission of unwanted information. (In some applications, a user can say that all universes are always valid, and then see everything. In other applications, universes can be used for separating access levels depending on the degree of classification for different parts of the document, as defined by the hyperdocument editor, but cannot be modified by individual end-users.)
A TNM engine is responsible for maintaining a namespace of universes for each mnemonic, and a namespace of mnemonics for each universe. Given a mnemonic, a TNM engine must be able to provide a comprehensive list of all mnemonics declared in semantic assignments within the TNM-hub's bounded object set (BOS).
Where appropriate the optional weighting attribute can be used to indicate the relevance of a particular instance of a semanitic assignment to the application. The specified integer could, for instance, be used to control the sequence of related assignments.
<!element TNM.SemanticAssignment
-- connects portions of
information sharing
a common semantic. --
- O (semanticTitle*) >
<!attlist TNM.SemanticAssignment
TNM NAME TNM.SemanticAssignment
id ID #IMPLIED
-- Each TNM.SemanticAssignment should be assigned a unique
identifier to allow the topic to be used as an
anchor for a topic relation link. As all topics need
not be anchors, the id is not required. --
mnemonic -- The short or key name for the subject matter of
this definition; machine-processable identifier.
Can be seen as a "semantically-loaded identifier"
(which may or may not be unique) --
CDATA #IMPLIED
--? How can mnemonic be a "key name" if it is not unique?--
SemanticUniverses
-- Defines the semantic universe in which this topic is
useful. This attribute is generally used to filter out
non-relevant topics according to a list of universes chosen
by the user. --
-- lextype(semantic-universe-name+) --
-- Question: What constraints should be placed on
a semantic-universe-name? Should it
be a valid SGML name or any text with
spaces replaced by underlines so that
spaces delimit universe specifications?
Where is the relevant lextype declared?--
CDATA #IMPLIED -- Default: Generic identifier of element
identifies relevant universe --
weighting -- Indicates relevence to topic or certainty
of information.
0 = means probably irrelevent.
100 = means definitely relevent.
If a weight is more than 100, it can indicate extreme
or compelling relevence, though weights greater
than 100 may be deemed to be 100 by any application.--
NUMBER #IMPLIED --Default: 100--
HyTime NAME hylink
anchrole NAMES "Topic #SELF OccurrenceRole_1 #LIST ... OccurrenceRole_n #LIST"
-- The number of anchroles is not specified in the
architectural form because it is application-specific.
The occurrence anchor sets are generally lists of
one or more objects (#LIST) or queries that return
lists of objects. Each occurrence role defined by this
attribute must be declared as an attribute within
the definition of the element using this
architecutral form. --
anchdesc -- Anchor description information --
-- Constraint: one per anchor or one for all --
CDATA --reference-- #IMPLIED -- Default: none --
linktrav -- Hyperlink traversal rules. One or more of:
E traversal after external arrival
I traversal after internal arrival
R return traversal after internal arrival
D departure after internal arrival
A any traversal or departure (EID)
N no traversal after internal arrival
P no internal arrival --
-- Constraint: one per anchor or one for all --
-- Lextype("I"|"R"|"D"|"A"|"N"|"P"|"ID"|"RD"|
"EI"|"ER"|"ED"|"EN"|"EP"|"ERD")+) --
NAMES #IMPLIED -- Default: Any traversal or departure --
--Eliot: Why is E not allowed on its own here?--
listtrav -- Traversal between members of list anchors.
One of:
N no traversal
L left traversal
R right traversal
A adjacent (both left and right) traversal
optionally concatenated with:
W wrapping traversal --
-- Constraint: one per anchor or one for all --
-- Lextype(("N"|"L"|"R"|"A"|"LW"|"RW"|"AW")+) --
NAMES #IMPLIED -- Default: No list traversal --
emptyanch -- Is empty anchor an error? --
-- Constraint: one per anchor or one for all --
-- Lextype("ERROR"|"NOTERROR") --
NAMES "noterror" -- Allows topic maps that have no
existing occurrences to be defined --
-- Definitions for attributes defined in the anchrole attribute --
>
The optional TNM.SemanticTitle element in the content of a TNM.SemanticAssignment element is intended to contain a brief, single phrase text title for the semantic: one that is normally longer than the value of the mnemonic attribute. Generally, a semantic assignment has one semantic title. But there can be - interesting - cases where zero or several semantic titles can be useful:
<!element TNM.SemanticTitle - - ANY >
-- Descriptive phrase title or expansion of the mnemonic
of the containing TNM.SemanticDefinition-form element --
<!attlist TNM.SemanticTitle
TNM NAME TNM.SemanticTitle
>
Editor's Note: Should we show how a HyTime desctxt or conloc attributes could be used to point to a semantic title stored elsewhere?
Note 85* in the second edition of ISO/IEC 10744 draws the distinction between descriptive text and the content location facility. Both allow the content of the element to be outside the syntactic content. However, conloc locates the content in another element that happens to be in the document, while desctxt draws it from a table of elements that were created as a resource -- presumably for use in several documents.
* Check this number against published text of 2nd edition
Topics may be linked to one another by means of topic relation links (TNM.TopicRelations). These links express application-defined relationships, if any, between the topics. Any number of relationships can exist between any two or more topics. The members of each topic are identified by a uniquely named attribute whose value resolves to the unique identifier of a TNM.SemanticAssignment.
Topics may be linked to one another to create abstract topic maps that might be used as skeletal structures onto which exemplary and/or related instances can subsequently be added.
The nature of the relationship represented by a topic relation link element type may be explained in an element which is linked, by the anchdesc attribute, to either a specific anchor role or to all of the anchor roles.
Where appropriate the optional weighting attribute can be used to indicate the relevance of a particular instance of a relationship to the application. The specified integer could be used to control the sequence of relationships.
The value of the TNM.SemanticUniverse attribute specifies the name(s) of the universe(s) in which the topic relationship expressed by the link is valid. A TNM engine must be able to warn the application whenever the TNM.SemanticAssignment-form element is processed in a context in which none of the universes specified by the token list is valid, so that the topic relationship can be disqualified.
Editor's Note: Now that parsing context is no longer specified in this way, but rather through a grove plan, is the above last sentence still relevant?
Universe(s) need not be specified, but they can be specified by defaulting them or fixing them in the DTD, or they can be specified (possibly overrriding a default value given in the DTD) in the start-tag of each element instance. If there is no default value and none is specified in the element instance, then the application's behavior with respect to disqualification is not specified by this standard.
The content of a TNM.TopicRelation element is not specified in this standard as it is, necessarilly, application dependent.
<!element TNM.TopicRelation - O ANY >
<!attlist TNM.TopicRelation
id ID #IMPLIED
TNM NAME TNM.TopicRelation
SemanticUniverses CDATA #IMPLIED -- Default: not specified --
-- Constraints: Use #ALL to mean "valid in all
universes" --
weighting -- Indicates relevence to relationship to
semanitic universes it is being applied to.
0 = means probably irrelevent.
100 = means definitely relevent.
If a weight is more than 100, it can indicate extreme
or compelling relevence, though weights greater
than 100 may be deemed to be 100 by any application.--
NUMBER #IMPLIED --Default: 100--
HyTime NAME hylink
anchrole NAMES #FIXED
"Relationship Topic_list_1 #LIST ... Topic_list_n #LIST"
-- Constraint: Topic names must match value(s) assigned to the
mnemonic (or id?) attribute(s) of
TNM.SemanticAssignment element(s) --
--? What is the scope of topic mnemonics? Must the mnemonics always
occur in the same TNM-hub document, or can relationships reference
topics defined in a set of topic navigation maps? If the latter
is the case, should a location source be associated with
individual locations or should the entity name of the
file containing the relevant topic navigation map be used to
qualify the topic mnemonic?--
-- The number of anchroles is not specified in the
architectural form because it is application-specific.
Each anchrole defined by this
attribute must be declared as an attribute within
the definition of the current element and
must identify objects through the mnemonic property
(or unique identifier?) of
associated semantic assignment elements. --
anchdesc -- Anchor description information --
-- Constraint: one per anchor or one for all --
IDREFS #IMPLIED -- Default: none --
linktrav -- Hyperlink traversal rules. One or more of:
E traversal after external arrival
I traversal after internal arrival
R return traversal after internal arrival
D departure after internal arrival
A any traversal or departure (EID)
N no traversal after internal arrival
P no internal arrival --
-- Constraint: one per anchor or one for all --
-- Lextype("I"|"R"|"D"|"A"|"N"|"P"|"ID"|"RD"|
"EI"|"ER"|"ED"|"EN"|"EP"|"ERD")+) --
NAMES #IMPLIED -- Default: Any traversal or departure --
listtrav -- Traversal between members of list anchors.
One of:
N no traversal
L left traversal
R right traversal
A adjacent (both left and right) traversal
optionally concatenated with:
W wrapping traversal --
-- Constraint: one per anchor or one for all --
-- Lextype(("N"|"L"|"R"|"A"|"LW"|"RW"|"AW")+) --
NAMES #IMPLIED -- Default: No list traversal --
emptyanch -- Is empty anchor an error? --
-- Constraint: one per anchor or one for all --
-- Lextype("ERROR"|"NOTERROR") --
NAMES "noterror" -- Allows topic maps that have no
existing occurrences to be defined --
-- Definitions for attributes defined in the anchrole attribute --
>
Editor's Note: At the current stage of development of this CD the examples identify a number of possible problems with the current definitions of the architectural forms. The examples have deliberately been defined to test some of the assumptions made in the definitions of the architectural forms, and should not be taken as indicating that the architectural forms as currently defined are wrong, or that the examples themselves are the correct way of implemeting the architectural forms as currently defined.
The following example shows how a document type definition for an annotated thesuari could be defined as a Topic Navigation Map:
<!SGML "ISO 8879:1986"
...
APPINFO "ArcBase"
>
<?ArcBase TNM HyTime>
<!DOCTYPE thesaurus [
<!NOTATION TNM PUBLIC "ISO 13250//NOTATION AFDR ARCBASE
Topic Navigation Map
Architecture Definition Document//EN"
-- A base architecture used in conformance with the
Architectural Form Definition Requirements of
International Standard ISO/IEC 10744. -->
<!ATTLIST #NOTATION TNM
ArcFormA NAME TNM
ArcNamrA Name TNM-name
-- Can be used to assign locally
meaningful names to TNM attributes --
ArcDTD CDATA #FIXED "%TNM-DTD"
ArcDocN NAME "thesaurus"
--Eliot: I'm having problems with this attribute. It would appear that
it has to be defined within the DTD it references. What happens
if the name specified here is not the same as the DOCTYPE name?
(Or should this actually be TNM-hub to indicate the class to be
used to identify the hub document?)-->
<!ENTITY % TNM-DTD PUBLIC "ISO 13250//DTD Topic Navigation Map meta-DTD//EN">
%TNM-DTD
<!--Eliot: A related problem is that the base document element has to be the
ArcDTD for HyTime as well! How can this be specified in a way that
ensures there is no conflict?-->
<!NOTATION HyTime PUBLIC
"+//ISO/IEC 10744:1992//NOTATION
HyTime Architecture Definition Document//EN" >
-- A document architecture conforming to the
Architectural Form Definition Requirements of
International Standard ISO/IEC 10744. --
>
<!ATTLIST #NOTATION HyTime
-- Support attributes for all architectures --
ArcFormA -- Attribute name: architectural form --
-- lextype(ATTNAME) --
NAME #FIXED HyTime
ArcVer -- Architecture version identifier --
CDATA #FIXED "ISO/IEC 10744:1992"
ArcNamrA -- Attribute name: attribute renamer --
-- lextype(ATTNAME) --
NAME "HyNames"
ArcDocN -- Architectural form name: document element --
NAME "HyDoc"
ArcBridA -- Attribute name: bridge functions --
NAME "HyBrid"
ArcFacN -- Attribute names: architecture facilities --
-- lextype(ATTNAME*) --
NAMES #FIXED
"base locs links"
-- Support attributes for
Topic Navigation Maps only --
hyqcnt -- Highest quantum count ceiling --
-- Constraint: power of 2 >= 32 --
NUMBER "32"
base -- ArcFacil: Base module --
-- lextype(NMTOKENS) --
CDATA "" -- Default: no options --
locs -- ArcFacil: Location address module --
-- lextype(NMTOKENS) --
CDATA #IMPLIED -- Default: no support --
links -- ArcFacil: Hyperlinks module --
-- lextype(NMTOKENS) --
CDATA #IMPLIED -- Default: no support --
sched -- ArcFacil: Scheduling module --
-- lextype(NMTOKENS) --
CDATA #IMPLIED -- Default: no support --
rend -- ArcFacil: Rendition module --
-- lextype(NMTOKENS) --
CDATA #IMPLIED -- Default: no support --
manyaxes -- Maximum number of axes allowed in coordinate spaces --
NUMBER #IMPLIED -- Default: no limit --
>
<!ENTITY % HyTime -- Meta-DTD for this DTDs instances --
-- THIS ENTITY IS NOT TO BE REFERENCED! --
-- Declares the set of HyTime facilities
that must be supported when a Topic Navigation Map
is being defined. --
SYSTEM CDATA HyTime [
hyqcnt=32
locs="anydtd grovplan grovedef
pgrovdef agrovdef HyLex exidrefs
multloc spanloc query
coordloc pathloc relloc bibloc"
links="manyanch" -- but not ilink --
sched="dimref" ]>
<!ELEMENT thesuarus - O (category+)>
<!ATTLIST thesaurus TNM NAME #FIXED "TNM-hub"
HyTime NAME #FIXED "HyDoc"
TNM-name CDATA "id subject"
subject ID #REQUIRED
-- Identifies semantic universe
of thesaurus.-- >
<!ELEMENT category - O (category-title, term*, broader-terms*,
related-terms*, narrower-terms*)
--NB: This model defines a set of relationships in itself.--
--Note: The term element is optional as some categories can be
defined using only terms that have already been defined
in other categories. Terms only need to be defined once.
The included-terms attribute points to terms defined
elsewhere that need to be included in the term set
as well as to the terms defined within this element.-->
<!ATTLIST category
id ID #REQUIRED
TNM NAME TNM.TopicRelation
SemanticUniverses CDATA #IMPLIED -- Default: Subject of thesaurus --
weighting -- Indicates relevence to category to subject
area of thesaurus.
0 = means probably irrelevent.
100 = means definitely relevent.
If a weight is more than 100, it can indicate extreme
or compelling relevence, though weights greater
than 100 may be deemed to be 100 by any application.--
NUMBER #IMPLIED --Default: 100--
--Question: Are weights really relevant to categories?
What effect would this weighting have on presentation
or use of the thesaurus? --
HyTime NAME hylink
anchrole NAMES #FIXED
--NB. 4 of the first 5 items in this list identify
relationships expressed in the model
of the element. The last 3 represent
relationships in addition to those
expressed in the model.--
"category-identified
included-terms #LIST
broader-terms #LIST
related-terms #LIST
narrower-terms #LIST
French-equivalents #LIST
German-equivalents #LIST
Italian-equivalents #LIST"
category-identified IDREF --reftype(category-title)-- #REQUIRED
included-terms IDREFS --reftype(term)-- #REQUIRED
broader-terms IDREFS --reftype(term)-- #IMPLIED
related-terms IDREFS --reftype(term)-- #IMPLIED
narrower-terms IDREFS --reftype(term)-- #IMPLIED
French-equivalents IDREFS --reftype(category)-- #IMPLIED
German-equivalents IDREFS --reftype(category)-- #IMPLIED
Italian-equivalents IDREFS --reftype(category)-- #IMPLIED
--Question: Would it be better to use CDATA and an associated reference
comment in place of IDREFS to allow terms in other files
to be referenced?--
linktrav -- Hyperlink traversal rules:
E traversal after external arrival
R return traversal after internal arrival
D departure after internal arrival --
-- Constraint: one per anchor or one for all --
-- Lextype("I"|"R"|"D"|"A"|"N"|"P"|"ID"|"RD"|
"EI"|"ER"|"ED"|"EN"|"EP"|"ERD")+) --
NAMES "ERD"
listtrav -- Traversal between members of list anchors.
R right traversal only
W wrapping traversal --
-- Lextype(("N"|"L"|"R"|"A"|"LW"|"RW"|"AW")+) --
NAMES "RW"
-- As the list is ordered by relevance weighting
right traversal seems a logical constraint. --
emptyanch -- Is empty anchor an error? --
-- Constraint: one per anchor or one for all --
-- Lextype("ERROR"|"NOTERROR") --
NAMES "noterror"
>
<!ELEMENT term - O (#PCDATA)
--NB: According to the model for TNM.SemanticAssignment you would
need to put a Semantic Title element as the model here, but I question
whether this is strictly necessary. The model here, though not
strictly conforming to the architectural form, does indicate a sensible
alternative to a Semantic Title.-->
<!ATTLIST term
TNM NAME TNM.SemanticAssignment
id ID #REQUIRED
-- A term only needs to be defined once, and can then be referenced
by other categories in which it is to be included. --
mnemonic -- The short or key name for the term --
CDATA #IMPLIED --Default: Same as id --
SemanticUniverses
-- Defines the semantic universe in which term is used.--
-- lextype(semantic-universe-name+) --
CDATA #IMPLIED -- Default: Value of subject attribute
of thesaurus.--
--NB: The default conflicts with the default value specified
in the architectural form definition, but seems to be a
more natural example as the generic identifier of the element
is simply term.--
weighting -- Indicates relevence to term to category:
terms could be ordered based on relevance
within category.
0 = means probably irrelevent.
100 = means definitely relevent.
If a weight is more than 100, it can indicate extreme
or compelling relevence, though weights greater
than 100 may be deemed to be 100 by any application.--
NUMBER #IMPLIED --Default: 100--
HyTime NAME hylink
anchrole NAMES #FIXED
"topic #SELF
dataset1-refs #LIST
dataset2-refs #LIST
dataset3-refs #LIST"
anchdesc -- Anchor description information --
-- Constraint: one per anchor or one for all --
IDREFS #IMPLIED -- Default: none --
--NB: There might be a case for making this description
compulsory. If this was the case each term could point
to a description that explained the role of the term
within the thesaurus. Whilst this does not appear to be
what the designers of HyTime expected this attribute to be
used for, it would seem to be a useful interpretation of the
role of this attribute within a topic navigation map.--
dataset1-refs IDREFS #REQUIRED
--NB: All terms in dataset1 glossaries
have a unique id.--
dataset2-refs IDREFS --reftype(treelocs)-- #REQUIRED
dataset2-refs CDATA --lextype(SDQL-query)--
'(matches "hot dogs")'
--Question: How should language equivalents of individual terms
(rather than categories) be identified in
this scenario? (Note that such terms would be
dependent on referencing equivalent datasets.)--
linktrav -- Hyperlink traversal rules. One or more of:
E traversal after external arrival
I traversal after internal arrival
R return traversal after internal arrival
D departure after internal arrival
A any traversal or departure (EID)
N no traversal after internal arrival
P no internal arrival --
-- Constraint: one per anchor or one for all --
-- Lextype("I"|"R"|"D"|"A"|"N"|"P"|"ID"|"RD"|
"EI"|"ER"|"ED"|"EN"|"EP"|"ERD")+) --
NAMES #IMPLIED -- Default: Any traversal or departure --
listtrav -- Traversal between members of list anchors.
One of:
N no traversal
L left traversal
R right traversal
A adjacent (both left and right) traversal
optionally concatenated with:
W wrapping traversal --
-- Constraint: one per anchor or one for all --
-- Lextype(("N"|"L"|"R"|"A"|"LW"|"RW"|"AW")+) --
NAMES #IMPLIED -- Default: No list traversal --
emptyanch -- Is empty anchor an error? --
-- Constraint: one per anchor or one for all --
-- Lextype("ERROR"|"NOTERROR") --
NAMES "noterror" -- Allows topic maps that have no
existing occurrences to be defined --
>
<!ELEMENT (broader-terms|related-terms|narrower-terms) - O EMPTY
--Question: Would it be necessary to make this model (term*) to
allow terms that only ever occur as related terms
to be defined outside of a category specification?--
>
<!ATTLIST (broader-terms|related-terms|narrower-terms)
id ID #IMPLIED
--NB: Here is a case where the old CApH rule requiring an ID does not
make sense - hence the change to #IMPLIED in the architectural
form definition. --
TNM NAME TNM.TopicRelation
SemanticUniverses CDATA #IMPLIED -- Default: Subject of thesaurus --
HyTime NAME hylink
anchrole NAMES #FIXED "relationship links-to"
relationship (broader-terms|related-terms|narrower-terms)
#IMPLIED --Default: Use GI--
links-to IDREFS --reftype(term)-- #REQUIRED
weighting -- Indicates relevence to associated terms to category.
0 = means probably irrelevent.
100 = means definitely relevent.
If a weight is more than 100, it can indicate extreme
or compelling relevence, though weights greater
than 100 may be deemed to be 100 by any application.--
NUMBER #IMPLIED --Default: 100--
linktrav -- Hyperlink traversal rules:
A any traversal or departure (EID) --
-- Constraint: one per anchor or one for all --
-- Lextype("I"|"R"|"D"|"A"|"N"|"P"|"ID"|"RD"|
"EI"|"ER"|"ED"|"EN"|"EP"|"ERD")+) --
NAMES "A"
listtrav -- Traversal between members of list anchors.
A adjacent (both left and right) traversal
W wrapping traversal --
-- Lextype(("N"|"L"|"R"|"A"|"LW"|"RW"|"AW")+) --
NAMES "AW"
emptyanch -- Is empty anchor an error? --
-- Constraint: one per anchor or one for all --
-- Lextype("ERROR"|"NOTERROR") --
NAMES "error"
>
]>
Editor's Note: Many existing examples of the use of topic maps rely on the relationships between people. The following example is an attempt to fully define the relations a person may have using the topic relation element type form. An initial analysis would suggest that there may be a problem in doing this because of the restriction that a topic-relation's anchroles resolve to elements identified using a mnemonic name rather than an id. Another problem, noted in the comments for the DTD, is that you cannot currently refer to the contents of siblings to define the type of relationship.
A geneology could be defined as part of a topic navigation map by defining a topic relation element type, and supporting elements, entities and processing instructions, of the following form:
<!ENTITY % calendars PUBLIC "ISO 13250//NONSGML LEXTYPES
TNM-example UTC date order//EN">
<?LEXUSE calendars>
<!ELEMENT person - O (surname, given-names, relations) >
<!ATTLIST person mnemonic ID #REQUIRED >
<!ELEMENT (surname|given-name) - O (#PCDATA)>
<!ELEMENT relations - O EMPTY
--NB This model gives problems with the use of #SELF for the first
anchrole. In fact what the anchor role wants to point to is
either the GI itself (which is sufficient for identifying the
role of the link) or the person's name defined by the contents of
the siblings of relations, i.e. the surname and given name
of the person who the other anchors are relations of. (One way
to do this could be to change the content model to allow the
element to contain a relloc.)
What do you think the preferred way of defining
the relationship should be in this case?--
>
<!ATTLIST relations
id ID #REQUIRED
TNM NAME TNM.TopicRelation
SemanticUniverses CDATA #IMPLIED -- Default: not specified --
HyTime NAME hylink
anchrole NAMES #FIXED
"relations-of #SELF
maternal-ancestors #LIST
paternal-ancestors #LIST
maternal-siblings #LIST
paternal-siblings #LIST
spouses #LIST
other-child-creators #LIST
sons #LIST
daughters #LIST"
maternal-ancestors IDREFS #REQUIRED --lextype(UTC-date
#ORDER calendar)--
--reftype(person)--
paternal-ancestors IDREFS #IMPLIED --lextype(UTC-date
#ORDER calendar)--
--reftype(person)--
maternal-siblings IDREFS #IMPLIED --reftype(person)--
paternal-siblings IDREFS #IMPLIED --reftype(person)--
spouses CDATA --reftype(person)--
--lextype (IDREF, UTC-date, UTC-date?)+--
--Constraint: First UTC-date identifies
start of relationship, second one
identifies end of relationship--
#IMPLIED
other-child-creators IDREFS #IMPLIED --reftype(person)--
sons IDREFS #IMPLIED --reftype(person)--
daughters IDREFS #IMPLIED --reftype(person)--
linktrav -- Hyperlink traversal rules:
A any traversal or departure (EID) --
-- Constraint: one per anchor or one for all --
-- Lextype("I"|"R"|"D"|"A"|"N"|"P"|"ID"|"RD"|
"EI"|"ER"|"ED"|"EN"|"EP"|"ERD")+) --
NAMES "A"
listtrav -- Traversal between members of list anchors.
A adjacent (both left and right) traversal
W wrapping traversal --
-- Lextype(("N"|"L"|"R"|"A"|"LW"|"RW"|"AW")+) --
NAMES "AW"
emptyanch -- Is empty anchor an error? --
-- Constraint: one per anchor or one for all --
-- Lextype("ERROR"|"NOTERROR") --
NAMES "noterror error noterror noterror noterror
noterror noterror noterror noterror"
>
For the preceding declarations to work there would need to be a lexical ordering defintion of the following form within the file identified through the lexord processing instruction:
<!--
This file is identified by the following public identifier:
"ISO 13250//NONSGML LEXTYPES TNM-example UTC date order//EN"
This set extends the default lexical ordering set, HyOrd, found
in HyTime.
-->
<!LEXORD calendar -- UTC date order --
SPEC PUBLIC "ISO 13250//NOTATION LEXORD
TNM-example UTC date order//EN" >
The Text Encoding Intiative (TEI) has defined the following set of elements for defining taxonomies within TEI class declarations:
<!ELEMENT classDecl - - (taxonomy+)>
<!ATTLIST classDecl %a.global; >
<!ELEMENT taxonomy - - (category+ |
((bibl | biblStruct | biblFull), category*))>
<!ATTLIST taxonomy %a.global; >
<!ELEMENT category - - (catDesc, category*)>
<!ATTLIST category %a.global; >
<!ELEMENT catDesc - o (%phrase.seq; | textDesc) >
<!ATTLIST catDesc %a.global; >
The example of the use of this construct given in the TEI Guidelines for Electronic Text Encoding and Interchange (TEI P3) is:
<taxonomy id=B> <bibl>Brown Corpus</bibl> <category id=B.A><catDesc>Press Reportage <category id=B.A1><catDesc>Daily</category> <category id=B.A2><catDesc>Sunday</category> <category id=B.A3><catDesc>National</category> <category id=B.A4><catDesc>Provincial</category> <category id=B.A5><catDesc>Political</category> <category id=B.A6><catDesc>Sports</category> ... </category> <category id=B.D><catDesc>Religion <category id=B.D1><catDesc>Books</category> <category id=B.D2><catDesc>Periodicals and tracts</category> </category> ... </taxonomy>
To use this existing data as a topic navigation map you would need to:
<taxonomy> as conforming to the
TNM.TopicRelation element type architectural form
<category> as conforming to the
TNM.SemanticAssignment element type architectural form
<catDesc> as conforming to the TNM.SemanticTitle
element type architectural form
Editor's Note: This last statement is currently invalid as the model for a TEI-hub does not allow for the complete range of TEI elements, unless %ArcCFC is redefined and the three elements it currently defined are made part of of the asssociated inclusion. In other words, should we change the model of TNM-hub to something like:
<!element TNM-hub O O ANY +(TNM.SemanticAssignment|TNMSemanticTitle|
TNM.TopicRelation|%loc;|%link;|%resorce;)>
To do this you would extend the existing definitions as follows:
<!ENTITY % TNM.TR --Attributes used to define a Topic Navigation Map
Topic Relation--
'TNM NAME TNM.TopicRelation
SemanticUniverses CDATA #IMPLIED -- Default: not specified --
HyTime NAME hylink
linktrav -- Hyperlink traversal rules. One or more of:
E traversal after external arrival
I traversal after internal arrival
R return traversal after internal arrival
D departure after internal arrival
A any traversal or departure (EID)
N no traversal after internal arrival
P no internal arrival --
-- Constraint: one per anchor or one for all --
-- Lextype("I"|"R"|"D"|"A"|"N"|"P"|"ID"|"RD"|
"EI"|"ER"|"ED"|"EN"|"EP"|"ERD")+) --
NAMES "A"
listtrav -- Traversal between members of list anchors.
A adjacent (both left and right) traversal
W wrapping traversal --
-- Lextype(("N"|"L"|"R"|"A"|"LW"|"RW"|"AW")+) --
NAMES "AW"
emptyanch -- Is empty anchor an error? --
-- Constraint: one per anchor or one for all --
-- Lextype("ERROR"|"NOTERROR") --
NAMES "noterror" '
>
<!ENTITY % TNM.SA --Attributes used to define a Topic Navigation Map
Semanitic Assignment--
TNM NAME TNM.SemanticAssignment
id ID #IMPLIED
mnemonic -- the short or key name for the term --
CDATA #IMPLIED --Default: Same as id --
SemanticUniverses
-- Defines the semantic universe in which term is used.--
-- Lextype: (semantic-universe-name+) --
CDATA #IMPLIED -- Default: All universes --
weighting -- Indicates relevence to term to category:
terms could be ordered based on relevance
within category.
0 = means probably irrelevent.
100 = means definitely relevent.
If a weight is more than 100, it can indicate extreme
or compelling relevence, though weights greater
than 100 may be deemed to be 100 by any application.--
NUMBER #IMPLIED --Default: 100--
HyTime NAME hylink
linktrav -- Hyperlink traversal rules. One or more of:
E traversal after external arrival
I traversal after internal arrival
R return traversal after internal arrival
D departure after internal arrival
A any traversal or departure (EID)
N no traversal after internal arrival
P no internal arrival --
-- Constraint: one per anchor or one for all --
-- Lextype("I"|"R"|"D"|"A"|"N"|"P"|"ID"|"RD"|
"EI"|"ER"|"ED"|"EN"|"EP"|"ERD")+) --
NAMES #IMPLIED -- Default: Any traversal or departure --
listtrav -- Traversal between members of list anchors.
One of:
N no traversal
L left traversal
R right traversal
A adjacent (both left and right) traversal
optionally concatenated with:
W wrapping traversal --
-- Constraint: one per anchor or one for all --
-- Lextype(("N"|"L"|"R"|"A"|"LW"|"RW"|"AW")+) --
NAMES #IMPLIED -- Default: No list traversal --
emptyanch -- Is empty anchor an error? --
-- Constraint: one per anchor or one for all --
-- Lextype("ERROR"|"NOTERROR") --
NAMES "noterror" -- Allows topic maps that have no
existing occurrences to be defined --
>
<!ELEMENT classDecl - - (taxonomy+)>
<!ATTLIST classDecl %a.global; >
<!--Question: Is there any logical reason why classDecl should not be
declared ss a TNM-hub even though it is not the
base document element for a TEI document?
At present TNM-hub is defined as the ArcDoc form
for the architecture, and ArcDoc is constrained to
be a document element (though it does not need to
be the base document element). This example raises the
question of hubs being only part of a larger entity,
as taxonomies are defined as part of a TEI corpora.-->
<!ELEMENT taxonomy - - (category+ |
((bibl | biblStruct | biblFull), category*))>
<!ATTLIST taxonomy %a.global;
%TNM.TR;
anchrole NAMES #FIXED
"taxonomy-of #SELF
categories-in #LIST"
anchdesc -- Anchor description information --
-- Constraint: one per anchor or one for all --
IDREFS #IMPLIED
-- Constraint: Must be at least one unless
one of the elements defining a bibliographic
source for the taxonomy has been specified
before the first embedded category. --
categories-in IDREFS #IMPLIED --Default: contained elements --
--reftype(category)-- >
<!ELEMENT category - - (catDesc, category*)>
<!ATTLIST category %a.global;
%TNM.SA;
anchrole NAMES #FIXED
"descriptor #SELF
--Question: Should this be changed to
be an explicit reference
to the enclosed catDesc element>--
sub-categories #LIST
sources #LIST"
anchdesc -- Anchor description information --
-- Constraint: one per anchor or one for all --
IDREFS #IMPLIED -- Default: None --
sub-categories IDREFS #IMPLIED --reftype(category)--
-- Default: Implied from
nesting of categories--
sources IDREFS #IMPLIED -- Default: None at present --
>
<!ELEMENT catDesc - o (%phrase.seq; | textDesc) >
<!ATTLIST catDesc %a.global;
--Note: If the category descriptor attribute cannot be defined
using #SELF the id attribute in a.global may have
to be redefined to make it required.--
TNM NAME "TNM.SemanticTitle" >