Rob, I think you've brought up another one of the complications...

The difference is in being controlled as a value vs. uncontrolled. The 
fictitious names in library records, like pseudonyms, are still 
controlled values. We will want to be able to know whether we have a 
controlled or an uncontrolled value in the "heading" fields.

I think that "transcribed" is yet another beast. It implies 
"uncontrolled" but it also refers to a certain set of rules for 
determining the value and a particular role in relation to the resource 
being described.

<great leap>
We should stop transcribing the title page and just show users a scan of 
it. This is the part of the library record that is supposed to be a 
surrogate for having the look at the book once you've done your 
retrieval on the headings. Why not just let people look at it on the 
screen?
</great leap>

kc

Rob Styles wrote:
> It seems to me that even a fictitious agent would be best served by 
> being described as a corporate agent, and have a property that indicates 
> it is fictitious. It can then have relationships with the genuine 
> corporate body or individual who made it up.
> 
> <teaching granny to suck eggs>
> LC Authority records already do equivalent to this with fictitious 
> author names don't they? recognising the pen name as a person and 
> relating it to the real author behind the name.
> </teaching granny to suck eggs>
> 
> Showing these things as entities in their own right, rather than simply 
> strings, puts a lot more meaning into the data and makes it possible to 
> do much more with it - for example, you could find out what proportion 
> of books were published by a fictitious publisher; you could discover 
> where the same fictitious publisher had been used by more than one body 
> to publish different works and so on.
> 
> rob
> 
> 
> On 9 Jul 2008, at 22:59, Karen Coyle wrote:
> 
>> One of the serious issues with library data, IMO, is that of 
>> transcribed data. If you've seen the talk I did at Code4Lib 
>> (http://www.code4lib.org/conference/2008/kcoyle), you will be familiar 
>> with the "publisher name" example that I used. It goes like this:
>>
>> The publication statement has (briefly):
>>  - place
>>  - publisher
>>  - date
>>
>> FRBR has a possible corporate agent whose relationship is "publisher."
>>
>> HOWEVER, what is recorded in an RDA-based metadata record in the 
>> publication statement is NOT the corporate agent whose relationship to 
>> the work is "publisher." What is recorded instead is the publisher 
>> name that appears on the title page. So in the case of samizat books 
>> and pamphlets, for example, the name of the publisher could be 
>> fictitious if it appears. In that case you record the fictitious name 
>> in the publication statement because the purpose of the publication 
>> statement is to represent what the work says about itself/ It is a 
>> surrogate for the self-identification on the title page of the item.
>>
>> There are a handful of data elements that are designed as "transcribed 
>> from the piece." It seems important to distinguish these from entries 
>> that are more functional (I can't think of a better word than that). 
>> Therefore, does it make sense to develop a class for transcribed 
>> strings? (They would always be strings, AFAIK). The advantage that I 
>> see is that by associating with a class, "transcribed" would always 
>> have the same meaning. When there are elements that are always 
>> transcribed (like the *title proper*) they would belong to that class. 
>> This would allow us to distinguish between dc:title or dcterms:title 
>> and the RDA "title proper."
>>
>> If this makes sense, then we need to figure out whether this works in 
>> terms of RDA. There are times when there is no title or publisher to 
>> transcribe and the catalogers are allowed to create one. Today it goes 
>> into the same "field" as the transcribed one, but with some special 
>> punctuation to show that it wasn't actually on the piece. We would 
>> need a way to cover this case as well.
>>
>> Right, it IS more complicated than it seems like it should be. But 
>> that's what we are working with.
>>
>> kc
>> -- 
>> -----------------------------------
>> Karen Coyle / Digital Library Consultant
>> [log in to unmask] http://www.kcoyle.net
>> ph.: 510-540-7596   skype: kcoylenet
>> fx.: 510-848-3913
>> mo.: 510-435-8234
>> ------------------------------------
> 
> Rob Styles
> tel: +44 (0)870 400 5000
> fax: +44 (0)870 400 5001
> mobile: +44 (0)7971 475 257
> msn: [log in to unmask]
> irc: irc.freenode.net/mmmmmrob,isnick
> web: http://www.talis.com/
> blog: http://www.dynamicorange.com/blog/
> blog: http://blogs.talis.com/panlibus/
> blog: http://blogs.talis.com/nodalities/
> blog: http://blogs.talis.com/n2/
> 
> 

-- 
-----------------------------------
Karen Coyle / Digital Library Consultant
[log in to unmask] http://www.kcoyle.net
ph.: 510-540-7596   skype: kcoylenet
fx.: 510-848-3913
mo.: 510-435-8234
------------------------------------