http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6891
--- Comment #4 from Xan Charbonnet <[email protected]> 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. >From there, it became apparent that funds, vendors, and what we and other systems call "shelf location" were also lists of basically the same nature. So rather than explicitly support each of these, they are also considered to be "holding types" in the XML. When migrating from one system to another, very often a library wants to swap types around, putting the secondary types into primary and vice-versa, swapping fund codes and vendors (I suppose because they've been putting things in the wrong place before), using shelf location as the material type, ignore and not import one list or other, etc. There are all kinds of things that people want to do with these "types". What this approach allows is for the importing software to configure a mapping for what to do with each of the types. This way, no matter what the library wants to do with them, the importer code doesn't have to be changed, nor does there need to be a step transforming the XML. I'm not married to this approach. Do you think it's too confusing? * Some systems (including Apollo) keep a usage count for biblios. Whenever an item checks out, the usage count for that item is incremented, as well as the usage count for that biblio. It isn't hugely important, but it means that for biblios with a lot of items and a lot of turnover on those items, items can be weeded without losing the count for the number of times the title has circulated. The biblio usageCount can be absent, in which case the importer (for a system that supports it) should probably add up the item usageCounts to create the biblio usageCount. * ILS-specific extensions should be fine, and that makes sense. Of course we'll want to make sure that anything that makes sense in the main spec goes there. Also it would be nice to have an export including the extensions validate against the schema, but I suppose an ILS could use its own schema, and declare that it's the same as "LDIF Version X" plus extensions. The main ILS-specific stuff that might be required (at least, that I can think of right now) would be the set of configuration options for a library. Those wouldn't really translate from one system to another, generally, but would be handy to have in the export for backup/restore purposes. Maybe there's a way to allow the storage of those in key/value pairs in the main spec. Let us work on some updates based on this conversation and we'll see how the XSD looks after that. Thanks for all your help! -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug. _______________________________________________ Koha-bugs mailing list [email protected] http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
