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.

kc


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;
>
> https://github.com/zepheira/pybibframe/blob/master/lib/reader/marcpatterns.py#L307
>
> 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;
>
> https://github.com/zepheira/pybibframe/blob/master/lib/plugin/labelizer.py
>
> 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;
>
> https://github.com/zepheira/pybibframe/blob/master/lib/plugin/labelizer.py#L97
>
> 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.

-- 
Karen Coyle
[log in to unmask] http://kcoyle.net
m: +1-510-435-8234
skype: kcoylenet/+1-510-984-3600