[Koha-bugs] [Bug 13381] RDA: 245 field changes in XSLT

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

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

--- Comment #17 from David Cook <dcook at prosentient.com.au> ---
(In reply to rgravel from comment #16)
> Statement of Responsibility:
> I am a cataloger and I do like the full statement of responsibility, ie the
> whole 245 field, to display at the top of the record. I think it is in fact
> helpful to patrons, because it is written in plain language and so clearly
> indicates to a patron whether the record they've found matches their needs. 
> It is fairly common in other systems and academic libraries to include the
> full statement, because it readily helps patrons understand what the record
> is a surrogate for, i.e. which book exactly the record really represents. 
> 

Hmm, fair enough. As a patron, I suppose I would prefer to see "Moby Dick /
Herman Melville ; retold by Kathy Burke." rather than just "Moby Dick". As you
say, it's a more accurate surrogate that way. 

Of course, if you have a lengthy statement of responsibility, the detail page
is going to get awfully crowded as the title/statement of responsibility area
is currently in a h1 element with a font size of about 140%. It's not so bad in
the search results where the title/statement of responsibility is in an a
element with about 104% font size.

I suppose as a patron, (technical services) librarian, and developer, I'd like
the display to be as useful as possible while also being usable/aesthetically
pleasing. 

Maybe changing the font size for the h1 to 120% instead of 140% will allow for
an easier to read heading, when more text is displayed.

> Furthermore, sometimes the statement differs from what is included in 100s
> and 700s, because it is up to the cataloger's taste and judgement to decide
> whether to make an access point for those folks listed in the statement. So,
> as a result, you could have important bibliographic information included in
> the statement, but no where else in the record, which is another reason I
> think many systems chose to display it. 
> 

Very true, especially in the case of AACR2 records where the "rule of three"
was encouraged. 

That said, if I recall correctly, cataloguers can choose to snip the statement
of responsibility as well if it's too long... but then that sort of negates my
earlier point about being concerned about overly long statements of
responsibility ;).

> GMD/Medium:
> Because there will be a mix of legacy AACR2 and new RDA records in our
> catalogs, we can no longer *consistently* rely on the GMD as the indicator
> of medium. The good news is, there are other indicators in the record that
> are consistent across AACR2 and RDA records, like the material type that is
> pulled from MARC's fixed fields/leader and already populates a Type tag in
> the record; a new medium or format tag that pulled the GMD in would be
> duplicative of this in my opinion. The type selected for the items, as well
> as any call number prefixes that might be use for DVDs or Ebooks, as also
> consistent indicators, not to mention RDA's new 33x fields.

Unfortunately, most of the records I encounter don't have any data or correct
data in the fixed fields/leader when it comes to the material type. I work
mainly in special libraries where knowledge of library cataloguing standards,
which can be readily found in public and academic libraries, is much more rare. 

On one hand, this can be incentive to clean-up old records and re-train staff
to catalogue more "properly". On the other hand, no one in special libraries
has time or money for that. In theory, I'd like to rely on the leader and the
fixed fields, but in practice I find that cataloguers just aren't consistent
enough.

That's why I think libraries introduced the RDA 33x fields. All that data was
already there, but now there is an easier (albeit also error-prone) way of
writing it out.

But yeah... 33x fields, leader/fixed fields, item type, GMD, call number
prefixes... there isn't a whole lot of consistency or reliability. 

In all honesty, I've been thinking about the possibility of introducing a
Koha-specific "record type". It seems that this sort of thing is pretty common
in other systems like Summon and EDS. It would be indexed, so you could search
it specifically or you could use it as a facet. It would display in the search
results and on the detail page, so that patrons could easily see what sort of
record the library deems it to be. The advantage of a record type over an item
type is that item type is currently mixed up between items and bib records via
the 942$c. It would be a high-level record type - completely unrelated to MARC
- which would be based on improving discoverability.

Why should we be bound to MARC? Ebsco and Serial Solutions ignore it/enhance
it, and people love their systems and laud them for "discovery".

(Of course, adding a Koha-specific "record type" would make bulk importing
records more difficult without a predefined mapping to use something in MARC to
map to the Koha-specific "record type")

--

In summary, I'm sold on the statement of responsibility. Let's do it up.

As for the Medium stuff... I still don't know the best solution.

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