[Koha-bugs] [Bug 6891] LDIF interoperability - a proposal

[bugzilla-daemon at bugs.koha-community.org]

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6891

--- Comment #4 from Xan Charbonnet <xan at biblionix.com> 2011-09-21 14:58:08 UTC ---
Robin,

* Apollo doesn't import or export authority records separately; we only deal
with what's in the bibliographic records.  I'm certainly okay with adding
authority records to this spec.

* Doing repeating holidays could work...  If exporting software doesn't support
repeating holidays, it can export the full list of dates, and if importing
software doesn't support repeating holidays, when reading "LDIF", the importer
can create individual holidays on that date for the following few years.

But would this really be very helpful?  Something like Christmas is fixed, but
at least around here, the "observed" dates for various holidays wander all over
the calendar.  Columbus Day, MLK Day, Washington's birthday, and others are
usually observed on a Monday.  And of course Good Friday and Easter move all
over.  Ideally, there'd be a way in the spec to say, eg, "the library is always
closed on Columbus Day (observed)", but I don't think there's any kind of
standard code that allows us to refer to holidays, and we don't want this spec
to have to include the names of all the international holidays.

So I'm not sure that repeating dates are worth the trouble.  Maybe it is still
worth it, even if it only works for the holidays that are fixed.

* Here's the thinking on holding types (or item types, or collection codes). 
Every system handles these things a little differently.  Some systems
(including now Apollo, because we import from these other systems) have two
orthogonal sets of holding types.  One may be based on call number and the
other on medium, for example.  It's up to the library what they want to use
them for (if they want them at all).  Some systems in fact have three or more
such sets of types.

We wanted "LDIF" to allow for all of these, so rather than having a "type"
attribute on the holding, and elements that define "type", and then also a
"type2" attribute, and elements that define "type2", and so on to "typeN", we
went with a way to store as many sets of types as are required.