
Within the Perseus text system, each object has a multi-part name, in which the parts are delimited by colons, for example Perseus:text:1999.04.0001. In these names, the first part denotes the naming authority, the second is the object type, and the rest is a name or code specific to the given object. Names of this form are used for collections, texts, tools, abstract bibliographic objects (ABOs), and software tools.
For a text stored in the system that defines it, the first part of the name will be the system name, the identifier defined for this system in its main configuration file. The second part will be 'text'. Conventionally the third name part, the specific identifier, has the form xxxx.xx.xxxx, where each 'x' is a digit. The first two groups of digits can be used to group similar texts. Within Perseus, for example, the specific identifiers for classical Greek texts are 1999.01.xxxx while those for classical Latin are 1999.02.xxxx.
The naming rules for OAI-harvested objects extend the rules for local
objects, and follow naturally from the naming rules in the OAI
protocol. Each object for which meta-data can be harvested has an
identifier assigned by its own system; the system also has an
identifier. The content <identifier> element in the response to the
GetRecord verb includes both the system identifier and the object
identifier, in the form oai:sysid:objid. These identifiers can be
assumed to be unique, and will not conflict with any identifiers defined
by the local system because the first field, 'oai', will not be the same
as the system name of the local system.
When the harvested system is another instance of the Perseus text system, using pdataprov as a data provider, the object identifier field in the OAI identifier will have the standard form. For example, a co-operating system might harvest a record identified as oai:perseus.tufts.edu:Perseus:text:1999.01.0001. Although this identifier can be used as it is, the harvesting system may optionally parse it, recognizing that this is a Perseus-form identifier, and treat it in the same way as local identifiers. That is, the 'oai' prefix and the system identifier (here 'perseus.tufts.edu') could be stripped, giving an identifier of the same form as those defined by the local system. It is expected in particular that this will be done for ABO identifiers, which can easily be shared.
The easiest way to recognize co-operating systems is with the OAI
ListFriends routine, which supplies a list of registered data providers,
their registry IDs, and the URLs of their data providers. This of
course includes all known, publicly declared OAI data providers. If a
system wishes to restrict itself only to other Perseus-type systems, it
can harvest from only those that support the 'perseus' metadata format.
In other words, if the response to the ListMetadataFormats verb includes
<metadataPrefix>perseuslt;/metadataPrefix>, the responding system supports
the Perseus text system, or at least its metadata elements; if this
prefix is not included in the response, the responding system is not
using the Perseus text system.
As data providers rarely make radical changes to their software, and new data providers do not come on line every week, it is not necessary to check the list of co-operating systems every time a harvest is run; once a month should be quite frequent enough.