About Profiles

• application, for example GILS or WAIS;
• function, for example author/title/subject searching;
• community, examples: the museum community, chemists, musicians, etc.; or
• environment, examples: the Internet, North America, Europe, etc.

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.

Architectural note

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?

• to provide a specification for vendors to build to, so that the resulting products will interoperate, and
• to provide a specification that a customer may reference for procurement.

Who Profiles?

• Potential customers of products implementing the profile.
• Vendors who intend to implement the profile. The underlying principle is that it is futile to develop a profile without determining in advance that the resultant specification will be implemented, and implemented by more than a single vendor, and that there will be a market for the implemented products.
• Subject Specialists. For example, a team developing a Geospatial profile would include geospatial specialists.
• Z39.50 experts.

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.

• An application profile is simply a profile that applies to an application protocol (e.g. Z39.50) as opposed to a lower-level protocol (e.g. tcp).
• An International Standardized Profile, ISP, is a formal document, internationally approved, that embodies one or more profiles.
• An Internationally Registered Profile , IRP, is less formal than an ISP: it is a profile that has been developed by a recognized group of users, with potentially wide use and applicability, that has been reviewed for technical conformance by the standards group responsible for the protocol to which the profile pertains (i.e. TC46/WG4 for Z39.50).
• A harmonized profile is profile which has achieved some level of "global" (i.e. international) consensus and is therefore believed to be ready for IRP or ISP status.
• Implementor agreements are informal agreements among a set of implementors aimed at achieving interoperability. An implementor agreement, or set of implementor agreements, differs from a profile in scope: though a profile is aimed at interoperability it usually has other specific objectives as well.

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:

• A set of base standards to be used together.
• How they are to be used together.
• Usage details for each of the base standards.
• A statement of scope , function, and purpose.
• Scenarios of interoperation.
• A statement of conformance requirements.

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

• A profile restricts the choice of base standard options to the extent necessary to maximize the probability of interworking;
• however, it must not specify any requirements that would contradict or cause non-conformance to a base standard;
• but it may specify requirements which are more specific than those of the base standard; it might exclude some optional capabilities which are valid in the standard.

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.