<?xml version="1.0" encoding="UTF-8"?><!-- generator="wordpress/2.2.1" -->
<rss version="2.0" 
	xmlns:content="http://purl.org/rss/1.0/modules/content/">
<channel>
	<title>Comments on: Bugs in Amber</title>
	<link>http://managemetadata.org/blog/2009/11/24/bugs-in-amber/</link>
	<description>It's all about the services</description>
	<pubDate>Thu, 09 Sep 2010 14:47:07 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.2.1</generator>

	<item>
		<title>By: PabloG &#187; Blog Archive &#187; links for 2010-01-14</title>
		<link>http://managemetadata.org/blog/2009/11/24/bugs-in-amber/#comment-8696</link>
		<author>PabloG &#187; Blog Archive &#187; links for 2010-01-14</author>
		<pubDate>Fri, 15 Jan 2010 01:02:37 +0000</pubDate>
		<guid>http://managemetadata.org/blog/2009/11/24/bugs-in-amber/#comment-8696</guid>
		<description>[...] Bugs in Amber &#124; Metadata Matters (tags: bibliothèques library marc reference metadonnees economie prix loc database opendata citation critique catalogage catalogue librarian standards interoperability future oclc) [...]</description>
		<content:encoded><![CDATA[<p>[&#8230;] Bugs in Amber | Metadata Matters (tags: bibliothèques library marc reference metadonnees economie prix loc database opendata citation critique catalogage catalogue librarian standards interoperability future oclc) [&#8230;]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: R2 report analysis: Diane Hillman &#171; Alles in Ordnung</title>
		<link>http://managemetadata.org/blog/2009/11/24/bugs-in-amber/#comment-7846</link>
		<author>R2 report analysis: Diane Hillman &#171; Alles in Ordnung</author>
		<pubDate>Mon, 30 Nov 2009 21:46:41 +0000</pubDate>
		<guid>http://managemetadata.org/blog/2009/11/24/bugs-in-amber/#comment-7846</guid>
		<description>[...] R2 report analysis: Diane&#160;Hillman  Metadata Matters blog comments on R2 report [...]</description>
		<content:encoded><![CDATA[<p>[&#8230;] R2 report analysis: Diane&nbsp;Hillman  Metadata Matters blog comments on R2 report [&#8230;]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: HotStuff 2.0 &#187; Blog Archive &#187; Word of the Day: &#8220;predicts&#8221;</title>
		<link>http://managemetadata.org/blog/2009/11/24/bugs-in-amber/#comment-7829</link>
		<author>HotStuff 2.0 &#187; Blog Archive &#187; Word of the Day: &#8220;predicts&#8221;</author>
		<pubDate>Mon, 30 Nov 2009 05:06:06 +0000</pubDate>
		<guid>http://managemetadata.org/blog/2009/11/24/bugs-in-amber/#comment-7829</guid>
		<description>[...] Matters (Diane Hillmann): Bugs in Amber [web link]Planet Cataloging (25/Nov/2009)&#8220;&#8230;in the direction r2 predicts or that those [...]</description>
		<content:encoded><![CDATA[<p>[&#8230;] Matters (Diane Hillmann): Bugs in Amber [web link]Planet Cataloging (25/Nov/2009)&#8220;&#8230;in the direction r2 predicts or that those [&#8230;]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jennifer Eustis</title>
		<link>http://managemetadata.org/blog/2009/11/24/bugs-in-amber/#comment-7812</link>
		<author>Jennifer Eustis</author>
		<pubDate>Sun, 29 Nov 2009 15:34:14 +0000</pubDate>
		<guid>http://managemetadata.org/blog/2009/11/24/bugs-in-amber/#comment-7812</guid>
		<description>I've noticed that some of my fellow catalogers don't want to add too many improvements to OCLC master records or share information on OCLC because of their distrust about what OCLC will do with that data. So many edit local records or wait to copy catalog an item instead of creating an original record. 

I feel that there has to be a better solution than OCLC and MARC21 to share cataloging records. A solution that is in part not based on a business model that prohibits sharing all together. In this sense, several digital library initiatives are a good start. I also think that using catalogers' skills for metadata in digital library initiatives is a testament that professionals can change and still remain relevant.</description>
		<content:encoded><![CDATA[<p>I&#8217;ve noticed that some of my fellow catalogers don&#8217;t want to add too many improvements to OCLC master records or share information on OCLC because of their distrust about what OCLC will do with that data. So many edit local records or wait to copy catalog an item instead of creating an original record. </p>
<p>I feel that there has to be a better solution than OCLC and MARC21 to share cataloging records. A solution that is in part not based on a business model that prohibits sharing all together. In this sense, several digital library initiatives are a good start. I also think that using catalogers&#8217; skills for metadata in digital library initiatives is a testament that professionals can change and still remain relevant.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Karen Coyle</title>
		<link>http://managemetadata.org/blog/2009/11/24/bugs-in-amber/#comment-7729</link>
		<author>Karen Coyle</author>
		<pubDate>Wed, 25 Nov 2009 22:36:52 +0000</pubDate>
		<guid>http://managemetadata.org/blog/2009/11/24/bugs-in-amber/#comment-7729</guid>
		<description>Diane, 

I found the report as interesting for what it &lt;em&gt;didn&lt;/em&gt;'t say than for what it did. (I don't blame R2 for this... I believe they were given a particular task by LC and did it.)

They didn't do any analysis of who really benefits from LC data. I think if they had, OCLC would have come out on top. Since LC records are the ones most sought-after for copy cataloging, it stands to reason that there are multiple uses of LC's original records on OCLC, and that OCLC makes money off of each use. (As did RLG, WLN and others while they existed.) So while it is true that members of the library community are benefiting from LC's cataloging, a number of those members are also paying for it, but not paying LC, and the cataloging services haven't returned any part of their earnings to LC for this use (AFAIK). 

As you mention, they didn't question whether "MARC records" is even the right question. Somehow it seems obvious that we have to address the fact that we have a bibliographic data format that is so onerous that libraries prefer to wait for an average of 3-6 months for copy cataloging to become available rather than create a record (p. 12)! Think of what those 3-6 months in which an item isn't visible in the catalog mean to user service.

The part that got to me the most, however, was the statement that 80% of libraries feel a need to edit copy that they do receive. Only 50% of those edits are 're-shared' (p.7). I was surprised to see that none of the respondents cited cost as a reason for not re-uploading their changes, but in looking at the original survey, cost was &lt;em&gt;not&lt;/em&gt; one of the options provided for selection. I find this curious, since to my knowledge cost is a reason why many edits do not go back to OCLC. Clearly having a way that the sharing of edits is technologically seamless and not a financial burden is a key element to increased sharing and better overall cataloging efficiency.</description>
		<content:encoded><![CDATA[<p>Diane, </p>
<p>I found the report as interesting for what it <em>didn</em>&#8216;t say than for what it did. (I don&#8217;t blame R2 for this&#8230; I believe they were given a particular task by LC and did it.)</p>
<p>They didn&#8217;t do any analysis of who really benefits from LC data. I think if they had, OCLC would have come out on top. Since LC records are the ones most sought-after for copy cataloging, it stands to reason that there are multiple uses of LC&#8217;s original records on OCLC, and that OCLC makes money off of each use. (As did RLG, WLN and others while they existed.) So while it is true that members of the library community are benefiting from LC&#8217;s cataloging, a number of those members are also paying for it, but not paying LC, and the cataloging services haven&#8217;t returned any part of their earnings to LC for this use (AFAIK). </p>
<p>As you mention, they didn&#8217;t question whether &#8220;MARC records&#8221; is even the right question. Somehow it seems obvious that we have to address the fact that we have a bibliographic data format that is so onerous that libraries prefer to wait for an average of 3-6 months for copy cataloging to become available rather than create a record (p. 12)! Think of what those 3-6 months in which an item isn&#8217;t visible in the catalog mean to user service.</p>
<p>The part that got to me the most, however, was the statement that 80% of libraries feel a need to edit copy that they do receive. Only 50% of those edits are &#8216;re-shared&#8217; (p.7). I was surprised to see that none of the respondents cited cost as a reason for not re-uploading their changes, but in looking at the original survey, cost was <em>not</em> one of the options provided for selection. I find this curious, since to my knowledge cost is a reason why many edits do not go back to OCLC. Clearly having a way that the sharing of edits is technologically seamless and not a financial burden is a key element to increased sharing and better overall cataloging efficiency.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Bryan</title>
		<link>http://managemetadata.org/blog/2009/11/24/bugs-in-amber/#comment-7727</link>
		<author>Bryan</author>
		<pubDate>Wed, 25 Nov 2009 22:18:39 +0000</pubDate>
		<guid>http://managemetadata.org/blog/2009/11/24/bugs-in-amber/#comment-7727</guid>
		<description>Based on what I have seen from OCLC Research (CrossWalk Web Service and CDF; http://bit.ly/8vI6pX), maybe the “also output as” option, as you put it, will be here sooner than we all think.</description>
		<content:encoded><![CDATA[<p>Based on what I have seen from OCLC Research (CrossWalk Web Service and CDF; <a href="http://bit.ly/8vI6pX" rel="nofollow">http://bit.ly/8vI6pX</a>), maybe the “also output as” option, as you put it, will be here sooner than we all think.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Diane Hillmann</title>
		<link>http://managemetadata.org/blog/2009/11/24/bugs-in-amber/#comment-7726</link>
		<author>Diane Hillmann</author>
		<pubDate>Wed, 25 Nov 2009 22:08:51 +0000</pubDate>
		<guid>http://managemetadata.org/blog/2009/11/24/bugs-in-amber/#comment-7726</guid>
		<description>Bryan, I just don't know.  I suspect that we'll be using it to some extent for another decade, at least, but that's just wild guesswork. More interesting to me is when the tipping point comes for RDA--that moment when we stop worrying about MARC and are willing to see it be an "also output as" option. This depends to a great extent on whether vendors (all kinds) start making it possible to use RDA "natively."  There are a few forward thinking vendors working on making that a reality, but I've no idea when those RDA-aware products will hit the streets.</description>
		<content:encoded><![CDATA[<p>Bryan, I just don&#8217;t know.  I suspect that we&#8217;ll be using it to some extent for another decade, at least, but that&#8217;s just wild guesswork. More interesting to me is when the tipping point comes for RDA&#8211;that moment when we stop worrying about MARC and are willing to see it be an &#8220;also output as&#8221; option. This depends to a great extent on whether vendors (all kinds) start making it possible to use RDA &#8220;natively.&#8221;  There are a few forward thinking vendors working on making that a reality, but I&#8217;ve no idea when those RDA-aware products will hit the streets.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Bryan</title>
		<link>http://managemetadata.org/blog/2009/11/24/bugs-in-amber/#comment-7724</link>
		<author>Bryan</author>
		<pubDate>Wed, 25 Nov 2009 20:43:42 +0000</pubDate>
		<guid>http://managemetadata.org/blog/2009/11/24/bugs-in-amber/#comment-7724</guid>
		<description>You wrote that "I agree that MARC will indeed be used by libraries for some time, but as a lossy exchange format, not the lynchpin of the library data world."

Would you be willing to put a number to  "for some time"?  5, 10, 15 years?</description>
		<content:encoded><![CDATA[<p>You wrote that &#8220;I agree that MARC will indeed be used by libraries for some time, but as a lossy exchange format, not the lynchpin of the library data world.&#8221;</p>
<p>Would you be willing to put a number to  &#8220;for some time&#8221;?  5, 10, 15 years?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: anna h</title>
		<link>http://managemetadata.org/blog/2009/11/24/bugs-in-amber/#comment-7721</link>
		<author>anna h</author>
		<pubDate>Wed, 25 Nov 2009 17:44:22 +0000</pubDate>
		<guid>http://managemetadata.org/blog/2009/11/24/bugs-in-amber/#comment-7721</guid>
		<description>good post; thanks.</description>
		<content:encoded><![CDATA[<p>good post; thanks.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jodi Schneider</title>
		<link>http://managemetadata.org/blog/2009/11/24/bugs-in-amber/#comment-7715</link>
		<author>Jodi Schneider</author>
		<pubDate>Wed, 25 Nov 2009 11:29:14 +0000</pubDate>
		<guid>http://managemetadata.org/blog/2009/11/24/bugs-in-amber/#comment-7715</guid>
		<description>Thanks, Diane, for this insightful commentary. I'm truly shocked at the perspectives from R2, particularly about sharing as "bad business".

From that perspective, isn't borrowing a book (which the borrowers haven't paid for) bad business as well?

Reuse of library data outside the library silo should be a huge goal of our community. I really admire your tirelessness in bringing linked data and library metadata communities to the same table.</description>
		<content:encoded><![CDATA[<p>Thanks, Diane, for this insightful commentary. I&#8217;m truly shocked at the perspectives from R2, particularly about sharing as &#8220;bad business&#8221;.</p>
<p>From that perspective, isn&#8217;t borrowing a book (which the borrowers haven&#8217;t paid for) bad business as well?</p>
<p>Reuse of library data outside the library silo should be a huge goal of our community. I really admire your tirelessness in bringing linked data and library metadata communities to the same table.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
