Andy Powell, UKOLN, University of Bath
The primary purpose of the partnerships is to facilitate record sharing between RDN hubs and HEA subject centres. The diagram shown here provides the overall architecture.
The OAI Protocol for Metadata Harvesting (OAI-PMH) is used to exchange records that conform to the RDN/LTSN LOM Application Profile (RLLOMAP).
Note that there may be other kinds of collaborative activities between RDN hubs and HEA subject centres, for example the exchange of news and events information using RSS. However, these activities are not covered by this FAQ.
That depends on whether you are an HEA subject centre or an RDN hub and, if you are a Hub, on whether you are going to be hosting a database of records about learning objects on behalf of one or more HEA subject centres.
All RDN hubs must modify their OAI repository software in order to expose a view of their records that conforms to the RLLOMAP. RDN hubs do not need to enhance their metadata records in order to do this (i.e. they do not need to add additional fields to their databases). Therefore the RLLOMAP records that they expose may be fairly sparse.
RDN hubs must continue to expose an oai_dc (simple DC) view of their records via their OAI repository software. They may also choose to offer an rdn_dc (qualified DC) view of their records as well (for example, to exchange metadata with other RDN hubs).
All RDN hubs must implement an OAI gatherer in order to harvest RLLOMAP records from HEA subject centres. The gatherer may dumb-down the gathered RLLOMAP records to their current internal record format if desired. However, RDN hubs are encouraged to store the full richness of the gathered RLLOMAP records.
RDN hubs that are hosting a database on behalf of one or more HEA subject centres must offer a database that supports the full richness of RLLOMAP and that exposes RLLOMAP records using the OAI-PMH.
All HEA subject centres must enhance their existing database(s) OR develop new databases OR reach hosting agreements with their RDN hub partner in order to store metadata records that comply with the RLLOMAP.
All HEA subject centres (or their hosting partner) must offer an OAI repository to expose a view of their records that conforms to the RLLOMAP.
All HEA subject centres (or their hosting partner) must expose an oai_dc (simple DC) view of their records via their OAI repository software as mandated by the OAI-PMH.
All HEA subject centres must enhance their existing records to conform with the RLLOMAP.
HEA subject centres (or their hosting partner) may also need to implement an OAI gatherer in order to harvest RLLOMAP records from RDN hubs. HEA subject centres only need to implement an OAI gatherer if they have plans to harvest records from other centres or from RDN hubs. Note that one reason for doing this is to re-harvest records that were given to the RDN hub for maintenance as part of rationalising your collection policies.
Metadata records should be exchanged using the Open Archives Initiative Protocol for Metadata Harvesting version 2.0.
The primary record format used for exchanging records between RDN hubs and HEA subject centres is defined by the LOM binding of the RDN/LTSN LOM application profile (see section 5.1). An XML schema for this binding is provided at http://www.rdn.ac.uk/oai/lom/lom.xsd.
As a minimum, RDN hubs and HEA subject centres should maintain metadata about their records according to the RDN admin metadata document. Such metadata is conventionally known as meta-metadata or admin metadata. It should be encoded in the 'about' section of an OAI-PMH record as defined in section 3.1 of the document above. In some cases, it may also be appropriate to store and exchange meta-metadata using the IEEE LOM metametadata container, as defined in section 3.2.
Each metadata record in an OAI repository is assigned a unique identifier. Record identifiers must conform to the OAI identifier format. Each RDN Hub must assign record identifiers using one of the following strings as the namespace-identifier:
For example: oai:agrifor.ac.uk:20016090
Each HEA Centre must assign record identifiers using one of the following strings as the namespace-identifier:
For example: oai:bio.ltsn.ac.uk:12345-67890
RDN hubs and HEA subject centres should assign a POI to all resources described by their metadata records. Each POI should be a direct transformation of the corresponding metadata record identifier, as described in section 4. of the POI document.
For the two example metadata record identifiers above, the corresponding POIs are:
In general, you do not need to manually create or assign a POI. Your cataloguing software should automatically generate an OAI identifier for the record that you are creating and should use this to generate the POI. (See next question for more detail.)
As it says above, in general you don't have to manually assign a POI - it is all done automagically. In very simple terms, the cataloguing process goes something like this:
Note that cataloguing software that generates RLLOMAP XML records from this information should always put the POI in the first technical.location field (as well as into the general.identifier field), also putting the URL into a second technical.location field (in those cases where a URL is available).
No. Individual POIs do not need to be registered with the PURL system. However, in order that the POI is resolvable, the OAI-PMH interface to the catalogue containing the metadata record about the resource must be registered with either the POI Lookup Tool and/or the OAI Registry at UIUC. RDN hubs and HEA subject centres are very strongly encouraged to register their OAI-PMH interfaces with the POI Lookup Tool. To do so, please send email to rdn-support@rdn.ac.uk.
In RLLOMAP records exposed using the OAI-PMH, the POI should be encoded in the '1.1.2 entry' field. The URL of the resource (if available) should be encoded in the '4.3 location' field. In DC records exposed using the OAI-PMH, the POI should be encoded in the first 'dc:identifier' field and the URL (if available) in a second 'dc:identifier' field.
The POI is a persistent identifier for the catalogued resource. What does persistent mean? Well, in this case it means that the POI is intended to be more persistent than the resource URL. So even if the resource URL changes, the POI will remain the same - it will just reolve to a different location. It is worth noting that assigning a POI (or any other kind of identifier) to the resources described by RDN hubs and HEA subject centres has little short-term benefit. However, the costs of assigning a POI are low (because the process is fully automated, based on the oai-identifier already assigned to the metadata record). In the longer term, it is hoped that the identifiers assigned now will support a range of additional services, such as annotations by end-users, and that such services will be more useful and usable because the POI is persistent.
The following rules should be used by RDN hubs and HEA subject centres when exchanging metadata records:
The rules above allow multiple (enhanced) metadata records about the same resource to flow around the system. RDN hubs and HEA centres are expected to EITHER display all records OR to de-duplicate in some fashion (according to their interprettation of user requirements, usability, etc.). De-duplication can be based on comparison of POIs and/or URLs.
Where an OpenURL is used as value of the '4.3 location' element, use as many fields as possible (in order to provide a rich OpenURL for resolvers to deal with).
For books, provide at least the following:
Also provide 'date' if known.
For journal articles, provide at least the following:
Also provide 'volume', 'spage', 'epage' and 'artnum' if known.
The following resources are available:
An XML-encoded byte stream.
The OAI-PMH mandates the use of UTF-8.
No... it's a little more complicated than that!
The OAI-PMH XML response must be correctly encoded as UTF-8 when it is generated from your back-end database.
In a UTF-8 document, the number of bytes used to represent each character varies between one and four. The first byte of each character indicates how many bytes make up the character. For example, if the first byte is 110xxxxx, the character is made up of two bytes, this one and the next one in the stream. In a conventional ASCII document all characters are one byte, a very different thing!
If, for example, an XML document saved as ASCII is sent to an OAI harvester which thinks it is receiving UTF-8, the following will happen:
For example, pi (ASCII 227) in binary is 11100011. The XML parser will read this as the first byte of a three byte UTF-8 character. Completely different to what was intended!
There's a good tutorial on XML and character encoding at http://skew.org/xml/tutorial/.
Any UTF-8 character is allowed in XML character data apart from < and & (see http://www.w3.org/TR/REC-xml/#syntax). Note that all text that is not markup constitutes the character data of the OAI-PMH response.
The ampersand character (&) and the left angle bracket (<) must be escaped using either numeric character references or the strings "&" and "<" respectively. The right angle bracket (>) may be represented using the string ">", and must, for compatibility, be escaped using either ">" or a character reference when it appears in the string "]]>" in content, when that string is not marking the end of a CDATA section.
Note that strings containing & and < may be encoded in a CDATA section (e.g. "<![CDATA[Sausage & chips]]>"). However, in general, this is not recommended because it introduces chunks of unparsed character data into the OAI-PMH response.
The XML documents carried by the OAI-PMH are exchanged as a byte stream of UTF-8 characters. Therefore, although numeric character references may be used, they are not required (other than for & and < as described above). In general, the use of numeric character references is not recommended.
That depends on what kind of database and operating system you are using. If your database/operating system supports Unicode, then you should store all characters in the database as Unicode. Otherwise, it is probably sensible to store any characters greater than ASCII 127 as numeric character references. Remember that if you do store encoded characters in your database, then you will have to similarly encode any end-user queries against the database in the same way before initiating a search.
Join the club! These two LOM attributes seem remarkably useless! Here's some guidance about recommended best practice for RLLOMAP:
Athens username required
Registration required
Payment required
In all other cases both fields should be omitted.
This is a non-trivial question to answer... but the following points should be noted:
N:<Family Name>;<Given Name>;<Additional Names>;<Honorific Prefixes>;<Honorific Suffixes>For example:
N:Stevenson;John;Philip,Paul;Dr.;Jr., M.D., A.C.P.
Here is a complete example:
<![CDATA[BEGIN:VCARD FN:Dr John Stevenson Jr.\, M.D.\, A.C.P. N:Stevenson;John;Philip,Paul;Dr.;Jr., M.D., A.C.P. ORG:Pugwash\, Bates and Cabinboy Ltd. VERSION:3.0 END:VCARD]]>
Yes, you can... and doing so may be useful in order to disambiguate two people with the same name. Use the vCard BDAY element as follows:
<![CDATA[BEGIN:VCARD FN:John Lennon N:Lennon;John;Winston;; BDAY:1940-10-09 VERSION:3.0 END:VCARD]]>
Note that you cannot use vCard to indicate the date of someone's death.
Not according to a strict interpretation of the above guidelines (and the vCard specification for that matter!). However, this issue has been discussed on various mailing lists and the closest we've come tro concensus seems to be the following:
For example:
<![CDATA[BEGIN:VCARD FN:University of Oxford N:;;University of Oxford ORG:University of Oxford VERSION:3.0 END:VCARD]]>
Conversely, for parsers the rule is
Although it doesn't matter what metadataPrefix you use, recommended best practice is to use "lom".
The LOM namespace URI is http://ltsc.ieee.org/xsd/LOM. Note that use of the older namespace URI, http://ltsc.ieee.org/xsd/LOMv1p0, is no longer recommended.
A working copy of the LOM XML schema is available at http://www.rdn.ac.uk/oai/lom/20040413/lom.xsd.
In summary, your LOM records encoded in OAI-PMH responses should be wrapped in:
...
<metadata>
<lom xmlns="http://ltsc.ieee.org/xsd/LOM" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://ltsc.ieee.org/xsd/LOM http://www.rdn.ac.uk/oai/lom/20040413/lom.xsd">
...
</lom>
</metadata>
...