 |
 |
Straight translations from MARC to [anything else] don't make sense unless you analyze not just the MARC coding but the intention and meaning behind the data element. (I covered this is in a code4lib journal article, to some extent.[1]) That some bit of data was broken up in a certain way in MARC is not necessarily meaningful in other situations. Title is a good example, and Thomale shows how hard it is to make sense based on MARC subfields.[2] One other example is personal author: the x00 field has a dozen or more subfields to encoding personal author data. In other MARC fields, all of that information is placed in a single subfield (because of the limit of 26 data subfields per tag). *100 **$a*Hamilton, Milton W. $q(Milton Wheaton), $d1901-** *773* *****$a*Hamilton, Milton W. (Milton Wheaton), 1901-** Yet one of the biggest problems in translating MARC to [anything else] is that because the data has only been expressed as text strings, no consistency checking has been done on the content. That 245 $p could have anything at all in it, including Aunt Martha's apple pie recipe. Developing a future format based on this data is a formula for failure, I'm afraid. Yes, we will need to translate our old data to some new form, but that is not the same as developing a new format intended to mimic the data of old one. kc [1] http://journal.code4lib.org/articles/5468 "MARC21 as Data: A Start" [2] http://journal.code4lib.org/articles/3832 "Interpreting MARC: Where's the Bibliographic Data?" On 7/25/14, 9:30 AM, Robert Sanderson wrote: > > +1 to all of these :) And to add: > > 0) http://bibframe.org/vocab/Title.html > > Do we need a title resource at all, or is a string sufficient? > > > On Fri, Jul 25, 2014 at 8:28 AM, [log in to unmask] > <mailto:[log in to unmask]> <[log in to unmask] > <mailto:[log in to unmask]>> wrote: > > Having now for the first time taken a close look at bf:Title, I'm > a bit taken aback. > 1) http://bibframe.org/vocab/titleValue.html: "Title being addressed." > > > According to my deproliferation, I read this as "value". And hence > the actual string that's being turned into a resource. > If there's a need for a bf:Title (per 0) then there's a need for the > value. > > I think the question is, if there is a need, is this the entire title > or only some part of it that's being decomposed into the resource. > > Otherwise ... > > What is the purpose of this specialized property in the face of > the bf:label that is available to all bf:Resources? What would > cause someone to use it? Is this just MARC 2045$a in a new format? > > > Yes. Or is it $a plus $b? Or does $b go in partTitle, but then where > does $p go? If we're recomposing, lets do it right :) > > 1.5) http://bibframe.org/vocab/title.html and > http://bibframe.org/vocab/titleStatement.html > > What about getting rid of bf:title and bf:titleStatement, and just > using bf:label? Quite independently of any other decision regarding > titles as resources and their attributes. > > 2) http://bibframe.org/vocab/titleQualifier.html: "Qualifier of > title information to make it unique." > > Working for the uniqueness of labels goes very much against the > practice of Linked Data. The Title entity is already possessed of > an identifier. If anything more is needed to ensure uniqueness, > isn't something badly wrong with the identifier? > > > +1. As currently described, titleQualifier seems to do more harm than > good. There's no example, so it's hard to tell exactly what's going on. > > Is this just 245 $v? > > 3) http://bibframe.org/vocab/partNumber.html and > http://bibframe.org/vocab/partTitle.html > > Is there any purpose to this distinction or is this just a case of > MARC 245$n and $p being mechanically preserved? In fact these two > properties have the same range. > > > +1. If partNumber is really a number (which I don't think it is, as > $n can hold "Part One") then it could be xsd:integer. Can a single > title have both a partNumber and a partTitle? > > 3.5) See question about $b > > 4) http://bibframe.org/vocab/formDesignation.html: "Class or genre > to which a Work or Instance belongs." > and > http://bibframe.org/vocab/titleAttribute.html: "Other > distinguishing characteristic of a work, such as version, etc.." > > These seem very strange to me. In what way are these properties of > a title at all? Is this just a mechanical transfer from MARC 245$k > and $s? This seems to be information that should be recorded on > the Work or Instance. > > > In order and in my opinion: No, Yes, Definitely :) > > Same with copyright from Provider? (Or better decompose provider back > on to the Instance) > > Rob -- Karen Coyle [log in to unmask] http://kcoyle.net m: 1-510-435-8234 skype: kcoylenet