<?xml version="1.0" encoding="utf-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	>
<channel>
	<title>Comments on: Plugging Into FRBR, Killing MARC</title>
	<atom:link href="http://community.muohio.edu/blogs/darcusb/archives/2006/09/11/plugging-into-frbr-killing-marc/feed" rel="self" type="application/rss+xml" />
	<link>http://community.muohio.edu/blogs/darcusb/archives/2006/09/11/plugging-into-frbr-killing-marc</link>
	<description>geek tools and the scholar</description>
	<pubDate>Mon, 23 Nov 2009 00:24:27 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.7</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: darcusblog &#187; Blog Archive &#187; OpenFRBR</title>
		<link>http://community.muohio.edu/blogs/darcusb/archives/2006/09/11/plugging-into-frbr-killing-marc/comment-page-1#comment-929</link>
		<dc:creator>darcusblog &#187; Blog Archive &#187; OpenFRBR</dc:creator>
		<pubDate>Wed, 29 Nov 2006 02:16:14 +0000</pubDate>
		<guid isPermaLink="false">http://netapps.muohio.edu/blogs/darcusb/darcusb/archives/2006/09/11/plugging-into-frbr-killing-marc#comment-929</guid>
		<description>&lt;p&gt;[...] Also, the main site page promises a standard format for other systems to use. If I may be so bold, I&#8217;d avoid using existing library standards to represent this sort of metadata, which will be both needlessly complicated, and frustratingly limited. As I&#8217;ve mentioned before, RDF is perfectly suited to this sort of use case, particularly given there is already a very good representation of FRBR. [...]&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p>[...] Also, the main site page promises a standard format for other systems to use. If I may be so bold, I&#8217;d avoid using existing library standards to represent this sort of metadata, which will be both needlessly complicated, and frustratingly limited. As I&#8217;ve mentioned before, RDF is perfectly suited to this sort of use case, particularly given there is already a very good representation of FRBR. [...]</p>]]></content:encoded>
	</item>
	<item>
		<title>By: Some Quickies for Oct 16 2006 at ebyblog</title>
		<link>http://community.muohio.edu/blogs/darcusb/archives/2006/09/11/plugging-into-frbr-killing-marc/comment-page-1#comment-897</link>
		<dc:creator>Some Quickies for Oct 16 2006 at ebyblog</dc:creator>
		<pubDate>Mon, 16 Oct 2006 02:51:42 +0000</pubDate>
		<guid isPermaLink="false">http://netapps.muohio.edu/blogs/darcusb/darcusb/archives/2006/09/11/plugging-into-frbr-killing-marc#comment-897</guid>
		<description>&lt;p&gt;[...] Darcus talks about RDF and FRBR and the death of MARC [...]&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p>[...] Darcus talks about RDF and FRBR and the death of MARC [...]</p>]]></content:encoded>
	</item>
	<item>
		<title>By: Bruce D'Arcus</title>
		<link>http://community.muohio.edu/blogs/darcusb/archives/2006/09/11/plugging-into-frbr-killing-marc/comment-page-1#comment-849</link>
		<dc:creator>Bruce D'Arcus</dc:creator>
		<pubDate>Tue, 12 Sep 2006 13:28:31 +0000</pubDate>
		<guid isPermaLink="false">http://netapps.muohio.edu/blogs/darcusb/darcusb/archives/2006/09/11/plugging-into-frbr-killing-marc#comment-849</guid>
		<description>&lt;p&gt;Hi Jonathan -- &lt;/p&gt;

&lt;p&gt;Let's take an example: titles. How does one distinguish a uniform title, from an abbrviated title, from a trnasliterated title in a relatively "simple" format like MODS? You have one complex XML structure, with four or five elements, and variety of attributes. That complex XML structure is designed to basically say "all of these are tiles."&lt;/p&gt;

&lt;p&gt;OK, but when you deal with complex data, you end up with quite complex XML; data which is simply difficult to work with.&lt;/p&gt;

&lt;p&gt;What if instead you just gave each separate URIs ...&lt;/p&gt;

&lt;p&gt;http:loc.gov/standard/mng/title
http:loc.gov/standard/mng/abbreviatedTitle
http:loc.gov/standard/mng/transliteratedTitle&lt;/p&gt;

