<?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 for ptsefton</title>
	<atom:link href="http://ptsefton.com/comments/feed" rel="self" type="application/rss+xml" />
	<link>http://ptsefton.com</link>
	<description>This seems to be a workblog</description>
	<lastBuildDate>Sun, 14 Mar 2010 23:00:54 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>Comment on Back to the wordprocessor by Paul McKey</title>
		<link>http://ptsefton.com/2010/03/09/back-to-the-wordprocessor.htm/comment-page-1#comment-1837</link>
		<dc:creator>Paul McKey</dc:creator>
		<pubDate>Sun, 14 Mar 2010 23:00:54 +0000</pubDate>
		<guid isPermaLink="false">http://ptsefton.com/2010/03/09/back-to-the-wordprocessor.htm#comment-1837</guid>
		<description>aaaaah this so refreshing. Your words spill over me like the falling dew of a misty morn.

So you are saying even I might be able to use this stuff one day soon? I understand the term Word Processor!</description>
		<content:encoded><![CDATA[<p>aaaaah this so refreshing. Your words spill over me like the falling dew of a misty morn.</p>
<p>So you are saying even I might be able to use this stuff one day soon? I understand the term Word Processor!</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on More details on a metdata store for data in/alongside VITAL by robert forkel</title>
		<link>http://ptsefton.com/2010/03/04/more-details-on-a-metdata-store-for-data-inalongside-vital.htm/comment-page-1#comment-1827</link>
		<dc:creator>robert forkel</dc:creator>
		<pubDate>Fri, 12 Mar 2010 07:41:20 +0000</pubDate>
		<guid isPermaLink="false">http://ptsefton.com/2010/03/04/more-details-on-a-metdata-store-for-data-inalongside-vital.htm#comment-1827</guid>
		<description>i&#039;d agree that a system explicitely - and exclusively - handling the task of maintaining redirects would be preferable to RewriteRules scattered around various apache config files. but my experience is that you&#039;ll have the latter anyway, in which case the handle system just adds complexity.</description>
		<content:encoded><![CDATA[<p>i&#8217;d agree that a system explicitely &#8211; and exclusively &#8211; handling the task of maintaining redirects would be preferable to RewriteRules scattered around various apache config files. but my experience is that you&#8217;ll have the latter anyway, in which case the handle system just adds complexity.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on More details on a metdata store for data in/alongside VITAL by Scott Yeadon</title>
		<link>http://ptsefton.com/2010/03/04/more-details-on-a-metdata-store-for-data-inalongside-vital.htm/comment-page-1#comment-1823</link>
		<dc:creator>Scott Yeadon</dc:creator>
		<pubDate>Thu, 11 Mar 2010 21:53:10 +0000</pubDate>
		<guid isPermaLink="false">http://ptsefton.com/2010/03/04/more-details-on-a-metdata-store-for-data-inalongside-vital.htm#comment-1823</guid>
		<description>I think this is beyond redirection (which I immediately think HTTP redirect) and into the handle resolution space. I think PILIN looked at something similar in their work where you could request a particular format or version depending on some context information. You could use fixed index values for storing particular values or value types so you could resolve to an immediate known value, or bring up a list of available values for the user to select from. Scenarios like this is where stuff gets interesting and goes beyond basic resolution.</description>
		<content:encoded><![CDATA[<p>I think this is beyond redirection (which I immediately think HTTP redirect) and into the handle resolution space. I think PILIN looked at something similar in their work where you could request a particular format or version depending on some context information. You could use fixed index values for storing particular values or value types so you could resolve to an immediate known value, or bring up a list of available values for the user to select from. Scenarios like this is where stuff gets interesting and goes beyond basic resolution.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on More details on a metdata store for data in/alongside VITAL by Scott Yeadon</title>
		<link>http://ptsefton.com/2010/03/04/more-details-on-a-metdata-store-for-data-inalongside-vital.htm/comment-page-1#comment-1822</link>
		<dc:creator>Scott Yeadon</dc:creator>
		<pubDate>Thu, 11 Mar 2010 21:48:39 +0000</pubDate>
		<guid isPermaLink="false">http://ptsefton.com/2010/03/04/more-details-on-a-metdata-store-for-data-inalongside-vital.htm#comment-1822</guid>
		<description>I&#039;d argue that if sysadmins care about redirects (i.e. ensuring a link always resolves to something useful for the user) then the handle system is useful as it abstracts the location metadata (URL in our example). Instead of having to maintain a possibly large chain/number of redirects over a long time, you just manage the handle metadata (i.e. the URL). Any user having access to the Internet has access to the handle (resolution) structure. I would be surprised if anyone was not able to get access to the infrastructure - CNRI don&#039;t strike me as wanting to put up barriers to their technology.</description>
		<content:encoded><![CDATA[<p>I&#8217;d argue that if sysadmins care about redirects (i.e. ensuring a link always resolves to something useful for the user) then the handle system is useful as it abstracts the location metadata (URL in our example). Instead of having to maintain a possibly large chain/number of redirects over a long time, you just manage the handle metadata (i.e. the URL). Any user having access to the Internet has access to the handle (resolution) structure. I would be surprised if anyone was not able to get access to the infrastructure &#8211; CNRI don&#8217;t strike me as wanting to put up barriers to their technology.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on More details on a metdata store for data in/alongside VITAL by ptsefton</title>
		<link>http://ptsefton.com/2010/03/04/more-details-on-a-metdata-store-for-data-inalongside-vital.htm/comment-page-1#comment-1821</link>
		<dc:creator>ptsefton</dc:creator>
		<pubDate>Thu, 11 Mar 2010 01:01:38 +0000</pubDate>
		<guid isPermaLink="false">http://ptsefton.com/2010/03/04/more-details-on-a-metdata-store-for-data-inalongside-vital.htm#comment-1821</guid>
		<description>In the case where people are going to use plain-old-URLs to access stuff cos they don&#039;t care about or know about or understand the one true handle way then you still need to look after redirects for the URLs - in which case all Handle is buying you is a doubling of infrastructure, more to go wrong.

That said, the handle system could be used a part of the redirect service. I think it could be used to register URLs but with handle itself never being exposed to the user. We&#039;re considering a service like this in our work on The Fascinator which has a propensity for serving the same thing on different URLs in different contexts - we could register all the URLs ever used and if one context goes offline fall back to another.</description>
		<content:encoded><![CDATA[<p>In the case where people are going to use plain-old-URLs to access stuff cos they don&#8217;t care about or know about or understand the one true handle way then you still need to look after redirects for the URLs &#8211; in which case all Handle is buying you is a doubling of infrastructure, more to go wrong.</p>
<p>That said, the handle system could be used a part of the redirect service. I think it could be used to register URLs but with handle itself never being exposed to the user. We&#8217;re considering a service like this in our work on The Fascinator which has a propensity for serving the same thing on different URLs in different contexts &#8211; we could register all the URLs ever used and if one context goes offline fall back to another.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on More details on a metdata store for data in/alongside VITAL by ptsefton</title>
		<link>http://ptsefton.com/2010/03/04/more-details-on-a-metdata-store-for-data-inalongside-vital.htm/comment-page-1#comment-1820</link>
		<dc:creator>ptsefton</dc:creator>
		<pubDate>Thu, 11 Mar 2010 00:45:56 +0000</pubDate>
		<guid isPermaLink="false">http://ptsefton.com/2010/03/04/more-details-on-a-metdata-store-for-data-inalongside-vital.htm#comment-1820</guid>
		<description>@andrew Well maybe, but important research data should be stored in places where the sysadmins DO worry about redirects etc. If they changing things around without worrying about that stuff then how would the data owners even know that they need to go and update the handle? Also, in many places end users won&#039;t have access to the identifier infrastructure.

It&#039;s about governance, which is hard.</description>
		<content:encoded><![CDATA[<p>@andrew Well maybe, but important research data should be stored in places where the sysadmins DO worry about redirects etc. If they changing things around without worrying about that stuff then how would the data owners even know that they need to go and update the handle? Also, in many places end users won&#8217;t have access to the identifier infrastructure.</p>
<p>It&#8217;s about governance, which is hard.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on More details on a metdata store for data in/alongside VITAL by Andrew Treloar</title>
		<link>http://ptsefton.com/2010/03/04/more-details-on-a-metdata-store-for-data-inalongside-vital.htm/comment-page-1#comment-1819</link>
		<dc:creator>Andrew Treloar</dc:creator>
		<pubDate>Wed, 10 Mar 2010 23:31:32 +0000</pubDate>
		<guid isPermaLink="false">http://ptsefton.com/2010/03/04/more-details-on-a-metdata-store-for-data-inalongside-vital.htm#comment-1819</guid>
		<description>@robert I don&#039;t see Handles as just symbolic - they do enable the owner of a resource to control a mapping to a URL where they may not be able to control the URL itself. Think DNS changes, web server reorganisation, etc. Not everyone runs their own webserver and can edit the Apache redirect table.</description>
		<content:encoded><![CDATA[<p>@robert I don&#8217;t see Handles as just symbolic &#8211; they do enable the owner of a resource to control a mapping to a URL where they may not be able to control the URL itself. Think DNS changes, web server reorganisation, etc. Not everyone runs their own webserver and can edit the Apache redirect table.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on More details on a metdata store for data in/alongside VITAL by Andrew Treloar</title>
		<link>http://ptsefton.com/2010/03/04/more-details-on-a-metdata-store-for-data-inalongside-vital.htm/comment-page-1#comment-1818</link>
		<dc:creator>Andrew Treloar</dc:creator>
		<pubDate>Wed, 10 Mar 2010 23:28:23 +0000</pubDate>
		<guid isPermaLink="false">http://ptsefton.com/2010/03/04/more-details-on-a-metdata-store-for-data-inalongside-vital.htm#comment-1818</guid>
		<description>Scott Yeadon has just pointed out that I need to clarify statement #1 above. The handles will only continue to resolve as long as (i) the local handles database (which contains the mapping between the PIDS and URLS) exists and (ii) the mappings are maintained (that is, updated as things move). (i) could be dealt with by getting some successor organisation to take over maintainance of the database, (ii) will require the owners of the PIDS to continue to care (which is an issue regardless of whether ANDS persists or not). Thanks Scott!</description>
		<content:encoded><![CDATA[<p>Scott Yeadon has just pointed out that I need to clarify statement #1 above. The handles will only continue to resolve as long as (i) the local handles database (which contains the mapping between the PIDS and URLS) exists and (ii) the mappings are maintained (that is, updated as things move). (i) could be dealt with by getting some successor organisation to take over maintainance of the database, (ii) will require the owners of the PIDS to continue to care (which is an issue regardless of whether ANDS persists or not). Thanks Scott!</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on ANDS metadata stores: Describing metadata collections in VITAL by ptsefton</title>
		<link>http://ptsefton.com/2010/02/23/ands-metadata-stores-describing-metadata-collections-in-vital.htm/comment-page-1#comment-1817</link>
		<dc:creator>ptsefton</dc:creator>
		<pubDate>Wed, 10 Mar 2010 20:30:38 +0000</pubDate>
		<guid isPermaLink="false">http://ptsefton.com/2010/02/23/ands-metadata-stores-describing-metadata-collections-in-vital.htm#comment-1817</guid>
		<description>Thanks Adrian, that makes sense, but in the VITAL/Fedora world where we are dealing with digital objects which are &quot;done&quot; then typical approach is to describe items with a metadata file in XML - usually MARCXML or MODS which are essentially equivalent.

The obvious question coming from a VITAL point of view is &quot;what schema should I use?&quot; And as far as I know some ANDS operatives have been suggesting RIF-CS. 

Another question, where I think ANDS should take an interest is &quot;What _terms_ should I use for things?&quot; To reuse an example from the IR world, today we have stuff being harvested where the dc:Type is expressed as a string: &quot;Journal Article&quot; &quot;Article (Peer Review)&quot;, &quot;Dest Category C&quot; (I don&#039;t know my DEST categories&quot;. It would be much better for the integrity of the whole system if we agreed to use a term like: http://purl.org/ontology/bibo/AcademicArticle as well as the locally-relevant string. ANDS and the RDA registry are still young enough to attack this issue NOW rather than end up in the situation we have with our IRs where the NLA has to normalize the data they harvest.

Is it in scope for ANDS to help with either of these? (a) Recommend a metadata schema for collection descriptions in static repositories, analogous to ARROW&#039;s recommendation of MARCXML and (b) recommend some properly defined terms from a set of ontologies to use therein?</description>
		<content:encoded><![CDATA[<p>Thanks Adrian, that makes sense, but in the VITAL/Fedora world where we are dealing with digital objects which are &#8220;done&#8221; then typical approach is to describe items with a metadata file in XML &#8211; usually MARCXML or MODS which are essentially equivalent.</p>
<p>The obvious question coming from a VITAL point of view is &#8220;what schema should I use?&#8221; And as far as I know some ANDS operatives have been suggesting RIF-CS. </p>
<p>Another question, where I think ANDS should take an interest is &#8220;What _terms_ should I use for things?&#8221; To reuse an example from the IR world, today we have stuff being harvested where the dc:Type is expressed as a string: &#8220;Journal Article&#8221; &#8220;Article (Peer Review)&#8221;, &#8220;Dest Category C&#8221; (I don&#8217;t know my DEST categories&#8221;. It would be much better for the integrity of the whole system if we agreed to use a term like: <a href="http://purl.org/ontology/bibo/AcademicArticle" rel="nofollow">http://purl.org/ontology/bibo/AcademicArticle</a> as well as the locally-relevant string. ANDS and the RDA registry are still young enough to attack this issue NOW rather than end up in the situation we have with our IRs where the NLA has to normalize the data they harvest.</p>
<p>Is it in scope for ANDS to help with either of these? (a) Recommend a metadata schema for collection descriptions in static repositories, analogous to ARROW&#8217;s recommendation of MARCXML and (b) recommend some properly defined terms from a set of ontologies to use therein?</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on More details on a metdata store for data in/alongside VITAL by robert forkel</title>
		<link>http://ptsefton.com/2010/03/04/more-details-on-a-metdata-store-for-data-inalongside-vital.htm/comment-page-1#comment-1814</link>
		<dc:creator>robert forkel</dc:creator>
		<pubDate>Wed, 10 Mar 2010 07:28:38 +0000</pubDate>
		<guid isPermaLink="false">http://ptsefton.com/2010/03/04/more-details-on-a-metdata-store-for-data-inalongside-vital.htm#comment-1814</guid>
		<description>@andrew: this may be a pet peeve of mine, but i&#039;d guess having handles resolve to the correct URLs over time is *really* hard, too, they just haven&#039;t had to stand the test of time yet.

the only advantage of handles i can see is sort of symbolic: using the handle system signals that people have actually considered the problem. but from my experience (with keeping URLs stable over &gt; 10 years) the same consideration will get you pretty far with URLs and HTTP redirection.</description>
		<content:encoded><![CDATA[<p>@andrew: this may be a pet peeve of mine, but i&#8217;d guess having handles resolve to the correct URLs over time is *really* hard, too, they just haven&#8217;t had to stand the test of time yet.</p>
<p>the only advantage of handles i can see is sort of symbolic: using the handle system signals that people have actually considered the problem. but from my experience (with keeping URLs stable over &gt; 10 years) the same consideration will get you pretty far with URLs and HTTP redirection.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
