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.


[1] "MARC21 as Data: A Start"
[2] "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)
> 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) "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) and 
> 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) "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) and
>     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) "Class or genre
>     to which a Work or Instance belongs."
>     and
> "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]
m: 1-510-435-8234
skype: kcoylenet