"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.]" Ed Jones -----Original Message----- From: Resource Description and Access / Resource Description and Access [mailto:RDA-L@LISTSERV.LAC-BAC.GC.CA] On Behalf Of Karen Coyle Sent: Thursday, January 20, 2011 8:37 AM To: RDA-L@LISTSERV.LAC-BAC.GC.CA Subject: Re: [RDA-L] Linked data Quoting Jonathan Rochkind <rochk...@jhu.edu>: > > What we need is a "data schema" (aka "data dictionary", aka "data > vocabulary") that actually semantically captures what we need to > capture. And I will again say what I have said before: I have set up a wiki page for such a project, if anyone wants to join in. I don't expect that we will be able to actually transform MARC in this informal way, but I see it as a way to explore some of the issues (like the one I brought up about the uniform title, and which I will add there). http://futurelib.pbworks.com/w/page/29114548/MARC-elements If you want to add info, comment, or edit the page, I will need to set you up with an ID, I think. Also, I'm trying to figure out how to allow comments... kc > That's the hard part, and it neccesarily will not be round-trip > backwards compatible with MARC. If we have that, whether we put it > in XML or something else doesn't matter. The serialization format > itself is, to a large extent, an implementation issue. This is my > contention. > > If you have that, then you can, as Behrnard says 'make it a snap to > extract the "title" of the piece represented, unambiguously and > independent of context inside the record that only a human reader > can unravel.' And, sure, you can do that from an XML format. Just > not AACR2-style MarcXML. > > Jonathan > >> In the light of this, what we need is a real data format. It may look >> not all that different from MARC, but it needs to be understood in >> a markedly different way (and RDA supports this view more than AACR2 in >> that it clearly leaves textual display (ISBD) outside the rules). >> What we do not need, however, is an RDB sort of format, consisting >> of a set of interrelated tables. This seems to be what Thomale >> understands best. And for many developers, RDB is synonymous with >> "database". And that's the other trap into which we ought not fall. >> >> A true format must, for one thing, make it a snap to extract the >> "title" of the piece represented, unambiguously and independent of >> context inside the record that only a human reader can unravel. >> OTOH, it will never be easy to say and pin down what the title of a >> thing is, no matter what syntax you use to record it. In MARC, the >> 245 is the most confounded element - no, textual paragraph. >> >> B.Eversberg > -- Karen Coyle kco...@kcoyle.net http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet
