[Display version only. This is a snapshot/cache copy derived from the canonical document at http://www2.elsevier.co.uk/~tony/spec/rss/mod_context.html, 2003-08-08; also to be posted to http://www.egroups.com/files/rss-dev/Modules/Proposed/mod_context.html. See the official distribution document at the Yahoo 'RDF Site Summary 1.0 Specification Working Group' website if possible.]

RDF Site Summary 1.0 Modules: Context

Authors [<<]

Tony Hammond, Elsevier

Timo Hannay, Nature Publishing Group

Eamonn Neylon, Manifest Solutions

Herbert Van de Sompel, Los Alamos National Laboratory

Version [<<]

Latest Version: http://www2.elsevier.co.uk/~tony/spec/rss/mod_context.html

Status [<<]

Proposed (Preliminary Version)

This draft RSS 1.0 module is being released to support applications that wish to make use of the ANSI/NISO Draft Standard for Trial Use 'The OpenURL Framework for Context-Sensitive Services'. It is anticipated that a revised version of this module will be resubmitted following a successful ballot by NISO Voting Members when the Draft Standard is published as currently expected NISO Standard Z39.88-2003.

It is being published now in a preliminary version to allow RSS 1.0 feeds to make use of the OpenURL Framework data model. It must be emphasized, however, that the OpenURL Framework has not been finalized and details are therefore subject to change.

Note that this draft is aligned with the OpenURL Framework DSFTU in following the OpenURL Framework naming architecture which makes use of the URI, ORI, XRI namespaces. Work is currently ongoing to harmonize this naming architecture with the URI naming architecture and to normalize all identifier references within the OpenURL Framework to be URIs. We expect the outcome of this work to coincide with the successful ballot of the Draft Standard.

About ANSI/NISO Draft Standards For Trial Use (DSFTU)

NISO releases proposed standards as Draft Standards for Trial Use (DSFTU) when there is a need for field experience. This DSFTU (see the DSFTU documents Part 1 and Part 2 on the NISO Committee AX website) has not been balloted by the NISO members and is not a consensus document. It is released for review and trial implementation for the period: May 1, 2003 - November 1, 2003.

Publication of this Draft Standard for Trial Use has been approved by the NISO Standards Development Committee. At the end of the Trial Use period, this draft Standard will be revised as necessary and balloted by the NISO Voting members, continue in the development cycle, or withdrawn.

Rights [<<]

Copyright © 2003 by the Authors.

Permission to use, copy, modify and distribute the RDF Site Summary 1.0 Specification and its accompanying documentation for any purpose and without fee is hereby granted in perpetuity, provided that the above copyright notice and this paragraph appear in all copies. The copyright holders make no representation about the suitability of the specification for any purpose. It is provided 'as is' without expressed or implied warranty.

This copyright applies to the RDF Site Summary 1.0 Specification and accompanying documentation and does not extend to the RSS format itself.

Contents [<<]

• Authors
• Version
• Status
• Rights
• Contents
• Description
• Orientation - RSS 1.0
• Orientation - OpenURL
• Namespace Declarations
• Model
• Overview
• Serializations
• Use Cases
• 1 - Saving Query State
• 2 - Feed of Feeds (I)
• 3 - Feed of Feeds (II)
• 4 - Service Redirection
• RSS 1.0 Elements
• Administration (<ctx:ctx_*>)
• Referent (<ctx:rft_*>)
• ReferringEntity (<ctx:rfe_*>)
• Requester (<ctx:req_*>)
• ServiceType (<ctx:svc_*>)
• Resolver (<ctx:res_*>)
• Referrer (<ctx:rfr_*>)
• Example

Description [<<]

The rationale in defining the 'mod_context' RSS 1.0 module is that this module allows RSS 1.0 feeds to provide contextual information which relates a description of the feed channel or item to the provenance of the feed, the requester of the feed, and the where and how the feed should be processed. Rich descriptions of this contextual information can be provided using both identifiers and metadata. The OpenURL Framework data model (see Model) exists to support network applications in the provisioning of context-sensitive services.

Orientation - RSS 1.0 [<<]

Structurally the 'mod_context' module follows the standard RSS 1.0 module 'mod_content' in that a single child element of <channel> or <item> is defined, <ctx:objects>, which provides a container for individual <ctx:object> elements. These <ctx:object> elements may be distinguished through their own individual child property elements.

Note that a more structured RDF/XML format could have been defined to parallel the 'hierarchical' XML format for the ContextObject as defined by the Draft Standard, but the 'flattened' RSS format presented here seems to be a better fit with RSS 1.0 generally and is simpler to deploy (see Serializations).

Orientation - OpenURL [<<]

This 'mod_context' RSS element set constitutes a new ContextObject Format which provides for a direct mapping of the Key/Encoded Value ContextObject Format used in OpenURL querystrings onto the RSS 1.0 data structure. The only real difference from the Key/Encoded Value Format is the support for multiple ContextObjects in the 'mod_context' ContextObject Format.

Note that this draft is aligned with the OpenURL Framework DSFTU in following the OpenURL Framework naming architecture which makes use of the URI, ORI, XRI namespaces. Work is currently ongoing to harmonize this naming architecture with the URI naming architecture and to normalize all identifier references within the OpenURL Framework to be URIs. We expect the outcome of this work to coincide with the successful ballot of the Draft Standard.

Namespace Declarations [<<]

• xmlns:ctx="http://www.openurl.info/registry/fmt/xml/rss10/ctx"

Model [<<]

For a full description of the 'The OpenURL Framework for Context-Sensitive Services' the reader is advised to consult the Draft Standard for Trial Use documents Part 1 and Part 2 on the NISO Committee AX website. This draft provides merely the briefest overview of the OpenURL Framework data model by way of introduction.

Overview [<<]

Essentially the OpenURL Framework defines two things: (1) a data model for an information structure termed the ContextObject which is a simple Entity/Descriptor matrix, and (2) a Registry mechanism for information components used in building up the ContextObject.

Six Entities are defined in the ContextObject:

• the Referent - the subject of the ContextObject
• the ReferringEntity - a resource that references the subject
• the Requester - the agent requesting services about the subject
• the ServiceType - the type of service to be provided
• the Resolver - the network service component that delivers services
• the Referrer - the host platform which generated the ContextObject

To describe these Entities four types of Descriptor are defined:

• an Identifier type
• a Metadata (By-Value) type
• a Metadata (By-Reference) type
• a Private Data type

The ContextObject also supports an optional Administration section which includes the following items:

• Version
• Encoding
• Identifier
• Timestamp

The OpenURL Framework defines an extensible means of serializing ContextObjects by making use of registered ContextObject Formats. Two such Formats are defined by the Draft Standard: a Key/Encoded Value Format for delivery on a URI querystring (the so-called OpenURL), and an XML Format for more generic purposes such as delivery of ContextObjects as a SOAP payload. This document defines a new ContextObject Format - RSS 1.0.

Serializations [<<]

Two serializations of the ContextObject into an RSS 1.0 feed are possible: a 'flattened' form and a 'hierarchical' form. The 'flattened' form is much the simpler and is the form adopted by this module. It does, however, present one curiosity: By-Value Metadata terms must be prefixed with the respective Entity to which they apply in order to differentiate the Entities and the prefix is separated by a period '.' character. This means that the schema for the Metadata format must repeat property definitions for each Entity if a general RDF processor is to make sense of the properties.

For example, with a By-Value Metadata format ori:fmt:xml:rss10:prism there may be a term issn. This term could in theory be applied to any of the six Entities. Therefore the schema would need to declare this same term as

• rft.issn for the Referent
• rfe.issn for the ReferringEntity
• req.issn for the Requester
• res.issn for the Resolver
• svc.issn for the ServiceType
• rfr.issn for the Referrer

The two serializations are presented below for a Referent Entity using each of the four possible Descriptors. We invite comments as to which serialization would be most appropriate for an RSS 1.0 module.

<item>
  <ctx:objects>
    <rdf:Bag>
      <rdf:li>
        <ctx:object>
          <ctx:rft_id>uri:urn:issn:0028-0836</ctx:rft_id>	
          <ctx:rft_val_fmt>ori:fmt:xml:rss10:prism</ctx:rft_val_fmt>	
          <ctx:rft.issn>0028-0836</ctx:rft.issn>	
          <ctx:rft_ref_fmt>ori:fmt:xml:rss10:prism</ctx:rft_ref_fmt>	
          <ctx:rft_ref>http://example.com/prism_data</ctx:rft_ref>	
          <ctx:rft_dat>47128012</ctx:rft_dat>	
        </ctx:object>
      </rdf:li>
    </rdf:Bag>
  </ctx:objects>
</item>

<item>
  <ctx:objects>
    <rdf:Bag>
      <rdf:li>
        <ctx:object>
          <ctx:rft parseType="rdf:resource">	
            <ctx:id>uri:urn:issn:0028-0836</ctx:id>	
            <ctx:val parseType="rdf:resource">	
              <ctx:fmt>ori:fmt:xml:rss10:prism</ctx:fmt>	
              <ctx:issn>0028-0836</ctx:issn>	
            </ctx:val>	
            <ctx:ref parseType="rdf:resource">	
              <ctx:fmt>ori:fmt:xml:rss10:prism</ctx:fmt>	
              <ctx:uri>http://example.com/prism_data</ctx:uri>	
            </ctx:ref>	
            <ctx:dat>47128012</ctx:dat>	
          </ctx:rft>	
        </ctx:object>
      </rdf:li>
    </rdf:Bag>
  </ctx:objects>
</item>

Use Cases [<<]

Some simple use cases for the 'mod_context' module are described herein. The first shows how query state can be embedded in the returned feed, the second (split into two parts) how contextual information can be maintained while walking a repository hierarchy, and the third how requester information can be passed through to a downstream network service component.

In these examples we assume a uniform means of querying an RSS aggregator for an RSS 1.0 feed - using an OpenURL as a query API. While any bespoke, or proprietary, URL can be used, the OpenURL provides an open, and public, vehicle for delivering contextual information, packaged as a ContextObject (see Model), to the RSS aggregator which can then return a ContextObject using 'mod_context'. Note that in the OpenURL examples spaces are introduced for reading clarity and no %- escaping has been performed.

1 - Saving Query State [<<]

The simplest use case for 'mod_context' is to embed the original query within the RSS 1.0 feed. Here an OpenURL bearing its hallmark signature 'url_ver=Z39.88-2003' is directed at an RSS aggregator 'http://rss.example.com/rss?' and requests a user's blog by identifying the subject of the query (the Referent) with the parameter 'rft_id=uri:http://www.example.com/weblog.rdf' and the agent requesting services about the subject (the Requester) with the parameter 'req_id=uri:mailto:john_doe@example.net'.

The RSS 1.0 feed returned uses the 'mod_context' module and embeds the original query information under the channel element. The RSS element structuring is similar to that used by the 'mod_content' module and allows for multiple ContextObjects although only a single ContextObject is shown in these examples. Note that both the query and the response provide a valid ContextObject. In this case the ContextObject contains the Identifier Descriptor URI 'http://www.example.com/weblog.rdf' for the Referent Entity as well as the Identifier Descriptor URI 'mailto:john_doe@example.net' for the Requester Entity. The ContextObject additionally provides the optional administrative Version element with the statutory value 'Z39.88-2003'

http://rss.example.com/rss?
  &url_ver=Z39.88-2003
  &rft_id=uri:http://www.example.com/weblog.rdf
  &req_id=uri:mailto:john_doe@example.net

<channel>
  <title>A blog</title>
  <link>http://www.example.com/weblog.rdf</link>
  <ctx:objects>
    <rdf:Bag>
      <rdf:li>
        <ctx:object>
          <ctx:ctx_ver>Z39.88-2003</ctx:ctx_ver>	
          <ctx:rft_id>uri:http://www.example.com/weblog.rdf</ctx:rft_id>	
          <ctx:req_id>uri:mailto:john_doe@example.net</ctx:req_id>	
        </ctx:object>
      </rdf:li>
    </rdf:Bag>
  </ctx:objects>
</channel>

Summary This example provides an illustration of simple pass-through of contextual information present in the original querystring.

2 - Feed of Feeds (I) [<<]

Now let us suppose the RSS aggregator provides a listings service for a fully navigable repository of serials publications. This repository can be broswed by supplying metadata terms appropriate to a particular level within the repository hierarchy. In the example below the subject of the query (the Referent) is described by two metadata terms 'rft.issn=0028-0836' and 'rft.publicationDate=2003' both drawn from the PRISM (Publishing Requirements for Industry Standard Metadata) metadata term set in Key/Encoded-Value Format 'rft_val_fmt=ori:fmt:kev:mtx:prism'. That is, we are requesting a listing for the serial publication whose ISSN is '0028-0836' and whose publication year is '2003'.

In this instance the repository answers with an RSS 1.0 feed which lists the volumes available for that title and for that publication year. The RSS 1.0 feed returned uses the 'mod_context' module and embeds the original query information under each item element for each volume available but adds in an additional element for the volume. Again both the query and the response provide a valid ContextObject. In the RSS example displayed here the ContextObject on the item element contains a single By-Value Metadata Descriptor for the Referent Entity. A Metadata Descriptor has two components: a Metadata Format and a set of Metadata Elements. The Metadata Format here is the corresponding PRISM term set for an RSS 1.0 feed available as the 'mod_prism' RSS 1.0 module 'ori:fmt:xml:rss10:prism', and the three Metadata Elements provided are the ISSN '0028-0836', the publication year '2003', and the volume number '424'.

Also supplied is the service component (the Resolver) which has the Identifier URI 'http://rss.example.com/rss?' for subsequent processing. This is the RSS aggregator itself which fronts the content repository. And again the ContextObject additionally provides the optional administrative Version element with the statutory value 'Z39.88-2003'.

Note that a simple XSLT transform is sufficient to generate OpenURL links (using standard Key/Encoded-Value syntax) to listings for each volume maintained in the repository. Of course, the RSS aggregator may simply include the OpenURL links directly when it assembles the RSS 1.0 feed, but the ContextObjects are already natively present in the RSS 1.0 feed for any client application to make use of as required.

http://rss.example.com/rss?
  &url_ver=Z39.88-2003
  &rft_val_fmt=ori:fmt:kev:mtx:prism
  &rft.issn=0028-0836
  &rft.publicationDate=2003

...
<item>
  <title>Nature 424 (2003)</title>
  <link>...</link>
  <ctx:objects>
    <rdf:Bag>
      <rdf:li>
        <ctx:object>
          <ctx:ctx_ver>Z39.88-2003</ctx:ctx_ver>	
          <ctx:rft_val_fmt>ori:fmt:xml:rss10:prism</ctx:rft_val_fmt>	
          <ctx:rft.issn>0028-0836</ctx:rft.issn>	
          <ctx:rft.publicationDate>2003</ctx:rft.publicationDate>	
          <ctx:rft.volume>424</ctx:rft.volume>	
          <ctx:res_id>uri:http://rss.example.com/rss?</ctx:res_id>	
        </ctx:object>
      </rdf:li>
    </rdf:Bag>
  </ctx:objects>
</item>
<item>
  <title>...</title>
  <link>...</link>
  <ctx:objects>
    <rdf:Bag>
      <rdf:li>
        <ctx:object>
        ...
        </ctx:object>
      </rdf:li>
    </rdf:Bag>
  </ctx:objects>
</item>
...

Summary This example shows how the original ContextObject is modified by the RSS aggregator service and contains additional metadata elements for linking deeper into the content repository.

3 - Feed of Feeds (II) [<<]

This next use case shows the follow-on step from the previous case in walking the hierarchy, but with an additional component. Now while the listings information is only available in English the content repository maintains the actual articles in both English and Japanese language versions. We can express a language preference at the start of the traversal and carry that language preference forward as we walk the hierarchy.

In the example below the subject of the query (the Referent) is now described by three metadata terms 'rft.issn=0028-0836', 'rft.publicationDate=2003' and 'rft.volume=424' again drawn from the registered PRISM metadata term set in Key/Encoded-Value Format 'rft_val_fmt=ori:fmt:kev:mtx:prism'. That is, we are requesting a listing for the serial whose ISSN is '0028-0836', whose publication year is '2003', and whose volume number is '424'.

We can express a Japanese language preference by describing the type of service required (the ServiceType) 'svc_id=xri:svc:lang:jp'. Since this a private identifier we need to include also the source of the ContextObject, 'rfr_id=uri:http://rss.example.com/rss?'.

In this instance the repository answers with an RSS 1.0 feed which lists the issue numbers available for that title, for that publication year and for that volume number. The RSS 1.0 feed uses the 'mod_context' module and embeds the original query information under each item element for each issue available but adds in an additional element for that issue number. Again both the query and the response provide a valid ContextObject. In the RSS example displayed here the ContextObject on the item element contains a single By-Value Metadata Descriptor for the Referent Entity. The Metadata Format is the corresponding PRISM term set for an RSS 1.0 feed 'ori:fmt:xml:rss10:prism', and the three Metadata Elements provided are the ISSN '0028-0836', the publication year '2003', the volume number '424', and the issue number '6948'.

Also supplied is the service component (the Resolver) which has the Identifier URI 'http://rss.example.com/rss?' for subsequent processing. This is the RSS aggregator itself. And again the ContextObject additionally provides the optional administrative Version element with the statutory value 'Z39.88-2003'

We also include a directive for the type of service required (the ServiceType) which has the Identifier 'xri:svc:lang:ja' to denote a Japanese language preference. Since this identifier is unregistered, i.e. is local to the Referrer environment, we need to add in a Descriptor for the Referrer, here an Identifier for the RSS aggregator itself as the origin of the ContextObject, 'http://rss.example.com/rss?'

Again OpenURL links to listings for each issue maintained in the repository can be generated by a simple XSLT transform of the RSS ContextObject if required or may already be present in the feed.

http://rss.example.com/rss?
  &url_ver=Z39.88-2003
  &rft_val_fmt=ori:fmt:kev:mtx:prism
  &rft.issn=0028-0836
  &rft.publicationDate=2003
  &rft.volume=424
  &svc_id=xri:svc:lang:ja
  &rfr_id=uri:http://rss.example.com/rss?

...
<item>
  <title>Nature 424, 6948 (2003)</title>
  <link>...</link>
  <ctx:objects>
    <rdf:Bag>
      <rdf:li>
        <ctx:object>
          <ctx:ctx_ver>Z39.88-2003</ctx:ctx_ver>	
          <ctx:rft_val_fmt>ori:fmt:xml:rss10:prism</ctx:rft_val_fmt>	
          <ctx:rft.issn>0028-0836</ctx:rft.issn>	
          <ctx:rft.publicationDate>2003</ctx:rft.publicationDate>	
          <ctx:rft.volume>424</ctx:rft.volume>	
          <ctx:rft.number>6948</ctx:rft.number>	
          <ctx:res_id>uri:http://rss.example.com/rss?</ctx:res_id>	
          <ctx:svc_id>xri:svc:lang:ja</ctx:svc_id>	
          <ctx:rfr_id>uri:http://rss.example.com/rss?</ctx:rfr_id>	
        </ctx:object>
      </rdf:li>
    </rdf:Bag>
  </ctx:objects>
</item>
<item>
  <title>...</title>
  <link>...</link>
  <ctx:objects>
    <rdf:Bag>
      <rdf:li>
        <ctx:object>
        ...
        </ctx:object>
      </rdf:li>
    </rdf:Bag>
  </ctx:objects>
</item>
...

Summary This example builds on the previous example and shows the next step in walking the repository. Again the original ContextObject is modified by the RSS aggregator service and contains additional metadata elements for linking deeper into the content repository. Also client state is maintained as shown in the language pereference that is bundled with the request.

4 - Service Redirection [<<]

Another scenario may be imagined whereby a user may request an RSS 1.0 feed for a subscription news service. However, they may have no access rights to that news service, whereas they may have access through their institution or company to a locally hosted version. By targetting the news feed items at a downstream network service component the links in the news feed can be adjusted by the service appropriately to the context of the user.

Here a request is made on an RSS aggregator 'http://rss.example.com/rss?' for a news feed by identifying the subject of the query (the Referent) with the parameter 'rft_id=uri:http://www.example.com/news_feed.rdf' and the agent requesting services about the subject (the Requester) with the parameter 'req_id=uri:mailto:john_doe@example.net'. The downstream service component (the Resolver) that will contextualize the news feed is identified with the parameter 'res_id=uri:http://service.example.org/resolver?'.

The RSS 1.0 feed returned uses the 'mod_context' module and embeds the original query information under each item element. In this case the ContextObject contains the Identifier Descriptor URI 'http://www.example.com/news_feed.rdf' for the Referent Entity, the Identifier Descriptor URI 'mailto:john_doe@example.net' for the Requester Entity, and the Identifier Descriptor URI 'http://service.example.org/resolver?' for the Resolver Entity. The ContextObject additionally provides the optional administrative Version element with the statutory value 'Z39.88-2003'

As before, OpenURL links to the news items can be generated by a simple XSLT transform of the RSS ContextObject if required or may already be present in the feed as shown here.

http://rss.example.com/rss?
  &url_ver=Z39.88-2003
  &rft_id=uri:http://www.example.com/news_feed.rdf
  &req_id=uri:mailto:john.doe@example.com	
  &res_id=uri:http://service.example.org/resolver?

...
<item>
  <title>News item</title>
  <link>http://service.example.com/resolver?
    &url_ver=Z39.88-2003
    &rft_id=uri:http://www.example.com/news_feed.rdf
    &req_id=uri:mailto:john.doe@example.com</link>
  <ctx:objects>
    <rdf:Bag>
      <rdf:li>
        <ctx:object>
          <ctx:ctx_ver>Z39.88-2003</ctx:ctx_ver>	
          <ctx:rft_id>uri:http://www.example.com/news_feed.rdf</ctx:rft_id>	
          <ctx:req_id>uri:mailto:john.doe@example.com</ctx:req_id>	
          <ctx:res_id>uri:http://service.example.org/resolver?</ctx:res_id>	
        </ctx:object>
      </rdf:li>
    </rdf:Bag>
  </ctx:objects>
</item>
<item>
  <title>Another news item</title>
  <link>...</link>
  <ctx:objects>
    <rdf:Bag>
      <rdf:li>
        <ctx:object>
        ...
        </ctx:object>
      </rdf:li>
    </rdf:Bag>
  </ctx:objects>
</item>
...

Summary This example shows how contextual information can be provided to a downstream network service component that can mediate the links embedded within a news feed of a subscription service based on a knowledge of the agent requesting the news feed.

RSS 1.0 Elements [<<]

RSS 1.0 element names for Entity Descriptors in the ContextObject are composed of a prefix for the Entity and a suffix for the Descriptor joined by an underscore. Abbreviate forms are used for the Entity and the Descriptor. For example, the element name for a Referent Identifier would be composed of the abbreviate form rft for Referent and id for Identifier giving rft_id.

Metadata Format identifiers follow a similar pattern by apppending a terminal Format to the element name. For example, the element name for the Format of a Referent Metadata (By-Value) would be composed of the abbreviate form rft for Referent, val for Metadata (By-Value) and fmt to mark it as a Format giving rft_val_fmt.

The table below lists all the abbreviate forms for the Entity Descriptor elements.

The Administration Elements follow a similar convention with ctx being used as the prefix for ContextObject - see the table below.

Metadata terms are provided either By-Value where the terms are presented in-line as elements within the RSS 1.0 feed, or By-Reference giving the URI of a network document. For the By-Value case in order to associate correctly the Metadata terms with their respective Entities, the element names are formed by prefixing the Metadata term with the Entity prefix followed by a period ('.'). For example, with a Metadata Format of ori:fmt:xml:rss10:journal declared for the Referent Entity, a particular term from this Metadata Format, jtitle say, is represented as an RSS 1.0 element by prefixing it with 'rft.', giving the element rft.jtitle. The example at the end provides further indications of other elements formed this way.

This section details each of the RSS 1.0 elements in order:

1. <channel>, <item> Elements:

• <ctx:objects>

The only child element of <channel> or <item> is <ctx:objects>.

2. <ctx:objects> Elements:

• <rdf:Bag>

The only child element of <ctx:objects> is <rdf:Bag>.

3. <rdf:Bag> Elements:

• <rdf:li>

The only child elements of <rdf:Bag> are <rdf:li>.

4. <rdf:li> Elements:

• <ctx:object>

The only child element of <rdf:li> elements is <ctx:object>.

5. <ctx:object> Elements:

The following elements are legal child elements of <ctx:object> (elements prefixed '[R]' are reserved for future use, while elements prefixed '[M]' are Metadata elements):

Admin Elements:

• <ctx:ctx_ver>
• <ctx:ctx_enc>
• <ctx:ctx_id>
• <ctx:ctx_tim>

Referent Elements:

• <ctx:rft_id>
• <ctx:rft_val_fmt>
• [R] <ctx:rft_val>
• [M] <ctx:rft.*>
• <ctx:rft_ref_fmt>
• <ctx:rft_ref>
• <ctx:rft_dat>

ReferringEntity Elements:

• <ctx:rfe_id>
• <ctx:rfe_val_fmt>
• [R] <ctx:rfe_val>
• [M] <ctx:rfe.*>
• <ctx:rfe_ref_fmt>
• <ctx:rfe_ref>
• <ctx:rfe_dat>

Requester Elements:

• <ctx:req_id>
• <ctx:req_val_fmt>
• [R] <ctx:req_val>
• [M] <ctx:req.*>
• <ctx:req_ref_fmt>
• <ctx:req_ref>
• <ctx:req_dat>

ServiceType Elements:

• <ctx:svc_id>
• <ctx:svc_val_fmt>
• [R] <ctx:svc_val>
• [M] <ctx:svc.*>
• <ctx:svc_ref_fmt>
• <ctx:svc_ref>
• <ctx:svc_dat>

Resolver Elements:

• <ctx:res_id>
• <ctx:res_val_fmt>
• [R] <ctx:res_val>
• [M] <ctx:res.*>
• <ctx:res_ref_fmt>
• <ctx:res_ref>
• <ctx:res_dat>

Referrer Elements:

• <ctx:rfr_id>
• <ctx:rfr_val_fmt>
• [R] <ctx:rfr_val>
• [M] <ctx:rfr.*>
• <ctx:rfr_ref_fmt>
• <ctx:rfr_ref>
• <ctx:rfr_dat>

Some of the content models used in this section make use of parameter entity references. These parameter entities and their meaning are:

Administration (<ctx:ctx_*>) [<<]

As Admininistration is an optional field in a ContextObject, any of the Elements with prefix ctx_ may be present.

• <ctx:ctx_ver> ( 'Z39.88-2003' )
  ContextObject version.
  Comments
  • This has a fixed value.
  
  
• <ctx:ctx_enc> ( %data; )
  ContextObject encoding.
  Comments
  • The value for ctx_enc specifies the character encoding used in the ContextObject. Legitimate values are taken from the IANA list. The values to be used in the ContextObject are those listed next to Name or if available the values with an indication of preferred MIME name in the IANA list. UTF-8 is the default value, representing UTF-8 encoded Unicode.
  
  
• <ctx:ctx_id> ( %data; )
  ContextObject Identifier.
  
  
• <ctx:ctx_tim> ( %time; )
  ContextObject timestamp.
  Comments
  • YYYY-MM-DD or YYYY-MM-DDThh:mm:ssTZD
  
  

Referent (<ctx:rft_*>) [<<]

As Referent is a mandatory Entity in a ContextObject, at least one of the Elements with prefix rft_ must be present.

• <ctx:rft_id> ( %id; )
  Referent Identifier.
  Comments
  • Multiple instances of rft_id do not indicate multiple Referents, but rather multiple ways to identify a single Referent.
  
  
• <ctx:rft_val_fmt> ( %fmt-id; )
  Identifier of By-Value Metadata Format for a Referent.
  Comments
  • URI of the Metadata Format used for the description of the Referent through By-Value Metadata.
  
  
• [R] <ctx:rft_val>
  Reserved for future use.
  
  
• [M] <ctx:rft.*> ( %data; )
  By-Value Metadata Element for a Referent.
  Comments
  • Elements defined in the Metadata Format specified by the Value of the rft_val_fmt Element, which must be present. Usage of the 'rft.' prefix is mandatory
  
  
• <ctx:rft_ref_fmt> ( %fmt-id; )
  By-Reference Metadata Format for a Referent.
  Comments
  • The rft_ref Element must also be present.
  
  
• <ctx:rft_ref> ( %url; )
  By-Reference Metadata Location for a Referent.
  Comments
  • The rft_ref_fmt Element must also be present. The Resolver should retrieve the Metadata from the specified location.
  
  
• <ctx:rft_dat> ( %data; )
  Referent Private Data.
  
  

ReferringEntity (<ctx:rfe_*>) [<<]

As ReferringEntity is an optional Entity in a ContextObject, any of the Elements with prefix rfe_ may be present.

• <ctx:rfe_id> ( %id; )
  ReferringEntity Identifier.
  Comments
  • Multiple instances of rfe_id do not indicate multiple ReferringEntities, but rather multiple ways to identify a single ReferringEntity.
  
  
• <ctx:rfe_val_fmt> ( %fmt-id; )
  Identifier of By-Value Metadata Format for a ReferringEntity.
  Comments
  • URI of the Metadata Format used for the description of the ReferringEntity through By-Value Metadata.
  
  
• [R] <ctx:rfe_val>
  Reserved for future use.
  
  
• [M] <ctx:rfe.*> ( %data; )
  By-Value Metadata Element for a ReferringEntity.
  Comments
  • Elements defined in the Metadata Format specified by the Value of the rfe_val_fmt Element, which must be present. Usage of the 'rfe.' prefix is mandatory
  
  
• <ctx:rfe_ref_fmt> ( %fmt-id; )
  By-Reference Metadata Format for a ReferringEntity.
  Comments
  • The rfe_ref Element must also be present.
  
  
• <ctx:rfe_ref> ( %url; )
  By-Reference Metadata Location for a ReferringEntity.
  Comments
  • The rfe_ref_fmt Element must also be present. The Resolver should retrieve the Metadata from the specified location.
  
  
• <ctx:rfe_dat> ( %data; )
  ReferringEntity Private Data.
  
  

Requester (<ctx:req_*>) [<<]

As Requester is an optional Entity in a ContextObject, any of the Elements with prefix req_ may be present.

• <ctx:req_id> ( %id; )
  Requester Identifier.
  Comments
  • Multiple instances of req_id do not indicate multiple Requesters, but rather multiple ways to identify a single Requester.
  
  
• <ctx:req_val_fmt> ( %fmt-id; )
  Identifier of By-Value Metadata Format for a Requester.
  Comments
  • URI of the Metadata Format used for the description of the Requester through By-Value Metadata.
  
  
• [R] <ctx:req_val>
  Reserved for future use.
  
  
• [M] <ctx:req.*> ( %data; )
  By-Value Metadata Element for a Requester.
  Comments
  • Elements defined in the Metadata Format specified by the Value of the req_val_fmt Element, which must be present. Usage of the 'req.' prefix is mandatory
  
  
• <ctx:req_ref_fmt> ( %fmt-id; )
  By-Reference Metadata Format for a Requester.
  Comments
  • The req_ref Element must also be present.
  
  
• <ctx:req_ref> ( %url; )
  By-Reference Metadata Location for a Requester.
  Comments
  • The req_ref_fmt Element must also be present. The Resolver should retrieve the Metadata from the specified location.
  
  
• <ctx:req_dat> ( %data; )
  Requester Private Data.
  
  

ServiceType (<ctx:svc_*>) [<<]

As ServiceType is an optional Entity in a ContextObject, any of the Elements with prefix svc_ may be present.

• <ctx:svc_id> ( %id; )
  ServiceType Identifier.
  Comments
  • Multiple instances of svc_id do not indicate multiple ServiceTypes, but rather multiple ways to identify a single ServiceType.
  
  
• <ctx:svc_val_fmt> ( %fmt-id; )
  Identifier of By-Value Metadata Format for a ServiceType.
  Comments
  • URI of the Metadata Format used for the description of the ServiceType through By-Value Metadata.
  
  
• [R] <ctx:svc_val>
  Reserved for future use.
  
  
• [M] <ctx:svc.*> ( %data; )
  By-Value Metadata Element for a ServiceType.
  Comments
  • Elements defined in the Metadata Format specified by the Value of the svc_val_fmt Element, which must be present. Usage of the 'svc.' prefix is mandatory
  
  
• <ctx:svc_ref_fmt> ( %fmt-id; )
  By-Reference Metadata Format for a ServiceType.
  Comments
  • The svc_ref Element must also be present.
  
  
• <ctx:svc_ref> ( %url; )
  By-Reference Metadata Location for a ServiceType.
  Comments
  • The svc_ref_fmt Element must also be present. The Resolver should retrieve the Metadata from the specified location.
  
  
• <ctx:svc_dat> ( %data; )
  ServiceType Private Data.
  
  

Resolver (<ctx:res_*>) [<<]

As Resolver is an optional Entity in a ContextObject, any of the Elements with prefix res_ may be present.

• <ctx:res_id> ( %id; )
  Resolver Identifier.
  Comments
  • Multiple instances of res_id do not indicate multiple Resolvers, but rather multiple ways to identify a single Resolver.
  
  
• <ctx:res_val_fmt> ( %fmt-id; )
  Identifier of By-Value Metadata Format for a Resolver.
  Comments
  • URI of the Metadata Format used for the description of the Resolver through By-Value Metadata.
  
  
• [R] <ctx:res_val>
  Reserved for future use.
  
  
• [M] <ctx:res.*> ( %data; )
  By-Value Metadata Element for a Resolver.
  Comments
  • Elements defined in the Metadata Format specified by the Value of the res_val_fmt Element, which must be present. Usage of the 'res.' prefix is mandatory
  
  
• <ctx:res_ref_fmt> ( %fmt-id; )
  By-Reference Metadata Format for a Resolver.
  Comments
  • The res_ref Element must also be present.
  
  
• <ctx:res_ref> ( %url; )
  By-Reference Metadata Location for a Resolver.
  Comments
  • The res_ref_fmt Element must also be present. The Resolver should retrieve the Metadata from the specified location.
  
  
• <ctx:res_dat> ( %data; )
  Resolver Private Data.
  
  

Referrer (<ctx:rfr_*>) [<<]

As Referrer is an optional Entity in a ContextObject, any of the Elements with prefix rfr_ may be present.

• <ctx:rfr_id> ( %id; )
  Referrer Identifier.
  Comments
  • Multiple instances of rfr_id do not indicate multiple Referrers, but rather multiple ways to identify a single Referrer.
  
  
• <ctx:rfr_val_fmt> ( %fmt-id; )
  Identifier of By-Value Metadata Format for a Referrer.
  Comments
  • URI of the Metadata Format used for the description of the Referrer through By-Value Metadata.
  
  
• [R] <ctx:rfr_val>
  Reserved for future use.
  
  
• [M] <ctx:rfr.*> ( %data; )
  By-Value Metadata Element for a Referrer.
  Comments
  • Elements defined in the Metadata Format specified by the Value of the rfr_val_fmt Element, which must be present. Usage of the 'rfr.' prefix is mandatory
  
  
• <ctx:rfr_ref_fmt> ( %fmt-id; )
  By-Reference Metadata Format for a Referrer.
  Comments
  • The rfr_ref Element must also be present.
  
  
• <ctx:rfr_ref> ( %url; )
  By-Reference Metadata Location for a Referrer.
  Comments
  • The rfr_ref_fmt Element must also be present. The Resolver should retrieve the Metadata from the specified location.
  
  
• <ctx:rfr_dat> ( %data; )
  Referrer Private Data.
  
  

Example [<<]

This example supposes that Amazon.com can provide an RSS 1.0 feed of a shopping session using 'mod_context' to preserve query state in the RSS 1.0 feed item elements. Here Jane Doe puts the following book (amongst others) into her Amazon.com shopping cart:

Professional XML Meta Data. 2001. ISBN 1861004516. by David Dodds, Andrew Watt, Mark Birbeck, Jay Cousins, Kal Ahmed, Daniel Rivers-Moore, Joshua Lubell, Miloslav Nic, Danny Ayers, Ann Wrightson.

In this case, the Referent is clearly the XML book whose ASIN number is '1861004516', Amazon.com is the Referrer as identified by the Registry Identifier 'rfr:amazon.com' as well as the URI 'http://amazon.com', and Jane Doe the Requester as shown by the email address 'jane_doe@example.org'. The ServiceType is "add to cart" (or 'addToCart').

Note that Jane Doe has not actually purchased any of these books but instead has compiled her ideal shopping list. She can now host the RSS 1.0 feed on her personal website for friends and family to access. They can then visit her website and submit the link to the RSS 1.0 feed to an Amazon.com purchase service and using their credit card purchase the books selected by Jane Doe for her birthday, say. The RSS 1.0 feed contains the details not only of the books but also a unique identifier for Jane Doe (in this case her email address) which is known to Amazon.com and tied to a shipping address for delivery of the books.

This example shows how by using 'mod_context' we can preserve contextual information within the RSS 1.0 feed to facilitate downstream context-sensitive services.

<?xml version="1.0" encoding="UTF-8"?>

<rdf:RDF xmlns="http://purl.org/rss/1.0/"
   xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
   xmlns:ctx="http://www.openurl.info/registry/fmt/xml/rss10/ctx"
>
  
  <channel rdf:about="http://www.example.com/">
    <title>Amazon.com - Book Sales</title>
    <link>http://www.example.com/"</link>

    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://www.example.com/booksales_1" />
        <rdf:li rdf:resource="http://www.example.com/booksales_2" />
        ... 
     </rdf:Seq>
    </items>
  </channel>
  
  <item rdf:about="http://www.example.com/booksales_1">
    <title>Professional XML Meta Data</title>
    <description>Professional XML Meta Data. 2001. ISBN 1861004516.
   by David Dodds, Andrew Watt, Mark Birbeck, Jay Cousins,
   Kal Ahmed, Daniel Rivers-Moore, Joshua Lubell, Miloslav
   Nic, Danny Ayers, Ann Wrightson.</description>
    <link>http://www.example.com/booksales_1</link>
    <ctx:objects>
      <rdf:Bag>
        <rdf:li>
          <ctx:object>

            <!-- # Admin Elements -->
            <ctx:ctx_ver>Z39.88-2003</ctx:ctx_ver>
            <ctx:ctx_enc>ori:enc:UTF-8</ctx:ctx_enc>
            <ctx:ctx_id>345871</ctx:ctx_id>
            <ctx:ctx_tim>2002-03-20T13:05:54Z</ctx:ctx_tim>

            <!-- # Referent Elements -->
            <ctx:rft_id>xri:ASIN:1861004516</ctx:rft_id>

            <!-- # Requester Elements -->
            <ctx:req_id>uri:mailto:jane_doe@example.org</ctx:req_id>

            <!-- # ServiceType Elements -->
            <ctx:svc_id>xri:addToCart</ctx:svc_id>

            <!-- # Referrer Elements -->
            <ctx:rfr_id>uri:http://amazon.com</ctx:rfr_id>
            <ctx:rfr_id>ori:rfr:amazon.com</ctx:rfr_id>

          </ctx:object>
        </rdf:li>
      </rdf:Bag>
    </ctx:objects>
  </item>
  
</rdf:RDF>