Closed pschreur closed 10 years ago
ntra00
commented
10 years ago Not having any further info in the MARC record, we can use creator, contributor, or agent. I chose bf:contributor for now. This would be a prime place for format specific relators, if we can generalize.
pschreur
commented
10 years ago But could we just not convert these to bf:works? I think the point was the data in the $r is just too variable to create a useful bf:work. Better to not generate one and let them be added by hand editing at some different point in time.
ntra00
commented
10 years ago Sure, but if the problem your having is with the relationship between the work and the agent responsible for it, then building the bf:work means that editing by hand down the line is just to find tune that relator, right? Otherwise, these nicely parsed fields will go into some giant blob of a field. Do you have example marc records where these parts with title should not be considered bf:works, however skimpily cataloged?
kefo
commented
10 years ago I'll second the request for samples.
I'm confused: if I understand correctly, Phil wants the 505s to be made Works (or not) and Nate is saying they are. Am I missing something?
ntra00
commented
10 years ago here's an example. (doesn't have the $r converted to bf:contributor, still bf:creator; I only made the change in test so far) I'm making them bf:works, but the $r probably can't be creator for certain kinds of works, so I thought I should tone it down to agent or contributor; Phil says don't even have them be works; it's too problematic.
kefo
commented
10 years ago Phil wrote:
I think the point was the data in the $r is just too variable to create a useful bf:work.
Yea, the bf:Work is pretty skimpy, as Nate noted, but we see these as stub "records." It's always possible to back away from this path, but we're also interested in seeing what happens when we take this route, where it takes us (at least for now). Other than them being skimpy, is there a strong objection to this we're not thinking of?
pschreur
commented
10 years ago The example I have is a very complicated one so let me try and explain it verbally at first but can always submit the data as well. This was generated from a collection of films starring James Dean. The formatted contents note had the titles of the films plus a seemingly random actor chosen to be placed in the $r. In speaking with my media cataloger, this is very common.
I'm not so much arguing that these are not works, but rather that the AAP generated for them looks so wrong. I have to admit, though, that I still do not fully understand the need for, or use of the AAP in this context. They are certainly not authoritative or unique. It gives the impression of a name/UT for a FRBR work (which it's not). And because of the randomness of what's in the $r, many different AAPs will be generated for the same bf:work from differing resources.
Perhaps this is more of an AAP question? We've run across a number of situations in which the AAP that is automatically generated is quite problematic.
Phil
On 5/19/2014 1:01 PM, Kevin Ford wrote:
Phil wrote:
I think the point was the data in the $r is just too variable to create a useful bf:work.Yea, the bf:Work is pretty skimpy, as Nate noted, but we see these as stub "records." It's always possible to back away from this path, but we're also interested in seeing what happens when we take this route, where it takes us (at least for now). Other than them being skimpy, is there a strong objection to this we're not thinking of?
— Reply to this email directly or view it on GitHub https://github.com/lcnetdev/marc2bibframe/issues/30#issuecomment-43548944.
Philip E. Schreur Head, Metadata Department Stanford University 650-723-2454 650-725-1120 (fax)
ntra00
commented
10 years ago I think that's it. I will drop AAP from these, since I don't have enough info to build a meaningfull one, even by accident with the 505 data.
rguenther52
commented
10 years ago Yes, there have been a number of questions about the AAP in general but they are particularly problematic in this case. Looking at sample data will help. These subfields in the 505 parsing out the pieces of the TOC came into the format pretty late in the game and it's never been clear who actually uses them. Interesting that they are using them for moving images. But since $r is a statement of responsibility it can have all kinds of text in it. Does it seem like people are using it just for a contributor name (and I agree with putting it in contributor rather than creator)?
pschreur
commented
10 years ago The problem with video examples is that they're so long :) ... The $r is not always given but in this case, for instance, the $r for the work "The Dream of Rarebit Fiend" if the manufacturer. I'm sure to video catalogers the choice isn't random but from teh outside there certainly seems to be a great deal of flexibility.
Philip
On 5/20/2014 6:35 AM, rguenther52 wrote:
Yes, there have been a number of questions about the AAP in general but they are particularly problematic in this case. Looking at sample data will help. These subfields in the 505 parsing out the pieces of the TOC came into the format pretty late in the game and it's never been clear who actually uses them. Interesting that they are using them for moving images. But since $r is a statement of responsibility it can have all kinds of text in it. Does i
The formatted 505 field is being converted as a bf:work with a creator (from the |r). THis can be very confusing in certain formats. For instance, with films, an actor may be in the |r. Perhaps for certain formats the creator should not be included.