This is an internal Working Draft for review by members of the topic map mailing list and other interested parties. It is a draft document and may be updated, replaced, or obsoleted by other documents at any time.
This document specifies how an ISO/IEC 13250 Topic Map can be expressed using the Extensible Markup Language (XML), and particularly the role played by XML Linking Language (XLink) for that standard. It shows how XML elements, together with links that use locations identified using XML Pointer Language (XPointer), can be used to define topics of interest to users which can have multiple names, multiple sets of occurrences with different roles and/or scopes, different facets that can be used to select subsets of topics, and associations that link related topics.
To follow
This specification defines XML constructs that can be used to define a set of related topics that provide named sets of occurrences of resources that are relevant to a particular subject. In addition it provides mechanisms for defining associations between topics, and characteristics that can be used to subset topics and associations so that user can see different facets (views) of the subject.
This specification defines a concrete representation, expressed in XML, of the general SGML architecture for topic maps defined in ISO/IEC 13250. It provides both a concrete syntax for the expression of topics and associations based on the use of XML Pointers and the XML Linking Language and a mechanism whereby application-specific elements can be declared to be topic map components.
The Topic Map International Standard provides a standardized notation for interchangeably representing information about the structure of information resources used to define topics, and the relationships between topics. A set of one or more interrelated documents that employs the notation defined by this International Standard is called a "topic map". In general, the structural information conveyed by topic maps includes:
A topic map defines a multidimensional topic space -- a space in which the locations are topics, and in which the distances between topics are measurable in terms of the number of intervening topics which must be visited in order to get from one topic to another, and the kinds of relationships that define the path from one topic to another, if any, through the intervening topics, if any.
NOTE: Two topics may be connected through an association, and they can also be connected by virtue of sharing an occurrence.
In addition, information objects can have properties, as well as values for those properties, assigned to them externally. These properties are called "facet types".
NOTE: The word "facet" can mean one side of a many-sided, polished object, or one segment of a compound eye (e.g. an insect's). Its metaphorical use here captures the idea that a facet is a property of a set of information objects that can be used to create a view of them.
Several topic maps can provide topical structure information about the same information resources. The Topic Maps architecture is designed to facilitate merging topic maps without requiring the merged topic maps to be copied or modified. Because of their extrinsic character, topic maps can be thought of as "overlays" on, or extensions to, sets of information objects.
The XML Linking Language (XLink) specification defines constructs that may be inserted into XML DTDs and document instances to describe links between resources. A link, as the term is used here, is an explicit relationship between two or more resources or portions of resources. The XLink specification is concerned with the syntax used to assert link existence and describe link characteristics.
XLink is a mechanism for asserting link relationships using elements contained in XML document instances. A simple case of establishing a link relationship within an XML document is the ID/IDREF mechanism. This mechanism is described in the XML 1.0 Recommendation, and is thus out of scope for XLink, but this specification provides a mechanism that extends this basic capability in a number of ways:
An important application of XLinks is in hypertext systems. For the purpose of this specification, "hyperlinks" are considered to be those links that are meaningful, frequently for direct use by end users. This specification defines hypertext meta-data that can be associated with a link.
A simple hyperlink case is an HTML A element, which has these characteristics:
While this set of characteristics is already very powerful and obviously has proven itself highly useful and effective, each of these assumptions also limits the range of hypertext functionality. The hyperlinking model defined in the XLinks specification provides ways to create hyperlinks that go beyond each of these specific characteristics, thus providing features previously available mostly in dedicated hypermedia systems.
Topic Maps are defined in ISO/IEC 13250 as an SGML document architecture whose definition conforms to the Architectural Form Definition Requirements in Normative Annex A.3 of ISO/IEC 10744:1997, the "SGML Architectural Form Definition Requirements" (AFDR). The formal definition of the topic map notation is expressed as a meta-DTD. The specification of the Topic Maps architecture is accomplished by a combination of narrative text and formal definitions.
In this document the topic map architecture is expressed in terms of both a fixed set of predefined XML elements, and as a set of namespace-controlled architectural forms that can be applied to an element with an applicaton-defined name. Application developers can choose to retain the element names defined in the specification or can use name-spaced attributes to identify the use of the constructs with elements with application-dependent names, but may not mix both approaches. When the predefined element names are used application-dependent extensions can only be made at points indicated in the content model of the predefined elements.
Location of elements within an XML Topic maps is defined through a set of rules for defining XML locations as Unique Resource Locators (URLs) taken from the XML Linking Language specification.
Wherever possible the text of this document is a copy of the relevant clause of the standard or specification it is derived from, with modifications to cover its use within an XML Topic Maps environment, and with the addition of examples where appropriate. The code productions within the text are derived from the standard, but are expressed in an XML conformant form. The code productions have been moved to the start of each section, preceding the description of their components, to conform with W3C documentation style.
The goals and objectives of this specification are to represent in XML the functions provided in SGML by International Standard 13250. The goals of this standard are stated within its Scope statement as:
"Topic maps enable multiple, concurrent views of sets of information objects. The structural nature of these views is unconstrained; they may reflect an object oriented approach, or they may be relational, hierarchical, ordered, unordered, or any combination of the foregoing. Moreover, an unlimited number of topic maps may be overlaid on a given set of information resources.
Topic maps can be used:
- To qualify the content and/or data contained in information objects as topics to enable navigational tools such as indexes, cross-references, citation systems, or glossaries.
- To link topics together in such a way as to enable navigation between them. This capability can be used for virtual document assembly, and for creating thesaurus-like interfaces to corpora, knowledge bases, etc.
- To filter an information set to create views adapted to specific users or purposes. For example, such filtering can aid in the management of multilingual documents, management of access modes depending on security criteria, delivery of partial views depending on user profiles and/or knowledge domains, etc.
- To structure unstructured information objects, or to facilitate the creation of topic-oriented user interfaces that provide the effect of merging unstructured information bases with structured ones. The overlay mechanism of topic maps can be considered as a kind of "external markup mechanism", in the sense that an arbitrary structure is imposed on the information without altering its original form."
In addition to ISO/IEC 13250 three standards have been especially influential in the development of this specification, and the standards it is based on:
The following terms are defined in ISO/IEC 13250 (modified here as necessary to allow for the use of the term in an XML rather than an SGML/HyTime environment):
addthems
) attribute of the document element. The
specified themes are added to the scopes of all of the topic characteristics
which are assigned to topics via the topic links and association links
contained in the document.
AddedThemes
) architectural form. The specified themes are
added to the topic characteristics assigned to topics via:
tmdocs
attribute),
cassign
attribute),
cassign
attribute, or any combination of the foregoing.
types
attribute. BaseName
) of a TopicNames
subelement of a topic link.
BaseName
element. DisplayedAs
) of a TopicNames
subelement of a topic link, containing the identifying information intended
to be displayed by the application to represent the subject of the topic
link.
DisplayedAs
element. identity
attributes of many topic links in many topic maps.
The subject described by the subject descriptor is thus easily recognized as
the common binding point of all the topic links that reference it, so that
they will be merged.
scope
attributes, the scope within which the topic characteristic applies to the
topic includes all the topics in the entire topic map; this special scope is
called "the unconstrained scope". If a scope is specified, the specification
consists of a set of topics, which, in the context of their role as members of
such a set, are called "themes". Each theme contributes to the extent of the
scope that the themes collectively define; a given scope is the union of the
subjects of the set of themes used to specify that scope.SortName
) of a TopicNames
subelement of a topic link, containing a string that is an alternative
representation of a topic name that is intended to be used for alphabetic or
other ordering.
SortName
element. identity
attribute of a topic
link is provided to allow the author of the topic link to indicate, as
unambiguously as possible, the subject he had in mind as the organizing
principle of the topic. See the definition of "subject descriptor".
identity
attribute of a topic link. (See also the definition of
"public subject descriptor".)identity
attribute) that it is to be regarded as the
authoritative definition of the organizing principle of the topic link. In the
other case, by characterizing a definition as a definitional occurrence, the
author is merely acknowledging the existence of the definition and its
possible relevance to the subject of the topic link. Subject descriptors may
be offline resources.
TopicNames
subelements of topic link
elements are used to assign names to topics as topic characteristics, so, in
topic map documents, they perform the function of assigning topic name
characteristics.
TopicMap
) of such a
document.
TopicMap
) of the topic map
document architecture. TopicNames
) element, as defined by this
specification.
BaseName
), display name
(DisplayedAs
) or name to be used as sort key
(SortName
) element, as defined by this specification, and/or
the information that such an element contains.
types
attribute. scope
attributes are explicitly specified as governing
a topic characteristic assignment, the scope within which the topic
characteristic assignment is made is the unconstrained scope.scope
attributes are explicitly specified for the name
characteristics of any topics, any two topic links that have any of the same
names will be merged, due to the effect of the topic naming
constraint.The following terms are defined in the W3C XML Linking Language specification:
The locator for a resource within an XML Topic Map must be provided by means of a Uniform Resource Identifier reference, or URI-reference [IETF RFC 2396]. A URI-reference is a URI [IETF RFC 2396], [IETF RFC 1738] and [IETF RFC 1808] with an optional fragment identifier separated from the URI by a crosshatch ("#") character. For locators into XML resources, the fragment identifier format is specified by the XPointer specification.
The topic map (TopicMap
) element can be used as the
document element of documents that conform to this specification. Its formal
definition is:
<!-- AddedElements: Elements added for use within a specific topic map. Defaults to no added elements.--> <!ENTITY % AddedElements "" > <!-- TMCFC: Topic Map Context Free Content - the set of elements allowed at the first level of a topic map.--> <!entity % TMCFC "Topic|Assocication|Facet|AddedThemes %AddedElements;" > <!-- Topic map document element --> <!ELEMENT TopicMap (%TMCFC;)* > & <!ATTLIST TopicMap xmlns CDATA #FIXED "http://www.infoloom.com/topicmaps" TopicMap CDATA #FIXED "topicmap" addthems CDATA #IMPLIED >
Issues:
1) What is the correct URL for identifying the
topic map specification. (Should it point to this spec or to the
standard?)
2) Is there any reason for retaining the HyTime attribute that
defines this element as a HyTime hub document within the XML version? (I am
presuming that it would be possible to embedd a topic map within a resource that
has metadata in it, so that it would not necessaruly be the hub document in the
XML application.)
The XML namespace attribute (xmlns
) defines the topic map
namespace. In the model defined above the element and attributes have been
defined as part of the default namespace, which has no namespace qualifier. An
alternative mechanism is to use a named namespace to identify that an element is
defined in terms of the architectural form, as follows:
<!-- Element conforming to the Topic Map document element architecture --> <!ELEMENT SubjectMap (%TMCFC;)* > & <!ATTLIST SubjectMap xmlns:TM CDATA #FIXED "http://www.infoloom.com/topicmaps" TM:TopicMap CDATA #FIXED "topicmap" TM:addthems CDATA #IMPLIED >
Issue: Should the namespace be declared on all elements or should we depend on the fact that all TM relevant elements must be declared within a TM:topicmap element, which should be sufficient to define the namespace for all subelements as well?
The TMCFC
parameter entity indicates that valid topic map
documents may or may not have any topic links, association links or facet links
in them. Some conforming applications may support only Facet
element types, while others may not support Facet
element types. At
certain well specified points in the model user defined elements can be added to
the contents of topic map elements. These points are indicated by the presence
of the %AddedElements;
parameter entity reference.
NOTE: When application-defined names are assigned to
elements within an XML Topic Map the element names in the replacement string for
the TMCFC
parameter entity should be changed to match those of the
first level subelements within the topic map.
The effect of specifying the added
themes (addthems
) attribute is to add the themes that it
references to the scopes of all of the topic characteristic assignments made
throughout the document of which the element is the root element.
The addthems
attribute can be used to acknowledge and document
the fact that the document specifies only topic characteristic assignments that
are within the scope defined by the set of themes that it specifies. It can be
used to avoid specifying these common themes explicitly in every scope. After a
topic map document is merged with other topic map documents, the contributions
that it made to the resulting merged topic map can be distinguished from the
contributions of all others by virtue of the fact that everything it contributed
continues to appear within the scopes of the topics specified by the
addthems
attribute of its document element.
The topic
link (Topic
) element is used to assign topic name
characteristics and topic occurrence characteristics to a topic. It has the
following form:
<!ELEMENT Topic (TopicNames | Occurrences)* > <!ATTLIST Topic xmlns CDATA #FIXED "http://www.infoloom.com/topicmaps" TopicMap CDATA #FIXED "topic" id ID #REQUIRED identity CDATA #IMPLIED types CDATA #IMPLIED scope CDATA #IMPLIED >
The XML namespace attribute (xmlns
) defines the topic map
namespace. In the model defined above the element and attributes have been
defined as part of the default namespace, which has no namespace qualifier. An
alternative mechanism is to use a named namespace to identify that an element is
defined in terms of the architectural form, as follows:
<!ELEMENT Subject (TopicNames | Occurrences)* > <!ATTLIST Subject xmlns:TM CDATA #FIXED "http://www.infoloom.com/topicmaps" TM:TopicMap CDATA #FIXED "topic" id ID #REQUIRED TM:identity CDATA #IMPLIED TM:types CDATA #IMPLIED TM:scope CDATA #IMPLIED >
NOTE: While the Topic
element is defined
as a HyTime variable link (varlink
) in the International Standard
it is the individual occurrences referenced by the topic that are defined using
the XML Linking Language.
Every topic link is intended by its author to be organized around exactly one
subject, regardless of whether that subject is explicitly defined anywhere. A
topic link may declare zero or more names and zero or more pieces of information
("occurrences") that are relevant to its subject. Names, and the scopes within
which the names are applicable to the subject, are declared by means of
TopicNames
subelements. Occurrences are the anchors of the topic
link; these, and the scopes within which the occurrences are applicable to the
subject, are specified by means of Occurrences
subelements.
The required unique identifier (id
) attribute allows the
topic to be adressed by association links, by the identity
attributes of other topic links, and, in their roles as themes in scopes, by
scope
and addthems
attributes.
The optional subject identity (identity
) attribute refers
to the local ID or remote URL of one or more resources that provide indications
("subject descriptors") that can be used to identify the subject (organizing
principle) of the topic. All of the other topic characteristics specified by the
topic link are regarded as elaborating, and in no way contradicting, the subject
described by the subject descriptor(s), if any. There are no restrictions on the
kinds of information that may be referenced by an identity
attribute.
Any two or more topic links that reference the same subject by means of their
identity
attributes are equivalent to a single topic link that has
the union of the characteristics (the names, occurrences, and associations) of
both topic links. The two or more topic links may be merged, and/or applications
may process and/or render them as if they have been merged.
NOTE: The two or more topic links do not have to have
identical URLs in order to be merged under this rule. It is only necessary that
the subject that is somehow indicated by the two identity
attributes be resolvable to the same URL. (For example, one topic map could use
a local ID, another could use a relative URL while a third could use an absolute
URL, all of which reference the same resource.) If two or more topics refer to
exactly the same subject descriptor, the subject descriptor may be described as
a "public subject descriptor", and it becomes possible to automate the merging
of all such topics by making the assumption that, if they all share the same
subject descriptor resource, they all share the same subject identity.
If the identity
attribute references one or more topic links,
topic map processing applications must regard the referencing topic link, and
all the referenced topic links, as having one and the same subject, and
therefore they may all be merged.
The optional topic types (types
) attribute references one
or more topic links. The subject of each such referenced topic link is a class
of subject of which the referencing topic link is an instance.
NOTE: The class-instance relationship established
between the subject of each referenced topic link and the subject of the
referencing topic link could alternatively be established by a topic association
link whose semantic is the relationship between a class and an instance of that
class. In other words, the types
attribute establishes a
relationship between topics (a topic association), rather than being a means
whereby the referencing topic becomes an occurrence of each of the referenced
topics. The topic relationships established by the types
attribute
are not superclass-subclass relationships. They are only class-instance
relationships. Superclass-subclass relationships between topics can be asserted
by topic association links that have been user-defined for that purpose.
The optional scope (scope
) attribute references the
themes that are added to the scopes within which all names and occurrences
specified by the topic link are valid.
NOTE: The scope
attribute of the
Topic
element is designed to permit a reduction in syntactic
redundancy by providing a means whereby the themes that are common to the scopes
within which all the names and occurrences of a topic are valid can be specified
once for all. There is no requirement that it be used, however, even if its use
would reduce redundancy.
A valid topic link must have at least one of the following: a topic name, a topic occurrence, or a role played in an association with at least one other valid topic.
NOTE: When only acting as the end point for an
otherwise undefined association link anchor the element should be defined as an
XML empty
element by use of the />
tag closing delimiter.
A topic may have zero or more name characteristics (topic names). Topic names
are specified using topic name (TopicNames
) elements; all
such names become topic characteristics of the topic whose subject is the
subject of the containing topic link.
<!ELEMENT TopicNames (BaseName+, DisplayedAs*, SortName* ) > <!ATTLIST TopicNames xmlns CDATA #FIXED "http://www.infoloom.com/topicmaps" TopicMap CDATA #FIXED "topname" scope CDATA #IMPLIED > <!ELEMENT BaseName (#PCDATA) > <!ATTLIST BaseName TopicMap CDATA #FIXED "basename" scope CDATA #IMPLIED > <!ELEMENT DisplayedAs (#PCDATA %AddedElements;)* > <!ATTLIST DisplayedAs TopicMap CDATA #FIXED "dispname" scope CDATA #IMPLIED > <!ELEMENT SortName (#PCDATA) > <!ATTLIST SortName TopicMap CDATA #FIXED "sortname" scope CDATA #IMPLIED >
Issue: Should the namespace be defined on all four elements?
The XML namespace attribute (xmlns
) defines the topic map
namespace. In the model defined above the element and attributes have been
defined as part of the default namespace, which has no namespace qualifier. An
alternative mechanism is to use a named namespace to identify that an element is
defined in terms of the architectural form, as follows:
<!ELEMENT Names (Name+, DisplayAs*, SortBy* ) > <!ATTLIST Names xmlns:TM CDATA #FIXED "http://www.infoloom.com/topicmaps" TM:TopicMap CDATA #FIXED "topname" TM:scope CDATA #IMPLIED > <!ELEMENT Name (#PCDATA) > <!ATTLIST Name TM:TopicMap CDATA #FIXED "basename" TM:scope CDATA #IMPLIED > <!ELEMENT DisplayAs (#PCDATA %AddedElements;)* > <!ATTLIST DisplayAs TM:TopicMap CDATA #FIXED "dispname" TM:scope CDATA #IMPLIED > <!ELEMENT SortBy (#PCDATA) > <!ATTLIST SortBy TM:TopicMap CDATA #FIXED "sortname" TM:scope CDATA #IMPLIED >
The three kinds of topic name that must be used: base name
(BaseName
), display name (DisplayedAs
), and
name used as sort key (SortName
), specified by means of the
three corresponding element types that a TopicNames
element may
contain. At least one BaseName
element must occur within each
TopicNames
element.
The scope (scope
) attribute of the
TopicNames
element specifies the themes that are common to the
scopes of all of the topic names specified by the contained
BaseName
, DisplayedAs
and SortName
elements. The scope is the context (or area of validity) in which the name
characteristic(s) specified by a TopicName
element is/are assigned
to the topic whose subject is the subject of the containing topic link.
The scope
attributes of the contained name elements
(BaseName
, DisplayedAs
and SortName
) may
be used to add more themes on a name-by-name basis, in the same manner as the
scope
attribute of the containing Topicnames
element.
NOTE: Thus, the scope
attribute of the
TopicNames
element form is really just a means of avoiding the
syntactic redundancy of specifying the themes common to the contained elements
separately via the scope
attribute of each contained element.
If no scope
attribute is specified by a BaseName
,
DisplayedAs
or SortName
element and no
scope
attribute is specified by its containing
TopicNames
element, nor by the containing TopicNames
's
containing Topic
element, then the scope of the name characteristic
specified by that BaseName
, DisplayedAs
or
SortName
is unconstrained. If any of the aforementioned
scope
attributes are specified, then the scope is constrained to
the themes specified by those scope attributes, even if the scope
attributes specify no themes, plus any themes added via any applicable
Addedthemes
elements in the bounded object set, plus any themes
added via the addthems
attribute of the containing
TopicMap
document element.
The content of the optional display name (DisplayedAs
)
element specifies a name that is designed to be displayed by an application to a
user, when the name specified by the BaseName
elements within the
same containing TopicNames
should not be used for display purposes.
NOTE: The display name can be used to specify an abbreviated name for use in situations where display resources are limited, or it can be a graphic expressed in some data content notation.
The content of the optional name to be used as sort key
(SortName
) element specifies a name that is designed to be used to
represent the topic in a sorting process that arranges a list of topics in some
order, when the name specified by the BaseName
elements within the
same containing TopicNames
should not be used for that purpose.
NOTE: Thus, the BaseName
elements, at
least one of which is required, is also, in effect, the default content of the
optional DisplayedAs
and SortName
elements. If no
DisplayedAs
elements are specified, the BaseName
elements are to be used as display names. Similarly, if no SortName
elements are specified, the BaseName
elements are to be used as
sort keys.
The data content of both BaseName
and SortName
elements must be text strings, and they may be words or phrases. The data
content of a DisplayedAs
element may be either a text string or
notation data; if it is notation data, it may be a displayable graphic or other
information intended to identify the subject to one or more of the senses of the
user of the topic map, e.g.:
<TopicNames id="Leonardo"> <BaseName>Leonardo da Vinci</BaseName> <DisplayedAs><IMG src="MonaLisa.gif"></DisplayedAs> <SortName>Da Vinci, Leonardo</SortName> </TopicNames>
NOTE: There are two reasons why base names, display
names, and names used as sort keys may share a single containing
TopicNames
element:
scope
attribute of the containing TopicNames
element, and/or
TopicNames
element. However, if no display names or sort
names are used, and many base names of a single topic have the same scope, all
of the base names may appear within a single TopicNames
element.
Two distinct subjects may not have the same name characteristic within exactly the same scope (a "topic naming constraint"). When topic maps are processed, each distinct set of themes that serves as a scope constitutes a namespace in which no two subjects can have the same name. If a conforming topic map application detects a situation in which multiple topic links have the same name characteristic within the same scope, the topics shall be merged.
NOTES:
1) This means that applications that render
the topic map will behave as though there was only a single topic link whose
characteristics comprise the union of the topic characteristics of all of the
topic links that had the same name within the same scope.
2) The topic naming constraint is designed to preserve
the ability to identify subjects unambiguously in terms of their topic name
characteristics. The topic naming constraint is also necessary in order to
support the most basic functionality of indexes and glossaries, which must make
distinctions between the various meanings of words and phrases in order to
support navigation to the relevant occurrences. Topic map authors must use
scopes to distinguish between the different meanings of any name that is used
for more than one subject. Consequently, if a topic map author does not wish to
specify scope
attributes explicitly, that author cannot use the
same name for any two different subjects, because the default scope is a single
scope: the unconstrained scope. Since any two identical names will appear within
that single scope, the two subjects of which the two names are topic
characteristics will be automatically merged. Such merging is erroneous and
extremely undesirable unless the two topic links that have the same name in the
same scope also have the same subject identity.
3) As an aid to topic map authors, topic map authoring and merging applications may be designed in such a way as to give warning when topic links are being merged on account of the fact that they have the same name in the same scope.
4) One of the effects of the topic naming constraint is that the merging of topic maps can be accomplished in such a way as to make the merger maintainable even when the member topic maps are maintained separately, asynchronously, and with no extra, agreed-upon discipline (such as some sort of element naming discipline) designed to permit easy maintenance of references among the component documents of the merged topic map. The topic naming constraint makes the addressing of the subjects covered by topic maps dependent only on their names and the distinguishing criteria of their names (the scopes within which their name characteristics are valid), and not on the organization or tagging of their corresponding topic links.
5) If any two topic maps that are to be merged
conflict with one another because they happen to provide the same name within
the same scope for two different subjects, the merger of the different subjects
can be prevented by applying different added themes to one or both of their
containing topic map documents, using one or more AddedThemes
elements. The added themes specified by such Addedthemes
elements
can serve to distinguish the two identical names, because they will no longer
appear within exactly the same scope.
By means of location addresses specified in its content, the topic
occurrence (Occurrences
) element references information (one or
more "occurrences") that is relevant to the subject of the containing topic
link. This specifications requires that occurrences are specified as XML
extended link elements. They are defined a follows:
<!ELEMENT Occurrences (xlink:locator*) > <!ATTLIST Occurrences xmlns CDATA #FIXED "http://www.infoloom.com/topicmaps" xmlns:xlink CDATA #FIXED "http://www.w3.org/XML/XLink/0.9" TopicMap CDATA #FIXED "occurs" scope CDATA #IMPLIED occrl CDATA #IMPLIED type CDATA #IMPLIED xlink:type (extended) #FIXED "extended" xlink:role CDATA #IMPLIED xlink:title CDATA #IMPLIED xlink:showdefault (new|parsed|replace) #IMPLIED xlink:actuatedefault (user|auto) #IMPLIED >
Issue: xml:locator elements must have IDs. Should we ask W3C to allow these to be implied?
The XML namespace attribute (xmlns
) defines the topic map
namespace. In the model defined above the topic map related element and
attributes have been defined as part of the default namespace, which has no
namespace qualifier. An alternative mechanism is to use a named namespace to
identify that an element is defined in terms of the architectural form, as
follows:
<!ELEMENT Instances (xlink:locator*) > <!ATTLIST Instances xmlns:TM CDATA #FIXED "http://www.infoloom.com/topicmaps" xmlns:xlink CDATA #FIXED "http://www.w3.org/XML/XLink/0.9" TM:TopicMap CDATA #FIXED "occurs" TM:scope CDATA #IMPLIED TM:occrl CDATA #IMPLIED TM:type CDATA #IMPLIED xlink:type (extended) #FIXED "extended" xlink:role CDATA #IMPLIED xlink:title CDATA #IMPLIED xlink:showdefault (new|parsed|replace) #IMPLIED xlink:actuatedefault (user|auto) #IMPLIED >
The xmlns:xlink
XML namespace attribute indicates that
attributes with the xlink:
qualifier are taken from the XML Linking
Language (XLink) specification. The attributes associated with XML extended
links are defined under the heading Extended Links in that
specification.
All of the occurrences specified by any given Occurrences
element fall into a single user-defined category of occurrences called an
"occurrence role" -- the role played by the occurrences in contributing to the
information that participates in the subject characterized by the containing
topic link. Within a single topic link, more than one Occurrences
element may reference the same information, in which case the information plays
multiple occurrence roles.
NOTE: For example, if the subject of a topic link is
Leonardo Da Vinci, there may be a "scientific-biography" occurrence role, and a
separate "artistic-biography" occurrence role. Some information resources may
fall into both categories; if so, such resources will be referenced by both of
the Occurrences
elements that correspond to the two occurrence
roles, e.g.:
<Topic id="Leonardo" types="Painter Engineer Anatomist"> <TopicNames> <BaseName>Leonardo da Vinci</BaseName> <DisplayedAs><IMG src="MonaLisa.gif"></DisplayedAs> <SortName>Da Vinci, Leonardo</SortName> </TopicNames> <Occurrences type="artistic-biography"> <xlink:locator id="location2345" href="http://www.britannia.com/encyclopedia/10/L.htm#Leonardo"> .... </Occurrences> <Occurrences type="scientific-biography"> <xlink:locator id="location2345" href="http://www.britannia.com/encyclopedia/10/L.htm#Leonardo"> .... </Occurrences> <Topic>
The occurrence role is the scope within which the occurrences are relevant to
the subject of the containing topic link. The set of themes (topics) that
constitute the scope is specified via the optional scope
(scope
) attribute. If no scope
attribute is specified
by an Occurrences
element, and no scope
attribute is
specified by its containing topic
link element, then the scope of
the occurrence characteristics specified by that Occurrences
element is unconstrained. If either of the aforementioned scope
attributes are specified, then the scope is constrained to the themes specified
by those scope attributes (even if the scope
attributes specify no
themes), plus any themes added via any applicable addthms
elements
in the bounded object set, plus any themes added via the addthems
attribute of the containing topicmap
document element.
The optional occrl
attribute can be used to provide a mnemonic
name for the occurrence role.
The optional occurrence role type (type
) attribute
references a single topic link. The subject of the referenced topic link is a
class of occurrence role of which the occurrence role expressed by the
Occurrences
element is an instance.
NOTE: The class-instance relationship established
between the subject of the referenced topic link and the referencing
Occurrences
element could alternatively be established by assigning
a unique identifier to the occurrence and then making the
Occurrences
element an occurrence of the referenced topic link,
within the scope of an occurrence role whose meaning is that the occurrence role
is an instance of the subject of the topic link.
If the occurrence role type (type
) attribute is
specified, and if the topic referenced by the type
attribute has a
name characteristic that lies within a scope that is appropriate to the topic
map user's context, the referenced topic's name characteristic is used to
characterize the occurrence role for the user. Otherwise, the value of the
occrl
attribute is used to characterize the occurrence role for the
user.
NOTE: The topic referenced via the type
attribute can have many names in scopes designed for many different user
contexts, including many different natural languages and delivery platforms,
while the occrl
attribute or XML element type name is just a single
token. Therefore, the use of a topic, referenced by the type
attribute, to characterize the occurrence role offers far more flexibility and
representational power than the simple mnemonic naming facility offered by the
occrl
attribute or XML element type name.
The xlink:locator
element that forms the content of an
Occurrence
element is defined in the Locator elements section
of the XML Linking Language (XLink) specification.
NOTE: The Occurrences
element type is
derived from the anchspec
element type of the HyTime architecture.
For the purposes of this specification, however, the HyTime attributes are
considered to be replaced by the equivalent XLink attributes.
The association link (Association
) element is used to
express relationships among topics. Topic Maps applications define the nature of
the relationships, and of the roles played by topics in those relationships. In
XML Topic Maps association links are XML extended links, and are defined as:
<!ELEMENT Association (Role)+ > <!ATTLIST Association TopicMap CDATA #FIXED "assoc" scope CDATA #IMPLIED linktype NMTOKEN #IMPLIED type CDATA #IMPLIED xmlns:xlink CDATA #FIXED "http://www.w3.org/XML/XLink/0.9" xlink:type (extended) #FIXED "extended" xlink:role CDATA #IMPLIED xlink:title CDATA #IMPLIED xlink:showdefault (new|parsed|replace) #IMPLIED xlink:actuatedefault (user|auto) #IMPLIED >
The XML namespace attribute (xmlns
) defines the topic map
namespace. In the model defined above the topic map related element and
attributes have been defined as part of the default namespace, which has no
namespace qualifier. An alternative mechanism is to use a named namespace to
identify that an element is defined in terms of the architectural form, as
follows:
<!ELEMENT Relationship (Arc)+ > <!ATTLIST Relationship xmlns:TM CDATA #FIXED "http://www.infoloom.com/topicmaps" xmlns:xlink CDATA #FIXED "http://www.w3.org/XML/XLink/0.9" TM:TopicMap CDATA #FIXED "assoc" TM:scope CDATA #IMPLIED TM:linktype NMTOKEN #IMPLIED TM:type CDATA #IMPLIED xlink:type (extended) #FIXED "extended" xlink:role CDATA #IMPLIED xlink:title CDATA #IMPLIED xlink:showdefault (new|parsed|replace) #IMPLIED xlink:actuatedefault (user|auto) #IMPLIED >
The xmlns:xlink
XML namespace attribute indicates that
attributes with the xlink:
qualifier are taken from the XML Linking
Language (XLink) specification. The attributes associated with XML extended
links are defined under the heading Extended Links in that
specification.
The optional scope (scope
) attribute specifies the scope
(the set of themes) within which the association is applicable to the topics
that serve as anchors of the association link. If the scope
attribute is not specified, the scope is unconstrained. If the
scope
attribute is specified, then the scope is constrained to the
themes specified by the scope attribute (even if the scope
attribute specifies no themes), plus any themes added via any applicable
addthms
elements in the bounded object set, plus any themes added
via the addthems
attribute of the containing topicmap
document element.
The optional hyperlink type (linktype
) attribute can be
used to provide a mnemonic name for the association type. If the
linktype
attribute is not specified, the XML element type name is
regarded as the mnemonic name of the association type.
The optional association type (type
) attribute references
a single topic link. The subject of the referenced topic link is a class of
association of which the association expressed by the association link is an
instance.
NOTE: The class-instance relationship established between the subject of the referenced topic link and the referencing association link could alternatively be established by making the association link an occurrence of the referenced topic link, with an occurrence role whose meaning is that the association link is an instance of the subject of the topic link.
If the association type (type
) attribute is specified,
and if the topic referenced by the type
attribute has a name
characteristic that lies within a scope that is appropriate to the topic map
user's context, the referenced topic's name characteristic is used to
characterize the association type for the user. Otherwise, the value of the
linktype
attribute (or, if the linktype
attribute is
not specified, the XML element type name) is used to characterize the
association type for the user.
NOTE: The topic referenced via the type
attribute can have many names in scopes designed for many different user
contexts, including many different natural languages and delivery platforms,
while the linktype
attribute or XML element type name is just a
single token. Therefore, the use of a topic, referenced by the type
attribute, to characterize the association type offers far more flexibility and
representational power than the simple mnemonic naming facility offered by the
linktype
attribute or XML element type name.
In XML Topic maps the Role element is defined as an empty XML Linking Language Arc element as follows:
<!ELEMENT Role EMPTY > <!ATTLIST Role xmlns CDATA #FIXED "http://www.infoloom.com/topicmaps" TopicMap CDATA #FIXED "assocrl" anchrole NMTOKEN #IMPLIED type CDATA #IMPLIED xmlns:xlink CDATA #FIXED "http://www.w3.org/XML/XLink/0.9" xlink:type (arc) #FIXED "arc" xlink:from IDREF #REQUIRED xlink:to IDREF #REQUIRED show (new|parsed|replace) "replace" actuate (user|auto) "user" >
The XML namespace attribute (xmlns
) defines the topic map
namespace. In the model defined above the topic map related element and
attributes have been defined as part of the default namespace, which has no
namespace qualifier. An alternative mechanism is to use a named namespace to
identify that an element is defined in terms of the architectural form, as
follows:
<!ELEMENT Arc EMPTY > <!ATTLIST Arc xmlns:TM CDATA #FIXED "http://www.infoloom.com/topicmaps" TM:TopicMap CDATA #FIXED "assocrl" TM:anchrole NMTOKEN #IMPLIED TM:type CDATA #IMPLIED xmlns:xlink CDATA #FIXED "http://www.w3.org/XML/XLink/0.9" xlink:type (arc) #FIXED "arc" xlink:from IDREF #REQUIRED xlink:to IDREF #REQUIRED xlink:show (new|parsed|replace) "replace" xlink:actuate (user|auto) "user" >
Issue: I have chosen to use xlink:arc rather than xlink:locator as this seems a more natural match. However, we need to be aware that there is a problem with the first draft of the xlink:arc specification in that it requires the use of IDs rather than URLs to locate linked resources. This would make it impossible to define an association between two topics in different maps. Is this a problem? Should we request W3C to change IDREF to CDATA to allow a URL to be specified? Would there be advantages in allowng multiple references for from or to (e.g. by using IDREFS in place of IDREF)?
The xmlns:xlink
XML namespace attribute indicates that
attributes with the xlink:
qualifier are taken from the XML Linking
Language (XLink) specification. The attributes associated with XML extended
links are defined under the heading Arc Element in that
specification.
In an XML Topic Map the association role (Role
) element
specifies a user-defined role that one topic plays with respect to another. The
two topics that are associated by the role are referenced by means of unique
identifiers specified in the xlink:from
and xlink:to
attributes.
Within a single association link, more than one Role
element may
reference the same topic, in which case the topic plays multiple roles in the
association.
NOTE: Thus, the containing Association
element can assert that a topic has one or more relationships with the same or
different topics, each relationship having a specific relationship direction.
Regardless of the association role(s) they play in the relationship expressed
by the containing Association
element, all topics referenced in the
content of the contained Role
elements play their roles in that
relationship within the same scope.
NOTE 44: This is the reason why there is no
scope
attribute on the Role
element form.
The optional HyTime-defined anchor role (anchrole
)
attribute can be used to provide a mnemonic name for the association role. If
the anchrole
attribute is not specified, the XML element type name
is regarded as the mnemonic name of the association role.
Issue: Should we put this in a separate HyTime name space or is it better to keep it as part of the TM namespace?
The optional association role type (type
) attribute
references a single topic link. The subject of the referenced topic link is a
class of association role of which the association role expressed by the
Role
element is an instance.
NOTE: The class-instance relationship thus established
between the subject of the referenced topic link and the referencing
Role
element could alternatively be established by making the
Role
element an occurrence of the referenced topic link, within the
scope of an occurrence role whose meaning is that the association role is an
instance of the subject of the topic link.
If the association role type (type
) attribute is
specified, and if the topic referenced by the type
attribute has a
name characteristic that lies within a scope that is appropriate to the topic
map user's context, the referenced topic's name characteristic is used to
characterize the association role for the user. Otherwise, the value of the
anchrole
attribute (or, if the anchrole
attribute is
not specified, the XML element type name) is used to characterize the
association
NOTE: The topic referenced via the type attribute can have many names in scopes designed for many different user contexts, including many different natural languages and delivery platforms, while the anchrole attribute or XML element type name is just a single token. Therefore, the use of a topic, referenced by the type attribute, to characterize the association role offers far more flexibility and representational power than the simple mnemonic naming facility offered by the anchrole attribute or XML element type name.
The commonly used class-member relationship between two topics can be specified using Associations as follows:
<Association type="ClassMembership"> <Role type="Supertype" xlink:from="Topic1" xlink:to="ClassTopic2"> <Role type="Subtype" xlink:from="ClassTopic2" xlink:to="Topic1" > </Association>
By using application-specific names, and taking advantage of the fact that
the default value for the type
attribute is the XML element type
name, this example can be simplified to:
<ClassMembership> <Supertype xlink:from="Topic1" xlink:to="ClassTopic2"> <Subtype xlink:from="ClassTopic2" xlink:to="Topic1" > </ClassMembership>
The themes to be added (AddedThemes
) element allows
themes to be added:
tmdocs
) attribute, and/or
cassign
) attribute, if any,
and/or
cassign
) attribute, if any. In XML Topic Maps the element is defined as:
<!ELEMENT AddedThemes ANY > <!ATTLIST AddedThemes xmlns CDATA #FIXED "http://www.infoloom.com/topicmaps" TopicMap CDATA #FIXED "addthms" addthems CDATA #REQUIRED tmdocs ENTITIES #IMPLIED cassign CDATA #IMPLIED >
The XML namespace attribute (xmlns
) defines the topic map
namespace. In the model defined above the topic map related element and
attributes have been defined as part of the default namespace, which has no
namespace qualifier. An alternative mechanism is to use a named namespace to
identify that an element is defined in terms of the architectural form, as
follows:
<!ELEMENT GeneralThemes ANY > <!ATTLIST GeneralThemes xmlns:TM CDATA #FIXED "http://www.infoloom.com/topicmaps" TM:TopicMap CDATA #FIXED "addthms" TM:addthems CDATA #REQUIRED TM:tmdocs ENTITIES #IMPLIED TM:cassign CDATA #IMPLIED >
The added themes (addthems
) attribute's value is a
reference to one or more topic link elements. The referenced topic link elements
must be regarded by topic map applications as additional themes in the scopes of
the topic characteristics specified via the tmdocs
and
cassign
attributes.
The tmdocs
and cassign
attributes are independent
of one another. If both are specified, the tmdocs
attribute does
not establish a location source for the addresses specified via the
cassign
attribute; the cassign
attribute must be used
in such a way that it establishes its own location source(s).
NOTE: When topic maps are to be merged, the
tmdocs
attribute can be used allow applications to distinguish
between the characteristics of topics in terms of the different topic maps that
contributed those characteristics. For example, a topic can be created that
represents the rhetorical position or purpose of a given topic map, and then, by
means of an addthms
element, that new topic can be used as an
additional scope within which all the topic characteristics specified by the
topic map is said to be valid. After the topic map document is merged with other
topic map documents, the contributions that it made to the resulting merged
topic map can be distinguished from all others by virtue of the fact that
everything it contributed continues to appear within the scope of the topic
representing the document or hyperdocument that contributed it.
The addthms
element's content is not defined by this
specification. While any element can be used the element will normally be
specified as an empty XML element, e.g.
<AddedThemes addthms="European-Artists" tmdocs="http://www.EU-topics.org/maps/artists.xml" >
The "facet linking" facility allows property/value pairs to be added to read-only information objects. The properties are called "facet types", and the values are called "facet values". This specification does not constrain the nature of facet linking applications; they may or may not also use topic links.
NOTE: The property/value pairs applied by facet links can be used, for example, as selection criteria to create partial views of a corpus of information. It should be noted, however, that topic links are much more generalized and powerful than facet links.
The facet link (facet
) element form is used to apply
property/value pairs to information objects specified by the contained
fvalue
elements. Facet link properties (facet types
) and
values (specified by means of the contained fvalue
elements) are
user-defined.
In XML Topic Maps the facet
element is defined as an XML
extended link as follows:
<!ELEMENT Facet (FacetValue+) > <!ATTLIST Facet xmlns CDATA #FIXED "http://www.infoloom.com/topicmaps" TopicMap CDATA #FIXED "facet" linktype NAME #IMPLIED type CDATA #IMPLIED >
The XML namespace attribute (xmlns
) defines the topic map
namespace. In the model defined above the topic map related element and
attributes have been defined as part of the default namespace, which has no
namespace qualifier. An alternative mechanism is to use a named namespace to
identify that an element is defined in terms of the architectural form, as
follows:
<!ELEMENT Property (Value+) > <!ATTLIST Property xmlns:TM CDATA #FIXED "http://www.infoloom.com/topicmaps" TM:TopicMap CDATA #FIXED "facet" TM:linktype NAME #IMPLIED TM:type CDATA #IMPLIED >
The optional hyperlink type (linktype
) attribute can be
used to provide a mnemonic name for the property (facet type). If the
linktype
attribute is not specified, the XML element type name is
regarded as the mnemonic name of the property.
The optional facet type (type
) attribute references a
single topic link. The subject of the referenced topic link is the property (the
facet type) specified in all of the property/value pair assignments made by the
facet link.
NOTE: The class-instance relationship established between the subject of the referenced topic link and the referencing facet link could alternatively be established by making the facet link an occurrence of the referenced topic link, with an occurrence role whose meaning is that the facet link is an instance of the subject of the topic link.
If the facet type (type
) attribute is specified, and if
the topic referenced by the type
attribute has a name
characteristic that lies within a scope that is appropriate to the topic map
user's context, the referenced topic's name characteristic is used to
characterize the property (the facet type) for the user. Otherwise, the value of
the hyperlink type (linktype
) attribute (or, if the
linktype
attribute is not specified, the XML element type name) is
used to characterize the property for the user.
NOTE: The topic referenced via the type
attribute can have many names in scopes designed for many different user
contexts, including many different natural languages and delivery platforms,
while the linktype
attribute or XML element type name is just a
single token. Therefore, the use of a topic, referenced by the type
attribute, to characterize the property (the facet type) offers far more
flexibility and representational power than the simple mnemonic naming facility
offered by the linktype
attribute or XML element type name.
The facet value (FacetValue
) element form specifies a
user-defined value of the property (facet type) being applied by the containing
facet link. The information objects to which the property/value pair is being
assigned are referenced by means of the location addresses specified in the
content of the fvalue
element.
In XML Topic Maps the FacetValue
element is defined as an XML
Extended Link as follows:
<!ELEMENT FacetValue (xlink:locator*) > <!ATTLIST FacetValue xmlns CDATA #FIXED "http://www.infoloom.com/topicmaps" xmlns:xlink CDATA #FIXED "http://www.w3.org/XML/XLink/0.9" TopicMap CDATA #FIXED "fvalue" facetval NMTOKEN #IMPLIED type CDATA #IMPLIED xlink:type (extended) #FIXED "extended" xlink:role CDATA #IMPLIED xlink:title CDATA #IMPLIED xlink:showdefault (new|parsed|replace) #IMPLIED xlink:actuatedefault (user|auto) #IMPLIED >
The XML namespace attribute (xmlns
) defines the topic map
namespace. In the model defined above the topic map related element and
attributes have been defined as part of the default namespace, which has no
namespace qualifier. An alternative mechanism is to use a named namespace to
identify that an element is defined in terms of the architectural form, as
follows:
<!ELEMENT Value (xlink:locator*) > <!ATTLIST Value xmlns:TM CDATA #FIXED "http://www.infoloom.com/topicmaps" xmlns:xlink CDATA #FIXED "http://www.w3.org/XML/XLink/0.9" TM:TopicMap CDATA #FIXED "fvalue" TM:facetval NMTOKEN #IMPLIED TM:type CDATA #IMPLIED xlink:type (extended) #FIXED "extended" xlink:role CDATA #IMPLIED xlink:title CDATA #IMPLIED xlink:showdefault (new|parsed|replace) #IMPLIED xlink:actuatedefault (user|auto) #IMPLIED >
The xmlns:xlink
XML namespace attribute indicates that
attributes with the xlink:
qualifier are taken from the XML Linking
Language (XLink) specification. The attributes associated with XML extended
links are defined under the heading Extended Links in that
specification.
The optional facet value name (facetval
) attribute
specifies the token which is the value of the property/value pair being
assigned. If the facetval
attribute is not specified, the XML
element type name of the FacetValue
element is the value being
assigned.
NOTE: The rules for defaulting the values of the
type
attribute of a Facet
element and the
facetval
attribute of a FacetValue
element mean that a
property assignment defined using the following set of predefined elements:
<Facet type="Language"> <FacetValue facetval="English"> <xlink:locator id="location1234" href="http://www.MI5.org/files/secrets.htm"/> </FacetValue> </Facet>
could also be defined as:
<Language> <English> <xlink:locator id="location1234" href="http://www.MI5.org/files/secrets.htm"/> </English> </Language>
if the appropriate namespace controlled attributes
have been assigned to the Language
and English
elements in the associated DTD.
The optional facet value type (type
) attribute references
a single topic link. The subject of the referenced topic link is the
significance of the facet value.
NOTE: The class-instance relationship established
between the subject of the referenced topic link and the referencing
fvalue
element could alternatively be established by making the
fvalue
element an occurrence of the referenced topic link, with an
occurrence role whose meaning is that the fvalue
element is an
instance of the subject of the topic link.
If an XML Topic Map document complies with all provisions of this specification, and is a valid XML document, it is a conforming topic map document.
Issue: Is it necessary to validate the XML file, or is it sufficient that the XML document is well-formed?
A conforming application intended to use existing XML Topic Maps must be able to:
A conforming application intended to read and write XML Topic Maps must meet both of the above sets of requirements. If an application can import topic maps, has features to edit them, but cannot export altered topic maps in the interchange syntax defined by this International Standard, then it is not a conforming application.
NOTE: This specification constrains neither the uses to which topic maps can be put, nor the character of the processing that may be applied by a conforming application. This conformance clause is intended to guarantee that conforming topic maps can be understood to whatever degree conforming read-only applications are intended to understand them, and that the topic mapping information expressed using the topic map syntax will be preserved by conforming read/write applications (except to the extent that the users of read/write applications deliberately alter that information).
A topic map template consists of a customized DTD and, optionally, a set of
topics, associations and facets that are relevant to more than one topic map.
The topics and associations in a topic map template typically define the topics
that will be referenced using the type
and scope
attributes to create subsets of the topic map.
The following (simplified) example shows a topic map template based on the predefined topic map elements defined within this specification:
<!DOCTYPE TopicMap [ <!-- AddedElements: Elements added for use within a specific topic map. Defaults to no added elements.-- > <!ENTITY % AddedElements "" > <!-- TMCFC: Topic Map Context Free Content - the set of elements allowed at the first level of a topic map.-- > <!entity % TMCFC "Topic|Assocication|Facet|AddedThemes %AddedElements;" > <!-- Topic map document element -- > <!ELEMENT TopicMap (%TMCFC;)* > <!ATTLIST TopicMap xmlns CDATA #FIXED "http://www.infoloom.com/topicmaps" TopicMap CDATA #FIXED "topicmap" addthems CDATA #IMPLIED > <!ELEMENT Topic (TopicNames | Occurrences)* > <!ATTLIST Topic xmlns CDATA #FIXED "http://www.infoloom.com/topicmaps" TopicMap CDATA #FIXED "topic" id ID #REQUIRED identity CDATA #IMPLIED types CDATA #IMPLIED scope CDATA #IMPLIED > <!ELEMENT TopicNames (BaseName+, DisplayedAs*, SortName* ) > <!ATTLIST TopicNames xmlns CDATA #FIXED "http://www.infoloom.com/topicmaps" TopicMap CDATA #FIXED "topname" scope CDATA #IMPLIED > <!ELEMENT BaseName (#PCDATA) > <!ATTLIST BaseName TopicMap CDATA #FIXED "basename" scope CDATA #IMPLIED > <!ELEMENT DisplayedAs (#PCDATA %AddedElements;)* > <!ATTLIST DisplayedAs TopicMap CDATA #FIXED "dispname" scope CDATA #IMPLIED > <!ELEMENT SortName (#PCDATA) > <!ATTLIST SortName TopicMap CDATA #FIXED "sortname" scope CDATA #IMPLIED > <!ELEMENT Occurrences (xlink:locator*) > <!ATTLIST Occurrences xmlns CDATA #FIXED "http://www.infoloom.com/topicmaps" xmlns:xlink CDATA #FIXED "http://www.w3.org/XML/XLink/0.9" TopicMap CDATA #FIXED "occurs" scope CDATA #IMPLIED occrl CDATA #IMPLIED type CDATA #IMPLIED xlink:type (extended) #FIXED "extended" xlink:role CDATA #IMPLIED xlink:title CDATA #IMPLIED xlink:showdefault (new|parsed|replace) #IMPLIED xlink:actuatedefault (user|auto) #IMPLIED > <!ELEMENT Association (Role)+ > <!ATTLIST Association TopicMap CDATA #FIXED "assoc" scope CDATA #IMPLIED linktype NMTOKEN #IMPLIED type CDATA #IMPLIED xmlns:xlink CDATA #FIXED "http://www.w3.org/XML/XLink/0.9" xlink:type (extended) #FIXED "extended" xlink:role CDATA #IMPLIED xlink:title CDATA #IMPLIED xlink:showdefault (new|parsed|replace) #IMPLIED xlink:actuatedefault (user|auto) #IMPLIED > <!ELEMENT Role EMPTY > <!ATTLIST Role xmlns CDATA #FIXED "http://www.infoloom.com/topicmaps" TopicMap CDATA #FIXED "assocrl" anchrole NMTOKEN #IMPLIED type CDATA #IMPLIED xmlns:xlink CDATA #FIXED "http://www.w3.org/XML/XLink/0.9" xlink:type (arc) #FIXED "arc" xlink:from IDREF #REQUIRED xlink:to IDREF #REQUIRED show (new|parsed|replace) "replace" actuate (user|auto) "user" > <!ELEMENT AddedThemes ANY > <!ATTLIST AddedThemes xmlns CDATA #FIXED "http://www.infoloom.com/topicmaps" TopicMap CDATA #FIXED "addthms" addthems CDATA #REQUIRED tmdocs ENTITIES #IMPLIED cassign CDATA #IMPLIED > <!ELEMENT Facet (FacetValue+) > <!ATTLIST Facet xmlns CDATA #FIXED "http://www.infoloom.com/topicmaps" TopicMap CDATA #FIXED "facet" linktype NAME #IMPLIED type CDATA #IMPLIED > <!ELEMENT FacetValue (xlink:locator*) > <!ATTLIST FacetValue xmlns CDATA #FIXED "http://www.infoloom.com/topicmaps" xmlns:xlink CDATA #FIXED "http://www.w3.org/XML/XLink/0.9" TopicMap CDATA #FIXED "fvalue" facetval NMTOKEN #IMPLIED type CDATA #IMPLIED xlink:type (extended) #FIXED "extended" xlink:role CDATA #IMPLIED xlink:title CDATA #IMPLIED xlink:showdefault (new|parsed|replace) #IMPLIED xlink:actuatedefault (user|auto) #IMPLIED > <!ELEMENT xlink:locator EMPTY > <!ATTLIST xlink:locator id ID #REQUIRED href CDATA #REQUIRED role CDATA #IMPLIED title CDATA #IMPLIED > ]> <TopicMap addthems="EuropeanArt"> <Topic id="EuropeanArt" identity="http://www.topics.org/subjects/index.xml#Art-Europeen" scope="http://www.topics.org/maps/Regions.xml#Europe"> <TopicNames scope="EnglishNames"> <BaseName>Art, European</BaseName> <BaseName>European Art</BaseName> <BaseName>History of European Art</BaseName> </TopicNames> <TopicNames scope="NomFrancais"> <BaseName>Art, Europečn</BaseName> <BaseName>Histoire d'Art Europečn</BaseName> <SortName>Art, Europeen</SortName> </TopicNames> </Topic> <Topic id="EnglishNames"> <TopicNames> <BaseName>English Version of Names</BaseName> <BaseName>Name in English</BaseName> </TopicNames> </Topic> <Topic id="NomFrancais"> <TopicNames> <BaseName>Nom Français</BaseName> <SortName>Nom Francais</SortName> </TopicNames> </Topic> <Topic id="Class"> <TopicNames scope="EnglishNames NomFrancais"> <BaseName>Class</BaseName> </TopicNames> </Topic> <Topic id="Member"> <TopicNames scope="EnglishNames"> <BaseName>Class Member</BaseName> <BaseName>Member (of class)</BaseName> </TopicNames> <TopicNames scope="NomFrancais"> <BaseName>Membre</BaseName> </TopicNames> </Topic> <Topic id="Supertype"/> <Topic id="Subtype"/> <Topic id="ArtistClass"> <TopicNames scope="EnglishNames"> <BaseName>Artist</BaseName> </TopicNames> <TopicNames scope="NomFrancais"> <BaseName>Artiste</BaseName> </TopicNames> </Topic> <Topic id="Painter"> <TopicNames scope="EnglishNames"> <BaseName>Painter</BaseName> </TopicNames> <TopicNames scope="NomFrancais"> <BaseName>Painteur</BaseName> </TopicNames> </Topic> <!--Add application-specific topics here --> <Association type="ClassMembership"> <Role type="Supertype" xlink:from="Painter" xlink:to="ArtistClass"> <Role type="Subtype" xlink:from="ArtistClass" xlink:to="Painter" > </Association> <!--Add application specific associations here --> <Facet type="Language"> <FacetValue facetval="English"> <!--Add locations for resources in English here --> </FacetValue> <FacetValue facetval="French"> <!--Add locations for resources in French here --> </FacetValue> </Facet> </TopicMap>
As well as defining a set of topics that are relevant for a wide range of
topic maps, including empty declarations for the Supertype
and
Subtype
types of association roles, the template also includes
placeholders that will allow language identifiers to be associated with
resources referenced using the topic map so that users can request views that
just show English or French resources.
Using an external entity to store the alternative set of elements with namespaced attributes shown as examples in the specification, the template would take the form:
<DOCTYPE SubjectMap SYSTEM "alternative.dtd"[]> <SubjectMap TM:addthems="EuropeanArt"> <Subject id="EuropeanArt" TM:identity="http://www.topics.org/subjects/index.xml#Art-Europeen" TM:scope="http://www.topics.org/maps/Regions.xml#Europe"> <Names TM:scope="EnglishNames"> <Name>Art, European</Name> <Name>European Art</Name> <Name>History of European Art</Name> </Names> <Names TM:scope="NomFrancais"> <Name>Art, Europečn</Name> <Name>Histoire d'Art Europečn</Name> <SortBy>Art, Europeen</SortBy> </Names> </Subject> <Subject id="EnglishNames"> <Names> <Name>English Version of Names</Name> <Name>Name in English</Name> </Names> </Topic> <Subhect id="NomFrancais"> <Names> <Name>Nom Français</Name> <SortBy>Nom Francais</SortBy> </Names> </Subhect> <Subject id="Class"> <Names TM:scope="EnglishNames NomFrancais"> <Name>Class</Name> </Names> </Subject> <Subject id="Member"> <Names TM:scope="EnglishNames"> <Name>Class Member</Name> <Name>Member (of class)</Name> </Names> <Names TM:scope="NomFrancais"> <Name>Membre</Name> </Names> </Subject> <Subject id="Supertype"/> <Subject id="Subtype"/> <Subject id="ArtistClass"> <Names TM:scope="EnglishNames"> <Name>Artist</Name> </Names> <Names TM:scope="NomFrancais"> <Name>Artiste</Name> </Names> </Subject> <Subject id="Painter"> <Names TM:scope="EnglishNames"> <Name>Painter</Name> </Names> <Names TM:scope="NomFrancais"> <Name>Painteur</Name> </Names> </Subject> <!--Add application-specific topics here --> <Relationship TM:type="ClassMembership"> <Arc TM:type="Supertype" xlink:from="Painter" xlink:to="ArtistClass"> <Arc TM:type="Subtype" xlink:from="ArtistClass" xlink:to="Painter" > </Relationship> <!--Add application specific associations here --> <Property TM:type="Language"> <Value TM:facetval="English"> <!--Add locations for resources in English here --> </Value> <Value TM:facetval="French"> <!--Add locations for resources in French here --> </Value> </Property> </SubjectMap>
The instance can be simplified further by defining elements for each property, permitted property value and type of relationship, e.g.
<DOCTYPE SubjectMap SYSTEM "alternative.dtd" [ <!ELEMENT Language (English|French)+ > <!ATTLIST Language xmlns:TM CDATA #FIXED "http://www.infoloom.com/topicmaps" TM:TopicMap CDATA #FIXED "facet" TM:linktype NAME #IMPLIED TM:type CDATA #IMPLIED > <!ELEMENT English (xlink:locator*) > <!ATTLIST English xmlns:TM CDATA #FIXED "http://www.infoloom.com/topicmaps" xmlns:xlink CDATA #FIXED "http://www.w3.org/XML/XLink/0.9" TM:TopicMap CDATA #FIXED "fvalue" TM:facetval NMTOKEN #IMPLIED TM:type CDATA #IMPLIED xlink:type (extended) #FIXED "extended" xlink:role CDATA #IMPLIED xlink:title CDATA #IMPLIED xlink:showdefault (new|parsed|replace) #IMPLIED xlink:actuatedefault (user|auto) #IMPLIED > <!ELEMENT French (xlink:locator*) > <!ATTLIST French xmlns:TM CDATA #FIXED "http://www.infoloom.com/topicmaps" xmlns:xlink CDATA #FIXED "http://www.w3.org/XML/XLink/0.9" TM:TopicMap CDATA #FIXED "fvalue" TM:facetval NMTOKEN #IMPLIED TM:type CDATA #IMPLIED xlink:type (extended) #FIXED "extended" xlink:role CDATA #IMPLIED xlink:title CDATA #IMPLIED xlink:showdefault (new|parsed|replace) #IMPLIED xlink:actuatedefault (user|auto) #IMPLIED > <!ELEMENT Relationship (Supertype|Subtype) > <!ELEMENT Supertype EMPTY > <!ATTLIST Supertype xmlns:TM CDATA #FIXED "http://www.infoloom.com/topicmaps" TM:TopicMap CDATA #FIXED "assocrl" TM:anchrole NMTOKEN #IMPLIED TM:type CDATA #IMPLIED xmlns:xlink CDATA #FIXED "http://www.w3.org/XML/XLink/0.9" xlink:type (arc) #FIXED "arc" xlink:from IDREF #REQUIRED xlink:to IDREF #REQUIRED xlink:show (new|parsed|replace) "replace" xlink:actuate (user|auto) "user" > <!ELEMENT Subtype EMPTY > <!ATTLIST Subtype xmlns:TM CDATA #FIXED "http://www.infoloom.com/topicmaps" TM:TopicMap CDATA #FIXED "assocrl" TM:anchrole NMTOKEN #IMPLIED TM:type CDATA #IMPLIED xmlns:xlink CDATA #FIXED "http://www.w3.org/XML/XLink/0.9" xlink:type (arc) #FIXED "arc" xlink:from IDREF #REQUIRED xlink:to IDREF #REQUIRED xlink:show (new|parsed|replace) "replace" xlink:actuate (user|auto) "user" > ]> <SubjectMap TM:addthems="EuropeanArt"> <Subject id="EuropeanArt" TM:identity="http://www.topics.org/subjects/index.xml#Art-Europeen" TM:scope="http://www.topics.org/maps/Regions.xml#Europe"> <Names TM:scope="EnglishNames"> <Name>Art, European</Name> <Name>European Art</Name> <Name>History of European Art</Name> </Names> <Names TM:scope="NomFrancais"> <Name>Art, Europečn</Name> <Name>Histoire d'Art Europečn</Name> <SortBy>Art, Europeen</SortBy> </Names> </Subject> <Subject id="EnglishNames"> <Names> <Name>English Version of Names</Name> <Name>Name in English</Name> </Names> </Topic> <Subhect id="NomFrancais"> <Names> <Name>Nom Français</Name> <SortBy>Nom Francais</SortBy> </Names> </Subhect> <Subject id="Class"> <Names TM:scope="EnglishNames NomFrancais"> <Name>Class</Name> </Names> </Subject> <Subject id="Member"> <Names TM:scope="EnglishNames"> <Name>Class Member</Name> <Name>Member (of class)</Name> </Names> <Names TM:scope="NomFrancais"> <Name>Membre</Name> </Names> </Subject> <Subject id="Supertype"/> <Subject id="Subtype"/> <Subject id="ArtistClass"> <Names TM:scope="EnglishNames"> <Name>Artist</Name> </Names> <Names TM:scope="NomFrancais"> <Name>Artiste</Name> </Names> </Subject> <Subject id="Painter"> <Names TM:scope="EnglishNames"> <Name>Painter</Name> </Names> <Names TM:scope="NomFrancais"> <Name>Painteur</Name> </Names> </Subject> <!--Add application-specific topics here --> <Relationship TM:type="ClassMembership"> <Supertype xlink:from="Painter" xlink:to="ArtistClass"> <Subtype xlink:from="ArtistClass" xlink:to="Painter" > </Relationship> <!--Add application specific associations here --> <Language> <English> <!--Add locations for resources in English here --> </English> <French> <!--Add locations for resources in French here --> </French> </Language> </SubjectMap>