Karen, Add to your list: - parallel titles - subsequent titles (on source, without collective title) - edition statement - series statement - parallel data for all of the above
But I don't think this approach will work if you want software to generate the ISBD punctuation; in which case you need more granluarity, not less. Deborah ------ Deborah Fritz MARC Database Consultant The MARC of Quality www.marcofquality.com Voice/Fax: (321) 676-1904 > -----Original Message----- > From: Resource Description and Access / Resource Description > and Access [mailto:[email protected]] On Behalf Of > Karen Coyle > Sent: Thursday, February 03, 2011 11:17 AM > To: [email protected] > Subject: Re: [RDA-L] Linked data > > Ed, that is a very interesting approach. If we treat > > New York, NY, Random House, c1998 > > as a simple string with no data "capabilities" it also > emphasizes those areas where we would need to create > separately actual data if we wish to provide services, e.g. > around place or date. In fact, this is approximately what > MARC already does by having data in fixed fields that > replicates information that is either transcribed or purely > textual. Taking this further, the entire set of transcribed > elements, from title proper through date, could be considered > a single unit, ISBD encoded for display. Everything else > could be represented as separate data elements. > > The downside to this is that it requires some information to > be coded and carried twice - once as text and once as data. > The way to satisfy both data and display considerations is to > generate displays from data (the other way around doesn't > work). So a coded date that represents a copyright date could > be displayed as "c1998". > > It seems to me that the number of strictly transcribed fields > is very small. Is this a full list? > > - title proper > - subtitle > - statement of responsibility > - place > - publisher > > kc > > Quoting Ed Jones <[email protected]>: > > > "What we need to capture" may be the key phrase here. There > are some > > MARC fields that would not suffer a loss of information if > they were > > treated as single elements. For example, while the 260 > field consists > > of several separately delimited elements, these elements are all > > transcribed (more or less) and the transcribed data is by > definition > > non-standard, dependent entirely on what appears on the source from > > which they are transcribed. From a machine (or Semantic > > Web) point of view, treating such component elements > separately just > > introduces a temptation to treat them as though the data they > > contained was standardized in some way and so reliable for creating > > record sets. Treating these transcribed fields as single elements > > would also obviate the need for relating them to one another in RDA > > triplets. If the information in one of the subfields in a > transcribed > > field is really considered useful for creating record sets, > it should > > be coded separately in a standardized way elsewhere in the record. > > Otherwise, something like the following should > > suffice: > > > > http://lccn.loc.gov/75647252, > http://marc21.info/element/260, "[New > > York, etc. Elsevier Inc., etc.]"
