[Koha-bugs] [Bug 12477] We need better ways to manage MARC Frameworks

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

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

--- Comment #14 from David Cook <dcook at prosentient.com.au> ---
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.