&lt;p&gt;[let's not worry about details, because the above is likely not quite right; but I'm sure you get the idea]&lt;/p&gt;

&lt;p&gt;In RDF/XML, you then end up with three different elements  You define the relations between them (that the last two are sub-properties of the first) in a separate RDF/OWL schema.&lt;/p&gt;

&lt;p&gt;In essence, you separate out the concerns (encoding and semantics).&lt;/p&gt;

&lt;p&gt;Another example is the constant use of the uncontrolled authority attribute in MODS and MADS.  Again, more complicated (and losely-controlled) XML to do work that can be done more easily and precisely.  We live in the 21st century, with a huge HTTP and URI infrastructure; so use it.&lt;/p&gt;

&lt;p&gt;&#60;mng:subject rdf:resource="http://loc.gov/topics/x"/&#62;&lt;/p&gt;

&lt;p&gt;Did I answer your question?&lt;/p&gt;

&lt;p&gt;Bruce&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p>Hi Jonathan &#8212; </p>

<p>Let&#8217;s take an example: titles. How does one distinguish a uniform title, from an abbrviated title, from a trnasliterated title in a relatively &#8220;simple&#8221; format like MODS? You have one complex XML structure, with four or five elements, and variety of attributes. That complex XML structure is designed to basically say &#8220;all of these are tiles.&#8221;</p>

<p>OK, but when you deal with complex data, you end up with quite complex XML; data which is simply difficult to work with.</p>

<p>What if instead you just gave each separate URIs &#8230;</p>

<p>http:loc.gov/standard/mng/title
http:loc.gov/standard/mng/abbreviatedTitle
http:loc.gov/standard/mng/transliteratedTitle</p>

<p>[let's not worry about details, because the above is likely not quite right; but I'm sure you get the idea]</p>

<p>In RDF/XML, you then end up with three different elements  You define the relations between them (that the last two are sub-properties of the first) in a separate RDF/OWL schema.</p>

<p>In essence, you separate out the concerns (encoding and semantics).</p>

<p>Another example is the constant use of the uncontrolled authority attribute in MODS and MADS.  Again, more complicated (and losely-controlled) XML to do work that can be done more easily and precisely.  We live in the 21st century, with a huge HTTP and URI infrastructure; so use it.</p>

<p>&lt;mng:subject rdf:resource=&#8221;http://loc.gov/topics/x&#8221;/&gt;</p>

<p>Did I answer your question?</p>

<p>Bruce</p>]]></content:encoded>
	</item>
	<item>
		<title>By: Jonathan</title>
		<link>http://community.muohio.edu/blogs/darcusb/archives/2006/09/11/plugging-into-frbr-killing-marc/comment-page-1#comment-848</link>
		<dc:creator>Jonathan</dc:creator>
		<pubDate>Tue, 12 Sep 2006 13:10:27 +0000</pubDate>
		<guid isPermaLink="false">http://netapps.muohio.edu/blogs/darcusb/darcusb/archives/2006/09/11/plugging-into-frbr-killing-marc#comment-848</guid>
		<description>&lt;p&gt;Hmm, you seem to be implying in the last paragraph that it's possible to still include meaning as rich as we need it (as rich as what's in current MARC (even if that meaning isn't generally used by systems, another issue) in a format as simple as DC. "tendency to overburden the formats themselves with the task of carrying meaning."  So your suggestion is that there's a way to pack all this meaning in, but not in the "formats themselves". &lt;/p&gt;

&lt;p&gt;I'm not following how you do this.&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p>Hmm, you seem to be implying in the last paragraph that it&#8217;s possible to still include meaning as rich as we need it (as rich as what&#8217;s in current MARC (even if that meaning isn&#8217;t generally used by systems, another issue) in a format as simple as DC. &#8220;tendency to overburden the formats themselves with the task of carrying meaning.&#8221;  So your suggestion is that there&#8217;s a way to pack all this meaning in, but not in the &#8220;formats themselves&#8221;. </p>

<p>I&#8217;m not following how you do this.</p>]]></content:encoded>
	</item>
</channel>
</rss>
