About Profiles

A profile specifies the use of a particular standard, or group of standards, to support a particular: By "specifying the use" we mean to select options, subsets, and values of parameters, where these choices are left open in the standard.

According to ISO TR 10000: Framework and Taxonomy of International Standardized Profiles (somewhat paraphrased):

A profile identifies a set of base standards, together with appropriate options and parameters necessary to accomplish identified functions for purposes including: (a) interoperability, and (b) methodology for referencing the various uses of the base standards, meaningful both to users and suppliers.
For this discussion, profiles for protocol standards only (either Z39.50 or Z39.50 used together with one or more other protocols) are considered, though other standards besides protocols are also profiled.

Architectural note

The distinction between "Z39.50" and "Z39.50 used together with other protocols" is important. In the simple case, a profile is developed for the use of Z39.50 for a particular application, for example GILS. In the case where multiple protocols are profiled, there are two cases to consider: there may be two application protocols used together to support an application (for example, Z39.50 and Interlibrary Loan), or a profile might specify that Z39.50 is to be used in conjunction with a particular supporting (i.e. lower level) protocol for example "Z39.50 and TCP". (In the latter case the profile would specify not only that the two protocols are to be used, but also, how they are used together.)

Thus architecturally, a profile specifies the use of:

  1. a single application level protocol (i.e. Z39.50);
  2. multiple application level protocols (e.g. Z39.50 and ILL; this is a hypothetical example as there are no profiles yet for this category.); or
  3. an application protocol together with a supporting communication protocol (e.g. Z39.50 and TCP).

Why Profiles?

Z39.50-1995 is (of necessity) a large standard, rich in functionality. In general an implementation does not support the complete standard, but rather a conforming subset corresponding to specific relevant requirements. The two primary reasons for profiles are:

Who Profiles?

Typically, a Z39.50 profile is developed by a profile team or committee with members including:

Some of the Terminology

Historically, the term "profile" has been refined over the past dozen or so years, during which it has been confused with various related terms such as "application profile", "International Standardized Profile" (ISP), "Internationally Registered Profile" (IRP), "Implementors Agreement(s)", and "harmonized profile". Following is a brief summary of these terms.

Profiles and ISPs

ISO TR 10000 discusses in detail its concept of a profile; the discussion is then extended to describe an International Standardized Profile. A profile is defined as:

A set of one or more base standards, and, where applicable, the identification of chosen classes, subsets, options and parameters of those base standards, necessary for accomplishing a particular function.

TR 10000 defines an ISP as:

"An Internationally agreed to, harmonized document which identifies a standard or group of standards, together with options and parameters, necessary to accomplish a function or set of functions".

So there is an important difference between the concepts of profile and ISP. An ISP is a formal document that has achieved international consensus (it in fact has the status of an international standard). A profile is much less formal, and does not necessarily reflect consensus (the use of a qualifier, as in "approved profile", may be used to indicate some level of consensus). In fact TR 10000 seems to view a profile as an abstract object and an ISP as its physical manifestation. The following text from TR 10000 supports this interpretation:

The concept of a profile ... is considered first in an abstract sense .... then extended to include defining its relationship to other profiles ... . Finally, since a profile has to have a concrete existence in order for it to be used effectively, these conceptual aspects are related to a formal documentation system.[Here, 'formal documentation system' means an ISP].

The Z39.50 Maintenance Agency is involved in the development of profiles for Z39.50, and supports the development of IRPs; the development of ISPs is out of scope. However, some of the guidelines described in TR-10000 are useful, in particular, the elements of a profile, and the principles of profiles.

Elements of a Profile

A profile definition includes these categories of information:

Note that the "set" of base standards could (and in many cases will be) a single standard (i.e. Z39.50), in which case the element "how they are to be used together" does not apply.

Not all of these elements will always be included in all profiles, but the list is a useful guideline.

Principles of Profiles

In general in a base standard, a particular feature is mandatory, optional, or conditional. If it is mandatory, it must be mandatory in a profile. A feature which is optional or conditional in the base standard could be mandatory, optional, conditional, or excluded in the profile. For example, a Z39.50 profile might exclude the use of named result sets (an optional feature). It might say that only the simple form of record composition name may be used, and not the complex form. It might exclude the use of the Delete service. But it could not exclude the use of the Present service; that would mandate non-conformance to the standard.

As another example, in contrast to the above example where a profile might exclude the use of named results sets, a Z39.50 profile might mandate the support of named result sets (i.e. require that a target accept Search requests specifying a ResultSetName other than "default"). Either of these would be a narrowing of the scope of the standard, which permits an implementation to choose to support or not support the use of named result sets.

Exclusion is the source of some confusion. Exclusion of a feature by a profile does not mean that an implementation which supports that feature does not conform to the profile. Suppose a profile excludes the use of named result sets (i.e. only the "default" set may be used). This means that participants using the profile have agreed that when they are operating according to the profile, named result sets will not be used. If an origin transmits a non-default result set name in a Search request and the target accepts it, then they are operating outside of the profile, but this does not mean that their implementations are non-conformant to the profile. For the origin system to conform to the profile, it would need to be configurable to operate in a mode in which it would suppress transmission of non-default result set names.

Library of Congress