The meaning of OAI 2.0 Markup

An exercise in markup interpretation

C. M. Sperberg-McQueen

22 December 2005

$Id: ioai.html,v 1.15 2005/12/23 01:47:57 cmsmcq Exp $

This document shows the translation of markup in the vocabulary defined by the Open Archives Initiative Protocol for Metadata Harvesting 2.0 [Lagoze et al. 2002] (which we will refer to simply as OAI for brevity) into logical form. It is intended as an exercise in the formal description of the meaning of markup, and assumes the proposal made by [Sperberg-McQueen/Huitfeldt/Renear 2001] that the meaning of markup may be described formally as the set of inferences licensed by that markup.[1]
The meaning of the markup is given here in the form of sentence schemata for sentences in first-order predicate calculus form. The sentence schemata (or ‘skeleton sentences’) have blanks, here represented by XPath expressions enclosed in braces. When a predicate-calculus representation of the meaning of an OAI document is to be generated, the sentence schemata are made into sentences by
  1. visiting each element (and conceivably each attribute) of the document in turn (call the item being visited E),
  2. identifying the sentence schema (or schemata) associated with E (in the most common case, this is a simple match on generic identifier or attribute name; in other cases, a more complex match pattern may be required),
  3. evaluating each XPath expression in the sentence schemata, using E as the current node, and
  4. filling in each blank in the sentence with the value thus obtained.
Each element in the document generates a set of sentences in this way; the inferences licensed by the markup in the document are the set of sentences thus generated.
Some generalizations are true for all conforming OAI data providers; these might be identified as consequences of the OAI-PMH element, on the theory that they follow from (are licensed as inferences by) the proposition that the server conforms to the OAI-PMH specification, and that it is through the use of the OAI-PMH element that we can plausibly infer that the server conforms. Alternatively they can be treated as knowledge about the world and conforming OAI implementations (“Conforming OAI repositories either do not maintain information about deletions, or else maintain persistent about deletions, or else maintain transient information about deletions”). Here, the generalizations are given as conditionals whose consequent is true for all conforming OAI repositories.
In section 1, each element and attribute in the OAI vocabulary is described using prose paraphrases and sentence schemata. Generalizations (world knowledge) are given in passing at what seem like opportune locations. Summaries of the types and relations used in the logical translation are given in sections 2 and 3. The logical notation used is described in section 4.
This document is unfinished.
At the moment, only a small number of the elements of the OAI vocabulary are described. The list of relevant types and relations is similarly incomplete. The author's plan is to proceed through the rest of the vocabulary, supplying prose paraphrases and translations into predicate calculus and augmenting the lists of types and relations as needed.
Separate documents, or possibly later versions of this paper, may be expected to supply Prolog and RDF versions of the sentence schemata given here, and XSLT code to generate full sentences from document instances using the vocabulary.

1. Interpretation of elements and attributes

1.1. The OAI-PMH element

The oai:OAI-PMH element contains the response sent by an OAI server in response to a particular request at a specified time. For example:
<OAI-PMH xmlns="" 
 <request verb="GetRecord" identifier=""
We can infer:
  • There exists an OAI server s, whose URI is the #PCDATA value of the oai:request child.
  • There exists a request q, which is modeled by the oai:request child element.
  • There an OAI response r, which is identical to (not “modeled by”) the current oai:OAI-PMH element.
  • There exists a moment of time t identified by the value of the oai:responseDate child element.
  • Server s sent response r in response to request q at time t.
Or more compactly (if also more awkwardly): “The oai:OAI-PMH element was sent as an OAI response, by the server identified by the content of oai:request, in response to the request described by oai:request, at the moment denoted by oai:responseDate.”
More formally:
(∃ q : OAI-request) (∃ r : OAI-response) (∃ s : OAI-server) (∃ t : moment)
(uri_server({string(./oai:request)}, s)
∧ models({./oai:request}, q)
∧ {.} = r
∧ xsd_lv(xsd:dateTime, {string(./oai:responseDate)}, t)
∧ served_response(q,s,t,r))
(Details of the notation are given in section 4.)
If we use XPointer tumblers to denote elements (as needed for the first argument of the models relation) and quoted literals to represent strings, then the example given above would generate the following sentence in logical notation:
(∃ q : OAI-request) (∃ r : OAI-response) (∃ s : OAI-server) (∃ t : moment)
(uri_server(‘’, s)
∧ models(element(/1/2), q)
element(/1) = r
∧ xsd_lv(xsd:dateTime, ‘2002-05-01T19:20:30Z’, t)
∧ served_response(q,s,t,r))

