<div id="RTEContent">Dear Richard<br>  <br>  I agree with you that several mirror copies will and are needed,  preferably well spread geographically as back-ups. This is exactely the  approach of GBIF, as they are now in the process to mirror their  services. <br>  <br>  However as highlighted by Bob Morris their is are social, but also  financial barriers to have all contributing institutions run a "full"  mirror. In order to insure the participation of all those who are  willing to, I believe that a distributed system where each provider can  participate with his part&nbsp; should be kept. Those who have the  ressources could of course set up full mirrors&nbsp; if this match  their needs and if this is allowed by the providers (there are also  IPRs issues which may be raise here by some institutions).<br>  <br>  Patricia <br>  <br><br><b><i>Richard Pyle &lt;deepreef@BISHOPMUSEUM.ORG&gt;</i></b> wrote:<blockquote class="replbq" style="border-left: 2px solid rgb(16, 16, 255);
 margin-left: 5px; padding-left: 5px;">  &gt; Long term what I think might happen is that users have their own triple<br>&gt; stores, and as they do queries the results get added to their own<br>&gt; triple store and they can make inferences locally that they are<br>&gt; interested in. MIT's Piggy bank project<br>&gt; (http://simile.mit.edu/piggy-bank/) is an example of this sort of<br>&gt; approach.<br><br>With hard drive sizes spiraling skyward, and $/GB ($/TB) spiraling<br>downward.... I'm wondering whether or not the "distributed" system that<br>serves us best might be "distributeded mirror copies", rather than<br>distributed complementary data.  I've been pushing this approach for<br>taxonomic data for a while, but perhaps it would be useful for other shared<br>data as well (geographic localities, people/agents, publications/references,<br>etc.)  Even for specimen data -- where "ownership" is unambiguous -- it<br>seems that as long as the ownership is clearly embedded in the
 core<br>metadata, there are more fundamental advantages in storing and serving data<br>from multiple data resources, rather than serving it from only one single<br>data resource.<br><br>One way to look at it would be "robust caching", with automated update<br>capabilities.  The main benefits would be:<br><br>1) Large-scale distributed backup of the world's biodata (ensuring<br>perpetuity across a changing technological landscape);<br>2) Performance and reliability enhancement for local data authority needs;<br>4) Essentially 100% data availability (like DNS), regardless of which<br>servers are up or down at any given moment;<br>3) Maximization of distributed work/effort for data "maintenance and<br>repair".<br><br>The point is, the technology discussions would focus less on issues of<br>distributed queries, and more on issues of replication/synchronization and<br>data edit authorization protocols.<br><br>Perhaps this would be reaching too far, too soon.  But on the other hand,
 I<br>don't see why implementing a "distributed mirror" system would be any more<br>technically, financially, or socially challenging than implementing a<br>distributed query system for distributed data.<br><br>Aloha,<br>Rich<br><br>Richard L. Pyle, PhD<br>Database Coordinator for Natural Sciences<br>  and Associate Zoologist in Ichthyology<br>Department of Natural Sciences, Bishop Museum<br>1525 Bernice St., Honolulu, HI 96817<br>Ph: (808)848-4115, Fax: (808)847-8252<br>email: deepreef@bishopmuseum.org<br>http://hbs.bishopmuseum.org/staff/pylerichard.html<br></blockquote><br></div><p>

                <hr size=1>Yahoo! Photos<br>
Ring in the New Year with <a href="http://us.rd.yahoo.com/mail_us/taglines/photos/*http://pg.photos.yahoo.com/ph//page?.file=calendar_splash.html&.dir=">Photo Calendars</a>. Add photos, events, holidays, whatever.