Mike Taylor
26th July 1999
Version 0.3b
(SCCSID "@(#)/export/home/staff/mike/src/zthes/SCCS/s.zthes.html 1.11")
It is intended that the abstract model described here is sufficiently general that it can also be implemented by protocols and data formats other than Z39.50. As an example, an appendix defines an XML DTD for thesaurus terms based on the model, and includes an example XML document using that DTD.
This profile does not mandate any relationship between a thesaurus and a database. The model is that terms from any thesaurus database may be used to search any other database (called a target database).
Each individual term in a thesaurus is represented by a record in the database. In the interests of simplicity and orthogonality, even non-preferred terms must be represented by their own records.
Term records consist of an initial part describing the term itself (with information such as its unique identifier, scope note, etc.), together with sub-records briefly describing related terms. The primary means of navigation from one term to another is by searching for the unique identifiers of the terms related to the first one.
| Value | Meaning |
|---|---|
| 1 | mandatory, not repeatable |
| 1+ | mandatory, repeatable |
| [0,1] | optional, not repeatable |
| 0+ | optional, repeatable |
The top level term record is composed of the following elements:
| Name | Occurrence | Description |
|---|---|---|
| termId | 1 | an opaque string of characters which uniquely identifies the term within the thesaurus |
| termName | 1 | the name of the term in a form which may be displayed to a user or used as a search term in a target database |
| termQualifier | [0,1] | an additional string which, if supplied, qualifies the term name such that the combination of term and qualifier is unique within the thesaurus |
| termType | [0,1] | an indication of the type of the term, chosen from the controlled vocabulary described below |
| termLanguage | [0,1] | the language of the term |
| termNote | [0,1] | a scope note for the term: that is, arbitrary prose clarifying the meaning and scope of the term |
| termCreatedDate | [0,1] | the date on which the record defining the term was created |
| termCreatedBy | [0,1] | the name of the person who created the record defining the term |
| termModifiedDate | [0,1] | the date on which the record defining the term was last modified |
| termModifiedBy | [0,1] | the name of the person who last modified the record defining the term |
| postings | 0+ | a sub-record, in the format described below, indicating the frequency with which the term occurs in a target database |
| relation | 0+ | a sub-record, in the format described below, briefly describing a term related to this one |
It is recognised that in many thesauri there is no explicit unique identifier field, and the term itself, perhaps in combination with the qualifier, uniquely identifies a record. Thesauri such as these must nevertheless provide a termID field, which may be automatically generated simply by combining the term and qualifier.
The termType element may take the following values:
Servers may return other values of termType at their discretion. It is recommended that such extension values begin with the string ``X-''.
Each postings sub-record is composed of the following elements:
| Name | Occurrence | Description |
|---|---|---|
| sourceDb | 1 | the host, port and name of a target database in which the term may be found |
| fieldName | [0,1] | if specified, the name of a field in the target database in which the term may be found; otherwise, the sub-record represents a postings count across the entire target database |
| hitCount | 1 | the number of occurrences of the term in the target database (in the nominated field only, if specified) |
If a server wishes to communicate separate postings counts for a term in more than one field, then multiple postings sub-records with the same value of sourceDb should be used.
Each relation sub-record is composed of the following elements:
| Name | Occurrence | Description |
|---|---|---|
| relationType | 1 | an indication of the type of the relation, chosen from the controlled vocabulary described below |
| sourceDb | [0,1] | if specified, the host, port and name of a different Zthes database in which the related term is found; otherwise, the related term is in the same database as the current one |
| termId | 1 | the unique identifier of the related term within its database |
| termName | 1 | the name of the related term |
| termQualifier | [0,1] | the qualifier of the related term |
| termType | [0,1] | the type of the related term |
| termLanguage | [0,1] | the language of the related term |
The relationType element may take the following values:
Servers may return other values of relationType at their discretion. It is recommended that such extension values begin with the string ``X-''.
With a single exception, this profile deliberately restricts its set of supported relations to those discussed in ISO 2788 [2], in the belief that it is better for a small set of relations to be used interoperably than for a larger set to be specified, with different servers and clients in practice using different subsets.
That sole exception is the addition to the standard relation types of ``LE'', introduced to model the multilingual links described in ISO 5964 [7].
The ``NT'' and ``BT'' relationships are reciprocal; so are ``USE'' and ``UF''; and ``RT'' and ``LE'' are reflexive. That is, when any term T1 points to another T2 using the relation ``NT'', T2 should point back to T1 using ``BT'' and vice versa; when T1 points to T2 using the relation ``USE'', T2 should point back to T1 using ``UF'' and vice versa; and when T1 points to T2 using the relation ``RT'' or ``LE'', T2 should point back to T1 using the same relation.
The termType element in a relation sub-record may take the same values as in the top-level record.
Support for additional searches, including the following, may be useful.
As such, it requires servers and clients to support version 3 of the Z39.50 protocol.
In designing the Zthes-1 attribute set of additional attributes required for thesaurus navigational searches, we have sought to comply with the guidelines expounded in the the Attribute Set Developers Guide[6].
Unusually for a Z39.50 profile, the intention of this profile is that it be used in conjunction with other profiles. It is envisaged that an application will use the Zthes profile to navigate a thesaurus and thereby obtain terms suitable for searching in a target database; and use a second, domain-specific profile such as GILS or CIMI to search in and retrieve from that database.
The Z39.50 objects defined by this profile have the following OIDs.
| Object | OID |
|---|---|
| tagSet-Zthes | No OID yet assigned by the Z39.50 Maintenance Agency; the private OID 1.2.840.10003.14.1000.136.1 may be used if necessary. |
| The Zthes Schema | 1.2.840.10003.13.8 |
| The Zthes-1 Attribute Set | 1.2.840.10003.3.13 |
| Tag | Name | ASN.1 Datatype |
|---|---|---|
| 1 | termQualifier | InternationalString |
| 2 | termType | InternationalString |
| 3 | relationType | InternationalString |
| 4 | postings | structured |
| 5 | fieldName | InternationalString |
| 6 | hitCount | INTEGER |
| Type | Meaning |
|---|---|
| 1 | tagSet-M, defined in appendix TAG.2.1 of the Z39.50 standard [1] |
| 2 | tagSet-G, defined in appendix TAG.2.2 of the Z39.50 standard [1] |
| 3 | application-defined string tags |
| 4 | tagSet-Zthes, defined above |
The abstract schema described in section 2.2 is represented in Z39.50 by a GRS-1 record encoded with the tag-paths specified in the following table. Where possible, standard tags from tagSet-M and tagSet-G are re-used; in these cases, the generic names of the tags are listed in the right-hand column.
| Tag Path | Occurrence | Element | Generic Name |
|---|---|---|---|
| (1,14) | 1 | termId | localControlNumber |
| (2,1) | 1 | termName | title |
| (4,1) | [0,1] | termQualifier | |
| (4,2) | [0,1] | termType | |
| (2,17) | [0,1] | termNote | description |
| (2,20) | [0,1] | termLanguage | language |
| (1,15) | [0,1] | termCreatedDate | creation date |
| (1,27) | [0,1] | termCreatedBy | record created by |
| (1,16) | [0,1] | termModifiedDate | dateOfLastModifification |
| (1,28) | [0,1] | termModifiedBy | record modified by |
| (4,4) | 0+ | postings | |
| (4,4)(2,36) | 1 | sourceDb | databaseName |
| (4,4)(4,5) | [0,1] | fieldName | |
| (4,4)(4,6) | 1 | hitCount | |
| (2,30) | 0+ | relation | relation |
| (2,30)(4,3) | 1 | relationType | |
| (2,30)(2,36) | [0,1] | sourceDb | databaseName |
| (2,30)(1,14) | 1 | termId | localControlNumber |
| (2,30)(2,1) | 1 | termName | title |
| (2,30)(4,1) | [0,1] | termQualifier | |
| (2,30)(4,2) | [0,1] | termType | |
| (2,30)(2,20) | [0,1] | termLanguage | language |
(The numeric value of the tagSet-G element databaseName is assumed since it is the first of two new tagSet-G elements up for consideration at the August 1999 ZIG, and the approved elements currently go up to 35.)
(The numeric values of the tagSet-M elements record created by and record modified by are assumed since they are the first and second new tagSet-M elements up for consideration at the August 1999 ZIG, and the approved elements currently go up to 26.)
The termLanguage element is expressed as one of the standard codes described in RFC 1766 [8] and ISO 639 [9] - for example, ``en'' for English, ``fr'' for French and ``de'' for German.
The administrative date fields should be returned in the ASN.1 GeneralizedTime format. (The working group considered the Z39.50 ASN.1 date/time definition [11], but reached the conclusion that the benefits would be outweighed by the barrier raised to implementation.
The person-name elements, termCreatedBy and termModifiedBy, may be returned in whatever format is convenient for the server: this profile does not attempt to address the interpretation of such administrative information across multiple databases.
The sourceDb element should be returned in the form of a z39.50s URL as described in RFC 2056 [10]. For example, if the related term is in the database called ``aat'' on the server running on port 3950 on the host foo.bar.org, then the sourceDb element should have the value z39.50s://foo.bar.org:3950/aat.
Servers may, at their discretion, include additional tagSet-M, tagSet-G and string-tagged (type 3) elements in the records they return; they may include such additional elements at the top level, within relation sub-records, or both. Clients may display any such additional elements as they see fit, or may ignore them.
This element set may be useful when constructing a summary of several records found by a search for initial entry points to a thesaurus; it unlikely to be useful when navigating from term to term.
| Type | Value | Name | Description |
|---|---|---|---|
| 1 | 1 | termQualifier | searches in the termQualifier element of the top-level term record |
| 1 | 2 | termType | searches in the termType element of the top-level term record |
| 1 | 3 | thesAdmin | used for a variety of searches related to administrative details of thesaurus structure - see below |
| 1 | 4 | relatedTermID | used in conjunction with a semantic qualifier
(attribute type 2) with value equal to one of the
relationTypes described in section 2.2;
searches for all records in the specified relation to
the record whose termID is equal to the
search term.
For example, a search for abc123 with access point relatedTermID and semantic qualifier ``NT'' finds all the narrower terms of the record whose termID is abc123. |
The thesAdmin access point must be used with one of a small set of well-known strings as the search term. Servers may support the following values:
| ``start'' | Searches for all records considered suitable as starting points for browsing. | ``whole'' |
Searches for a special record describing the thesaurus as a
whole, and containing material such as introductory text and
revision history that might be front matter in a printed
thesaurus. This record, when it exists at all, may not be
found in any other search.
This profile does not currently specify the format of this special record: candidate respresentions would be a pre-formatted SUTRS record or a GRS-1 record using specialised schema. |
The Zthes-1 attribute set conforms to attribute set class 1 as described in the Z39.50 Attribute Architecture. However, it prescribes no rules to resolve conflict between its own semantics and those of another attribute set in the case where attributes for both are used in a single search term of a type-1 query and the top-level attribute-set of that query is Zthes-1.
| Attribute Set | Type | Value | Search For | Generic Name |
|---|---|---|---|---|
| utility | 1 | 4 | termID | local control number |
| cross-domain | 1 | 1 | termName | title |
| zthes-1 | 1 | 1 | termQualifier | |
| utility | 1 | 10 | all elements | all access points |
(In this table and the next, the numeric values of the attributes taken from the utility set are assumed from the position of those attributes in the lists in draft 3 of the utility set document. The numbers may change after the August 1999 ZIG.)
For the purpose of searches on the local control number access point, values of the termID function as opaque ``magic cookies''. Therefore, such search terms should not include any contentAuthority attribute, even if it happens that for the specific thesaurus in question, the termID identifiers are taken from a well-known source.
The following additional access points may optionally be supported:
| Attribute Set | Type | Value | Search For | Generic Name |
|---|---|---|---|---|
| zthes-1 | 1 | 3 | thesAdmin | |
| zthes-1 | 1 | 4 | relatedTermID | |
| (with a semantic qualifier from the relationType controlled vocabulary) | ||||
| utility | 1 | 3 | termLanguage | language |
| cross-domain | 1 | 4 | termNote | description |
| zthes-1 | 1 | 2 | termType | |
| utility | 1 | 1 | termCreatedDate | record date |
| (with functional qualifier ``date/time created'') | ||||
| utility | 1 | 2 | termCreatedBy | record creator |
| (with functional qualifier ``creator'') | ||||
| utility | 1 | 1 | termModifiedDate | record date |
| (with functional qualifier ``date/time last modified'') | ||||
| utility | 1 | 2 | termModifiedBy | record creator |
| (with functional qualifier ``last modifier'') | ||||
| utility | 1 | 2 | either termCreatedBy or termModifiedBy |
record creator |
| (with no functional qualifier) | ||||
(The semantic qualfiers to be used with the utility access point 2 (record creator) are not defined anywhere - the utility attribute set says
May be qualified in the same manner as the Access Point value 'Name' in the Cross Domain set.but the cross-domain attribute set does not specify any semantic qualifiers, so we have made up some sensible values for the Zthes profile, in the hope that they will be adopted by the utility set.)
A client can gain two kinds of information about Zthes databases from Explain: the fact that a particular database is a Zthes database, and the fact that a Zthes database is relevant to a particular TermList.
These two uses are specified in the next two sections.
Once a client has observed the Zthes schema in the schemas for a database, it may presume that the server observes the behaviour described in this profile. (The client may still need other information from Explain, for example what record syntaxes are supported.)
AuthorityFileInfo ::= SEQUENCE {
name [1] IMPLICIT HumanString, -- for display
database [2] IMPLICIT InternationalString,
-- z39.50s URL to the authority database.
-- Simplifies to a database name if on the same server.
exclusive [3] IMPLICIT NULL OPTIONAL
-- If present, all terms in the term
-- list come from this authority file.
-- If absent, other terms may or may not
-- be present in the term list.
}
Note: it may be desirable to include an additional item to indicate the kind of authority file being referenced. If it is desirable, an appropriate identification scheme will be required.
| [1] | National Information Standards Organization. ANSI/NISO Z39.50-1995. Information Retrieval (Z39.50): Application Service Definition and Protocol Specification. Bethesda, MD: NISO Press, 1995. Also available at http://lcweb.loc.gov/z3950/agency/document.html |
| [2] | International Organization for Standardization. ISO 2788: Guidelines for the establishment and development of monolingual thesauri, 2nd ed. Geneva: ISO, 1986. For some inexplicable and inexcusable reason, ISO standards are not generally available on-line. |
| [3] | Z39.50 Maintenance Agency. Z39.50 Attribute Architecture, Draft of November 1998. Available at http://lcweb.loc.gov/z3950/agency/attrarch/arch.html |
| [4] | Z39.50 Maintenance Agency. Z39.50 Utility Attribute Set, Draft 3 of July 1999. Available at http://lcweb.loc.gov/z3950/agency/attrarch/util.html |
| [5] | Ralph LeVan. A Cross-Domain Attribute Set, version 1.2 of 1998/11/16. Available at http://www.oclc.org/~levan/docs/crossdomainattributeset.html |
| [6] | George Percivall. Attribute Set Developers Guide, annotated outline of 18th September 1998. Available at http://harp.gsfc.nasa.gov/~eric/attr_set_developers_guide.html |
| [7] | International Organization for Standardization. ISO 5964: Guidelines for the establishment and development of multilingual thesauri. Geneva: ISO, 1985. |
| [8] | H. Alvestrand. RFC 1766: Tags for the Identification of Languages. March 1995. Available at ftp://ftp.uu.net/inet/rfc/rfc1766.Z |
| [9] | International Organization for Standardization. Prepared by ISO/TC 37, Terminology (principles and coordination). ISO 639:1988 (E/F): Code for the representation of names of languages, 1st edition, 1988. |
| [10] | R. Denenberg, J. Kunze, D. Lynch. RFC 2056: Uniform Resource Locators for Z39.50. November 1996. Available at ftp://ftp.uu.net/inet/rfc/rfc2056.Z |
| [11] | Z39.50 Maintenance Agency. Z39.50 Date/Time Definition, April 6, 1998 (amended February 17, 1999.) Available at http://lcweb.loc.gov/z3950/agency/defns/date.html |
<!-- Zthes DTD
Based on Z39.50 Profile for Thesaurus Navigation, version 0.1
(20 Feb 1999)
Version of DTD: 25 Feb 1999 -->
<!-- #PCDATA: parseable character data = text
occurence indicators (default: required, not repeatable):
?: zero or one occurrence (optional)
*: zero or more occurrences (optional, repeatable)
+: one or more occurrences (required, repeatable)
|: choice, one or the other, but not both
-->
<!ENTITY % term "termId, termName, termQualifier?,
termType?, termLanguage?">
<!ENTITY % admin "termCreatedDate?, termCreatedBy?,
termModifiedDate?, termModifiedBy?">
<!ELEMENT Zthes (%term;, termNote?,
%admin;,
relation*)>
<!ELEMENT relation (relationType, sourceDb?, %term;)>
<!ELEMENT termId (#PCDATA)>
<!ELEMENT termName (#PCDATA)>
<!ELEMENT termQualifier (#PCDATA)>
<!ELEMENT termType (#PCDATA)>
<!ELEMENT termLanguage (#PCDATA)>
<!ELEMENT termNote (#PCDATA)>
<!ELEMENT termCreatedDate (#PCDATA)>
<!ELEMENT termCreatedBy (#PCDATA)>
<!ELEMENT termModifiedDate (#PCDATA)>
<!ELEMENT termModifiedBy (#PCDATA)>
<!ELEMENT relationType (#PCDATA)>
<!ELEMENT sourceDb (#PCDATA)>
(This appendix should include a crosswalk with any pre-existing thesaurus DTDs if appropriate.)
<?XML version="1.0" ?>
<!DOCTYPE Zthes SYSTEM "zthes.dtd">
<Zthes>
<termId>102067</termId>
<termName>video art</termName>
<termType>PT</termType>
<termNote>
Use for works of art that employ video technology, especially
videotapes. For the study and practice of the art of producing such
works, use "video."
</termNote>
<relation>
<relationType>UF</relationType>
<termId>102067/001</termId>
<termName>art, video</termName>
<termType>ND</termType>
</relation>
<relation>
<relationType>BT</relationType>
<termId>185191</termId>
<termName>[time-based works]</termName>
<termType>NL</termType>
</relation>
<relation>
<relationType>RT</relationType>
<termId>54153</termId>
<termName>video</termName>
<termType>PT</termType>
</relation>
<relation>
<relationType>RT</relationType>
<termId>253827</termId>
<termName>video artists</termName>
<termType>PT</termType>
</relation>
</Zthes>
Running servers are generally generally available on z39.50s://muffin.indexdata.dk:9004/thatt and z39.50s://muffin.indexdata.dk:9004/eurovoc-eng
Several other people and organisations have also expressed an interest in implementing this profile.