scope:

Purpose and Scope

The OpenURL Framework Standard defines an architecture for creating OpenURL Framework Applications, briefly called Applications in the remainder of this Standard. An Application is a networked service environment, in which packages of information are transported over a network. These packages have a description of a referenced resource at their core, and they are transported with the intent of obtaining context-sensitive services pertaining to the referenced resource. To enable the recipients of these packages to deliver such context-sensitive services, each package describes the referenced resource itself, the network context in which the resource is referenced, and the context in which the service request takes place. These packages are ContextObject Representations.

Part 1 (Sections 5 through 11) defines the ContextObject as an abstract information construct. This Standard is independent of the application domain. It does not constrain the type of resources that may be described in a ContextObject. However, it does specify how communities can create concrete ContextObject Representations for use in their Applications. To that end, this Standard introduces the following core components of the OpenURL Framework: Character Encodings, Serializations, Constraint Languages, ContextObject Formats, Metadata Formats, and Namespaces.

Although ContextObject Representations may reside as autonomous data files in information systems, this Standard expects that ContextObject Representations will be transported between networked systems. Section 10 defines Transports, a core component of the OpenURL Framework in which communities specify how to transport ContextObject Representations in their Applications. This Standard does not restrict the purpose of such transportation. It is expected, however, that most transportations of ContextObject Representations will be requests for contextsensitive services pertaining to the referenced resource.

The targets of the transportation of ContextObject Representations are networked systems that are able to process ContextObject Representations and provide context-sensitive services. These systems are called Resolvers. Resolver behavior and usage are outside of the scope of this Standard. However, a community may use a Community Profile to define conformance for Resolvers that operate in its application domain. A community specifies its selections for each of the aforementioned core components in a Community Profile. This is the final core component of the OpenURL Framework, and it is defined in Section 11.

Section 6 defines the OpenURL Framework Registry and the rules that govern its usage. The OpenURL Framework Registry contains the selections for all core components made by communities that define Applications. The Registry ensures that this Standard can be used in many different application domains.

Parts 2, 3, and 4 specify the initial content of the OpenURL Framework Registry and provide detailed definitions of the registered content. The initial Registry deploys two Applications for the scholarly-information community. These Applications are defined by two Community Profiles:

• The Level 1 San Antonio Community Profile (SAP1), defined in Appendix C, is based on a Key/Encoded-Value Representation of ContextObjects. Key/Encoded-Value ContextObject Representations may be transported by any one of the three HTTP-based Transports defined in Part 4. The Transport defined in Section 22 was developed to provide a certain level of backward compatibility with the OpenURL 0.1 specification.

• The Level 2 San Antonio Community Profile (SAP2), defined in Appendix D, is based on an XML Representation of ContextObjects. XML ContextObject Representations may be transported by any one of two HTTP-based Transports defined in Part 4, Sections 20 and 21. The SAP2 Community Profile is not backward compatible with the OpenURL 0.1 specification.

Part 2 (Sections 12 through 15) defines a ContextObject Format inspired by the query string of the HTTP(S) GET request as specified in OpenURL 0.1. The Key/Encoded-Value ContextObject Format defines how to represent a ContextObject as a concatenation of ampersand-delimited Key/Encoded-Value pairs. The foremost purpose of the Key/Encoded-Value ContextObject Format is backward compatibility. It provides an elegant transition from the OpenURL 0.1 specification to this Standard.

Part 3 (Sections 16 through 19) defines a ContextObject Format based on XML (eXtensible Markup Language). XML Documents are widely used in the exchange of structured text and data between computer applications. The XML ContextObject Format is about the future. Using the full expressive power of the XML syntax, ContextObjects can be described in greater detail, which Resolvers can use to provide more and better services.

Part 4 (Sections 20 through 22) specifies mechanisms by which ContextObject Representations can be transported using the HTTP(S) protocol. Collectively, these are called OpenURL Transports.

Communities interested in deploying new Applications should use Parts 2, 3 and 4 as a guideline. Deploying a new Application consists of the following steps:

• Register any new definitions of the following core components of the OpenURL Framework that are needed to support the Application: Character Encodings, Serializations, Constraint Languages, ContextObject Formats, Metadata Formats, Namespaces, and Transports.

• Construct a new Community Profile that defines the Application by selecting appropriate Registry entries.

• Register the Community Profile.

Communities should create Implementation Guidelines to simplify implementation and deployment of their Applications.