<?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: Can something be abstract and not have the property of being abstract?</title>
	<atom:link href="http://marklindner.info/blog/2007/01/09/can-something-be-abstract-and-not-have-the-property-of-being-abstract/feed/" rel="self" type="application/rss+xml" />
	<link>http://marklindner.info/blog/2007/01/09/can-something-be-abstract-and-not-have-the-property-of-being-abstract/</link>
	<description>Palmer, CL. “Structures and strategies of interdisciplinary science.”  JASIS 50(3): 242-253, 1999</description>
	<lastBuildDate>Tue, 10 Apr 2012 15:15:46 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	
	<item>
		<title>By: Mark</title>
		<link>http://marklindner.info/blog/2007/01/09/can-something-be-abstract-and-not-have-the-property-of-being-abstract/comment-page-1/#comment-1784</link>
		<dc:creator>Mark</dc:creator>
		<pubDate>Wed, 10 Jan 2007 04:52:56 +0000</pubDate>
		<guid isPermaLink="false">http://marklindner.info/blog/2007/01/09/can-something-be-abstract-and-not-have-the-property-of-being-abstract/#comment-1784</guid>
		<description>Hi Steve and thanks for the reply.  I do agree, in a sense, with both views.  

And I most certainly agree with you that FRBR (or something like it) needs to be pragmatically implementable!  There is no point in doing this just because some theory says so.

But I also know that Renear and Choi are trying to help make FRBR just that.  Allen Renear is one of the biggest supporters of FRBR that we have at UIUC.  He does guest lectures in most any class that talks about it.  And he leaves out (most of) the high minded philosophical abstractions when he does.

But the bottom line is that FRBR is an entity-relation model, and as such is a philosophical work that needs to cohere.  In the end, some of the finer philosophical points may not matter.  But to find that out we need both analysis and real implementations, both of which feed each other.

We also need thoughtful folks like you questioning the questioner(s).  Thanks again.</description>
		<content:encoded><![CDATA[<p>Hi Steve and thanks for the reply.  I do agree, in a sense, with both views.  </p>
<p>And I most certainly agree with you that FRBR (or something like it) needs to be pragmatically implementable!  There is no point in doing this just because some theory says so.</p>
<p>But I also know that Renear and Choi are trying to help make FRBR just that.  Allen Renear is one of the biggest supporters of FRBR that we have at UIUC.  He does guest lectures in most any class that talks about it.  And he leaves out (most of) the high minded philosophical abstractions when he does.</p>
<p>But the bottom line is that FRBR is an entity-relation model, and as such is a philosophical work that needs to cohere.  In the end, some of the finer philosophical points may not matter.  But to find that out we need both analysis and real implementations, both of which feed each other.</p>
<p>We also need thoughtful folks like you questioning the questioner(s).  Thanks again.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Steve</title>
		<link>http://marklindner.info/blog/2007/01/09/can-something-be-abstract-and-not-have-the-property-of-being-abstract/comment-page-1/#comment-1782</link>
		<dc:creator>Steve</dc:creator>
		<pubDate>Wed, 10 Jan 2007 04:23:06 +0000</pubDate>
		<guid isPermaLink="false">http://marklindner.info/blog/2007/01/09/can-something-be-abstract-and-not-have-the-property-of-being-abstract/#comment-1782</guid>
		<description>Hello, Mark. Apologies for the commenting confusion, we shut comments down due to spam since anyone who seems to link to our posts (as in the case of your link) seems to automatically create a trackback on our blog. Plus, we never really thought anyone would find, much less read, our conversations...

Your comments gel with some of my own trepidation about writing the post in the first place. In the end I convinced myself that when a work is an abstact entity, it is abstract insofar as it is a conceptual model. That is to say that its abstraction/abstractness applies more to the model than the thing it is modeling and this is what I was getting at in stating that a work is an abstract model but Hamlet the work does not have the property of abstractness. 

&quot;Hamlet the work&quot; is a conceptual model in the same way that a clay sculpture of a car is a physical model of a car. In both cases I believe the model is a concrete thing even though it abstracts the thing it describes. This is where I was disagreeing with Renear/Choi and siding with Coyle&#039;s intuition about metadata. 

In the end I think that FRBR must be rooted in implementation rather than theory: it must find its way past philosophers and librarians and prove to be beneficial to normal people looking to find bibliographic things. In this way I think that works, abstract entities though they may be, will have concrete properties when they are represented in what everyone seems to like to call these days the &quot;next generation catalog.&quot;

As I write this I wonder whether a work is not abstract, but closer to the programmer&#039;s concept of an interface: a model or type that is not yet developed enough to be instantiable, let alone instantiated. You can think of this like a framework: a blueprint for a blueprint.</description>
		<content:encoded><![CDATA[<p>Hello, Mark. Apologies for the commenting confusion, we shut comments down due to spam since anyone who seems to link to our posts (as in the case of your link) seems to automatically create a trackback on our blog. Plus, we never really thought anyone would find, much less read, our conversations&#8230;</p>
<p>Your comments gel with some of my own trepidation about writing the post in the first place. In the end I convinced myself that when a work is an abstact entity, it is abstract insofar as it is a conceptual model. That is to say that its abstraction/abstractness applies more to the model than the thing it is modeling and this is what I was getting at in stating that a work is an abstract model but Hamlet the work does not have the property of abstractness. </p>
<p>&#8220;Hamlet the work&#8221; is a conceptual model in the same way that a clay sculpture of a car is a physical model of a car. In both cases I believe the model is a concrete thing even though it abstracts the thing it describes. This is where I was disagreeing with Renear/Choi and siding with Coyle&#8217;s intuition about metadata. </p>
<p>In the end I think that FRBR must be rooted in implementation rather than theory: it must find its way past philosophers and librarians and prove to be beneficial to normal people looking to find bibliographic things. In this way I think that works, abstract entities though they may be, will have concrete properties when they are represented in what everyone seems to like to call these days the &#8220;next generation catalog.&#8221;</p>
<p>As I write this I wonder whether a work is not abstract, but closer to the programmer&#8217;s concept of an interface: a model or type that is not yet developed enough to be instantiable, let alone instantiated. You can think of this like a framework: a blueprint for a blueprint.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

