[This local archive copy mirrored from the canonical site: http://www.hightext.com/tnm/psjan98.htm - January 22, 1998; links may not have complete integrity, so use the canonical document at this URL if possible.]

ISO/IEC CD 13250

ISO/IEC JTC1/WG4

Document Processing and Relating Communication --
Document Description and Processing Languages


Title:
Information Processing -- SGML Applications -- Topic Navigation Maps
Source:
ISO JTC1/WG4
Project:
SGML Rapporteur Group
Status of Document:
Committee Draft
Requested action:
Approval of Committee Draft
Summary of major points:
Revised CD
Distribution:
National bodies participating in or observing the activities of JTC1/WG4

Information Processing -- SGML Applications -- Topic Navigation Maps

0. Introduction

This international standard provides a general mechanism for assigning properties to information objects using links. Thus, an object described as having a given property need not possess the property intrinsically, but may have it assigned extrinsically using a topic navigation map. Because of the extrinsic character of a topic map, it may be thought of as an "overlay" on a set of information objects.

Note: The Greek word 'topos' from which the English word 'topic' originates means 'location'. Therefore, 'topic' means here the qualification of a subject by the locations in which it is mentioned.

Note: A parallel distinction between the intrinsic and the extrinsic exists in the world of book indexing: the subject headings of an index need not appear as strings in the indexed text; indeed, those headings that do not appear offer more potential value to the user than those that do appear, offering as they do a measure of abstraction.

An unlimited number of topic navigation maps may be overlaid on a given bounded object set. Thus, topic navigation maps enable multiple, concurrent views of information objects. These views may be relational, hierarchical, or both.

Note: Thus, topic navigation maps provide a flexible mechanism for defining database schemata.

Topic navigation maps may assign properties to information objects for the following applications, among others:

This standard provides for multilingual topic navigation maps. Filters may be set up to view or ignore information objects based on assigned properties including language or nationality. The topic navigation map's anchor roles (that is, its user interface) may be presented in a specific language using the localization attribute.

All property assignment in this standard is performed using the HyTime varlink (variable link) architectural form and any or all of the location addressing facilities of HyTime. Therefore, information objects that can be addressed through a Topic Navigation Map can exist in any notation.

Note: In its design, HyTime distinguishes rigorously between linking (a relation among information objects) and locating (addressing the information objects). This design decision is essential to topic map interchange.

1. Scope

This standard provides techniques, based on facilities defined in ISO/IEC 10744:1997, for assigning extrinsic properties to information objects using topics, and for linking sets of related topics.

Note: This standard does not require or disallow use of any addressing scheme for the location of information objects, or any format for document storage.

One field of application for the standard is the addition of information to data not intrinsically, as markup, but extrinsically, as an "overlay".

Note: Content created using embedded markup and overlays may be deemed to be equivalent.

This field of application includes, but is not limited to, the interchange of indexes, glossaries, cross-references, thesauri, and other such reference material.

2. Conformance

If a document complies with all provisions of this International Standard, is a conforming SGML document as defined in ISO 8879, and is a conforming HyTime document as defined in ISO 10744:1997, it is a conforming Topic Navigation Map document.

Conformance to the Topic Navigation Map standard is independent of whether the document also conforms to any other document architecture.

A conforming Topic Map Engine must be able to perform architectural processing on the architectural forms defined in this standard: TNM::Topic, TNM::TopicRelationship, TNM::TopicTitle, TNM::Filter, and TNM::Anchspec.

Editor's note: The following paragraphs are imported from ISO 10744. They only need to be quoted here. To do: specify the way the TNM architecture is derived from the HyTime AFDR.

A.3.1 Enabling architectures

A document architecture can also be "enabling", in which case it does not specify complete document types. Instead, an enabling architecture defines rules, known as "architectural forms", that application designers can apply in their document type definitions. These rules, and the associated architectural semantics, are described in an "architecture definition document". The set of formal SGML specifications of the architectural forms, and related declarations for an enabling architecture, comprises a "meta-DTD".

Conceptually, there are two steps to architectural processing. In the first step, generic architectural processing, a generic architecture engine validates a client document against the meta-DTD of its base architectures and, optionally, creates an architectural instance for each base architecture. In the second step, an architecture-specific semantic engine processes both the relevant architectural instances and the client document in order to implement and/or validate architecture-specific semantics.

Note: In practice, these steps may be combined into a single architecture- or application-specific processor. In other words, an application-specific processor may implement architecture-defined semantics without doing generalized architectural processing.

3. Normative references

4. Definitions

Conventions

Editor's note (SH): 1/2/98. so what is duplicative, if not identical to the original, should be removed?

Editor's note (SH): 1/2/98. Somewhere the "::" convention needs to be documented.

The terms and definitions given in ISO 8879:1986 and ISO/IEC 10744:1997 and the following terms and definitions apply to this standard.

For the purposes of this standard the conventions defined in Clause 5 of ISO/IEC 10744:1997 have been followed.

Anchor
An object (or list of objects) that is linked to other objects or lists of objects by a hyperlink. [ISO 10744].
Anchor Role
The role an anchor plays in a link.
Architectural forms
Rules for creating and processing components of documents. Four kinds of architectural form are defined in ISO/IEC 10744:1997: element form, attribute form, data entity form, and data attribute form.
Architectural Form Definition Requirements (AFDR)
The requirements, specified in Annex A of ISO/IEC 10744:1997, for the formal definition of the architectural forms by which an enabling document architecture governs the SGML representation of its documents.
Assignable property
A property that may be assigned to an information object by a link. The property may, but need not be, deemed to be intrinsic to the information object.
Filter
A link that assigns properties to an information object for purposes other than navigation. For example, depending of properties assigned to them by a filter, objects may be selected or ignored by an application.
Hub document
The HyTime document in which access to a hyperdocument begins.
HyTime hyperlink
An information structure, defined using architectural forms defined in ISO/IEC 10744:1997, that represents a relationship between two or more objects.
Link
See HyTime hyperlink.
Mnemonic
An alternate representation of content, used for application-dependent processing (for example, alphabetic sorting of a topic by title, as expressed in its mnemonic attribute).
Navigation
Interactive traversal among the anchors of hyperlinks.
Occurrence role
See anchor role.
Property Assignment
See Assignable property. Two property assignments are defined in this international standard: topical assignment (topic) and filtering assignment (filter).
TNM engine
An application that can process topic navigation maps.
Topic
A link that relates information objects with common assigned properties for purposes of navigation.
Topic relationship
A link whose anchors are topics only.
Topic title
The text by which a topic is known.

5. Resources

5.1 Parameter entities

<!entity % loc -- Location address forms --
               "anchloc|bibloc|dataloc|fcsloc|linkloc|listloc|
                mixedloc|nameloc|nmsploc|pathloc|proploc|queryloc|
                relloc|treeloc"

5.2 Defining the base element of a Topic Navigation Map

A topic navigation map may form a HyTime hub document. If this is the case, the base document element of the topic navigation map shall conform (except that the list of options provided in each parameter entity may be a subset of that shown) to the following architectural forms:

A Topic Map Engine shall be able to process the following subset of HyTime:

Editor's Note: To do: shrink this list

       <!-- HyTime Topic Navigation Map Document Hub -->
<!entity %
 loc            -- Location address forms --
 "anchloc|bibloc|dataloc|linkloc|listloc|mixedloc|nameloc|
  nmsploc|pathloc|proploc|queryloc|relloc|treeloc"          >
<!entity %
 link           -- Hyperlink forms --
 "varlink"                       >
<!entity %
 resbase        -- Base module resource forms --
 "bosspec"                                                  >
<!entity %
 resloc         -- Location address module resource forms --
 "agrovdef|datatok|grovplan|pgrovdef"                       >
<!entity %
 resschd        -- Scheduling module resource forms --
 "calspec|evsched|extent|extlist|measure"                                  >
<!entity %
 resorce        -- All resource architectural forms --
 "%resbase;|%resloc;|%resschd;"                             >
<!element TNM::hub  -- Topic Navigation Map HyTime hub document element --
           - O ANY +(%loc;|%link;|%resorce;)
-- OptionalAttributes [base]: bos, bosspcat --
-- OptionalAttributes [locs]: dgrvplan --
-- CommonAttributes [GenArc]: dvlatt, etfullnm, id, irefmodl,
 ireftype, lextype --
-- CommonAttributes [base]: dtxtatt, valueref --
-- CommonAttributes [locs]: refctl, refloc, reftype, rflocspn -- >
<!attlist TNM::hub
  TNM      NAME  #FIXED "TNM::hub"
  HyTime   NAME  #FIXED "HyDoc"    >

Note: The formal definition of the elements and attributes defined in this section is provided in Clause 6 of ISO/IEC 10744:1997.

5.3 Topic Navigation Maps Context-Free Content (TNMCFC)

<!entity % TNMCFC "ANY -(TNM::Topic | TNM::TopicRelationship | TNM::Anchspec |  %locs;)" 

Editor's note: Check if this notation is correct.

%TNMCFC; is the TNM equivalent of HyCFC. It includes PCDATA, Images, EMPTY, This is done in order to prevent titles and mnemonic to be separated from each other by indirections.

5.4 Alternate attribute values for localization

Language-dependent attribute names

Use valueref to allow the user to enter a single value for all three attributes.

Use #ALL to concentrate all cuteness in a single location.

<!-- Values for subdvl and sibdvl are taken from selfdvl --
<!-- and selfdvl renamed to Localization in AFDR --

<!attlist
      #ALL
      valueref CDATA #FIXED "subdvl selfdvl sibdvl selfdvl" 
      ArcNames CDATA "selfdvl localization"

6. TNM architectural forms

The Topic Navigation Maps standard defines five architectural forms:

The TNM::Topic, TNM::TopicRelationship, and TNM::Filter architectural forms are derived from the HyTime variable link (varlink) architectural form. A variable link contains anchor specification (anchspec) elements that define each anchor role. Each anchspec contains the location elements that address the members of that anchor.

6.1 Representation of Topics: -- TNM::Topic

A topic is a link that relates information objects with assigned properties in common for purposes of navigation.

Note: For example, in the subject heading index to a printed book, the term topic would encompass both the subject headings and the subject locators (page numbers, in all likelihood.)

A property assigned by a topic map is named by an anchor specification elements contained within the topic map element. Because a topic map may contain an unlimited number of anchor specification elements, it may assign an unlimited number of properties.

The topic element type form (TNM::Topic) may serve as the base architecture for as many link element types as desired in a DTD. Each such element becomes a topic element type. Different topic element types will typically have different sets of anchor specification elements (that is, assign different properties).

Most topic elements will be assigned a unique identifier (id) so that they can become part of a topic navigation map topic relationship (see Clause ???).

Note: Those topic elements that are intended to become part of a topic navigation map topic relationship must have a unique identifier (id). To prepare topic elements that can later play a role in a topic relationship, it is a good practice to assign ids to all topic elements, although this is not an absolute requirement of this standard.

<!element TNM::Topic
          - -
          (TopicTitle*, anchspec*)
          

<!attlist TNM::Topic
          TNM
            NAME TNM::Topic
          HyTime
            NAME
            varlink
          id
            ID
            #IMPLIED     -- Constraint: id is required if topics 
                            are to be anchors of topic relationships. -- 
          linktrav       -- Hyperlink traversal rules -- 
                         -- Traversal between anchors of hyperlinks: A 
                           any traversal or departure (EID) --
            (A|EI|ER|ED|EN|EP|ERD|I|ID|D|N|P|R|RD)
            A
          listtrav       -- List traversal rules -- 
                         -- Traversal between members of list anchors: 
                            A adjacent (both left and right) traversal 
                            W wrapping traversal --
            (A|AW|L|LW|N|R|RW)
            AW           -- Constraint: ignored if anchor is not a list --
>
          

6.2 Topic titles: -- TNM::TopicTitle

The Topic Title architectural form is an anchor specification element (anchspec) containing the address of the element(s) by which a topic is known.

Note: As in SGML, the element pointed to by a topic title may be in any notation. Thus, a graphic or sound could become a topic title.

Note: The element containing the title may be inside or outside the topic map document.

Note: A topic may require multiple titles to create alternative entry points in a single language (for example, "Art Museum" and "Museum of Art"), or to provide titles in different languages.

A mnemonic attribute may be attached to the topic title anchor specification element, to allow a short name to be given to a title. Where no mnemonic is assigned, the contents of the title element will be used as the mnemonic. The way in which the value of the mnemonic attribute may be used is application-dependent.

Note: For example, values of the mnemonic attribute may be used to control the order in which topics that are entries in a subject index are to be sorted.

<!element TNM::TopicTitle
         - -
         (%loc;)>
         
<!attlist TNM::TopicTitle -- TNM::TopicTitle -- 
                          -- attributes used to identify titles associated 
                             with Topic Navigation Map Topics --
                          -- Clause ???? --
         TNM
           NAME
           "TNM::TopicTitle"
         HyTime
           NAME
           "anchspec"
         mnemonic        -- The short name for the title text --
           CDATA
           #IMPLIED      -- Default: Content of element --
  	anchrole         -- Anchor role --
           NAME 
           "TNM::TopicTitle" 
                         -- Default: for anchspec, anchor role is GI of element --
                         -- Default: for varlink, varlink is not self anchor --
         id
           ID
           #IMPLIED       -- Id may be useful to apply filters on titles --
>
         

6.3 Representation of relationships between topics: -- TNM::TopicRelationship

A topic is a link that relates topics with assigned properties in common for purposes of navigation.

Any number of relationships can exist between any two or more topics.

A property assigned by a topic relationship is named by an anchor specification elements contained within the topic relationship element. Because a topic relationship may contain an unlimited number of anchor specification elements, it may assign an unlimited number of properties.

The topic relationship element type form (TNM::TopicRelationship) may serve as the base architecture for as many link element types as desired in a DTD. Each such element becomes a topic relationship element type. Different topic element relationship types will typically have different sets of anchor specification elements (that is, assign different properties).

All other attributes in this architectural form have the same role as for the TNM::Topic element type architectural form (see Clause ????).

<!element TNM::Topicrelationship
          - -
          (anchspec,anchspec+)
          
<!attlist TNM::Topicrelationship
          TNM
            NAME
            TNM::topicrelationship
          HyTime
            NAME
            varlink
          id
            ID
            #IMPLIED
          linktrav       -- Hyperlink traversal rules -- 
                         -- Traversal between anchors of hyperlinks:
                            A any traversal or departure (EID) --
            (A|EI|ER|ED|EN|EP|ERD|I|ID|D|N|P|R|RD)
            A
          listtrav       -- List traversal rules -- 
                         -- Traversal between members of list anchors: 
                            A adjacent (both left and right) traversal 
                            W wrapping traversal --
            (A|AW|L|LW|N|R|RW)
            AW           -- Constraint: ignored if anchor is not a list --
          

6.4 Representation of Filters: -- TNM::Filter

A filter is a link that relates topics with assigned properties in common for purposes that are not navigational.

Note: For example, a language filter might be used to select (or ignore) anchors with an "English" property for subsequent viewing or traversal in a topic map.

Note: If a topic map can be thought of as an overlay, a filter can be thought of as a mask.

There are no constraints on the information objects that can be pointed to by filters. Filters can point to topics, to topic relationships, to anchor specification elements, to titles, etc.

The behavior of filters is left to the application designer. Topic Map Engines will be able to process the information pointed to by filter links by providing the necessary data that allow applications to build partial views, to extract portions or to provide selection mechanisms to users. Examples of filters include "Domain", "Language", "User profile", "Weighting", "Time-validity", "Security".

Note: Since the filter architectural form disables traversal, it is not possible to use the filter for navigation.

<!element TNM::Filter
          - -
          (anchspec)+
          
<!attlist TNM::Filter
          TNM
            NAME
            TNM::Filter
          HyTime
            NAME
            varlink
          id
            ID
            #IMPLIED
          linktrav            -- Hyperlink traversal rules --
                              -- Traversal between anchors of hyperlinks: 
                                 N no traversal after internal arrival. --
            (N)               -- Filters are not for traversal. --
             N                
          listtrav            -- List traversal rules --
                              -- Traversal between members of list anchors: 
                                 N no traversal --
            (N)               -- Filters are not for traversal. --
             N                -- Constraint: ignored if anchor is not a list --
>
           

6.5 Anchor Specification: -- TNM::AnchSpec

An anchor specification defines the anchor roles of, and contains the locators for, topic maps, topic relations, and filters. In a topic map, an anchor role names a property assigned to the information objects addressed by its locators.

Note: This standard places no restriction on location addressing methods. Located anchor addresses can be shared by different topics.

Editor's note. SH: Would it be more elegant to do this using a filter?

Editor's note. MBz: Yes, this would be clearer to explain (and probably easier to implement). To do: Study this possibility.

When a value for the "localization" attribute is not present, the generic identifier of the anchor specification names the assignable property (the anchor role) by default. Otherwise, the value must be the ID of an element conforming to the HyTime dvlist element form, which is a list of attribute specifications. These specifications are used to supply an assignable property name (the anchor role) to replace the default name. In this way, multilingual anchor roles are enabled.

Note: This is made possible by using the selfdvl, subdvl, and sibdvl (self-, subelement- and siblings default value list) architectural forms in HyTime. Subdvl and sibdvl take the same value as selfdvl (using the valueref attribute), and "selfdvl" is renamed "localization" (see 5.3).

The "multmem" attribute consolidates several anchors into one object by having the value "list". This value can be changed at the DTD level, if the application requires each anchor to be treated separately. However, if two anchspecs have the same generic identifier, none of them can have multmem=single.

<!element TNM::Anchspec
          - O
          (%loc;)*
          


<!attlist TNM::Anchspec -- Location address forms -- 
                        -- Reference -- 
                        -- Note: Use of refloc facility required -- 
          HyTime
            NAME
            anchspec
          anchrole
            NAME
            #IMPLIED     -- Default: for anchspec, anchor role is GI of element --
          localization   -- Points directly to a specification for alternate
                              anchrole names -- 
            IDREFS
            #IMPLIED
          multmem        -- May anchor have multiple members? -- 
            (single|list|corlist)
            list
>
          

Informative Annex A: Sample Topic Maps

Typographic conventions used in the examples are:

Example 1. One Topic Instance, using HyTime Location Addressing

This example declares that "Venice" is an instance of a topic belonging to the type "city".

This topic is a link that has two anchor roles: "title", and "description".

The title anchor points to an element called title, which is the title for the element. It contains the "name" of the topic, i.e. "Venice".

The description anchor points to two elements identified by the unique identifiers "id3" and "id4" which are located within a document whose entity name is "doc1", and to an element identified by the unique identifier "id5" located within a document whose entity name is "doc2".

Note: The following addressing markup is not optimized for saving space. Many alternatives are possible. It shows the syntax of addressing aggregates in multiple documents using HyTime 1997 architectural forms.

Note that this international standard provides a common representation for linking semantics. The syntax of addressing is left to the application. The DTD used to represent the topic map information is application-specific, and is only given here as an example. What matters for ISO 13250 conformance is the use of TNM architectural forms, but not the DTD itself.

Document Instance

<Topicmap>
<TopicTitle id=id1>Venice</TopicTitle>
<City id=Ven>
  <TitleAnchor mnemonic=Venice id=tit1>
   <mixedloc>
    <nmsploc>id1</nmsploc>
   </mixedloc>
  </TitleAnchor>
  <DescriptionAnchor>
   <mixedloc>
    <nmsploc locsrc=doc1>id3 id4</nmsploc>
    <nmsploc locsrc=doc2>id5</nmsploc>
   </mixedloc>
  </DescriptionAnchor>
</City>
</Topicmap>

DTD

<!DOCTYPE TopicMap [

<!ELEMENT TopicMap - - ( (TopicTitle*, City) | (TopicTitle*, Country) )+ >

<!-- Topic Titles -->

<!ELEMENT TopicTitle - - (#PCDATA) >
<!ATTLIST TopicTitle
	id	ID	#REQUIRED
>

<!-- Topics -->

<!ELEMENT City - - (TitleAnchor,DescriptionAnchor?) >
<!ATTLIST City
	tnm	NAME	TNM::Topic
	HyTime	NAME	varlink
	id	ID	#IMPLIED
>
<!ELEMENT Country - - (TitleAnchor,MentionAnchor?, HistoryAnchor?) >
<!ATTLIST Country
	tnm	NAME	TNM::Topic
	HyTime	NAME	varlink
	id	ID	#IMPLIED
>

<!-- Anchors -->

<!ELEMENT TitleAnchor - - (mixedloc) >
<!ATTLIST TitleAnchor
	tnm	 NAME	 TNM::TopicTitle	#FIXED
	mnemonic CDATA   #IMPLIED
	id	 ID	 #IMPLIED
	HyTime	 NAME	 anchspec
>
<!ELEMENT DescriptionAnchor - - (mixedloc) >
<!ATTLIST DescriptionAnchor
	tnm	 NAME	TNM::Anchspec
	HyTime	 NAME	anchspec
	anchrole NAME	 Description
>
<!ELEMENT MentionAnchor - - (mixedloc) >
<!ATTLIST MentionAnchor
	tnm	 NAME	TNM::Anchspec
	HyTime	 NAME	anchspec
	anchrole NAME	 Mention
>
<!ELEMENT HistoryAnchor - - (mixedloc) >
<!ATTLIST HistoryAnchor
	tnm	 NAME	TNM::Anchspec
	HyTime	 NAME	anchspec
	anchrole NAME	 History
>

<!-- Addresses -->

<!ELEMENT mixedloc - - (nmsploc)+ >
<!ATTLIST mixedloc
	HyTime	NAME	mixedloc
>
	
<!ELEMENT nmsploc - - (#PCDATA) >
<!ATTLIST nmsploc
	HyTime	NAME	nmsploc
	locsrc	CDATA	#IMPLIED
>
]>

Example 2. Same topic with different address syntax.

This example uses the TEI Xpointers syntax to address elements in external documents.

Document Instance

<TopicMap>
<TopicTitle id=id1>Venice</TopicTitle>
<City id=Ven>
  <TitleAnchor mnemonic=Venice id=tit1>
    <ptr target=id1>
  </TitleAnchor>
  <DescriptionAnchor>
    <xptr doc=doc1 from='id (id3)'>
    <xptr doc=doc1 from='id (id4)'>
    <xptr doc=doc2 from='id (id5)'>
  </DescriptionAnchor>
</City>
</TopicMap>

DTD

<!DOCTYPE TopicMap [

<!ELEMENT TopicMap - - ( (TopicTitle*, City) | (TopicTitle*, Country) )+ >

<!ELEMENT TopicTitle - - (#PCDATA) >
<!ATTLIST TopicTitle
	id	ID	#REQUIRED
>
<!ELEMENT City - - (TitleAnchor, DescriptionAnchor?) >
<!ATTLIST City
	tnm	NAME	TNM::Topic
	HyTime	NAME	varlink
	id	ID	#IMPLIED
>
<!ELEMENT Country - - (TitleAnchor, MentionAnchor?, History?) >
<!ATTLIST Country
	tnm	NAME	TNM::Topic
	HyTime	NAME	varlink
	id	ID	#IMPLIED
>

<!-- Anchors -->

<!ELEMENT TitleAnchor - - (ptr)+ >
<!ATTLIST TitleAnchor
	tnm	 NAME	TNM::TopicTitle
	HyTime	 NAME	anchspec
	mnemonic CDATA	 #IMPLIED
>
<!ELEMENT DescriptionAnchor - - (xptr)+ >
<!ATTLIST DescriptionAnchor
	tnm	NAME	TNM::Anchspec
	HyTime	NAME	anchspec
>
<!ELEMENT MentionAnchor - - (xptr) >
<!ATTLIST MentionAnchor
	tnm	NAME	TNM::Anchspec
	HyTime	NAME	anchspec
>
<!ELEMENT HistoryAnchor - - (xptr) >
<!ATTLIST HistoryAnchor
	tnm	NAME	TNM::Anchspec
	HyTime	NAME	anchspec
>
<!-- TEI DTD -->
<!-- ptr (pointer) used for titles, required here to be in the
        topic map document -->
<!-- xptr (extended pointer) used for addressing anchors in
        external documents -->

<!ELEMENT ptr - O EMPTY>

<!ATTLIST ptr 
     ana IDREFS #IMPLIED 
     corresp IDREFS #IMPLIED 
     next IDREF #IMPLIED 
     prev IDREF #IMPLIED 
     id ID #IMPLIED 
     n CDATA #IMPLIED 
     lang IDREF #IMPLIED 
     rend CDATA #IMPLIED 
     type CDATA #IMPLIED 
     resp CDATA #IMPLIED 
     crdate CDATA #IMPLIED 
     targType NAMES #IMPLIED 
     targOrder (Y | N | U) "U" 
     evaluate (all | one | none) #IMPLIED 
     target IDREFS #REQUIRED 
     TEIform CDATA "ptr" >


<!ELEMENT xptr - O EMPTY>
<!ATTLIST xptr 
     ana IDREFS #IMPLIED 
     corresp IDREFS #IMPLIED 
     next IDREF #IMPLIED 
     prev IDREF #IMPLIED 
     id ID #IMPLIED 
     n CDATA #IMPLIED 
     lang IDREF #IMPLIED 
     rend CDATA #IMPLIED 
     type CDATA #IMPLIED 
     resp CDATA #IMPLIED 
     crdate CDATA #IMPLIED 
     targType NAMES #IMPLIED 
     targOrder (Y | N | U) "U" 
     evaluate (all | one | none) #IMPLIED 
     doc ENTITY #IMPLIED 
     from CDATA "ROOT" 
     to CDATA "DITTO" 
     TEIform CDATA "xptr" 
>
]>

Note: The examples 1 and 2 are identical for the semantic properties applied to the topic, but they use a different addressing mechanism. The two topic map documents are interchangeable from the perspective of ISO 13250. Interchange may become operational if a mapping mechanism exists between the two forms of addressing. It is outside the scope of this international standard to provide mechanisms for address interchangeability, especially because there are a number of topic map applications which address information stored in proprietary formats. However, interchange is greatly facilitated by the fact that linking semantics is kept separate from addressing semantics.

Example 3. Topic with two titles

In this example, the topic "Venice" has two titles: "Venice" and "Venezia".

3.1 Two title anchors

<TopicTitle id=id1>Venice</TopicTitle>
<TopicTitle id=id2>Venezia</TopicTitle>
<City id=Ven>
  <TitleAnchor mnemonic=Venice id=tit1><nmsploc>id1</nmsploc></TitleAnchor>
  <TitleAnchor mnemonic=Venezia id=tit2><nmsploc>id2</nmsploc></TitleAnchor>
  <DescriptionAnchor>
    <mixedloc>
      <nmsploc locsrc=doc1>id3 id4</nmsploc>
      <nmsploc locsrc=doc2>id5</nmsploc>
    </mixedloc>
  </DescriptionAnchor>
</city>

Editor's note : In this example and the following, insert DTDs.

3.2 Three topics

This example extends the example 3.1 to three topic declarations.

In this example, the optional attribute mnemonic is not present.

Note that Venice has occurrences (descriptions) in some documents, while "Rome" and "Italy" have no occurrences. They are still fully valid topics.

<TopicTitle id=id1>Venice</TopicTitle>
<TopicTitle id=id2>Venezia</TopicTitle>
<City id=Ven>
  <TitleAnchor id=tit1><nmsploc>id1</nmsploc></TopicTitle>
  <TitleAnchor id=tit2><nmsploc>id2</nmsploc></TopicTitle>
  <DescriptionAnchor>
    <mixedloc>
     <nmsploc locsrc=doc1>id3 id4</nmsploc>
     <nmsploc locsrc=doc2>id5</nmsploc>
    </mixedloc>
  </DescriptionAnchor>
</City>
<TopicTitle id=id6>Rome</TopicTitle>
<TopicTitle id=id7>Roma</TopicTitle>
<City id=Rom>
  <TitleAnchor id=tit6><nmsploc>id6</nmsploc></TitleAnchor>
  <TitleAnchor id=tit7><nmsploc>id7</nmsploc></TitleAnchor>
</City>
<TopicTitle id=id8>Italy</TopicTitle>
<TopicTitle id=id9>Italia</TopicTitle>
<Country id=It>
 <TitleAnchor id=tit8><nmsploc>id8</nmsploc></TitleAnchor>
 <TitleAnchor id=tit9><nmsploc>id9</nmsploc></TitleAnchor>
</Country>

4. Topic relationship Example

This examples expresses the fact that Rome and Venice are both in Italy.

In TNM terms, it translates as: The topic "Italy" is related to the topics "Rome" and "Venice" through a topic relationship whose semantics is "containment".

<Containment>
<Container><nmsploc>It</nmsploc></Container>
<Contained><nmsploc>Rom Ven</nmsploc></Contained>
</Containment>

Note: If the DTD does not allow aggregates into topic relationships anchroles, i.e. is limited to one-to-one relationships, the same example could be written instead: Italy contains Venice and Italy contains Rome:


<Containment>
<Container><nmsploc>It</nmsploc></Container>
<Contained><nmsploc>Ven</nmsploc></Contained>
</Containment>

<Containment>
<Container><nmsploc>It</nmsploc></Container>
<Contained><nmsploc>Rom</nmsploc></Contained>
</Containment>

5. Language filter

In the example 3.2, topics have alternate titles. These titles (whose anchor specs are identified by tit1 and tit2) happen to be in different languages. Furthermore, if the element (e.g. a section) which is identified by id3 in doc2 is in English, while the element identified by id4 in doc2 is in Italian, it is possible to describe these properties using a TNM::filter hyperlink for language. Note that hyperlinks enable pointing to elements belonging to various types.

<Language>

<English>
<mixedloc>
<nmsploc>tit1 tit6 tit8</nmsploc>
<nmsploc locsrc=doc1><nmsploc>id3</nmsploc>
</mixedloc>
</English>

<Italian>
<mixedloc>
<nmsploc>tit2 tit7 tit9</nmsploc>
<nmsploc locsrc=doc2><nmsploc>id4 id5</nmsploc>
</mixedloc>
</Italian>

</Language>


Normative Annex B: Architectural Form Definition Requirements specification for Topic Navigation Maps

The architectural form definitions defined in Annex A shall be associated with each SGML document type definition that conforms to this standard.

Note: Normally this will be done by using a parameter reference to point to a file containing a copy of the declarations given in Annex A.

The architectural form definition for topic navigation maps references the architectural form definitions for HyTime. The architectural forms in this standard are identified as being applicable to element type forms defined in the HyTime standard. The attributes defined in the topic navigation map architectural forms extend the set defined for the referenced architectural forms in ISO/IEC 10744:1997, which must also be applied as appropriate for the element types used to define a topic map.

This annex 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 ISO/IEC 10744:1997. The meta-DTD defined by this document starts, therefore, with a (non-processable) markup declaration of the form:

<!AFDR "ISO/IEC 10744:1997">

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 part of the DTD that contains definitions using HyTime or the architectural forms defined in this document as possible, a processing instruction, coded using the document's concrete syntax, whose contents are IS10744 ArcBase TNM HyTime where IS10744 indicates that this standard conforms the the Architectural Form Definition Requirements specified in Annex A of ISO/IEC 10744:1997, 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 an 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:1998//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"
  ArcNamrA       NAME    TNM::name
                         -- Can be used to assign locally
                            meaningful names to TNM attributes --
  ArcDTD         CDATA   #FIXED "TNM::DTD"
  ArcDocF        NAME    "TNM::hub"
  ArcAuto        (ArcAuto|nArcAuto) "nArcAuto"
  ArcQuant       CDATA   #FIXED "NAMELEN 24"
  -- NAMELEN has been extended to 24 to allow "natural" naming
     to be applied to Topic Navigation Map attribute values -- >

Editor's Question: Do we need other attributes here, such as ArcBridF and ArcSuprA (or is the fact that the standard HyTime options are defined in the next section sufficient)? Sam: We don't need ArcBridF because we are doing an overlay. So where's the bridge? What's to suppress? No ArcSuprA either.

Note: Definitions of the attributes defined in this declaration are provided in Annex A of the 2nd Edition of ISO/IEC 10744.

Editor's note (Michel + Sam): We should try to keep this section as small as we can.

The DTD must also contain the following entity definition, with its associated notation declaration, which is referenced by the following architecture support attributes:

<!NOTATION AFDRMeta --AFDR Meta-DTD Notation--
            PUBLIC "ISO/IEC 10744:1997//NOTATION AFDR
                    Meta-DTD Notation//EN" >

<!ENTITY TNM::DTD    -- Meta-DTD for navigation map instances --
            PUBLIC "ISO 13250:1998//DTD AFDR Meta-DTD
                    Topic Navigation Map//EN" CDATA AFDRMeta >

In addition support should be declared for at least a minimal set of HyTime functionality by including the following declarations:

<!-- HyTime Support Declarations -->
<!NOTATION
 HyTime         -- HyTime Architecture --
                -- A base architecture used in conformance with the
                   Architectural Form Definition Requirements of
                   International Standard ISO/IEC 10744. --
 PUBLIC "ISO/IEC 10744:1997//NOTATION AFDR ARCBASE
         Hypermedia/Time-based Structuring Language (HyTime)//EN"
>
<!ATTLIST  #NOTATION HyTime
 ArcFormA NAME     HyTime
 ArcNamrA NAME     HyNames
 ArcSuprA NAME     sHyTime
 ArcIgnDA NAME     HyIgnD
 ArcDocF  NAME     HyDoc
 ArcDTD   CDATA    "HyTime"
 ArcQuant CDATA    #FIXED "NAMELEN 9"
 -- NAMELEN must be at least 9 because the HyTime meta-DTD uses
    8-character parameter entity names. --
 ArcDataF NAME     #FIXED HyBridN
 ArcBridF NAME     #FIXED HyBrid
 ArcAuto  (ArcAuto|nArcAuto) nArcAuto
 ArcOptSA NAMES    "GenArc base locs links"
 GenArc            -- General architecture facilities --
          CDATA    -- Lextype: csname+ --
                   "HyLex ireftype lextype"
 base              -- Base module facilities --
          CDATA    -- Lextype: csname+ --
                   "bos bosspec conloc dimspec HyDimLst HyDimSpc valueref"
 locs              -- Location address module facilities --
                   -- Clause: 6.3 --
          CDATA    -- Lextype: csname+ --
                   "agrovdef bibloc dataloc datatok grovplan listloc mixedloc
                    multloc nameloc nmsploc pathloc pgrovdef proploc queryloc
                    refctl referatt refloc reftype relloc spanloc treecom treeloc
                    treetype"
 links             -- Hyperlinks module facilities --
                   -- Clause: 6.3 --
          CDATA    -- Lextype: csname+ --
                   "agglink anchloc clink hylink ilink linkloc traverse varlink"
 sched             -- Scheduling module facilities --
                   -- Clause: 6.3 --
          CDATA    -- Lextype: csname+ --
                   "calspec dimref grpdex grprepet HyCalSpc HyExSpec
                    HyExtLst HyGrand measure objalign pulsemap sched"
 anysgml           -- Any SGML declaration allowed --
                   -- Clause: 6.3 --
          (anysgml|nanysgml) anysgml
 exrefs            -- External references allowed --
                   -- Clause: 6.3 --
          (exrefs|nexrefs)   exrefs
 refmodel          -- SGML model groups for reftype --
                   -- Clause: 6.3 --
          (SGMLmdl|nSGMLmdl) SGMLmdl
 hyqcnt            -- Highest quantum count limit --
                   -- Clause: 6.3 --
          NUMBER   -- Constraint: power of 2 >= 32  --
                   32
 manyanch          -- Maximum number of anchors allowed in
                      hyperlinks --
                   -- Clause: 6.3 --
          NUMBER   -- Constraint: must be >= 2 --
                   #IMPLIED    -- Default: no limit --
>
<!NOTATION AFDRMeta
 PUBLIC "ISO/IEC 10744:1997//NOTATION AFDR Meta-DTD Notation//EN"
>
<!ENTITY
 HyTime         -- HyTime meta-DTD --
                -- Clause: 6.3 --
                PUBLIC "ISO/IEC 10744:1997//DTD AFDR Meta-DTD
                        Hypermedia/Time-based Structuring Language (HyTime)//EN"
                CDATA AFDRMeta
>

All of the addressing mechanisms allowed by HyTime may be used in the context of this standard. However, each application can limit itself to a more specific list of the options relevant to its context by removing unused options from the declarations given above.


Informative Annex C: TNM Meta-DTD

This annex brings together all of the formal productions of this standard in a form that creates a valid SGML meta-DTD for topic naviation navigation maps.

Note: While the copyright of this standard rests with ISO, the formal SGML definitions provided in this Annex may be copied providing that the following text is included, for example as an SGML comment, with the copy:

(C) International Organization for Standarization 1998.
Permission to copy in any form is granted for use with conforming
Topic Navigation Maps as defined in ISO 13250, providing that
this notice is included with all copies.

The meta-DTD constructs required for Topic Navigation Map processing are:

Editor's note: To be added later.