[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 #11 from David Cook <dcook at prosentient.com.au> ---
(In reply to Bernardo Gonzalez Kriegel from comment #10)
> I created a new fw, set hidden = -6 for all subtags. A new record using this
> fw will only show those tags/subtags that are mandatory.
> Editing an existing record will show any tag/subtag that have a value, even
> hidden ones, and on saving no information is loose.

Ah, my mistake! That's good! I'm glad that I was wrong! 

It appears that this is also the case when using Z39.50. I think the problem I
may have encountered in the past was losing data when importing a record that
contained fields/subfields that didn't exist in that framework.

*checks with an example*

Aha! Yes! That's what it is! It makes sense...if the field/subfield doesn't
exist in the framework, it has no way of including it in the record. 

I suppose this might be both a pro and a con...

When copy-cataloguing, you might only want to import a certain subset of
fields, so you'd want to ignore fields not defined in that framework.

On the other hand, if you're cataloguing RDA records and you're not familiar
with the extra fields and subfields needed for RDA, you'll lose data that you
might want to keep when importing. That said, I think the onus needs to be on
librarians to properly configure their frameworks for that.

I don't know if this distinction is necessarily apparent in Koha. I imagine
it's possible that a librarian could create a new framework with a subset of
fields, and lose data when importing records because they forgot a
field/subfield. 

But...you could argue the onus is still on the person configuring the
framework. If they didn't include the field/subfield, they have no one but
themselves to blame for lost data.

> I think that default and sample (or simple) frameworks needs only 3 hidden
> values: visible (0), editable but not visible (2), and hidden (5)
> [visibility on opac/staff]. (5) could be used for obsoleted/deprecated
> tags/subtags (e.g. 440), but again you can't hide something in the editor
> with a value
> 
> (-6) is the value I was told to use when adding new tags/subtags, they do
> not display on editor (for new) and produce no functional change, but
> imported record can show values [opac/staff].

That sounds reasonable to me. 


> Whichever we use, my thinking is that we need to use a few hidden values as
> possible, and default FW needs to show as many tags as possible

Agreed.

> Then sample FW could be built by copying default, and _hiding_ (editor) all
> but a selected subset of tags. Which subset... I don't care, but it need a
> certain rationale behind. Not an universal agreement though.

That also makes sense. I don't know which subset either. While there are
cataloguing standards, I find practice is often highly localized, so they'll
need to be re-configured by end-users anyway. It might be useful to get input
from cataloguers that work with a range of materials for this one. I mostly
catalogued books, so I would say Leader,005,008,100(a),245(a,b,c),260(a,b,c)
(maybe also 264(a,b,c) as it's used in
RDA),300(a),336(a,2),337(a,2),338(a,2),490(a,v,x),500(a),505(a,r,t),520(a,b),700(a,t,d,f).

I don't have a lot of experience with serials but it should probably include
773(a,t,d,g,w).

Other frameworks would probably benefit from cataloguers with more specialized
knowledge and experience.

> But if they have all tags/subs then no information will be loose.
> That's what we need to ensure

Agreed. In that case, what do you think about the Fast Add Framework? It only
includes a small collection of fields/subfields. Wouldn't it make more sense to
include all the fields, and only show the subset that it currently shows?

While I'm somewhat skeptical of the utility of many of the sample frameworks, I
think the Fast Add Framework is quite useful. Admittedly, I don't know if it
needs to have all the fields, as I doubt one would ever really be importing
records into it. I suppose it would be good to have all the fields in case you
accidentally switched to the Fast Add Framework and saved a record. That would
lose data...

-- 
You are receiving this mail because:
You are watching all bug changes.