1.2. A digression on definite descriptions

If we want to be careful to capture the meaning of the definite articles in the English paraphrase, we may be troubled by the translation above. In English, we spoke of “the request”, “the server”, and so on: the descriptions (it is implied) uniquely identify a single request, a single server. To capture this information, we can use a slightly more elaborate translation:
(∃ q : OAI-request) (∃ r : OAI-response) (∃ s : OAI-server) (∃ t : moment)
(uri_server({string(./oai:request)}, s)
    ∧ (∀ x)(uri_server({string(./oai:request)}, x) ⇒ x = s)
    ∧ (∀ x)(uri_server(x, s) ⇒ x = {string(./oai:request)})
∧ models({./oai:request}, q)
    ∧ (∀ x)(models({./oai:request}, x) ⇒ x = q)
∧ {.} = r
∧ xsd_lv(xsd:dateTime, {string(./oai:responseDate)}, t)
    ∧ (∀ x)(xsd_lv(xsd:dateTime, {string(./oai:responseDate)}, x) ⇒ x = t)
∧ served_response(q,s,t,r))
Here the indented clauses have been added vis-a-vis the previous translation.
In prose,
There exist an OAI request q, an OAI response r, an OAI server s, and a moment in time t, such that:
  • The string value of the oai:request child is the URI of s (and there is only one such server, i.e. any server whose URI is that string value is identical to s, and also that server has only one URI, i.e. any URI which is the URI of s is that string value).
  • The request q is modeled by the oai:request child (and there is only one such request).
  • The response r is the same as the current (oai:OAI-PMH) element.
  • The moment t is the moment identified by the string value of the oai:responseDate child, interpreted according to the usual lexical mapping of the XML Schema dateTime type (and there is only one such moment).
  • Server s served response r to request q at moment t.
