Francis Lapka wrote:
I have what is probably a naïve question, touching on RDA and BIBFRAME. I'll preface the question with an example. Imagine a resource with the following title page: " An heroic epistle to an unfortunate monarch, by Peregrine the Elder. Enriched with explanatory notes. The second edition. London: Published in the year MDCCLXXVIII by E. Benson " Let's suppose that a cataloger encoded the data in one of the following (imaginary) schemes: Encoding 1 <titleStatement>An heroic epistle to an unfortunate monarch, by Peregrine the Elder. Enriched with explanatory notes.</titleStatement> <editionStatement>The second edition.</edition> <imprint>London: Published in the year MDCCLXXVIII by E. Benson</imprint> Encoding 2 <titlePage> An heroic epistle to an unfortunate monarch, by Peregrine the Elder. Enriched with explanatory notes. The second edition. London: Published in the year MDCCLXXVIII by E. Benson </titlePage> Would these encodings be considered valid RDA cataloging for the elements covered in the example? That is, would these encodings satisfy the RDA core requirements for Title, Statement of Responsibility, Edition statement, and Publication statement? All of the required data is included, but it is not encoded in parsed fields equivalent to RDA elements. Does this make it invalid? If not, would it be reasonable to expect BIBFRAME to accommodate (or play well with) encoding scenarios such as these? Later responding: In these encoding scenarios, the entities that we want to treat as *data* would be handled in distinct fields, separate from the transcription. For an imprint we could augment the transcription with separate data elements, such as: <hasPlaceOfPublication>tgn7011781</hasPlaceOfPublication> <hasPublisher>http://id.loc.gov/authorities/names/n50028787</hasPublisher<http://id.loc.gov/authorities/names/n50028787%3c/hasPublisher>> <hasPublicationDate>1788</hasPublicationDate> As stated, while the proffered examples RECORD the data that RDA specifies, they do not ENCODE, as such, the actual elements required for an RDA record. RDA has separate CORE elements for Title, for Statement of Responsibility, for Edition Statement, and for Publication Statement, with the latter having CORE sub-elements of Place of Publication, Publisher's Name, and Date of Publication. One could not ask of the encoding in either of these examples to identify most of these RDA elements, with the exception of Edition Statement in the first encoding. Which is a long, drawn out explanation leading to the conclusion that, no, these would not be valid RDA encodings. The closing question posed is a pertinent one though - how flexible will/should BIBFRAME be with respect to addressing alternative descriptive cataloging standards from RDA and alternative models from FRBR? I more than suspect this need for flexibility underlies the modification from FRBR in creating BibFrame Works, BibFrame Instances, BibFrame Authorities, and BibFrame Notations. Within the actual tagging structure, the use of wrapper tags for groupings of tags would only be applicable, in an RDA context, where RDA subordinates sub-elements to larger elements. The use of <titlePage> as a wrapper would not work, as RDA does not require the data contained therein from this specific example to be uniformly sourced from the "title page" of all resource (setting aside the issue that "title page" is specific to print resources). Entire parallel structures of tags would potentially need to be developed if required for separate descriptive standards. And we would not have to look far to see this play out as we tried to encompass RDA and AACR2's approaches to publication data within a single scheme - currently dealt with by the separate MARC tags of 264 and 260. Roy Tennant was working on something like this a few years back - I remember him presenting at the (Metadata?) Interest Group session at ALA Midwinter in Boston. He had been experimenting with a meta-scheme that would pull information from a variety of schema and wrap each scheme's contribution in a set of wrapper tags identifying the data as coming from the respective scheme (which is an approach different from the simple scenario torpedoed above). And to the subsequent reply, I agree that there is considerable tension between our desire to accurately describe our resources and effectively provide access to them in our online environment. In cards, the only access was through the controlled points we created; every other detail was subordinated to the descriptive function provided by the researcher visually scanning the card. The online environment makes our descriptive elements available for access, subject though to the vagaries and inconsistencies of publisher and cataloger practices. My sense, since being exposed to XML, has been that that the solution to the controlled access we seek is to embed the controlled forms (or rather the links to the corresponding controlled vocabulary terms) as an attribute within the opening tag, while the tag pair encloses the transcribed data. That is, to draw from the example: <hasPlaceOfPublication a=tgn7011781>London</hasPlaceOfPublication>. It's the one possibility within an XML-type scheme that I prefer over a Linked Data/RDF scheme. I am confident the relationships between resource and descriptive element, and descriptive element to controlled form could be devised in RDF, but the complexity of creating and compiling those connections is daunting to my brain at this point. John F. Myers, Catalog Librarian Schaffer Library, Union College Schenectady NY 12308 mye...@union.edu<mailto:mye...@union.edu> 518-388-6623
