Proposals and schemes for encoding KOS data range from general schemes, such as RDF (with the OWL extensions) and the Topic Map standard to much simpler and specific schemes for encoding thesaurus data as specified in ISO 2788, which inherit all the limitations of this standard and are of equally limited usefulness for the new tasks ahead. Something in between is needed. After some preliminary remarks on the functions of such a standard, we make a proposal that is parsimonious but allows for encoding very rich data. For this reason, it may seem a bit opaque at first. The first author will be happy to entertain any questions or comments.
Functions to be served by standards for machine-readable KOS
1. Input of KOS data into programs/transfer of thesaurus data from one program into another
1.1 Format for original input files (but XML difficult for that, use a more user-friendly format, such as inputting a hierarchy with levels specified by the number of dots at the beginning of a line)
1.2 Transfer from one KOS development program to another
1.3 Transfer from a KOS development program to an information system that uses a KOS for authority control, query expansion (synonym and /or hierarchic), display/browse/search, or other purposes
1.4 Transfer from a KOS development program to a KOS display/browse/search program
2. Querying KOSs and viewing results (for example, using Z39.50)
2.1 By people
2.2 By systems to use data from external KOSs for query term expansion, etc.
3. Identifying specific terms/concepts in specific KOSs
This requires rules for URIs that uniquely identify specific term/concept records in specific KOSs. Probably requires some sort of name resolution service (such a KOS registry)
3.1 Links from one KOS to another
3.2 Indexing terms/concepts in the metadata for an object, or any other reference to a term/concept in a text/object
Elements of an XML KOS data specification
This schema is parsimonious yet allows the recording of many types of data. It gives enough information to derive a full XML specification.
This specification assumes that data from each source are grouped, so that source attribution is not needed for each element; otherwise the structure would be much more complex. This works for a communications format but not for an internal database format.
The term itself is indicated in a relationship of type TERM. This allows for terms in multiple languages for the same concept and simplifies the schema since elements in term would be the same as in relationship target.
Addition of the scope element was inspired by the Topic Map Standard.
Most schemes advanced for KOS data hard-code the permissible relationship types as tags. This makes it very hard to introduce new relationship types. The scheme proposed here is based on a more elegant principle: it simply provides a generic syntax for recording relationships and makes the relationship type a data element recorded in an appropriate tag. The scheme needs a method (not given here) for indicating a relationship set defined elsewhere and used within the source or for defining a relationship set for the source. A relationship must specify the relationship types and domain and range for each. RDFS could be used for this specification (RDF object classes are entities, RDF properties are relationship types). A system processing data organized in this scheme would process a relationship instance as follows: look up the relationship type in the relationship set and get the proper entity type for domain and range, respectively. Then check the entity type in the source (domain) slot and the target (range) slot to verify agreement with the restrictions. The scheme is neutral as to how concepts, terms, and relationship types are identified. The identifiers could be URIs, system-assigned numbers, character strings representing codes or character strings representing terms.
Default is minOccurs="1" maxOccurs="1"
Source (minOccurs="0" maxOccurs="unbounded")
Pointer to or definition of relationship set used
Unit: Concept or term or group of terms (minOccurs="0" maxOccurs="unbounded")
Unique identifier
Type of concept/term [from list of values, to include facetHead]
Hierarchy position (minOccurs="0" maxOccurs="unbounded")
Hierarchical level
Class number/notation
Scope for which this concept/term holds (minOccurs="0" maxOccurs="unbounded")
Relationship (minOccurs="0" maxOccurs="unbounded")
Relationship type
Relationship target
/* See below for structure. */
Relationship strength (minOccurs="0" maxOccurs="1")
Audience level /* Of this relationship */ (minOccurs="0" maxOccurs="unbounded")
Perspective /* Of this relationship */ (minOccurs="0" maxOccurs="unbounded")
Scope for which this relationship holds (minOccurs="0" maxOccurs="unbounded")
Relationship, added information (minOccurs="0" maxOccurs="unbounded")
/* This could be a scope note explaining the relationship, an image illustrating the relationship, another term, etc. */
Type of added information /* Relationship types might be reused here. */
Relationship target
Audience level /* Of this piece of info. */ (minOccurs="0" maxOccurs="unbounded")
Perspective /* Of this piece of information */ (minOccurs="0" maxOccurs="unbounded")
Where relationship target has this structure (unifying term, text, images, multimedia document)
Relationship target
Type
/* Includes types of terms (descriptor, other preferred term, non-preferred term and types of texts and other documents, may be an elaborate hierarchy. */
Target value (a term or a document)
Term
Term variant (minOccurs="0" maxOccurs="unbounded")
Type of variant
/* Such as Preferred Spelling, other SPelling, ABbreviation, Full Term. */
Term form (complete term or Stem plus suffix)
Complete term
Stem plus suffix
Stem
Suffix
Document
Language (zero to many, exactly one for terms)
Audience level /* Of this relationship target */ (minOccurs="0" maxOccurs="unbounded")
Perspective /* Of this relationship target */ (minOccurs="0" maxOccurs="unbounded")
Scope for which this/term holds (minOccurs="0" maxOccurs="unbounded")
