This targetNamespace is very temporary!
We want to use ldif.org or similar, once the name is finalized.
October 2, 2023 - Joe Axford, Biblionix
Version 053 of the standard currently known as "LDIF".
This schema describes how to express ILS data in XML.
Notes:
* Fields containing times should never specify a
timezone. All times are local time for the library.
Changes from version 052:
* Add "hostname" to "conversionStep".
Changes from version 051:
* Restrict "membership" prefixes to "hm" or "pm".
Changes from version 050:
* Add "note" for each "patronMembershipList" and "holdingMembershipList"
Changes from version 049:
* Add "memory" for each "conversionStep" in "summary"
Changes from version 048:
* Add conversionNotes to "summary"
Changes from version 047:
* Add editrecords attribute to alertOnEvent for holding notes.
Changes from version 046:
* Add the concept of "condition" for holdings.
Changes from version 045:
* Add "location" attribute to "userdef", "patronMembership", "holdingMembership",
and "booklists".
Changes from version 044:
* Add "virtual" attribute to "biblio"
Changes from version 043:
* Add patron files.
Changes from version 042:
* Add the "username" attribute to "patron"
Changes from version 041:
* Add many more things to "summary": start time, parameters, files used,
hashes and timestamps of files
Changes from version 040:
* Added "photos" as a descendant of "biblio" (in addition to "patron")
Changes from version 039:
* Added "notePatron" attribute to "address", "email", and "phone"
* Added "isParent" attribute to same
Changes from version 038:
* Added the "summary" element which can be used to document the LDIF generation process
Changes from version 037:
* Added "associatedProblem" to "problem".
* Added "continuation" to "fine".
Changes from version 036:
* Add "quarantine" as a checkout type
* Add "checkoutReceiptContact" element to "patron"
* Add the concept of "previousBarcodes" attached to "patron"
* Add "alertOnEvent" to "holdingNote"
Changes from version 035:
* Add "signupLocation" as an attribute of "patron"
Changes from version 034:
* Add "description" as an attribute of "booklist"
Changes from version 033:
* Add "circHistoryDays" as an attribute of "patron"
Changes from version 032:
* Add "note" as an attribute of "address", "email", and "phone"
Changes from version 031:
* Add "membership" as a type of problem
Changes from version 030:
* Make the "status" attribute of biblios and holdings optional,
with a default to "active"
* Added a "status" attribute to patron
Changes from version 029:
* Added many attributes to branch locations.
Changes from version 028:
* Added "nameSuffix" to patron, "middleName" and "preferredName" to firstName
Changes from version 027:
* Updated email regex - we were rejecting some rare but valid addresses
Changes from version 026:
* Added "salutation" parameter to patrons
Changes from version 025:
* Added "cost" parameter to passwords
Changes from version 024:
* Due "dates" are now dateTime timestamps rather than dates
* Added constraints via xs:unique and xs:keyref
Changes from version 023:
* Added a "ldif:contactSelection" element type and used it multiple places
Changes from version 022:
* Added a "public" option for holdingNotes
Changes from version 021:
* Added an "urgent" option for holdingNotes
Changes from version 020:
* Added "temporary" to biblios
Changes from version 019:
* Added "issue" to holdings
Changes from version 018:
* Added preferredLocation to patrons
* Allowed zero-length patron memberships
* Removed the simple "password" attribute in favor of hashes, salts, etc
* Added "booklists"
Changes from version 017:
* Renewals can now include the previous due date
Changes from version 016:
* Copy and volume fields added for holdings
* Call suffix for holdings added
* Added regular expressions for the ILS to map call numbers to material types
* Reserve "placed" and "resolved" now dateTime instead of date
* Added "latest activity" attribute for patrons
Changes from version 015:
* holidays element no longer requires at least one date
Changes from version 014:
* Added support for patron password
* Added support for custom fields ("userdefs") for patrons
and holdings
Changes from version 013:
* Added an "urgent" option for patronNotes
* Removed the "require"ment for a number of fields
* Changed amountPaidCents in fines to default "0" rather
than required
Changes from version 012:
* Support for multiple branches
* Added SMS email address to phones
* Internationalized addresses
Changes from version 011:
* Give the full external URL in MARC XML's schemaLocation
* Remove the bitmask for days of the week closed in favor
of a more XML-like solution
Changes from version 010:
* Added documentation
* Added the system element for describing the software
that generated a document
* Added a way to represent days of the week the library
is closed
* Internationalized phone numbers
* Converted from base64-encoded MARC to MARC in XML,
referring to the official LoC MARC XML schema
* Added support for authorities, via the same MARC in XML
schema
* Changed "types" (eg, holdingTypeLists) to "memberships"
(eg holdingMembershipLists)
* Removed the concept of "age" in favor of a
patronTypeMembership
* Replaced patronType and holdingType from checkouts
with a reference to applicable membershipLists
* Swapped the order of holdingMembershipLists and
patronMembershipLists (only because it's easier to
explain the holding version in the inline documentation)
* Removed cardRenewals (didn't seem worth the trouble)
* Simplified purchaseRequests
* Moved reserves inside of patrons
* A few other minor housekeeping things
The "version" attribute is the version of the LDIF
spec to which the document conforms.
The name of the entity whose data this is.
The "system" tag describes the ILS which generated
the document.
Information about the generation of the LDIF file.
There may be a multi-step process to generating an LDIF file.
Presumably there's always at least one step.
Each step can be documented here.
The Unix timestamp when the step began.
The amount of time in seconds that this step took.
The maximum amount of memory used in bytes.
Size of the file in bytes.
Lower-case hexadecimal representation of a hash/code.
Unix representation of the modification timestamp of the file.
Many systems allow a library to specify "user-defined" fields,
which store data the ILS doesn't have a particular slot for.
These can also be used, of course, to store data in LDIF which
LDIF doesn't have a particular slot for.
Set only if this field applies to a particular branch
rather than to the whole system.
If the library is a multi-building system, then each
building will have a corresponding location element.
If the library has only a single building, then a location
element is not required.
The ID of the location is used to define the "home" of
holdings, in checkouts to identify where items were
checked out and in, and in reserves to indicate where
a patron wishes to pick up an item
The official name of the location, eg:
Springfield Public Library
This is how "holding types" are represented in LDIF.
Every system is different, and in order to be generic,
we don't assign fixed attributes like "type", "secondary
type", "vendor", "fund", "shelf location", etc.
Instead, there's a holdingMembershipList for each of
the above attributes, and a holding may be a member
of zero or one of the holdingMemberships corresponding
to each list.
A holding MAY NOT be a member of more than one "type"
from a single list.
For example:
hm1
hm4
hm2
hm3
]]>
some systems associate a number with their
holding types, presenting eg "type 15" to
users, who may expect that numbering to
be preserved across a migration if possible
some systems (especially for funds) allow
a selection to be retired. That is, it's
still in the system with holdings attached,
but does not show up as an option when
cataloging.
Set only if this field applies to a particular branch
rather than to the whole system.
a system may use a Perl regular expression (here)
to map call numbers to material types
The greater this number, the higher the priority.
In other words, the list of patterns is sorted in
priority order, and the first to match wins.
This is how "patron types" are represented in LDIF.
See the documentation for holdingMembershipLists above.
some systems associate a number with their
holding types, presenting eg "type 15" to
users, who may expect that numbering to
be preserved across a migration if possible
some systems categorize their patron types
into broader groups, for example, some types
are in group "A", some in group "B", etc.
Set only if this field applies to a particular branch
rather than to the whole system.
A patron may have chosen a friendlier alias for purposes of
logging in, as opposed to the card number.
This is how many days the patron has chosen to keep circ
history. Absent implies no setting. A value of 0 (zero)
implies "keep forever". Otherwise the number of days to
keep history.
This is the two-letter country code specified in ISO-3166.
This is the ISO 3166-2 Sub-division/State Code.
Some libraries use "family accounts", where multiple
members of a family share one card. For this reason,
LDIF allows multiple firstNames per account. Most
libraries will not use this, and will have exactly
one firstName per patron.
It is possible to have a patronMembershipList that
applies at the firstName level, if a library does
use multiple firstNames per patron. It is expected
that any membershipList that applies at the firstName
level will NOT apply at the patron level. Behavior
in case of conflicts is undefined.
If patrons have indicated that they are unavailable
to receive reserved items on particular days, that
information can be stored here.
Some systems allow patrons to put items on a "wish list",
for items that they are not reserving, but which they
may wish to refer to later. This can be either at the
biblio or holding level (but not both).
"pending" - the patron wants the item
"completed" - the patron checked out the item
"deleted" - the reserve was deleted before any
fulfillment action was taken on it
"expired" - the item waited too long for the
patron to pick it up, and it was
returned to circulation without
having been checked out to the
reserving patron
"preempted" - the patron went and found the item
on the shelf before it was pulled
to wait for him
Reserves can be either at the bibliographic or the
holding level. Exactly one of "biblio" and "holding"
should be specified.
The dates on which notification(s) for this infraction
occurred can be represented here. This allows for
proper dovetailing of notifications when transitioning
between systems.
Some systems don't create a "fine" until the item has
been returned. Any overdue which has had a notification
should be a "fine" in LDIF (presumably with $0 amounts)
so that its notification dates can be represented.
"open" - the difference between amountCents and
amountPaidCents is currently being charged
"paid" - the fine is no longer being charged
"forgiven" - the fine is no longer being charged, and
the difference between amountCents and
amountPaidCents is considered "forgiven"
"converted" - the fine has been superceded by an
automatically created "problem"
A fine should refer to a checkout or to a holding
(but not both, since a checkout implies a holding).
Referring to a checkout is preferred.
"returned" and "due" only apply if not referring
to a checkout.
When "inprogress", the fine should continue to accumulate,
according to the current rules.
When "completed", the fine should not accumulate further,
regardless of the current rules.
Purchase / ILL requests coming in from patrons
In case any systems which support more than one photo
per patron exist, this supports any number of photos.
At this point, values for "mime" should probably always
be "image/jpeg".
User defined values refer to the field (called "uId", the "id"
value of a "userdef" tag) to which they belong.
One patron or holding may have at most one userdef value
per field. Enforcement of the data type is not done (at this
time) in the schema, but values must conform to the field's
declared data type.
Expresses a preference for a particular contact method.
Refers to either a phone number or email by IDREF.
When referring to a phone number, the SMS modifier may be
enabled.
Authority records, conforming to the LoC's XML Schema
for MARC.
Just like authorities, the XML for biblios is MARC
in XML form, conforming to the LoC's Schema.
This XML may be generated any way the exporting system
wishes. One suggestion is Galen Charlton's
MARC::File::XML, available on CPAN. Its XML output
works inside LDIF (with a little tweaking).
http://search.cpan.org/~gmcharlt/MARC-XML-0.93/lib/MARC/File/XML.pm
The "virtual" flag indicates that a biblio is some kind of
electronic resource that does not have physical holdings.
Most likely, it doesn't make sense for such a biblio to
have any holding records associated with it.
The most recent condition (by timestamp) is the current condition.
A deleted holding may refer to the "problem" which caused
its deletion.
Some libraries record whether renewals happened inside
vs outside the library, and whether they happened as
a result of staff or patron action.
The ID of the reserve with which this checkout
is associated.
Some systems store the patron and material types,
etc, that were in effect at the time of the checkout
Whether the item has been returned or not.
The default is for items to have been returned,
since (including historical checkouts) most checkouts
have been returned.
"normal" - a normal checkout out to a patron
"reserve" - the item is/was checked out to
the "reserve shelf", waiting for
a particular patron to pick it up
"in-library" - the item was checked in without
having been checked out
"transit" - transit between branches
"quarantine" - item is in post-checkout quarantine
This is the location ID of the destination branch.
It only makes sense for checkouts of type "transit".
In-progress inventories can be represented in LDIF.
Each inventory encompasses a subset of the collection.
This can be specified by holdingMembership, a range
of call numbers, both, or neither (for the whole
collection).
Problems are issues that block circulation, either
for a patron, a holding, or both.
For example, if an item is damaged, there is a problem
of type "damaged" that refers to the holding. If there
is a patron to blame for the damage, then that problem
also refers to a patron.
problemHoldingMovement contains problemHoldingLocation
elements, which serve to track the progression (or
simply the current location) of the item.
Examples of "location" are things like "missing",
"technical services", "circulation desk". Anywhere
that problem items sit while being dealt with can
be a problem location.
Unfortunately there doesn't seem to be an obvious
way to standardize this.
Absence of a problem location probably should imply
"missing", but it's better to specifically indicate
that. (Of course that only applies when there's a
holding attached to the problem.)
Most libraries which charge a processing fee for Lost items
do so by adding the amount of the fee to the Lost problem.
However, some want to use a separate problem for the processing
fee. This attribute may appear in Lost problems and points
to the associated processing problem.
This is intended to store information both about lists
that the library wants to be public (eg, "staff picks",
"Books for babies", whatever) as well as patrons' individual
"wish lists".
The biblios which are on the list.
The holdings which are on the list.
The name of the list (if applicable).
A description of the list (if applicable).
The patron whose list this is. If this attribute is
omitted, then this is a public, library-wide list
(and a "name" attribute really is required).
Set only if this field applies to a particular branch
rather than to the whole system.