If we use the ‘description operator’ (“℩”) introduced by Russell and used since by others (e.g. [Quine 1951] and [Quine 1982]) to allow terms corresponding to phrases like “the moment denoted by oai:responseDate” to appear as arguments, we'll have[2]
(∃ r : OAI-response)
{.} = r
∧ served_response(
    (℩ q)(OAI-request(q) ∧ models({./oai:request}, q)),
    (℩ s)(OAI-server(s) ∧ uri_server({string(./oai:request)}, s)
             ∧ (∀ x)(uri_server(x, s) ⇒ x = {string(./oai:request)})),
    (℩ t)(moment(t) ∧ xsd_lv(xsd:dateTime, {string(./oai:responseDate)}, t)),
Although this form of expression is more compact, some readers also find it harder to follow (as does the author), in part because replacing simple variables like q with expressions like “(℩ q)(OAI-request(q) ∧ models({./oai:request}, q))” makes it harder to read the larger expressions in which the reference is made. An alternative which some find more legible is offered by the notation suggested by [Hughes/Cresswell 1996], in which ℩ is treated as a kind of quantifier:
(∃ r : OAI-response)
    (℩ q (OAI-request(q) ∧ models({./oai:request}, q)))
    (℩ s (OAI-server(s) ∧ uri_server({string(./oai:request)}, s)))
    (℩ t (moment(t) ∧ xsd_lv(xsd:dateTime, {string(./oai:responseDate)}, t)))
((∀ x)(uri_server(x, s) ⇒ x = {string(./oai:request)})
    ∧ {.} = r
    ∧ served_response(q,s,t,r))
In prose paraphrase, this works out to something like “There exists an OAI response r such that there exist (a) a unique OAI request q modeled by the oai:request child element, (b) a unique OAI server whose URI is the string value of the oai:request child element, and (c) a unique moment t which is mapped to from the string value of the oai:responseDate child using the lexical mapping for xsd:dateTime, such that server s served response r to request q at moment t. ”
It may be just a question of what one is accustomed to, but some readers may feel that the quantifiers have become top-heavy here.
In some cases, of course, a general knowledge of which relations are functions can eliminate the need for writing out the additional clauses, or allow us to automate the task. For example, if we adopt the axiom that
(∀ s : OAI-server) (∀ u : string) (uri_server(u, s) ⇒ (∀ x)(uri_server(u, x) ⇒ x = s) ∧ (∀ x)(uri_server(x, s) ⇒ x = u))
(i.e. both the relation uri_server and its inverse are functions), then the relative uniqueness of the arguments need not be asserted each time the relation is used. It is an empirical question, whose answer is not currently clear, whether all definite descriptions in our logical translation can be handled in this way.
In what follows, we will usually omit any attempt to capture claims of uniqueness, unless they seem particularly interesting. When we do attempt to capture them, we will use a variant on the Russell/Quine notation which attempts to retain the legibility of expressions like “served_response(q,s,t,r)” and which follows the convention of giving types for variables quantified by ℩:
(∃ q : OAI-request) (∃ r : OAI-response) (∃ s : OAI-server) (∃ t : moment)
( q = (℩ q : OAI-request)(models({./oai:request}, q))
    ∧ s = (℩ s : OAI-server)(uri_server({string(./oai:request)}, s))
    ∧ t = (℩ t : moment)(xsd_lv(xsd:dateTime, {string(./oai:responseDate)}, t))
    ∧ (∀ x)(uri_server(x, s) ⇒ x = {string(./oai:request)})
    ∧ {.} = r
    ∧ served_response(q,s,t,r))

1.3. The responseDate element

The oai:responseDate element indicates the date and time the response was sent. Its meaning has been captured in the rule for oai:OAI-PMH, but if we wish to have an independent rule for each element type, then we can say that from an oai:responseDate element we can infer that the response consisting of the parent oai:OAI-PMH element was sent by the responsible server at the time indicated. Formally:
(∃ t : moment) (∃ r : OAI-response)
(xsd_lv(xsd:dateTime, {string(.)}, t)
r = {..}
∧ was_sent_at(r,t))
For example:

1.4. The request element

The oai:request element indicates what request generated the enclosing oai:OAI-PMH response. The content (of simple type xsd:anyURI) gives the base URI of the request, and thus the URI we use here to identify the server.[3] The attributes document the key/value pairs of the request; there will always be a verb attribute, and in a correct request the other attributes will vary with the verb.
For example:
<request verb="GetRecord" identifier=""
We can infer:
  • There is a request, which is modeled by this element.
  • When the request is valid, the verb of the request was that given in the verb attribute, and the other key/value pairs of the request are all and only those given in the other attributes.
  • When the request raises a badVerb or badArgument error, no key/value pairs of the request are given; the only information is the base URL of the request.
  • When the request is not valid in some other way (i.e. it raises an error or exception condition other than badVerb or badArgument), the specification appears to leave the behavior undefined.
More formally:
(∃ q : OAI-request) (models({ . }, q)
∧ ( {string(@verb)} ≠ "" ⇒ request_verb(q, {string(@verb)}) )
∧ ( ( {string(@verb)} = "GetRecord"
    ∧ request_identifier(q, {string(@identifier)})
    ∧ request_metadataPrefix(q, {string(@metadataPrefix)}) )
∨ ( {string(@verb)} = "Identify"
    ∧ {count(@*)} = 0 )
∨ ( {string(@verb)} = "ListIdentifiers"
    ∧ request_from(q, {string(@from)})
    ∧ request_until(q, {string(@until)})
    ∧ request_metadataPrefix(q, {string(@metadataPrefix)})
    ∧ request_set(q, {string(@set)})
    ∧ request_resumptionToken(q, {string(@resumptionToken)}) )
∨ ( {string(@verb)} = "ListMetadataFormats"
    ∧ request_identifier(q, {string(@identifier)}) )
∨ ( {string(@verb)} = "ListRecords"
    ∧ request_from(q, {string(@from)})
    ∧ request_until(q, {string(@until)})
    ∧ request_metadataPrefix(q, {string(@metadataPrefix)})
    ∧ request_set(q, {string(@set)})
    ∧ request_resumptionToken(q, {string(@resumptionToken)}) )
∨ ( {string(@verb)} = "ListSets"
    ∧ request_resumptionToken(q, {string(@resumptionToken)}) ) )
The resumptionToken mechanism is not dealt with satisfactorily in this version of this paper.

1.5. The error element

The oai:error element appears as the third child (after responseDate and request when the request raises an error condition. For example, a request with an unknown verb might return:[4]
<error code="badVerb">Illegal OAI verb</error>
We can infer:
  • The request which elicited this response was invalid.
  • The specific error was the one indicated in keyword form by the code attribute.
  • The specific error was the one describe in natural language by the #PCDATA content, if any.
More formally:
(∃ q : OAI-request) (models({preceding-sibling::oai:request}, q)
∧ invalid(q)
∧ request_error(q, {string(@code)})
∧ ({string(.)} ≠ "" ⇒ error_nldesc(q, {string(.)}) ) ) )
For detailed description of the errors, see the OAI specification; we won't go into more detail about the errors here.

1.6. The GetRecord element

The oai:GetRecord element contains the response of the server to a successful request to fetch a particular metadata record.
Note that the OAI vocabulary carefully distinguishes three things:
  • the resource described by the metadata, which might be a document held by a library or archive (e.g. an autograph letter)
  • the item for which a record is requested
  • the metadata record actually returned by the server
The item may be thought of as a sort of abstract record; conceptually it is a constituent part of a repository, but by repository the OAI documentation means an OAI server, not the library or archive or project or other institution which might hold a collection of physical documents or similar objects and which might be running the server to provide descriptions of those objects. Each item corresponds to a single resource and may provide metadata in multiple formats. So a MARC record, a Dublin Core record, and other metadata records may share the same item identifier; a particular metadata record is uniquely identified not by the item identifier, but by the item identifier (each item is guaranteed to have one), plus the metadata prefix (an identifier for a given metadata format), plus the datestamp showing when the record was created or last changed.[5]
A GetRecord request must specify an item identifier and a metadata format; the oai:GetRecord element contains an oai:record element which represents the item.
If the request is faulty (e.g. because the identifier is not known or because the requested metadata format is not available), an oai:error element is returned, not a GetRecord element. (If the particular metadata record requested has been deleted, a record will be returned with status="deleted" in the record header.) So from the existence of a GetRecord element, we can infer:
  • The verb of the request was GetRecord. (N.B. this is redundant with the verb attribute on the oai:request element.)
  • The request raised no error and no exception. (This may be thought redundant with the absence of an error element.)
  • The item requested exists in the repository.
  • The metadata format requested exists for the requested item in the repository, or did exist before the record was deleted.
Note that we need, for these inferences, to be able to refer to “the current response”, “the request which elicited the current response”, “the repository which emitted the current response”, etc. In the paraphrase below, we assume a set of relations which pair the OAI response (the ancestor oai:OAI-PMH element) with other relevant objects.
(∃ q : OAI-request) (∃ s : oai-server) (∃ d : string) (∃ i : oai-item) (∃ p : string)
(q = (℩ q : OAI-request)(req_resp(q,{ancestor::oai:OAI-PMH}))
    s = (℩ s : oai-server)(resp_server({ancestor::oai:OAI-PMH}, s))
    d = (℩ d : string)(request_identifier(q, d))
    i = (℩ i : oai-item)(item_id(i, d))
    p = (℩ p : string(p)(request_metadataPrefix(q, p))
∧ request_verb(q, "GetRecord")
∧ errorfree(q)
∧ isin_repository_item(s, i)
∧ hasformat_repository_item_format(s, i, p) )
In addition, we know in practice that the oai:record child of oai:GetRecord contains the requested metadata record in the requested format for the requested item. But it's more convenient to capture that in the sentence schemata for the oai:record element than here.

1.7. Remaining elements

The following element types have not yet been described in this version of this document:
  • GetRecord/record
  • Identify
  • Identify/*, i.e.
    • baseURL
    • protocolVersion
    • adminEmail
    • earliestDatestamp
    • deletedRecord
    • granularity
    • compression
    • description
  • ListIdentifiers
  • ListIdentifiers/header
  • ListIdentifiers/resumptionToken
  • ListMetadataFormats
  • ListMetadataFormats/metadataFormat
  • ListRecords
  • ListRecords/record
  • ListRecords/resumptionToken
  • ListSets
  • ListSets/set
  • ListSets/resumptionToken
  • record/header
  • record/metadata
  • record/about
  • record/header/identifier
  • record/header/datestamp
  • record/header/setSpec
  • record/header/@status
  • metadataFormat/metadataPrefix
  • metadataFormat/schema
  • metadataFormat/metadataNamespace
  • set/setSpec
  • set/setName
  • set/setDescription

2. Types

The interpretation rules given above assume that individuals can be identified as belonging to particular types. For our purposes, a type can be regarded simply as a set of particular individuals, and an individual has, or is of, a given type only if that individual is a member of that set, and a notation like “(∃ i : t) P” (‘there exists an i of type t such that P’) is merely a more concise way of writing “(∃ i)(itP)”, or (using the type name as a predicate true for members of the set and for no others) “(∃ i)(t(i) ∧ P)”.
It follows that the types described here need not be disjoint, although at the current stage of completion of this paper, they are in fact all pairwise disjoint except for the object type, which contains everything in the universe of discourse, and the value type, which contains the union of the value spaces of the simple XML Schema datatypes.

2.1. OAI-specific types

The types assumed by the OAI vocabulary are:
  • moment: an instant of time; in practice, moments are identified by time stamps in the usual way.
  • OAI-request: an HTTP GET request following (or not following) the rules for OAI requests.[6]
  • OAI-response: an XML element with the generic identifier OAI-PMH in the OAI 2.0 namespace which obeys the rules laid down in [Lagoze et al. 2002]
  • OAI-server: an OAI repository. As the OAI specification says: “A repository is a network accessible server that can process the 6 OAI-PMH requests in the manner described in” the OAI 2.0 specification. For our purposes, we treat repositories as uniquely identified by their URI (the base URI of an OAI request sent to that server); this should be non-controversial. It is less plausible to treat, as we do here, distinct URIs as identifying distinct servers. But there is no way, within an OAI message, to make any claims about whether two OAI servers are or are not the same.[7]
  • OAI-harvester: a consumer of OAI data. Within a given request/response interaction, typically the client of an OAI server. It is clear (e.g. from the discussion of provenance statements in section 2.5 of [Lagoze et al. 2002]) that the same institution may run both a server (repository) and a harvester, possibly in the same executable. For purposes of this paper, however, the reader can assume that within any given transaction (at least) the server and the client are different pieces of software.
This list is incomplete; the plan is to add to it gradually as the skeleton sentences require more entries.

2.2. Other types

In addition, there are a few types we need to define our expression language, or to define signatures of relations:
  • attribute: an attribute of an XML element; typically denoted by an XPath expression.
  • element: an XML element; typically denoted by an XPath expression.
  • expandedName: a pair consisting of a URI and an XML NCName; what a qualified name (QName) expands to in context.
  • object: any kind of thing at all.
  • xsd:string: a string of characters (here, in practice, invariably a string of Unicode characters).
  • value: a member of the value space of some XML Schema datatype.

3. Predicates and relations

3.1. Primitive relations

The rules of interpretation given in section 1 appeal to a number of primitive relations. It is hoped that the nature of the relations has been clear enough from context to allow the reader to follow the rules of interpretation; the following list gives a natural-language description of each relation.

3.1.1. OAI-specific relations

As with the set of types, the most interesting relations are perhaps those specific to the OAI vocabulary:
  • error_nldesc (OAI-request × xsd:string): holds when the string is a sequence of characters which constitute a written form of a natural-language description of an error in the OAI request.
  • hasformat_repository_item_format (OAI-server × OAI-item × xsd:string): holds when the item named has, in the repository named, a metadata record in the format identified by the string (which is the label associated with that format).
  • invalid (OAI-request): true when the OAI request is invalid, false when it is valid.
  • item_id (OAI-item × xsd:string): holds when the string is the item identifier of the OAI item.
  • isin_repository_item (OAI-server × OAI-item): holds when the item named is in the repository identified.[8]
  • req_resp (OAI-request × OAI-response): holds when the OAI response is the response sent by an OAI server to the OAI request. The inverse is a function: any given response corresponds to only one request.
  • request_error (OAI-request × xsd:string): holds when the string is the error code for an error in the OAI request.
  • request_from (OAI-request × xsd:string): holds when the string is the identifier of the record at the beginning of the range requested by the OAI request (or, equivalently, when the string is the property of the request's from parameter). A function.
  • request_identifier (OAI-request × xsd:string): holds when the string is the identifier of the record requested by the OAI request (or, equivalently, when the string is the property of the request's identifier parameter). A function.
  • request_metadataPrefix (OAI-request × xsd:string): holds when the string is the metadata prefix for the metadata format requested by the OAI request (or, equivalently, when the string is the property of the request's metadataPrefix parameter). A function.
  • request_resumptionToken (OAI-request × xsd:string): holds when the string is the resumption token passed by the OAI request to the server (or, equivalently, when the string is the property of the request's resumptionToken parameter). A function.
  • request_set (OAI-request × xsd:string): holds when the string is the identifier of the set from which the identifier or records requested by the OAI request are to be drawn (or, equivalently, when the string is the property of the request's set parameter). A function.
  • request_until (OAI-request × xsd:string): holds when the string is the identifier of the record at the end of the range requested by the OAI request (or, equivalently, when the string is the property of the request's until parameter). A function.
  • request_verb (OAI-request × xsd:NMTOKEN): holds when the NMTOKEN is the verb of the OAI request. (Informally, is known only when the OAI-request is valid.) A function.
  • resp_server (OAI-response × OAI-server): holds when the OAI response was sent by the OAI server. A function.[9]
  • served_response (OAI-request × OAI-server × moment × OAI-response): holds if and only if at the specified moment the specified OAI server sent the specified OAI response as an answer to the specified OAI request.
  • uri_server (xsd:string × OAI-server): holds when the string is the URI of the server, i.e. the base URI of queries addressed to the server. A 1:1 relation.
This list is incomplete; the plan is to add to it gradually as the skeleton sentences require more entries.

3.1.2. Other relations

Other relations appealed to are more general in nature:
  • models (element × object): holds when the XML element string is a representation of the object (or, equivalently, when the object is described by the element). A function.
  • xsd_lv (expandedName × xsd:string × value): holds when (a) the expanded name denotes a simple type in the XML Schema type system (in practice, here, always one of the primitive types); (b) the string is in the lexical space of that type; (c) the value is in the value space of that type; and (d) in the lexical mapping appropriate to the type, the string maps to the value.

3.2. Derivable relations

Some relations used in the rules of interpretation are implied by others. These are:
  • errorfree (OAI-request): holds when the request has no errors; the complement of invalid. Definable as:
    (∀ q : OAI-request)(errorfree(q) ≡ ¬invalid(q))
  • was_sent_at (OAI-response × moment): The OAI-response was sent at the specified moment. Derivable:
    (∀ q : OAI-request) (∀ s : OAI-server) (∀ t : moment) (∀ r : OAI-response) (served_response(q,s,t,r) ⇒ was_sent_at(r,t))

4. Notation

The notation used here is what the authors believe to be a fairly conventional form of first-order predicate calculus. Since notation for logic varies so greatly, however, it may be worth describing the notation for individuals and sentences here.
An individual may be denoted by
  1. a name (in practice, we use names which match the NCName production in Namespaces 1.1)
  2. a variable reference (shown here as an NCName in italics)
  3. an XPath expression enclosed in braces (used only if the individual is an XML element, an attribute, a string, or an xsd:double floating-point number)
  4. an XPointer tumbler expression i.e. a string matching the regular expression “(/[0-9]+)+”, surrounded by parentheses and preceded by the keyword element, e.g. element(/1/2/2/8/3/1/3), which denotes (or did, at one point) this list item in the XML source of this document (used only if the individual is an XML element)
  5. an expression of the form “(℩ x : T)(P)” where P is a sentence, x is a variable, and T is the name of a type; informally, this means “The unique x of type T such that P is true”.
Sentences can be combined in the usual ways with Boolean connectors, and prefixed with variable quantifiers:
  1. A relation name followed by a parenthesized list of comma-separated arguments is a sentence; each argument must be an identifier, a variable.
  2. If P and Q are sentences, then “PQ” is a sentence; the connector “∧” denotes conjunction.
  3. If P and Q are sentences, then “PQ” is a sentence; the connector “∨” denotes inclusive disjunction.
  4. If P is a sentence, and x is a variable, and T is the name of a type, then “(∃ x)P” is a sentence, and so is “(∃ x : T)P
  5. If P is a sentence, and x is a variable, and T is the name of a type, then “(∀ x)P” and “(∀ x : T)P” are sentences.

A. References

Hughes, G. E., and M. J. Cresswell. 1996. A new introduction to modal logic. London, New York: Routledge.

Lagoze, Carl, Herbert Van de Sompel, Michael Nelson, and Simeon Warner, ed. 2002. The Open Archives Initiative Protocol for Metadata Harvesting. Protocol Version 2.0 of 2002-06-14. Document Version 2004/10/12T15:31:00Z. [n.p.]: Open Archives Initiative, 2002. <URL:>

Quine, Willard Van Orman. 1951. Mathematical logic. Revised edition. Cambridge, Mass.: Harvard University Press.

Quine, W. V. 1982. Methods of logic. Cambridge, Mass.: Harvard University Press.

Sperberg-McQueen, C. M., Claus Huitfeldt, and Allen Renear. “Meaning and interpretation of markup.” Markup Languages: Theory & Practice 2.3 (2001): 215–234. <URL:>


[1] Thanks are due to my colleague Eric Miller for discussions of the OAI vocabulary and of the general topic of schema annotations; the idea of a formal description of the OAI vocabulary arose in the context of our collaborative work on schema annotation. Thanks are also due to Claus Huitfeldt, Allen Renear, and David Dubin, my collaborators on the so-called ‘Bechamel’ project on markup semantics. The core of this paper is an attempt to apply to the OAI vocabulary the description techniques we have been exploring in the Bechamel project.
[2] In passing, it may be noted that this translation moves the type information associated with q, s, and t into the descriptions; it omits for convenience the clause (“(∀ x)(uri_server(x, s) ⇒ x = {string(./oai:request)})”) which claims that a given server has only a single URI.
[3] The author is not absolutely certain, after reading the documentation, whether identifying the base URI of the request with “the” URI of the server is completely kosher.
[4] Only “might”, because although conforming processors are required to use badVerb as the value of the code attribute, the textual content of the element is not constrained.
[5] Strictly speaking, if the metadata record is uniquely identified by the triple (item id, metadata prefix, datestamp), then a change in the datestamp invariably denotes the creation of a new record, and so no record can ever be changed. For the sake of readers less pedantic than the author of this paper, the OAI documentation does not insist on this point.
[6] It might be preferable to distinguish OAI-request from request, where the former is guaranteed valid.
[7] Is this true?
[8] The treatment of deleted records needs to be reviewed, to make sure the interpretations given here deal correctly with records deleted from the repository.
[9] This (and some others) may be derivable.