Thanks! Yes, in this case, 245 $a becomes the work title, other
subfields are ignored for works, used only for instances.
How this differs from what a cataloger would develop as a work title in
most cases is beyond me, but I may dig in the rules for some interesting
cases. I asked and it appears that although FRBR&BIBFRAME assume that
there is always a work title, current RDA cataloging continues to create
"uniform titles" in a small number of specific situations only, so the
FRBR "work title" is not getting human scrutiny.
And of course there are all of the records in the MARC back file that
should have had a uniform title but do not (fairly common, in my
experience) and therefore the title proper \= work title. I wonder if
there won't be a way to make this more accurate through data mining...
it's a thought.
On 4/17/15 10:01 AM, Mark Baker wrote:
> Hi Karen. FWIW, pybibframe uses 245$a as our base Work title in BF Lite;
> and as you can see there, we preserve other subfields as separate
> properties which can be custom assembled in different contexts via
> your own code, or the labelizer plugin we provide;
> AFAIK, this hasn't been widely field-tested yet (so obviously prone to
> change at any moment), but if you choose to use the plugin, multiple
> occurrences of properties are concatenated using a separator;
> I haven't verified the ordering, but I expect it's effectively random
> because Python :P But ordering (of any kind, including preserved from
> the MARCXML) can be added.
[log in to unmask] http://kcoyle.net