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 amy give 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.
Topic navigation maps may assign properties to information objects for the following applications, among others:
This standard provides for multilingual topic navigation maps. Property Assignments 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 HyTime hyperlink architectural forms 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.
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.
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:TopicAssociation, TNM:TopicNameLocator, TNM:PropertyAssignment, and optionally TNM:Anchspec(1).
(1)Note:
This form is used in the case Topic Maps are based on the HyTime varlink architectural form.TNM architectures are defined with reference to "SGML enabling architectures", as defined in Annex A of ISO 10744 (HyTime - SGML Extended Facilities).
Editor's note (SH): 1/2/98. so what is duplicative, if not identical to the original, should be removed?
For the purposes of this standard the conventions defined in Clause 5 of ISO/IEC 10744:1997 have been followed.
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.
This standard provides facilities for creating, maintaining and interchanging topic-based navigational aids to large corpora of documents containing interrelated information. This standard makes a distinction between topic navigation maps -- sets of relations between formally defined topics covered in a given corpus -- defined within this standard and the links to, and addresses of, occurrences 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 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 topics, and classifies topics with respect to each other. This standard helps 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 electronic information sets, 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 associations 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 associations 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 associations 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.
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 create, easier to maintain, and easier to use. As new associations 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.
There are many cases where individuals need to create their own classification of the information sets they frequently access. For example, when researching a subject a reader may wish to create his own method for linking relevant files together. This standard, therefore, provides a mechanism by which individuals can create their own 'views' of an information set, or of the associations between topics defined in existing topic navigation maps by other experts.
A topic navigation map defines topics and the associations that they bear to one another. It must, therefore, permit:
to be represented, universally interchanged, processed, merged, and used for data navigation.
In supplement, a topic navigation map assigns properties that apply to information objects, topics and topic assocations and are used for filtering in or out these information components from the current topic map view.
This standard provides SGML architectural forms that can be used in conjunction with the architectural forms defined in the HyTime standard to link topics definitions with information sources so that it can support applications that provide:
Topic navigation maps are defined using TNM:Topic-form attributes that assign a known meaning, universe and weighting to a topic, and TNM:TopicAssociation-form attributes that identify associations between topics, and TNM:PropertyAssignment form attributes that assign properties to information components. Categories of topics may be iteratively 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.
<!entity % loc -- Location address forms --
"anchloc|bibloc|dataloc|fcsloc|linkloc|listloc|
mixedloc|nameloc|nmsploc|pathloc|proploc|queryloc|
relloc|treeloc"
A topic navigation map may form a HyTime hub document. The purpose of a hub document is to give a HyTime engine the necessary information about the notations and entities comprising the hyperdocument. It is the starting point as far as HyTime processing is concerned. However, the hub document does not necessarily correspond to the document used as an entry point for user navigation. This entry point is application-dependent. If a topic navigation map forms a HyTime hub document, 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.
This Topic Navigation Maps standard defines the following SGML architectural forms:
The TNM-Topic, TNM-Member, TNM-TopicAssociation, and TNM-PropertyAssignment
architectural forms can be used to add semantics to any HyTime link type.
The architecture is based on the concept HyTime aggregate links (agglink).
Three variants of the architectural forms are provided in the meta-DTD
to allow users to use topic navigation maps with the HyTime Hyperdocument
Links (hylink), Independent Links (ilink) or
Variable Links (varlink) architectural forms. Annex B explains
the equivalence between the three forms, and shows how how you can map between
the three forms. The following parameter entities can be used to
control which types of links are to be used by an application. For any
application one of these entries will be set to "INCLUDE"
and the other two must be set to "IGNORE".
<!ENTITY % varlink "INCLUDE"> <!ENTITY % hylink "IGNORE"> <!ENTITY % ilink "IGNORE">
For the purposes of the interchange of topic maps, applications should be able
to convert the local storage format to the form of the architecture
derived from a HyTime variable link (varlink) representation.
A TNM-Topic is a HyTime link that relates information objects sharing
semantics for the purposes of navigation. A topic link relates all
information objects "about" a given subject (described by the topic name).
A TNM-Topic link element can optionally have attributes that identify:
TNM-name)
Each of these attributes can either be entered as a single string of SGML character
data contained in an attribute value (TNM-name and TNM-definition), or as a
set of references to the unique identifiers of objects, or object locators,
defined as part of the topic navigation map
(TNM-name-refs and TNM-def-refs) .
Note: As in SGML, elements addressed through a TNM-name-refs
or TNM-def-refs attribute may be in any
notation. Thus, a graphic or sound could become a topic name.
Note: The optional TNM-definition attribute can be used to
disambiguate topic names that could serve more than one purpose. It can
also be used to provide information that would help users to understand
the parameters used to identify the information objects associated
with the topic. More than one definition may be required (e.g. to provide
different language representations of the definitions).
A TNM-Topic may also have associated with it the following optional
attributes:
TNM-Class, which must be assigned the fixed value of TNM-Topic
- ID
TNM-Topic in a TopicAssociation
definition loctype, which indicates which type of references are to be
used to find topic names and definitions.
valueref, which must at least contain the entries
"TNM-name TNM-name-refs TNM-definition TNM-def-refs" to indicate that
the name-refs attribute can be used to refer to element(s)
that contain or locate the value(s) to be assigned to the TNM-name attribute
while TNM-def-refs can be used to refer to element(s) that contain
or locate one or more definitions for the topic.
- TNM-SelectorAssociation
TNM-PropertyAssignment element, which can be used as masks to create
subsets of the topic locations when viewing large lists.
An element that conforms to the HyTime varlink architectural form
will automatically assume the presence of the following fixed attributes,
or attributes with a mimimal specified value:
TNM-Class, which must be assigned the fixed value of TNM-Topic
linktype, which must be assigned the fixed value of agglink to
indicate that the link conforms to the definition of a HyTime aggregate link
HyTime, which must be assigned the fixed value of varlink
to indicate that the element must contain one or more elements that conform
to the HyTime anchspec element type form used by varlink
anchrole, which must be set to agg to indicate
that the link element itself defines the aggregate.<!ENTITY % TopicAttributes
'TNM-Class NAME #FIXED "TNM-Topic"
-- CommonAttributes [GenArc]: id --
TNM-names CDATA #IMPLIED
-- Referential --
-- Points to element(s) containing names used to identify the topic --
TNM-definitions CDATA #IMPLIED
-- Referential --
-- Points to element(s) containing definitions of the topic's subject's --
loctype CDATA "TNM-names IDLOC TNM-definitions IDLOC"'
TNM-SelectorAssociation IDREFS -- Points to SelectorPropertySet elements
that:
a) reference the identifiers of
property assignment type elements that
have been used to assign properties to
located elements
b) identify the names of attributes
of location address elements
c) identify the names of attributes assigned
to located elements
that can be used to manage referenced data --
#IMPLIED
>
<![ %varlink; [
<!element TNM-Topic -- Topic Navigation Map Topic Definition (varlink syntax variant) --
- O (aggmem)+
-- Attributes [links]: ancspcat, agglinkv, varlink, vartrav --
-- CommonAttributes [GenArc]: dafe, dvlatt, etfullnm, id,
ireftype, lextype, opacity --
-- CommonAttributes [base]: activity, conloc, dtxtatt, valueref --
-- CommonAttributes [locs]: refctl, refloc, reftype, rflocspn --
>
<!attlist TNM-Topic
%TopicAttributes;
linktype NAME #FIXED "agglinkv"
>
]]>
<![ %hylink; [
<!element TNM-Topic -- Topic Navigation Map Topic Definition (hylink syntax variant) --
- O (%HyCFC;)
-- Attributes [links]: ancspcat, agglink --
-- OptionalAttributes [link]: traverse --
-- Eliot: Is this correct? --
-- CommonAttributes [GenArc]: dafe, dvlatt, etfullnm, id,
ireftype, lextype, opacity --
-- CommonAttributes [base]: activity, conloc, dtxtatt, valueref --
-- CommonAttributes [locs]: refctl, refloc, reftype, rflocspn --
>
<!attlist TNM-Topic
%TopicAttributes;
linktype NAME #FIXED "agglink"
members IDREFS #REQUIRED
>
]]>
<![ %ilink; [
<!element TNM-Topic -- Topic Map Navigation Topic Definition link (ilink syntax variant) --
(%HyCFC;)
-- Attributes [links]: ilink --
-- OptionalAttributes [links]: traverse --
-- CommonAttributes [GenArc]: dafe, dvlatt, etfullnm, id,
ireftype, lextype, opacity --
-- CommonAttributes [base]: activity, conloc, dtxtatt, valueref --
-- CommonAttributes [locs]: refctl, refloc, reftype, rflocspn --
>
<!attlist TNM-Topic
%TopicAttributes;
linktype NAMES #FIXED "agglinki"
linkends IDREFS #REQUIRED
>
]]>
Mnenmonic attribute to be changed to an element that links the mnemonics can be assigned directly to the named locations.
A mnemonic attribute may be attached to each topic name
referenced in the name-refs attribute to allow a short name
to be given to the name. Where no mnemonic is assigned, the contents of the
referenced element can 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.
<attlist %locs; --Constraint: May only be used in addresses listed
in a name-refs attribute--
TNM-Mnemonic CDATA #IMPLIED
>
A TNM-Member is an element conforming to the
HyTime anchor specification (anchspec) architectural form
used in the varlink variant of the architecture.
A HyTime anchor specification contains HyTime location address elements,
e.g. name space locators (nmsploc) or tree location
(treeloc) locators. Within the definition of a topic
these addresses identify places where information relating to the
topic may be found.
Should we have the following? Optionally each TNM-Member can be assigned
a TNM-role attribute to indicate the role played by
members of the set within the link. By default the element type name
of the element conforming to the TNM-Member architecture
will be used.
TNM-role CDATA #IMPLIED --Default: Element type name --
Note: For topics defined in other forms the names assigned to
anchoroles will be sufficient to identify the role of the anchor specification
within the topic navigation map. For the varlink this is not
possible as the anchrole for an aggregate link must be fixed to "members".
<![ %varlink; [
<!element TNM-Member -- Topic Navigation Map aggregation link member --
(#PCDATA | %HyCFC;)*
-- Attributes [links]: anchspec, ancspcat, aggmem, vartrav --
-- CommonAttributes [GenArc]: dafe, dvlatt, etfullnm, id,
ireftype, lextype, opacity --
-- CommonAttributes [base]: activity, conloc, dtxtatt, valueref --
-- CommonAttributes [locs]: refctl, refloc, reftype, rflocspn -->
<!attlist TNM-Member
TNM-Class NAME #FIXED "TNM-Member"
linktype NAME #FIXED "aggmem"
HyTime NAME #FIXED "anchspec"
anchrole NAME #FIXED "members #LIST"
loctype CDATA "#CONTENT IDLOC"
TNM-role CDATA #IMPLIED -- Default: Element name --
>
]]>
Question: Does ilink need something to identify the roles of the locators referenced in the linkends attribute.
A TNM-TopicAssociation is a link that relates topics and assigns
association semantics for purposes of navigation.
Any number of associations can exist between any two or more topics.
Note: The topic association element type form
(TNM-TopicAssociation) may serve as the base architecture for
as many link element types as desired in a document type definition (DTD).
Each such element becomes a topic association element type.
Different topic element association types
will typically have different sets of anchor specification elements
(that is, assign different semantics).
A TNM-TopicAssociation is a record of a relationship. It points to one or
more location address elements of TNM-Topics or TNM-TopicAssociations that
are linked by the association.
Note: This constraint is formally defined by the inclusion of a
Hytime reftype attribute in the definition of the
TNM-TopicAssociation architectural definition.
The HyTime linktype attribute indicates the type of
relationship being associated with the linked addresses. If no value is
specified, the name of the element type using this architectural form is
assumed to identify the type of relationship.
Other attributes are defined as for the TNM-Topic
architectural form, or are inherited from HyTime.
>!ENTITY TopicAssociationAttributes
'TNM-Class NAME #FIXED "TNM-TopicAssociation"
-- CommonAttributes [GenArc]: id --
reftype (TNM-Topic|TNM-TopicAssociation|TNM-PropertyAssignment) #IMPLIED
TNM-names CDATA #IMPLIED
-- Referential --
-- Points to element(s) containing names used to identify the topic --
TNM-definitions CDATA #IMPLIED
-- Referential --
loctype CDATA "TNM-Names IDLOCS TNM-definitions IDLOC"'
TNM-SelectorAssociation IDREFS -- Points to SelectorPropertySet elements
that:
a) reference the identifiers of
property assignment type elements that
have been used to assign properties to
located elements
b) identify the names of attributes
of location address elements
c) identify the names of attributes assigned
to located elements
that can be used to manage referenced data --
#IMPLIED
>
<![ %varlink; [
<!element TNM-TopicAssociation -- Topic Navigation Map Topic Association (varlink syntax variant) --
- O (anchspec)+
-- Attributes [links]: ancspcat, varlink, vartrav --
-- CommonAttributes [GenArc]: dafe, dvlatt, etfullnm, id,
ireftype, lextype, opacity --
-- CommonAttributes [base]: activity, conloc, dtxtatt, valueref --
-- CommonAttributes [locs]: refctl, refloc, reftype, rflocspn --
>
<!attlist TNM-TopicAssociation
%TopicAssociationAttributes;
linktype NAME #FIXED "varlink"
>
]]>
<![ %hylink; [
<!element TNM-TopicAssociation -- Topic Navigation Map Topic Association (hylink syntax variant) --
- O (%HyCFC;)
-- Attributes [links]: hylink --
-- OptionalAttributes [links]: traverse --
-- CommonAttributes [GenArc]: dafe, dvlatt, etfullnm, id,
ireftype, lextype, opacity --
-- CommonAttributes [base]: activity, conloc, dtxtatt, valueref --
-- CommonAttributes [locs]: refctl, refloc, reftype, rflocspn --
>
<!attlist TNM-TopicAssociation
%TopicAssociationAttributes;
linktype NAME #FIXED "hylink"
>
]]>
<![ %ilink; [
<!element TNM-TopicAssociation -- Topic Map Navigation Topic Association link (ilink syntax variant) --
- O (%HyCFC;)*
-- Attributes [links]: ilink --
-- OptionalAttributes [links]: traverse --
-- CommonAttributes [GenArc]: dafe, dvlatt, etfullnm, id,
ireftype, lextype, opacity --
-- CommonAttributes [base]: activity, conloc, dtxtatt, valueref --
-- CommonAttributes [locs]: refctl, refloc, reftype, rflocspn --
>
<!attlist TNM-TopicAssociation
%TopicAssociationAttributes;
linktype NAME #FIXED "ilink"
linkends IDREFS #REQUIRED
>
]]>
A property assignment is a link that relates topics with shared assigned properties.
Note: Such links can be used for purposes other than navigation, e.g. for filtering. For example, a language property assignment 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 property assignment can be thought of as a mask.
There are no constraints on the information objects to which properties can be assigned. These include topics, topic associations, anchor specification elements, names, documents, elements in documents, etc.
Note: The behavior of information objects to which property have been assigned is left to the application designer. Topic Map Engines will be able to process the information pointed to by property assignment 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 property assignments include "Domain", "Language", "User profile", "Weighting", "Time-validity", "Security".
Note: Since the property assignment architectural form disables traversal, it is not possible to use the property assignment for navigation.
A TNM-PropertyAssignment has the following TNM-specific attributes:
TNM-Class, which identifies that the associated element is
a TNM-TopicAssociation
TNM-PropertyNames, which identifies the locator of the name(s)
that are used to describe the property TNM-PropertyValue, which identifies the locator of the definition the value
to be assigned to the property. Question: Should this be a pointer, or just a CDATA attribute?
The locations of the data to which the properties are to be assigned are defined according to the type of link being used.
<!ENTITY % PropertyAssignmentAttributes
'TNM-Class NAME #FIXED "TNM-PropertyAssignment"
-- CommonAttributes [GenArc]: id --
TNM-names CDATA #IMPLIED
-- Referential --
TNM-definitions CDATA #IMPLIED
-- Referential --
loctype CDATA "TNM-names IDLOC TNM-definitions IDLOC"'
>
<![ %varlink; [
<!element TNM-PropertyAssignment -- Topic Navigation Map Property Assignment link (varlink syntax variant) --
- O (aggmem)+
-- Attributes [links]: ancspcat, agglinkv, varlink, vartrav --
-- CommonAttributes [GenArc]: dafe, dvlatt, etfullnm, id,
ireftype, lextype, opacity --
-- CommonAttributes [base]: activity, conloc, dtxtatt, valueref --
-- CommonAttributes [locs]: refctl, refloc, reftype, rflocspn --
>
<!attlist TNM-PropertyAssignment
%PropertyAssignmentAttributes;
linktype NAME #FIXED "agglinkv"
>
]]>
<![ %hylink; [
<!element TNM-PropertyAssignment -- Topic Navigation Map Property Assignment link (hylink syntax variant) --
- O (%HyCFC;)+
-- Attributes [links]: ancspcat, agglink
-- OptionalAttributes [links]: traverse --
-- CommonAttributes [GenArc]: dafe, dvlatt, etfullnm, id,
ireftype, lextype, opacity --
-- CommonAttributes [base]: activity, conloc, dtxtatt, valueref --
-- CommonAttributes [locs]: refctl, refloc, reftype, rflocspn --
>
<!attlist TNM-PropertyAssignment
%PropertyAssignmentAttributes;
linktype NAME #FIXED "agglink"
members IDREFS #REQUIRED
>
]]>
<![ %ilink; [
<!element TNM-PropertyAssignment -- Topic Map Navigation Property Assignment link (ilink syntax variant) --
(%HyCFC;)
-- Attributes [links]: ilink --
-- OptionalAttributes [links]: traverse --
-- CommonAttributes [GenArc]: dafe, dvlatt, etfullnm, id,
ireftype, lextype, opacity --
-- CommonAttributes [base]: activity, conloc, dtxtatt, valueref --
-- CommonAttributes [locs]: refctl, refloc, reftype, rflocspn --
>
<!attlist TNM-PropertyAssignment
%PropertyAssignmentAttributes;
linktype NAMES #FIXED "agglinki"
linkends IDREFS #REQUIRED
>
]]>
The TNM-SelectorPropertySet architectural form can be used
to define elements which identify the names of properties that can be
used to create subsets of the topics. Such subsets will make it easier for
users to find the information they need where topics are associated with
large numbers of information sources.
Note: TNM-SelectorPropertySet elements allow sets of properties
to be shared between topics, and topic associations, without having to be
defined/managed separately for each element.
To be done: describe attributes check this needs members.
<!ENTITY % SelectorPropertySetAttributes
'TNM-Class NAME #FIXED "TNM-SelectorPropertySet"
TNM-AssignedProperties IDREFS #IMPLIED -- Default: All assigned properties --
TNM-LocatorProperties NAMES #IMPLIED -- Default: None --
Properties-of-Data NAMES #IMPLIED -- Constraint: Name must be defined
as attribute name for an SGML
element that contains the located
elements -- '
>
]]>
Note: Probably to be removed, but needs further discussion
ATNM-LocationAssociationcan be used to define the relationship(s) between two or more data source locations. The contents of theTNM-LocationAssociationare a set of data source locators that identify objects or objects sets to be associated with each other. Each such location will have associated with it, either as part of its definition or through aTNM-PropertyAssignment, aDESCRIPTIONattribute that locates aDescriptionthat describes the role played by the location in the association.
<?IS10744 arch
name="hytime"
arc-public-id="ISO/IEC 10744:1997//NOTATION Hypermedia/Time-based Structuring Language (HyTime)//EN"
dtd-public-id="ISO/IEC 10744:1997//DTD AFDR Meta-DTD Hypermedia/Time-based Structuring Language (HyTime)//EN"
form-att="HyTime"
renamer-att="HyNames"
doc-elem-form="HyDoc"
bridge-form="hybrid"
options="hylink clink agglink varlink ilink nmsploc"
>
<!-- Architectural DTD -->
<!ELEMENT TopicMap
- -
ANY
>
<!ELEMENT ( TNM-Topic | TNM-PropertyAssignment )
- O
(TNM-Member)+
>
<!ATTLIST ( TNM-Topic | TNM-PropertyAssignment )
TNM-Names -- Points to elements used as names for the topic. Referential --
CDATA
#IMPLIED
TNM-Definitions -- Points to elements used as definitions for the topic. Referential --
CDATA
#IMPLIED
loctype
CDATA
"TNM-Names IDLOC TNM-Definitions IDLOC"
-- tells you what kind of location addresses is used for the
attribute called TNM-names and TNM-definitions. --
-- default: IDREFS -
linktype -- we are in a varlink variant --
NAME
#FIXED "agglinkv"
HyTime
NAME
#FIXED "varlink"
anchrole
NAME
#FIXED "agg"
>
<!ELEMENT TNM-TopicAssociation - O
(TNM-Member)+
>
<!ATTLIST TNM-TopicAssociation
-- Reftype: only relates TNM-Topics, TNM-TopicAssociations, and TNM-Property Assignments --
TNM-Names -- Points to elements used as names for the topic. Referential --
CDATA
#IMPLIED
TNM-Definitions -- Points to elements used as definitions for the topic. Referential --
CDATA
#IMPLIED
loctype
CDATA
"TNM-Names IDLOC TNM-Definitions IDLOC"
-- tells you what kind of location addresses is used for the
attribute called TNM-names and TNM-definitions. --
-- default: IDREFS -
linktype -- we are in a varlink variant --
NAME
#FIXED "agglinkv"
HyTime
NAME
#FIXED "varlink"
anchrole
NAME
#FIXED "agg"
>
<!ELEMENT TNM-Member
- O
(#PCDATA)*
>
<!ATTLIST TNM-Member
HyTime
NAME
#FIXED "anchspec"
linktype
NAME
#FIXED "aggmem" -- aggregate members --
anchrole
NAME
#FIXED "members #LIST" -- check whether we need it. --
loctype
CDATA
"#CONTENT IDLOC" -- The content of an element is interpreted as an ID --
TNM-role -- Semantic of the grouping --
CDATA
#IMPLIED -- default: element name --
>
<!ELEMENT TNM-TopicAssociation
- -
(TNM-Member+)
-- reftype: can only point to topic elements. Check with Eliot --
>
<!ATTLIST TNM-TopicAssociation
HyTime
NAME
#FIXED "varlink"
linktype
NAME
#IMPLIED -- Default: element type name --
>
<!-- Why do we need this ? -->
<!ELEMENT TNM-TopicmapBridge
- -
(#PCDATA | TNM-TopicmapBridge)*
>
<!ATTLIST TNM-TopicmapBridge
ID
ID
#IMPLIED
>
<!DOCTYPE MyTopicMap [
<?IS10744 arch name="topicmap"
public-id="ISO/IEC 13250//NOTATION Topic Map Navigation//EN"
dtd-system-id="topicmaparch.dtd"
renamer-att="TNMnames"
options="nmsploc ... " -- insert here all necessary
addressing facilities of HyTime --
>
<!-- This is an external document in which the name of Gaudi is to be found -->
<!ENTITY doc2 SYSTEM "doc2.sgm" NDATA SGML >
<!ELEMENT MyTopicMap
- -
ANY
>
<!ATTLIST MyTopicMap
topicmap
NAME
#FIXED "topicmap"
>
<!ELEMENT Para
- -
(#PCDATA)
>
<!ATTLIST Para
ID
ID
#IMPLIED
topicmap
NAME
#FIXED "topicmap-bridge"
>
<!ELEMENT Painter
- -
((Name|nmsploc)* ,
(Mentions |
Works)+)
>
<!ATTLIST Painter
id
ID
#REQUIRED
TNM-names
IDREFS #REQUIRED
topicmap
NAME
#FIXED "topic"
>
<!ELEMENT Name
- -
(#PCDATA)
>
<!ATTLIST Name
id
ID
#REQUIRED
>
<!ELEMENT nmsploc
- -
(#PCDATA)
>
<!ATTLIST nmsploc
HyTime NAME #FIXED nmsploc
locsrc ENTITY #IMPLIED
namespc CDATA elements
id ID #REQUIRED
>
<!-- reflevel can be used to restrict the number of levels of indirections -->
<!ELEMENT Mentions
- O
EMPTY
>
<!ATTLIST Mentions
topicmap
NAME
#FIXED "TopicMember"
members
IDREFS
#REQUIRED
TNMnames
CDATA
"#ARCCONT members"
>
<!ELEMENT InfluencedBy
- -
(anchspec+)
>
<!ATTLIST InfluencedBy
topicmap
NAME
#FIXED "topic-association"
>
<!ELEMENT anchspec
- -
(#PCDATA)
>
<!ATTLIST anchspec
anchrole
NAME
#REQUIRED
topicmap
NAME
#FIXED "anchspec"
loctype
CDATA
#FIXED "#CONTENT IDLOC"
>
<!ELEMENT (OilPaintings | Watercolors | Sketches)
- O
((name|nmsploc)*,
Mentions+)
>
<!ATTLIST (OilPaintings | Watercolors | Sketches)
id
ID
#REQUIRED
names
IDREFS
#REQUIRED
TNM-Class
NAME
#FIXED "TNM-Topic"
>
<!ELEMENT Works
- O
EMPTY
>
<!ATTLIST Works
TNM-Class
NAME
#FIXED "TNM-Member"
members
IDREFS
#REQUIRED
TNMnames
CDATA
"#ARCCONT members"
>
]>
<!-- 1. Most restrictive policy: only addressing by name is allowed
obvious to implement
not general
2. No restriction on addressing
difficult to implement
general
-->
<!-- Conforming interchange topic map application :
Conforming TNM: specific TNM instances, but not all (e.g., varlink-based)
Conforming TNM-engine: any valid TNM document.
-->
<MyTopicMap>
<!--
Main Topics
-->
<Painter id="picasso" names="picasso-name" definitions="picasso-def-en picasso-def-fr">
<!-- 1.Names -->
<name id="picasso-name">Picasso</name>
<!-- Direct reference to a name in the current document -->
<!-- names is the attribute that assigns name(s) to the topic
by pointing to a user-defined element containing the actual name,
or containing the addresses of all names used for the topic.
-->
<!-- name is an element (not address element) -->
<!-- name and bio are non-architectural element types -->
<!-- 2. Definitions -->
<bio id="picasso-def-en">Spanish painter and sculptor (1881-1973), who left Spain after the Civil War.</bio>
<bio id="picasso-def-fr">Peintre et sculpteur espagnol (1881-1973)</bio>
<!-- 3. Topic aggregate members -->
<Mentions members="pic1 pic2 pic3">
<Works members="pic-oils pic-sketches">
</Painter>
<!-- Put in the DTD
-- check notation declaration --
-->
<Painter id="gaudi" names="gaudi-name">
<!-- Here the name of Gaudi is to be found in an external document doc2 -->
<nmsploc id="gaudi-name" locsrc="doc2">Gaudi</nmsploc>
<Mentions members="gaudi1 gaudi2">
</Painter>
<!--
Sub Topics
-->
<!-- Question: Number of resolution levels has an impact on the topic map engines -->
<OilPaintings id="pic-oils" names="OilPicasso HuilePicasso">
<Name id="OilPicasso">Oil Paintings by Picasso</Name>
<Name id="HuilePicasso">Peintures à l'huile de Picasso</Name>
<Mentions members="pic-oil-1 pic-oil-2">
</OilPaintings>
<Sketches id="pic-sketches" names="SketchPicasso">
<Name id="SketchPicasso">Sketches by Picasso</Name>
<Mentions members="pic-sketch-1">
</Sketches>
<!--
Topic Associations
-->
<InfluencedBy>
<anchspec anchrole="influencee">Picasso</anchspec>
<anchspec anchrole="influencer">gaudi</anchspec>
</InfluencedBy>
<!--
Mentions of things in topics
-->
<Para id= "pic1">Picasso</Para>
<Para id="pic-oil-1">A painting</Para>
<Para id="pic-oil-2">Another painting</Para>
<Para id="pic-sketch-1">A sketch</Para>
<Para id= "pic2">Picasso</Para>
<Para id= "pic3">Picasso</Para>
<para id="gaudi1">Gaudi</Para>
<para id="gaudi2">Gaudi</Para>
<PropertyAssignment names="language-name" def-refs="languages-def">
<property-name id="language-name">Language</property-name>
<property-definition id="languages-def">Thing that is spoken by a group.</property-definition>
<anchspec property-value="english">Picasso Gaudi picasso-def-en ...</anchspec>
<anchspec property-value="french">Picasso Gaudi picasso-def-fr ...</anchspec>
</PropertyAssignment>
<!-- Note: it is possible to split the anchspecs into groups that collect the elements of the same type and still get the same result globally.
<anchspec property-value = "english" type="name">Picasso Gaudi</anchspec>
<anchspec property-value = "english" type="def">picasso-def-en ...</anchspec>
<anchspec property-value = "french" type="name">Picasso Gaudi</anchspec>
<anchspec property-value = "french" type="def">picasso-def-fr ...</anchspec>
End of Note -->
</MyTopicMap>
<!DOCTYPE HYDOC PUBLIC "ISO/IEC 10744:1997//DTD AFDR Meta-DTD Hypermedia/Time-based Structuring Language (HyTime)//EN"> <HYDOC> <VARLINK ANCHROLE="AGG" LINKTYPE="AGGLINK"> <ANCHSPEC ANCHROLE="MEMBERS">PIC1 PIC2 PIC3</ANCHSPEC> <ANCHSPEC ANCHROLE="MEMBERS">PIC-OILS PIC-SKETCHES</ANCHSPEC> </VARLINK> <VARLINK ANCHROLE="AGG" LINKTYPE="AGGLINK"> <ANCHSPEC ANCHROLE="MEMBERS">GAUDI1 GAUDI2</ANCHSPEC> </VARLINK> <VARLINK ANCHROLE="AGG" LINKTYPE="AGGLINK"> <ANCHSPEC ANCHROLE="MEMBERS">PIC-OIL-1 PIC-OIL-2</ANCHSPEC> </VARLINK> <VARLINK ANCHROLE="AGG" LINKTYPE="AGGLINK"> <ANCHSPEC ANCHROLE="MEMBERS">PIC-SKETCH-1</ANCHSPEC> </VARLINK> <VARLINK> <ANCHSPEC ANCHROLE="INFLUENCEE">Picasso</ANCHSPEC> <ANCHSPEC ANCHROLE="INFLUENCER">gaudi</ANCHSPEC> </VARLINK> <HYBRID ID="PIC1"> </HYBRID> <HYBRID ID="PIC-OIL-1"> </HYBRID> <HYBRID ID="PIC-OIL-2"> </HYBRID> <HYBRID ID="PIC-SKETCH-1"> </HYBRID> <HYBRID ID="PIC2"> </HYBRID> <HYBRID ID="PIC3"> </HYBRID> <HYBRID ID="GAUDI1"> </HYBRID> <HYBRID ID="GAUDI2"> </HYBRID> </HYDOC>
<!DOCTYPE TOPICMAP SYSTEM "topicmaparch.dtd"> <TOPICMAP><TOPIC LOCTYPE="name-ref treeloc"> <TOPICMEMBER>PIC1 PIC2 PIC3</TOPICMEMBER> <TOPICMEMBER>PIC-OILS PIC-SKETCHES</TOPICMEMBER> </TOPIC> <TOPIC LOCTYPE="name-ref treeloc"> <TOPICMEMBER>GAUDI1 GAUDI2</TOPICMEMBER> </TOPIC> <TOPIC LOCTYPE="name-ref treeloc"> <TOPICMEMBER>PIC-OIL-1 PIC-OIL-2</TOPICMEMBER> </TOPIC> <TOPIC LOCTYPE="name-ref treeloc"> <TOPICMEMBER>PIC-SKETCH-1</TOPICMEMBER> </TOPIC> <TOPIC-ASSOCIATION> <ANCHSPEC ANCHROLE="INFLUENCEE">Picasso</ANCHSPEC> <ANCHSPEC ANCHROLE="INFLUENCER">gaudi</ANCHSPEC> </TOPIC-ASSOCIATION> <TOPICMAP-BRIDGE ID="PIC1">Picasso</TOPICMAP-BRIDGE> <TOPICMAP-BRIDGE ID="PIC-OIL-1">A painting</TOPICMAP-BRIDGE> <TOPICMAP-BRIDGE ID="PIC-OIL-2">Another painting</TOPICMAP-BRIDGE> <TOPICMAP-BRIDGE ID="PIC-SKETCH-1">A sketch</TOPICMAP-BRIDGE> <TOPICMAP-BRIDGE ID="PIC2">Picasso</TOPICMAP-BRIDGE> <TOPICMAP-BRIDGE ID="PIC3">Picasso</TOPICMAP-BRIDGE> <TOPICMAP-BRIDGE ID="GAUDI1">Gaudi</TOPICMAP-BRIDGE> <TOPICMAP-BRIDGE ID="GAUDI2">Gaudi</TOPICMAP-BRIDGE></TOPICMAP>
This example shows how three topics can be created and linked together using XML Links conforming to the Topic Navigation Map architecture to point to data stored in a set of HTML files. To make it easier to relate this example to the architecture the element names in the example are the same as the architectural form names. Filter property assignments are used to qualify relevance characteristics on the data sources.
The figure represents the three topics (SGML, XML, HTML) associated through a topic association to another topic, SGML uses. Each topic points to three aggregates of information objects: name, definition, and data source. The data sources contain URL to various Web sites.
For the sake of simplification, the filters used to qualify relevance of each data source are not represented on the figure.
Note. The element "Description" used in the document instance contains the name and definition for each topic. It is present here for the sake of clarity, but it is not imposed by the standard. In general, ISO 13250 does not impose any specific DTD and element containment, but only standardizes the attributes that are required for topic navigation information.
<?IS10744 arch
name="hytime"
arc-public-id="ISO/IEC 10744:1997//NOTATION Hypermedia/Time-based Structuring Language (HyTime)//EN"
dtd-public-id="ISO/IEC 10744:1997//DTD AFDR Meta-DTD Hypermedia/Time-based Structuring Language (HyTime)//EN"
form-att="HyTime"
renamer-att="HyNames"
doc-elem-form="HyDoc"
bridge-form="hybrid"
options="hylink clink agglink varlink ilink nmsploc"
>
<!-- Architectural DTD -->
<!ELEMENT TopicMap
- -
(Topic+, Description+, TopicAssociation*, Filters*)
>
<!ELEMENT Topic
- O
(TopicMember)+
>
<!ATTLIST Topic
name
CDATA
#IMPLIED -- Constraint: Must not be specified if
name-refs is specified. --
name-refs -- Referential --
CDATA
#IMPLIED -- Constraint: Must not be specified if
name is specified. --
definition
CDATA
#IMPLIED -- Constraint: Must not be specified if
def-refs is specified. --
def-refs -- Constraint: Must not be specified if
definition is specified. --
CDATA
#IMPLIED
loctype
CDATA
"name-refs IDLOC"
valueref
CDATA
"name name-ref"
linktype
NAME
#FIXED "agglink"
HyTime
NAME
#FIXED "varlink"
anchrole
NAME
#FIXED "agg"
>
<!ELEMENT TopicMember
- O
(#PCDATA)*
>
<!ATTLIST TopicMember
HyTime
NAME
#FIXED "anchspec"
anchrole
NAME
#FIXED "members"
loctype
CDATA
"#CONTENT IDLOC"
>
<!ELEMENT anchspec
- -
(#PCDATA)
>
<!ATTLIST anchspec
anchrole
NAME
#REQUIRED
loctype
CDATA
"#CONTENT IDLOC"
HyTime
NAME
#FIXED "anchspec"
>
<!ELEMENT Topic-Association
- -
(anchspec+)
>
<!ATTLIST Topic-Association
HyTime
NAME
#FIXED "varlink"
linktype
NAME
#IMPLIED -- Default: element type name --
>
<!ELEMENT Topicmap-Bridge
- -
(#PCDATA | Topicmap-Bridge)*
>
<!ATTLIST Topicmap-Bridge
ID
ID
#IMPLIED
>
<!ELEMENT Description (Name+, Definition*) >
<!ATTLIST Description
id ID #IMPLIED
mandator CDATA #IMPLIED -- attribute specific to this example --
created CDATA #IMPLIED -- date: format: YYYYMMDD : specific to this example --
>
<!ELEMENT Name (#PCDATA) >
<!ATTLIST Name
id ID #REQUIRED
>
<!ELEMENT Definition (#PCDATA) >
<!ATTLIST Definition
id ID #REQUIRED
>
<!ELEMENT TopicAssociation (Anchspec+) >
<!ATTLIST TopicAssociation
TNM-class NAME #FIXED "TNM-TopicAssociation"
id ID #IMPLIED
xml:link (simple | extended) extended #FIXED
>
<!ELEMENT Filters (FilterNames, Filter+ >
<!ELEMENT FilterNames (FilterName+) >
<!ATTLIST FilterNames
id ID #IMPLIED
mandator CDATA #IMPLIED
created CDATA #IMPLIED
>
<!ELEMENT FilterName (#PCDATA) >
<!ATTLIST FilterName
id ID #REQUIRED
>
<!ELEMENT Filter (locator+) >
<!ATTLIST Filter
xml:link (simple | extended) extended #FIXED
>
<!-- End of DTD -->
<!-- Start of Document Instance -->
<TopicMap>
<!-- Topics -->
<Topic
id="SGML-topic"
name-refs="SGML-N1 SGML-N2"
def-refs="SGML3 SGML4 SGML5">
<TopicMember>
http://www.ornl.gov/sgml/WG8/wg8home.htm
http://www.isgmlug.org
http://www.sgmlopen.org/sgml/docs/goodies/goodies.htm
</TopicMember>
</Topic>
<Topic
id="XML-topic"
name-ref="XML-N1 XML-N2" def-refs="XML-D1 XML-D2"
>
<TopicMember>
http://www.w3.org/XML
http://www.isgmlug.org
http://www.sgmlopen.org/xml/docs/goodies/goodies.htm
</TopicMember>
</Topic>
<Topic
id="HTML-topic"
name-refs="HTML-N1 HTML-N2"
def-refs="HTML-D1 HTML-D2"
>
<TopicMember>
http://www.w3.org/HTML
http://www.echo.lu/oii/en/docstand.html#HTML
</TopicMember>
</Topic>
<Topic
id="SGML-applications-topic"
name-refs="SGML-APP-N1 SGML-APP-N2 SGML-APP-N3"
def-refs="SGML-APP-D1"
>
</Topic>
<!-- Names and Definitions -->
<!-- Version management specific information in element "Description" -->
<Description id="SGML" mandator="mb" created="19980501">
<Name id="SGML-N1">SGML</Name>
<Name id="SGML-N2">Standard Generalized Markup Language</Name>
<Name id="SGML-N3">ISO 8879</Name>
<Definition id="SGML-D1">International standard for marking up electronic data</Definition>
<Definition id="SGML-D2">ISO 8879:1986 <cite>Information Processing -
Standard Generalized Markup Language (SGML)</cite></Definition>
</Description>
<Description id="XML" mandator="mb" created="19980501">
<Name id="XML-N1">XML</Name>
<Name id="XML-N2">Extensible Markup Language</Name>
<Definition id="XML-D1">W3C standard for marking up electronic data for interchange over the Internet</Definition>
<Definition id="XML-D2">W3C REC-xml-19980210 <cite>Extensible Markup Language (XML) 1.0</cite>
(http://www.w3.org/TR/1998/REC-xml-19980210.html)</Definition>
</Description>
<Description id="HTML" mandator="mb" created="19980501">
<Name id="HTML-N1">HTML</Name>
<Name id="HTML-N2">HyperText Markup Language</Name>
<Definition id="HTML-D1">W3C standard for marking up documents for delivery as part of the World Wide Web (W3)</Definition>
<Definition id="HTML-D2">W3C REC-html40-971218 <cite>HTML 4.0 Specification</cite>
(http://www.w3.org/TR/REC-html40)</Definition>
</Description>
<Description id="SGML-applications" mandator="mb" created="19980501">
<Name id="SGML-APP-N1">SGML Applications</Name>
<Name id="SGML-APP-N2">Applications of the Standard Generalized Markup Language</Name>
<Name id="SGML-APP-N3">Use of ISO 8879</Name>
<Definition id="SGML-APP-D1">Use of International Standard 8879:1986 as basis for computer application</Definition>
</Description>
<!-- Topic Association -->
<TopicAssociation id="SGML-uses">
<TopicMember anchrole="container">SGML-applications-topic</TopicMember>
<TopicMember anchrole="composed-of">SGML-topic XML-topic HTML-links</TopicMember>
</TopicAssociation>
<!-- Property Assignments -->
<!-- Filters are used for relevance weighting -->
<!-- role = 100 means "relevance weighting = 100%", etc. -->
<Filters>
<FilterNames id="RelevanceWeighting" mandator="mb" created="19980509">
<FilterName id="weighting-n">Relevance weighting</FilterName>
<!-- ... Other filter names when applicable ... -->
</FilterNames>
<Filter>
<TopicMember
anchrole=weighting-100
>
SGML6 XML5 HTML5
</TopicMember>
<TopicMember
anchrole=weighting-90
>
SGML7 SGML8 XML6
</TopicMember>
<TopicMember
anchrole=weighting-50
>
XML7 HTML6
</TopicMember>
</Filter>
</Filters>
...
</TopicMap>
Because XML locators can only identify a single Unique Resource Name (which could return a set, but normally returns a single object or a span) it will be more efficient to use HyTime variable links (varlink), anchor specifications (anchspec) and name space locations (nmsploc) to identify multiple data sources. This example shows the relationships between the categories (topics) that have been identified in a thesaurus and the definitions of the relevant concepts provided within a dictionary or glossary. Each concept consists of a term (the identifier of the concept) and a definition. For each category it is possible to identify equivalent terms, broader terms, narrower terms and other possibly related terms, and pointers to equivalent terms in French and German that are recorded in other thesauri.
Note: To help you to relate the example to the TNM and HyTime architectures each architectural element has had its TNM type recorded in a
TNM-class attribute and its HyTime type recoded in a HyTime attribute (unless its element name is the same as the class name). However, not all relevant attributes are noted. For example, most of the anchspec elements also need multmem="list" to allow them to have multiple members.
Note: In practice all the HyTime and TNM attributes can be removed as they will form a fixed part of the DTD. The same may also be true for the
nmsploc tags.
<!ELEMENT
Thesaurus - -
(Associations, Topics, Names, TopicMapDocumentation)
>
<!ATTLIST
Thesaurus
TNM-class NAME hub
HyTime NAME HyDoc
>
<!-- Containers for this specific example -->
<!ELEMENT Associations - - (category+) >
<!ELEMENT Topics - - (topic+) >
<!ELEMENT Names - - (concept+) >
<!ELEMENT TopicMapDocumentation - - (description+) >
<!ELEMENT category - - (category-title, equivalent-terms, broader-terms, narrower-terms, related-terms, french-equivalents, german-equivalents) >
<!ATTLIST category
TNM-class NAME TopicAssociation
HyTime NAME varlink
id ID #IMPLIED
>
<!ELEMENT category-title - - (nmsploc+) >
<!ATTLIST category-title
HyTime NAME anchspec
>
<!ELEMENT equivalent-terms - - (nmsploc+) >
<!ATTLIST equivalent-terms
HyTime NAME anchspec
>
<!ELEMENT broader-terms - - (nmsploc+) >
<!ATTLIST broader-terms
HyTime NAME anchspec
>
<!ELEMENT narrower-terms - - (nmsploc+) >
<!ATTLIST narrower-terms
HyTime NAME anchspec
>
<!ELEMENT related-terms - - (nmsploc+) >
<!ATTLIST related-terms
HyTime NAME anchspec
>
<!ELEMENT french-equivalents - - (nmsploc+) >
<!ATTLIST french-equivalents
HyTime NAME anchspec
>
<!ELEMENT german-equivalents - - (nmsploc+) >
<!ATTLIST german-equivalents
HyTime NAME anchspec
>
<!ELEMENT nmsploc - - (#PCDATA) >
<!ATTLIST nmsploc
HyTime NAME nmsploc
>
<!ELEMENT topic - - (term, definition) >
<!ATTLIST topic
TNM-class NAME Topic
HyTime NAME varlink
id ID #IMPLIED
>
<!ELEMENT term - - (nmsploc+) >
<!ATTLIST term
TNM-class NAME NameLocator
HyTime NAME anchspec
id ID #IMPLIED
>
<!ELEMENT definition - - (nmsploc+) >
<!ATTLIST definition
HyTime NAME anchspec
id ID #IMPLIED
>
<!ELEMENT concept - - (#PCDATA) >
<!ATTLIST concept
id ID #REQUIRED
>
<!ELEMENT description - - (list | #PCDATA)* >
<!ATTLIST description
id ID #REQUIRED
>
<!ELEMENT list - - (item+) >
<!ELEMENT item - - (#PCDATA) >
<!-- End of DTD -->
<!-- Start of Document Instance -->
<Thesaurus TNM-class="TNM-hub" HyTime="HyDoc">
<!-- Topic Associations -->
<Associations>
<category TNM-class="TopicAssociation" HyTime="varlink" >
<category-title HyTime="anchspec"><nmsploc>reality</nmsploc></category-title>
<equivalent-terms HyTime="anchspec"><nmsploc>substantiality in-accordance-with-fact</nmsploc></equivalent-terms>
<broader-terms HyTime="anchspec"><nmsploc>existence being</nmsploc></broader-terms>
<narrower-terms HyTime="anchspec"><nmsploc>fact thing entity</nmsploc></narrower-terms>
<related-terms HyTime="anchspec"><nmsploc>absoluteness factualness no-lie</nmsploc></related-terms>
<french-equivalents HyTime="anchspec"><nmsploc>realite reel</nmsploc></french-equivalents>
<german-equivalents HyTime="anchspec"><nmsploc>wirklichkeit realitat</nmsploc></german-equivalents>
</category>
...
</Associations>
<!-- Topics -->
<!-- Pb with name-ref and definition. Def-ref doesn't work because
definitions are in an external document (?) -->
<Topics>
<topic id="topic-reality" name-ref="t1">
<definition><nmsploc locsrc="ConciseOED">d1</nmsploc></definition>
</topic>
<topic id="topic-substantiality" name-ref="t2">
<definition><nmsploc locsrc="ConciseOED">d2</nmsploc></definition>
</topic>
<topic id="topic-in-accordance-with-fact" name-ref="t3" mnemonic="InAccordanceWithFacts">
<!-- Where does the mnemonic go? -->
<term TNM-class="TNM-NameLocator" >
<definition><nmsploc locsrc="MB-Book">d3</nmsploc></definition>
</topic>
<topic id="topic-existence" name-ref="t4">
<definition><nmsploc locsrc="ConciseOED">d4</nmsploc></definition>
</topic>
<topic id="topic-being" name-ref="t5">
<definition><nmsploc locsrc="ConciseOED">d5</nmsploc></definition>
</topic>
<topic id="topic-factualness" name-ref="t6">
<definition><nmsploc locsrc="ConciseOED">d6</nmsploc></definition>
</topic>
<topic id="realite" name-ref="t7">
<definition><nmsploc locsrc="Larousse">d7</nmsploc></definition>
</topic>
<topic id="reel" name-ref="t8">
<definition><nmsploc locsrc="Larousse">d8</nmsploc></definition>
</topic>
<topic id="wirklichkeit" name-ref="t9">
<definition><nmsploc locsrc="GTh">d9</nmsploc></definition>
</topic>
<topic id="realitat" name-ref="t10">
<definition><nmsploc locsrc="GTh">d10</nmsploc></definition>
</topic>
<topic id="category">
<term TNM-class="Name"><nmsploc locsrc="http://www.publisher-x.com/thesauri/definitions.sgml">>
<definition><nmsploc>category-def</nmsploc></definition>
</concept>
</Topics>
<!-- List of topic names -->
<Names>
<concept id="t1">Reality</concept>
<concept id="t2">Substantiality</concept>
<concept id="t3">In accordance with facts</concept>
<concept id="t4">Existence</concept>
<concept id="t5">Being</concept>
<concept id="t6">Factualness</concept>
<concept id="t7">Réalité</concept>
<concept id="t8">Réel</concept>
<concept id="t9">Wirklichkeit</concept>
<concept id="t10">Realität</concept>
<concept id="thesaurus-category" >Category</concept>
</Names>
...
<TopicMapDocumentation>
<description id="Category-def">A category in this thesaurus consists of:
<list>
<item>a compulsory category-title, which is shown in the list of categories
<item>one or more identifiers of equivalent terms
<item>optionally, one or more identifiers of broader terms which can be deemed to encompass the term in the category title
<item>optionally, one or more identifiers of terms that, whilst not exactly equivalent, can be considered to be related to the category title
<item>optionally, one or more narrower terms which can be deemed to form a sub-catefory of the term in the category title.
</list>
</description>
</TopicMapDocumentation>
</Thesaurus>
<!-- External documents -->
<!-- 1. Concise OED -->
<ConciseOED>
...
<definition id="d1">
Property of being real; resemblance to original;
what is real, what underlies appearances; existent thing
</definition>
...
<definition id="d2">
Having substance, actually existing, not illusory
</definition>
...
<definition id="d4" source="ConciseOED">Being, existing
</definition>
...
<definition id="d5" source="ConciseOED">
Existence, constitution, nature, essence, anything that exists, a person
</definition>
...
<definition id="d6" source="ConciseOED">
The state of being factual
</definition>
...
</ConciseOED>
<!-- 2. MB-Book -->
<MB-Book>
...
<def id="d3">
That which agrees with well substantiated facts
</def>
...
</MB-Book>
<!-- 3. Larousse -->
<def id="d7">Caractère de ce qui est réel, de ce qui existe effectivement.
</def>
<def id="d8">Ce qui existe effectivement, ce qui arrive en fait.
</def>
<!-- 4. German Thesaurus -->
<def id="d9">Die Wirklichkeit ...
</def>
<def id="d10">Die Realität ...
</def>
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; >
<!ELEMENT textDesc - o (channel, constitution, derivation,
domain, factuality, interaction, preparedness,
purpose+) >
<!ATTLIST textDesc %a.global;
%a.declarable; >
<!ELEMENT bibl - o (#PCDATA | %m.phrase; | %m.biblPart;)*
<!ATTLIST bibl %a.global;
%a.declarable; >
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 TopicAssociation architectural form <category> as conforming to the TNM Topic architectural form <bibl> as a conforming Description TNM anchor role <catDesc> with a conforming TNM Name Locator Note: To complete the definition for all the elements in the model of a TEI taxonomy you would also have to:
<biblStruct> and <biblFull> as conforming Description TNM anchor roles.
<textDesc> as a conforming Definition TNM anchor role.
The following example shows how the existing element definitions could be extended by defining a few extra parameter entities and then referencing these or adding TNM class identifiers to the existing attribute sets.
<!ENTITY % TNM-TA --Attributes used to define a Topic Navigation Map
Topic Association--
'TNM-class NAME "TopicAssociation"
id -- Unique identifier for assignment --
-- ISO/IEC 10744 Clause: A.5.2 --
ID #IMPLIED
-- Each TNM TopicAssociation can be assigned a unique
identifier to allow the association to be used as an
anchor for another topic association. As all associations
need not be anchors, the id is not required. -- '
>
<!ENTITY % TNM-Topic --Attributes used to define a Topic Navigation Map
Topic--
'TNM-class NAME "Topic"
id -- Unique identifier for assignment --
-- ISO/IEC 10744 Clause: A.5.2 --
ID #IMPLIED
-- Each TNM Topic should be assigned a unique
identifier to allow the topic to be used as an
anchor for a topic association. As all topics need
not be anchors, the id is not required. -- '
>
<!ENTITY % TNM-varlink
'HyTime NAME varlink
linktrav -- Hyperlink traversal rules. One or more of:
A any traversal or departure (EID)
D departure after internal arrival
E traversal after external arrival
I traversal after internal arrival
N no traversal after internal arrival
P no internal arrival
R return traversal after internal arrival --
-- Constraint: one per anchor or one for all --
(A|D|ED|EI|EN|EP|ER|ERD|I|ID|N|P|R|RD)
"A"
listtrav -- Traversal between members of list anchors.
A adjacent (both left and right) traversal
L left traversal
N no traversal
R right traversal
W wrapping traversal --
(N|L|R|A|LW|RW|AW)
"AW"
emptyanch -- Is empty anchor an error? --
-- Constraint: one per anchor or one for all --
-- Lextype("ERROR"|"NOTERROR") --
NAMES "noterror" '
>
<!ELEMENT classDecl - - (taxonomy+)>
<!ATTLIST classDecl %a.global; >
<!--Question: Is there any logical reason why classDecl should not be
declared as 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-TopicAssociation;
%TNM-varlink;
>
<!ELEMENT category - - (catDesc, category*)>
<!ATTLIST category %a.global;
%TNM-Topic;
%TNM-varlink;
>
<!ELEMENT catDesc - o (%phrase.seq; | textDesc) >
<!ATTLIST catDesc %a.global;
TNM-class NAMES #FIXED "Description Name"
>
<!ELEMENT textDesc - o (channel, constitution, derivation,
domain, factuality, interaction, preparedness,
purpose+) >
<!ATTLIST textDesc %a.global;
%a.declarable;
TNM-class NAME #FIXED "Description"
>
<!ELEMENT bibl - o (#PCDATA | %m.phrase; | %m.biblPart;)*
<!ATTLIST bibl %a.global;
%a.declarable;
TNM-class NAMES #FIXED "Description Name"
>
Note: When, shortly, multiple attribute list declarations are permitted for each element then it will be possible to add these attributes directly using separate declarations, without having to modify the TEI declarations.
The following simplified example shows an XML-coded topic navigation map that links together a small subset of genealogical data:
Note (Michel): This example needs to be further developed.
<Genealogical-Information>
<record-set>
<record type="birth" id="BFC22-1">http://www.births.uk/Benfleet/1948|Bryan6851</record>
<record type="birth" id="BFC22-2">http://www.births.uk/Shipley/1951|Oxley2342</record>
<record type="marriage" id="BFC22-3">http://www.marriages.uk/Shipley/1978|Cert1637</record>
<record type="birth" role="son" id="BFC22-4">http://www.births.uk/Cheltenham/1984|Bryan9242</record>
<record type="birth" id="BFC22-5" http://www.births.uk/Gloucester/1987|Bryan9429</record>
</record-set>
<relation-info TNM-class="Topic" id="families">
<pointer role="description" >families</pointer>
<pointer role="husbands" >male-partners</pointer>
<pointer role="wifes" >female-partners</pointer>
<pointer role="children" >children</pointer>
<!-- to do : fix address of following line -->
<pointer role="occurrence" >below-in-doc</pointer>
</relation-info>
<relation-info id="male-partners" TNM-Class="Topic">
<pointer role="description" >male-partner</pointer>
<pointer role="husband" >husband"
</relation-info>
<relation-info id="female-partners" TNM-Class="Topic">
<pointer role="description" >female-partner</pointer>
<pointer role="wife" >wife"
registry="Shipley, W. Yorkshire, England::1978::Marriages/>
...
</relation-info>
<relation-info id="children" TNM-Class="Topic">
<pointer role="description" >child</pointer>
<pointer role="child" >BFC22-1</pointer>
<!-- This line should be replaced by a pointer to the appropriate record (?) -->
<pointer role ="registry">Benfleet, Essex, England::1948::Births</pointer>
<pointer role="child" >BFC22-2</pointer>
registry="Shipley, Yorkshire, England::1951::Births/>
<pointer role="child" >BFC22-4</pointer>
registry="Cheltenham, Glos, England::1984::Births/>
<pointer role="child" >BFC22-5</pointer>
registry="Gloucester, Glos, England::1987::Births</pointer>
...
</topic>
<description TNM-class="Description" id="families" TNM-filters="type lang"
TNM-mandator="Martin Bryan" TNM-created="19980401">
<!-- filters should be put outside -->
<name lang="en" type="normal">Family</title>
<name lang="en" type="generic">Household</title>
<name lang="en" type="generic">Partnership</title>
<name lang="fr" type="normal">Famille</title>
<name lang="fr" type="generic">Ménage</title>
<name lang="fr" type="generic">Communauté</title>
<definition TNM-class="Definition" lang="en"
source="http://www.myco.com/definitions/social.xml#Family">
Two or more partners living together, with or without children
</definition>
</description>
<description TNM-class="Description" id="male-partner"
TNM-filters="type lang">
<name lang="en" type="normal">Husband</title>
<name lang="en" type="generic">Spouse</title>
<name lang="en" type="generic">Partner</title>
<name lang="fr" type="normal">Mari</title>
<name lang="fr" type="generic">Époux</title>
<name lang="fr" type="generic">Partenaire</title>
<definition TNM-class="Definition" lang="en">
Male partner of formal marriage
</definition>
</description>
<description TNM-class="Description" id="female-partner"
TNM-filters="type lang">
<name lang="en" type="normal">Wife</title>
<name lang="en" type="generic">Spouse</title>
<name lang="en" type="generic">Partner</title>
<name lang="en:cockney" type="slang">Trouble and strife</title>
<name lang="fr" type="normal">Femme</title>
<name lang="fr" type="generic">Épouse</title>
<name lang="fr" type="generic">Partenaire</title>
<definition TNM-class="Definition" lang="en">
Female partner of formal marriage
</definition>
</description>
<description TNM-class="Description" id="father"
TNM-filters="type lang">
<name lang="en" type="normal">Father</title>
<name lang="en" type="slang">Dad</title>
<name lang="en" type="snob">Pater</title>
<name lang="fr" type="normal">Père</title>
<name lang="fr" type="slang">Papa</title>
<definition TNM-class="Definition" lang="en">
Biological father of child
</definition>
</description>
<description TNM-class="Description" id="mother"
TNM-filters="type lang">
<name lang="en" type="normal">Mother</title>
<name lang="en" type="slang">Mum</title>
<name lang="en" type="snob">Mater</title>
<name lang="fr" type="normal">Mère</title>
<name lang="fr" type="slang">Maman</title>
<definition TNM-class="Definition" lang="en">
Biological mother of child
</definition>
</description>
<description TNM-class="Description" id="son"
TNM-filters="type lang">
<name lang="en" type="normal">Son</title>
<name lang="en" type="generic">Child</title>
<name lang="fr" type="normal">Fils</title>
<name lang="fr" type="generic">Enfant</title>
<definition TNM-class="Definition" lang="en">
Male child of mother and (possibly unidentified) father
</definition>
</description>
<description TNM-class="Description" id="brother"
TNM-filters="type lang">
<name lang="en" type="normal">Brother</title>
<name lang="en" type="slang">Bro</title>
<name lang="fr" type="normal">Frère</title>
<name lang="fr" type="slang">Frangin</title>
<definition TNM-class="Definition" lang="en">
Male sibling
</definition>
</description>
<description TNM-class="Description" id="daughter"
TNM-filters="type lang">
<name lang="en" type="normal">Daughter</title>
<name lang="en" type="generic">Child</title>
<name lang="fr" type="normal">Fille</title>
<name lang="fr" type="generic">Enfant</title>
<definition TNM-class="Definition" lang="en">
Female child of mother and (possibly unidentified) father
</definition>
</description>
<description TNM-class="Description" id="sister"
TNM-filters="type lang">
<name lang="en" type="normal">Sister</title>
<name lang="en" type="slang">Sis</title>
<name lang="fr" type="normal">Soeur</title>
<name lang="fr" type="slang">Frangine</title>
<definition TNM-class="Definition" lang="en">
Female sibling
</definition>
</description>
<description TNM-class="Description" id="child"
TNM-filters="type lang">
<name lang="en" type="generic">Child</title>
<name lang="en" type="normal">Son</title>
<name lang="en" type="normal">Daughter</title>
<name lang="fr" type="normal">Enfant</title>
<name lang="fr" type="normal">Fils</title>
<name lang="fr" type="normal">Fille</title>
<definition TNM-class="Definition" lang="en">
Child of mother and (possibly unidentified) father
</definition>
</description>
<relations id="BFC22-1relations"
TNM-class="TopicAssociation">
<child >BFC22-1</child>
<mother-of >BFS1-2</mother-of>
<father-of >BFS1-1</father-of>
<brother-of >BFS1-5</brother-of>
<son-of >BFC22-4</son-of>
<daughter-of >BFC22-5</daughter-of>
</relations>
<relations id="BFC22-2relations"
TNM-class="LocationAssociation">
<child >BFC22-2" description="child"/>
<mother-of >OFS2-2" description="mother"/>
<father-of >OFS2-1" description="father"/>
<sister-of >OFS2-4" description="sister"/>
<son-of >BFC22-4" description="son"/>
<daughter-of >BFC22-5" description="daughter"/>
</relations>
<relations id="BFC22-4relations"
TNM-class="LocationAssociation">
<child >BFC22-4" description="son"/>
<mother-of >BFC22-2" description="mother"/>
<father-of >BFC22-1" description="father"/>
<brother-of >BFC22-5" description="brother"/>
</relations>
<relations id="BFC22-4relations"
TNM-class="LocationAssociation">
<child >BFC22-5" description="daughter"/>
<mother-of >BFC22-2" description="mother"/>
<father-of >BFC22-1" description="father"/>
<sister-of >BFC22-4" description="sister"/>
</relations>
<relations id="BFC22marriage"
TNM-class="TopicAssociation">
<certificate >BFC22-3</certificate>
<husband >BFC22-1</husband>
<wife >BFC22-2<wife/>
</relations>
</Genealogical-Information>
Note: In practice most of the attributes beginging
xml: and TNM- would not appear in the document instance but would be defined once in the formal document type definition. Their presence here is simply to allow the relationships between the component parts of the message to be clearly indicated in the example.
This example shows how HyTime links other than the varlink form used as the basis for XML Links can be used as part of a Topic Navigation Map. Unless otherwise specified the links are defined in the generic hyperlink format (HyLink).
The example is also designed to show how different topic maps can be interconnected. Three separate topic maps are defined, each of which shows how books and articles relating to computing will be classified under one of the standard library classification schemes, the Universal Decimal Classification (UDC), the Dewey Decimal Classification (DDC) and the Library of Congress Classification Scheme (LCC). A single set of topic associations is defined at the end of the example to indicate the relationships between the classification schemes.
<Catalogue TNM-class="TNM-hub">
<Classification level=0 id="UDC-base">
<Name id="UDC-name">Universal Decimal Classification</Name>
<Definition id="UDC-def">BS 1000M: <cite>International Medium Edition of the Universal Decimal Classification</cite></Definition>
<SubClassifications>UDC-0 UDC-1 UDC-2 UDC-3 UDC-4 UDC-5 UDC-6 UDC;7 UDC-8 UDC-9</SubClassifications>
</Classification>
...
<Classification level=1 id="UDC-5">
<Name id="UDC5-name">5 Mathematics and Natural Sciences (inc. Chemistry, Biology, Computing)</Name>
<Definition id="UDC5-def">Information related to mathematics and scientific subjects</Definition>
<SubClassifications>UDC-Mathematics</SubClassifications>
</Classification>
...
<Classification level=2 id="UDC-Mathematics">
<Name id="UDC-Mathematics-name">Mathematics</Name>
<Definition id="UDC-Mathematics-def">The sciences used for calculation</Definition>
<SubClassifications>... UDC-Computing ... </SubClassifications>
</Classification>
...
<Classification level=3 id="UDC-Computing">
<Name id="UDC-Computing-name">Computing</Name>
<Definition id="UDC-Computing-def">The development and use of electronic computers</Definition>
</Classification>
</ClassificationScheme>
<ClassificationScheme id="DeweyDecimal">
<Classification level=0 id="Dewey">
<Name id="Dewey-desc-name">Dewey Decimal Classification</Name>
<Definition>A complete listing of classifications can be found at
http://www.tnrdlib.bc.ca/dewey.html</Definition>
<SubClassifications>Dewey-000 Dewey-100 Dewey-200 Dewey-300 Dewey-400
Dewey-500 Dewey-600 Dewey-700 Dewey-800 Dewey-900</SubClassifications>
</Classification>
<Classification level=1 id="Dewey-000">
<Name id="Dewey-000-name">Generalities</Name>
<Definition id="Dewey-000-def">Subjects with a wide range of application</Definition>
<SubClassifications>Dewey-001 Dewey-002 Dewey-003 Dewey-004
Dewey-005 Dewey-006 Dewey-007 Dewey-008 Dewey-009</SubClassifications>
</Classification>
...
<Classification level=2 id="Dewey-004">
<Name id="Dewey-004-name">Data processing, Computer science</Name>
<Definition id="Dewey-004-def">Electronic proceessing of data and scientific theories applying thereto</Definition>
<SubClassifications>Dewey-DP Dewey-CS</SubClassifications>
</Classification>
<Classification level=2 id="Dewey-005">
<Name id="Dewey-005-name">Computer programming, programs, data</Name>
<Definition id="Dewey-005-def">Writing of computer programs to process data, and information on data types</Definition>
<SubClassifications>Dewey-CP Dewey-Programs Dewey-Data</SubClassifications>
</Classification>
<Classification level=2 id="Dewey-006">
<Name id="Dewey-006-name">Special computer methods</Name>
<Definition id="Dewey-006-def">Information relating to computers not categorized under
Dewey classifications 004 and 005
</Description ></Definition>
<SubClassifications>Dewey-SCM</SubClassifications>
</Classification>
...
</ClassificationScheme>
<ClassificationScheme id="LCC">
<Classification level=0 id="LCC-base">
<Name id="LCC-name">Library of Congress Classification Scheme</Name>
<Definition id="LCC-desc" ><cite>Outline of the Library of Congress Classification</cite></Definition>
<SubClassifications>LCC-A LCC-B LCC-C LCC-D LCC-E LCC-F LCC-G LCC-H
LCC-J LCC-K LCC-L LCC-M LCC-N
LCC-P LCC-Q LCC-R LCC-S LCC-T LCC-U LCC-V LCC-Z</SubClassifications>
</Classification>
...
<Classification level=1 id="LCC-Q">
<Name id="LCC-Q-name">Q Science</Name>
<Definition id="LCC-Q-def">Information related to scientific subjects</Definition>
<SubClassifications>... LCC-Mathematics ... LCC-GeneralSciences</SubClassifications>
</Classification>
...
<Classification level=1 id="LCC-T">
<Name id="LCC-T-name>T Technology</Name>
<Definition id="LCC-T-def>Information related to technical subjects</Definition>
<SubClassifications>... LCC-Electronics ... </SubClassifications>
</Classification>
...
<Classification level=1 id="LCC-Z">
<Name id="LCC-Z-name">Z Library Sciences</Name>
<Definition id="LCC-Z-def">Information related to libraries</Definition>
<SubClassifications>... LCC-InformationResources ... </SubClassifications>
</Classification>
...
<Classification level=2 id="LCC-Mathematics">
<Name id="LCC-Mathematics-name">Mathematics</Name>
<Definition id="LCC-Mathematics-def">The sciences used for calculation</Definition>
<SubClassifications>... LCC-ElectronicComputers LCC-ComputerScience
LCC-ComputerSoftware ... </SubClassifications>
</Classification>
...
<Classification level=3 id="LCC-ElectronicComputers">
<Name id="LCC-Electronic-Computers-name">Electronic Computers</Name>
<Definition id="LCC-Electronic-Computers-def">The development and use of electronic computers</Definition>
</Classification>
...
<Classification level=3 id="LCC-ComputerScience">
<Name id="LCC-Computer-Sciename">Computer Science</Name>
<Definition id="LCC-Computer-Science">Scientific theories related to the development and use of
electronic computers</Definition>
</Classification>
...
<Classification level=3 id="LCC-ComputerSoftware">
<Name id="LCC-Computer-Software-name">Computer Software</Name>
<Definition id="LCC-Computer-Software-def">Programs for the control of electronic computers</Definition>
</Classification>
...
<Classification level=2 id="LCC-GeneralSciences">
<Name id="LCC-General-Sciences-name">General Sciences</Name>
<Definition id="LCC-General-Sciences-def">Sciences nor covered in other categories</Definition>
<SubClassifications>... LCC-Cybernetics ... </SubClassifications>
</Classification>
...
<Classification level=3 id="LCC-Cybernetics">
<Name id="LCC-Cybernetics-name">Cybernetics</Name>
<Definition id="LCC-Cybernetics-def">Electronic process control</Definition>
<SubClassifications>... LCC-InformationTheory ... </SubClassifications>
</Classification>
...
<Classification level=4 id="LCC-InformationTheory">
<Name id="LCC-Information-Theory-name">Information Theory</Name>
<Definition id="LCC-Information-Theory-def">Scientifically provable theories relating to the control and use of
information</Definition>
</Classification>
...
<Classification level=2 id="LCC-Electronics">
<Name id="LCC-Electronics-name">Electronics</Name>
<Definition id="LCC-Electronics-def">Use of electronic signals</Definition>
<SubClassifications>... LCC-ComputerHardware ... </SubClassifications>
</Classification>
...
<Classification level=3 id="LCC-ComputerHardware">
<Name id="LCC-Computer-Hardware-name">Computer Hardware</Name>
<Definition id="LCC-Computer-Hardware-def">Electronic components used for commputing</Definition>
</Classification>
...
<Classification level=2 id="LCC-InformationResources">
<Name id="LCC-Information-Resources-name">Information Resources</Name>
<Definition id="LCC-Information-Resources-def">Places from which information can be obtained</Definition>
<SubClassifications>... LCC-InformationSuperhighway
LCC-ComputerNetworkResources
LCC-Databases ... </SubClassifications>
</Classification>
...
<Classification level=3 id="LCC-InformationSuperhighway">
<Name id="LCC-Information-Superhighway-name">Information Superhighway</Name>
<Definition id="LCC-Information-Superhighway-def">Highway used to interconnect computer networks for the purposes of
information dissemination</Definition>
</Classification>
...
<Classification level=3 id="LCC-ComputerNetworkResources">
<Name id="LCC-Computer-Network-Resources-name">Computer Network Resources</Name>
<Definition id="LCC-Computer-Network-Resources-def">Interconnected computer networks used for information dissemination</Definition>
</Classification>
...
<Classification level=3 id="LCC-Databases">
<Name id="LCC-Databases-name">Databases</Name>
<Definition id="LCC-Databases-def">Electronic stores of data organized into searchable records</Definition>
</Classification>
...
</ClassificationScheme>
<ClassificationAssociation>
<name>ComputingInfo-name
<Definition>Computing-Info-def
<UDC>UDC-Computing
<Dewey>Dewey-004 Dewey-005 Dewey-006
<LCC>LCC-ElectronicComputers LCC-ComputerScience LCC-ComputerSoftware
LCC-InformationTheory LCC-ComputerHardware LCC-InformationSuperhighway
LCC-ComputerNetworkResources LCC-Databases>
</ClassificationAssociation>
<Description >
<Name id="ComputingInfo-name>ComputingInfo"
<Definition id="ComputingInfo-def">Information on the use of computers
</Description>
This example shows how a library catalogue could be generated by adding local extensions to a standardized classification scheme (UDC) and then linking books, articles and locally-produced theses to relevant classifications.
<!-- UDC is considered a fixed classification system organized as a
tree structure. Therefore, each topic has a subclassification anchrole
which is inherent in its definition. -->
<!-- Document 1. UDC Classification Topic Map -->
<UDC-Classification >
<Classification level=0 id="UDC-base">
<Name>Universal Decimal Classification</Name>
<Definition>BS 1000M: <cite>International Medium Edition of the Universal Decimal Classification</cite></Definition>
<SubClassifications>UDC-0 UDC-1 UDC-2 UDC-3 UDC-4 UDC-5 UDC-6 UDC-7 UDC-8 UDC-9</SubClassifications>
</Classification>
...
<Classification level=1 id="UDC-5" >
<Name id="UDC5-name">5 Mathematics and Natural Sciences (inc. Chemistry, Biology, Computing)</Name>
<Definition>UDC5-def</definition>
<SubClassifications>UDC-Mathematics ... </SubClassifications>
</Classification>
....
<Def id="UDC5-def">Information related to mathematics and scientific subjects</Definition>
...
<Classification level=2 id="UDC-Mathematics">
<Name id="UDC-Mathematics-name">Mathematics</Name>
<Definition id="UDC-Mathematics-def">The sciences used for calculation</Definition>
<SubClassifications>... UDC-Computing ...>
</Classification>
...
<Classification level=3 id="UDC-Computing"
<Name id="UDC-Computing-name">Computing</Name>
<Definition id="UDC-Computing-def1">The development and use of electronic computers</Definition>
</Classification>
</UDC-Classification>
<!-- ------------------------------------------------------ -->
<!-- Document 2 -->
<Local-Library-Classification>
<Link-to-UDC
anchrole = "UDC-classification Explanation Local-Subclassifications"
<UDC-Classification>UDC-Computing
<Explanation>Local-Computing
<Local-subclassifications>Local-ADA Local-BASIC Local-C Local-Databases
Local-HTML Local-Java Local-Pascal Local-SGML
Local-Spreadsheets Local-XML Local-General
>
<Explanation id="Local-Computing">Local subclassifications to make computing subjects accessible to staff and students</Explanation>
</Link-to-UDC>
<Classification level=3 id="Local-ADA">
<Name id="Local-ADA-sources-name">ADA</Name>
<Definition id="Local-ADA-sources-def">Information relating to the ADA programming language</Definition>
<SubClassifications>Local-ADA-books Local-ADA-articles Local-ADA-theses
</Local-Library-Classification>
</Classification>
<!-- ------------------------------------------ -->
<!-- Document 3. Stacks -->
<Local-Stacks>
<Shelf-area id="Local-ADA-books" position="Row12 Stack3 RowB">
<SetName>Books on use of ADA programming language</SetName>
<Book AcquisitionNo="a4114"><author>Bloggs, J.</author><title>ADA for dummies</title><Book>
<Book AcquisitionNo="a5123"><author>Smith, J.</author><title>Advanced ADA</title><Book>
...
</Shelf-area>
<!-- Normally ordered by name of publication -->
<Articles id="Local-ADA-articles">
<Article Journal="ADAToday" Issue="Vol.13 No.3" Pages="23-25"
position="Row22 Stack4 RowC Box15">
<author>Bryan, M</author>
<author>Biezunski, M</author>
<title>Topic Navigation in Computer Programs</title>
</Article>
...
</Articles>
<!-- Normally ordered by date of presentations -->
<Theses id="Local-ADA-theses">
<Thesis Department="Computing" Accepted="19970715"
position="Row1 Stack3 RowA"
author="Bryan. M"
title="Using ADA to create and manage Topic Navigation Maps">
</Thesis>
...
</Theses>
...
</Local-Stacks>
Typographic conventions used in the examples are:
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.
<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>
<!DOCTYPE TopicMap [ <!ELEMENT TopicMap - - ( (TopicTitle*, City) | (TopicTitle*, Country) )+ > <!-- Topic Names --> <!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-NameLocator #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 > ]>
This example uses the TEI Xpointers syntax to address elements in external documents.
<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>
<!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-NameLocator
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.
In this example, the topic "Venice" has two titles: "Venice" and "Venezia".
<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.
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>
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 association 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 associations anchroles, i.e. is limited to one-to-one associations, 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>
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-PropertyAssignment 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>
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.
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.