F.32 TMRM/TMDM – Topic Map Reference/Data Models
A topic map is a standard for the representation and interchange of knowledge, with an emphasis on the findability of information. Topic maps were originally developed in the late 1990s as a way to represent back-of-the-book index structures so that multiple indexes from different sources could be merged. However, the developers quickly realized that with a little additional generalization, they could create a meta-model with potentially far wider application. The ISO standard is formally known as ISO/IEC 13250:2003.
A topic map represents information using
- topics, representing any concept, from people, countries, and organizations to software modules, individual files, and events,
- associations, representing hypergraph relationships between topics, and
- occurrences, representing information resources relevant to a particular topic.
Topic maps are similar to concept maps and mind maps in many respects, though only topic maps are ISO standards. Topic maps are a form of semantic web technology similar to RDF.
See also: https://www.isotopicmaps.org/tmrm/, https://www.iso.org/standard/40757.html (ISO/IEC 13250-5:2015 Information technology – Topic Maps – Part 5: Reference model), https://www.isotopicmaps.org/sam/sam-model/ (Topic Maps – Data Model)
F.32.3 Key characteristics
A generic ontology with little ontological commitment. Allows higher order levels. Potentially non-well bounded (no notion of particulars). Instantiation is possibly gunky and junky across topics. Sub-class is possibly gunky and junky across topics. No explicit commitment to mereological relations.
F.32.4 Relevant Extracts
Ontology and merging
Topics, associations, and occurrences can all be typed, where the types must be defined by the one or more creators of the topic map(s). The definitions of allowed types is known as the ontology of the topic map.
The Topic Maps Reference Model - 5 Ontological Commitments
This Standard deliberately leaves undefined the methods whereby subject proxies are derived or created. No specific mechanism of subject identification is inherent in or mandated by this Standard, nor does it predefine any subject proxies.
NOTE 1 Any subject proxy design choices would be specific to a particular application domain and would exclude equally valid alternatives that might be appropriate or necessary in the contexts of various requirements.
Two types of relationships, sub (subclass of) and isa (instance of), are defined. These predicates are always interpreted relative to a given map m:
a) Two proxies c, c0 can be in a subclass-superclass relationship, subm _ m × m. In such a case, the same relationship can be stated either c is a subclass of c0 or c0 is a superclass of c.
subm is supposed to be reflexive and transitive. Reflexive implies that any proxy is a subclass of itself, regardless whether the proxy is used as a class in the map or not: x subm x for all x 2 m.
Transitive implies that if a proxy c is a subclass of another, c0, and that subclasses c00, then c is also a subclass of c00, i.e. if c subm c0 and c0 subm c00 then also c subm c00 must be true.
NOTE 2 Circular subclass relationships may exist in a map.
b) Two proxies a, c can be in an isa relationship, isam _ m × m. In such a case, the same relationship can be stated either a is an instance of c or c is the type of a.
The isa relationship is supposed to be non-reflexive, i.e. x isam x for no x 2 m, so that no proxy can be an instance of itself. Additionally, whenever a proxy a is an instance of another c, then a is an instance of any superclass of 😄 if x isam c and c subm c0, then x isam c0 is true.
NOTE 3 This Standard does not mandate any particular way of representing such relationships inside a map. One option is to model such a relationship simply with a property using a certain key (say type). An alternative way is to provide a proxy for each such relationship. Such relationship proxies could, for example, have properties whose keys are instance and class, or respectively subclass and superclass.
7 Core subject identifiers
7.2 The type-instance relationship
A topic type is a subject that captures some commonality in a set of subjects. Any subject that belongs to the extension of a particular topic type is known as an instance of that topic type. A topic type may itself be an instance of another topic type, and there is no limit to the number of topic types a subject may be an instance of.
The type-instance relationship is not transitive. That is, if B is an instance of the type A, and C is an instance of the type B, it does not follow that C is an instance of A.
7.3 The supertype-subtype relationship
The supertype-subtype relationship is the relationship between a more general type (the supertype) and a specialization of that type (the subtype). If B is the subtype of A, it follows that every instance of B is also an instance of A. The converse is not necessarily true. A type may have any number of subtypes and supertypes.
The supertype-subtype relationship is transitive, which means that if B is a subtype of A, and C a subtype of B, C is also a subtype of A.
Loops in this relationship are allowed, and should be interpreted to mean that the sets of instances for all types in the loop are the same. This does not, however, necessarily imply that the types are the same.
The semantics of the supertype-subtype relationship implies the existence of further type-instance and supertype-subtype relationships in addition to those explicitly represented by associations in the topic map. This part of ISO/IEC13250 does not require associations to be created for inferred relationships.
Continue to Appendix G: Prior ontological commitment literature