http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12477
--- Comment #14 from David Cook <[email protected]> --- I'm thinking more about how to keep frameworks current... In theory, all MARC Bibliographic Frameworks should include all MARC Bibliographic fields and subfields. I can only think of two scenarios where this theory would be false: 1) You've bent the MARC Bibliographic Framework in an attempt to support a different sort of metadata format. [Note: I don't think this is an overly valid reason not to auto-update frameworks.] 2) You want a framework that will discard certain fields when importing records. For instance, you might never ever want to keep the 035 for incoming records (although it's a nice bit of data to keep). So you delete the 035 from the framework. [Note: This scenario is more interesting. By deleting certain fields, you could potentially increase the efficiency of your cataloguing workflow. That is, you would reduce the amount of time spent deleting unwanted data when importing records. Yet... I can't help but feel that the "xkcd: Workflow" comic (http://xkcd.com/1172/) is relevant here. I suppose a way to mitigate this might be to add an "auto-update" flag to the frameworks. You could turn it off for frameworks whose structure you don't want to change. Yet...that doesn't make sense either...because there will come a time where you need to add fields/subfields (such as the RDA fields/subfields). I suppose that leads us back to doing manual updates... but that can be painful for a number of reasons. One of those being that the full list of missing fields/subfields will show up each time, so you need to hand-pick which fields/subfields you want to add. Plus, if you're doing manual updates, you need a prompt to do the updates. I suppose this could be done with a staff client news item...but then when to do framework update checks...] --- I've been thinking more about visibility. Regardless of what metadata format we use, we'll run into this problem again and again. Instead of using one column ("hidden"), it might make sense to use three columns ("internal","external","editor"). "internal" and "external" would control visibility in the staff client and the OPAC (maybe OAI as well...hence my use of "external" as a label). "editor" would have more options: "used","used - collapsed", "hidden", "unused". In this case, "used" shows up uncollapsed, "used - collapsed" shows up as a collapsed field, "hidden" doesn't show up unless you're importing records with a value in that subfield, "unused" means that there can never be a value in this field. Alternatively... we keep the current "hidden" column and add a "used" column which defaults to "on". If someone wants a framework that will ignore certain fields when importing, they can turn "used" to "off". In support of this mechanism, it might make sense to remove the ability for people to delete fields/subfields from frameworks (unless they're local fields/subfields that they've added). Of course, that's easy to circumvent by just importing a framework that doesn't have certain fields/subfields (until the next auto-update comes around which re-populates those missing fields/subfields). --- I don't know... I've looked at this a bit in DSpace as well, and I don't really like the way they do it either. In DSpace, there is a metadata registry, then you define input forms (which would be analogous to our frameworks in a way). It gets incredibly unwieldy after the first form or two, especially if you have a lot of fields per form. In the past, I've mostly done original cataloguing, so I'm not 100% sure what other ILSes/LMSes do for templates with copy cataloguing. I recall cataloguers using Horizon would have to delete unwanted data when importing records. I think the function of the templates were more so to provide a minimal set of fields/subfields that you should fill out. (You then had the option to add more fields/subfields manually as necessary.) --- -- You are receiving this mail because: You are watching all bug changes. _______________________________________________ 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/
