<div id="RTEContent">Dear Colleagues<br> <br> Yes I agree with Chuck that we have to be carefull here. <br> <br> For example providers have agreed to make their data public by providing it to GBIF, but are not aware what this really implies. Most of our providers are for example very pleased to have now their georeferenced data so easy and nice in google earth others are not because of the lack of precision or the fact that apparently some center of areas are shown fasely as too precise sampling points. <br> <br> The same reactions of lost of control or "where does my data show up and how" will certainly come with mirrors, caching or "central" GUID attributions. Before suggesting anything official as a GUID and GUID system, I agree with Chuck that we should be aware of political implications and maybe misinterpretation of our purely technical purposes. I guess there will be some "legal" documents
needed to negociate and agree in advance in form maybe as an extension to GBIF data users and providers agreements ?<br> <br> Patricia <br> <br> <br> <br> <br> <br> <br> <br><br><b><i>Chuck Miller <Chuck.Miller@MOBOT.ORG></i></b> wrote:<blockquote class="replbq" style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"> <meta http-equiv="Content-Type" content="text/html; charset=US-ASCII"> <meta name="Generator" content="Microsoft Word 11 (filtered medium)"> <!--[if !mso]> <style> v\:* {behavior:url(#default#VML);} o\:* {behavior:url(#default#VML);} w\:* {behavior:url(#default#VML);} .shape {behavior:url(#default#VML);} </style> <![endif]--><o:SmartTagType namespaceuri="urn:schemas-microsoft-com:office:smarttags" name="PlaceType"> <o:SmartTagType namespaceuri="urn:schemas-microsoft-com:office:smarttags" name="PlaceName"> <o:SmartTagType namespaceuri="urn:schemas-microsoft-com:office:smarttags"
name="PostalCode"> <o:SmartTagType namespaceuri="urn:schemas-microsoft-com:office:smarttags" name="State"> <o:SmartTagType namespaceuri="urn:schemas-microsoft-com:office:smarttags" name="City"> <o:SmartTagType namespaceuri="urn:schemas-microsoft-com:office:smarttags" name="place"> <o:SmartTagType namespaceuri="urn:schemas-microsoft-com:office:smarttags" name="Street"> <o:SmartTagType namespaceuri="urn:schemas-microsoft-com:office:smarttags" name="address"> <!--[if !mso]> <style> st1\:*{behavior:url(#default#ieooui) } </style> <![endif]--> <style> <!-- /* Font Definitions */ @font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:12.0pt; font-family:"Times New Roman";} a:link, span.MsoHyperlink {color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed
{color:blue; text-decoration:underline;} p {mso-margin-top-alt:auto; margin-right:0in; mso-margin-bottom-alt:auto; margin-left:0in; font-size:12.0pt; font-family:"Times New Roman";} span.EmailStyle18 {mso-style-type:personal-reply; font-family:Arial; color:navy;} @page Section1 {size:8.5in 11.0in; margin:1.0in 1.25in 1.0in 1.25in;} div.Section1 {page:Section1;} --> </style> </o:SmartTagType></o:SmartTagType></o:SmartTagType></o:SmartTagType></o:SmartTagType></o:SmartTagType></o:SmartTagType></o:SmartTagType><div class="Section1"> <div class="MsoNormal"><font color="navy" face="Arial" size="2"><span style="font-size: 10pt; font-family: Arial; color: navy;">Querying a central database is certainly technically easier and more responsive than distributed data. Mirroring servers is mature technology. And, disk drives get cheaper every
day.<o:p></o:p></span></font></div> <div class="MsoNormal"><font color="navy" face="Arial" size="2"><span style="font-size: 10pt; font-family: Arial; color: navy;"><o:p> </o:p></span></font></div> <div class="MsoNormal"><font color="navy" face="Arial" size="2"><span style="font-size: 10pt; font-family: Arial; color: navy;">But, in addition to the social, technical and financial factors that limit the ability to implement distributed caches or full mirrors there is also the political factor, which GBIF has spent great effort successfully addressing. As a global entity, GBIF cannot exist without the political support from its members that leads in turn to financial support. Most of the members of GBIF are sovereign nations who seek to preserve and protect their country’s assets. Some protect more than others.<o:p></o:p></span></font></div> <div class="MsoNormal"><font color="navy" face="Arial" size="2"><span style="font-size: 10pt;
font-family: Arial; color: navy;"><o:p> </o:p></span></font></div> <div class="MsoNormal"><font color="navy" face="Arial" size="2"><span style="font-size: 10pt; font-family: Arial; color: navy;">To cache or mirror data in multiple locations, the dilemma lies in the simplest question: “Where is my data?” A cache or mirror from a technologist’s perspective is just a technical trick, identical to the original, dependent upon the master version, no big deal. But, simplistically, the data may be actually located in another country, no matter how it got there, and some politicians could misconstrue the whole thing, if not properly negotiated and agreed upon in advance. In my experience, negotiating such agreements is more work than the technical development.<o:p></o:p></span></font></div> <div class="MsoNormal"><font color="navy" face="Arial" size="2"><span style="font-size: 10pt; font-family: Arial; color:
navy;"><o:p> </o:p></span></font></div> <div class="MsoNormal"><font color="navy" face="Arial" size="2"><span style="font-size: 10pt; font-family: Arial; color: navy;">I think the distributed nature of DiGIR was critical to selling it at the start of GBIF. The original design assured providers that their source data would “stay” in their country and not be wholesale copied somewhere else. It’s hard to say what the political effect of creating mirrors would be. <o:p></o:p></span></font></div> <div class="MsoNormal"><font color="navy" face="Arial" size="2"><span style="font-size: 10pt; font-family: Arial; color: navy;"><o:p> </o:p></span></font></div> <div class="MsoNormal"><font color="navy" face="Arial" size="2"><span style="font-size: 10pt; font-family: Arial; color: navy;">Chuck Miller<o:p></o:p></span></font></div> <div class="MsoNormal"><font color="navy" face="Arial" size="2"><span style="font-size:
10pt; font-family: Arial; color: navy;">Missouri Botanical Garden<o:p></o:p></span></font></div> <div class="MsoNormal"><font color="navy" face="Arial" size="2"><span style="font-size: 10pt; font-family: Arial; color: navy;"><o:p> </o:p></span></font></div> <div> <div class="MsoNormal" style="text-align: center;" align="center"><font face="Times New Roman" size="3"><span style="font-size: 12pt;"> <hr tabindex="-1" align="center" size="2" width="100%"> </span></font></div> <div class="MsoNormal"><b><font face="Tahoma" size="2"><span style="font-size: 10pt; font-family: Tahoma; font-weight: bold;">From:</span></font></b><font face="Tahoma" size="2"><span style="font-size: 10pt; font-family: Tahoma;"> Patricia Mergen [mailto:p_mergen@YAHOO.COM] <br> <b><span style="font-weight: bold;">Sent:</span></b> Wednesday, January 04, 2006 5:38 AM<br> <b><span style="font-weight: bold;">To:</span></b> TDWG-GUID@LISTSERV.NHM.KU.EDU<br> <b><span style="font-weight:
bold;">Subject:</span></b> Re: [TDWG-GUID] RDF query and inference in a distributed environment</span></font><o:p></o:p></div> </div> <div class="MsoNormal"><font face="Times New Roman" size="3"><span style="font-size: 12pt;"><o:p> </o:p></span></font></div> <div id="RTEContent"> <div class="MsoNormal"><font face="Times New Roman" size="3"><span style="font-size: 12pt;">Dear Rich<br> <br> <b><i><span style="font-weight: bold; font-style: italic;">Richard Pyle <deepreef@BISHOPMUSEUM.ORG></span></i></b> wrote:<o:p></o:p></span></font></div> <div class="MsoNormal"><font face="Times New Roman" size="3"><span style="font-size: 12pt;">Hi Patricia,<br> <br> Many thanks for the feedback (and thanks also to Bob -- who I neglected to<br> thank in my previous post).<br> <br> What do you reckon would be the limiting social and financial factors for<br> full mirrors? In social terms, if I'm going to expose my data to the world<br> anyway (e.g., via DiGIR),
then I don't see why I would be socially reluctant<br> to allow others to mirror the data (provided robust syncronization protocols<br> are in place -- see my previous response to Bob; and provided data<br> "ownership" credentials are embedded within the core metadata).<br> <br> I agree with you about the logic in this. However accoding to my daily experience with potential dataproviders there is a lot of teaching and conviencing needed to make this logic accepted that this does not result in the loss of control over own data. I agree that to be conviencing a robust syncronization is needed. <br> <br> As for financial, I prefaced my original post with the observation of ever<br> decreasing $/GB for storage space. I suspect that, before TDWG nails down<br> the GUID protocols, entry-level web servers (of the sort that even the most<br> modest DiGIR provider would need to establish) will come with nearly a TB of<br> disk storage space by default.
Perhaps the cost of bandwidth will be a<br> limiting factor? Or maybe DB software capable of managing such large<br> datasets?<br> <br> I agree that for machines and storage it is not that expensive. I was more referring to the human ressources needed to manage the mirror. Smaller institutions do not have necessary the funds or cannot justify to their hierachy that staff is devoting time to maintain a full miror containing mainly "references" to information coming from other institutions, but it is easier to justify the time spent to contribute to the whole with the part concerning directly the institution ... <br> <br> As for IPR -- well, ultimately that applies mostly to specimens. And again,<br> assuming that "ownership" metadata remains intact, I see no basis for<br> increased apprehension about allowing mirrored copies of data records (as<br> GBIF already does, for example) over and above exposing
them in the first<br> place.<br> <br> Yes I agree with you here too, but as said before this need teaching and convincing ... <br> <br> Personally, I don't think the social, legal, or financial barriers are<br> significantly greater for a mass-mirror paradigm than they are for<br> distributed complementary data sets. I suspect the major barriers will be<br> more technical (i.e., those aforementioned "robust syncronization<br> protocols").<br> <br> Yes I agree with you that robust syncronization will be needed but as my IT colleague always remind me, I guess we must not forget that setting up an IT infrastructure is most of the time 10 % technical issues to be solved and 90% of the time solving "human problems and barriers" to make it work and accepted ... <br> <br> Pat<br> <br> <br> Aloha,<br> Rich<br> <br> -----Original Message-----<br> From: Taxonomic Databases Working Group GUID Project<br> [mailto:TDWG-GUID@LISTSERV.NHM.KU.EDU]On Behalf Of Patricia
Mergen<br> Sent: Tuesday, January 03, 2006 10:31 PM<br> To: TDWG-GUID@LISTSERV.NHM.KU.EDU<br> Subject: Re: RDF query and inference in a distributed environment<br> <br> <br> Dear Richard<br> <br> I agree with you that several mirror copies will and are needed, preferably<br> well spread geographically as back-ups. This is exactely the approach of<br> 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<br> barriers to have all contributing institutions run a "full" mirror. In order<br> to insure the participation of all those who are willing to, I believe that<br> a distributed system where each provider can participate with his part<br> should be kept. Those who have the ressources could of course set up full<br> mirrors if this match their needs and if this is allowed by the providers<br> (there are also IPRs issues which may be raise here by some institutions).<br>
<br> Patricia<br> <br> <br> Richard Pyle <deepreef @bishopmuseum.org="">wrote:<br> > Long term what I think might happen is that users have their own triple<br> > stores, and as they do queries the results get added to their own<br> > triple store and they can make inferences locally that they are<br> > interested in. MIT's Piggy bank project<br> > (http://simile.mit.edu/piggy-bank/) is an example of this sort of<br> > 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 han d, 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, <st1:place w:st="on"><st1:PlaceName w:st="on">Bishop</st1:PlaceName> <st1:PlaceType w:st="on">Museum</st1:PlaceType></st1:place><br> <st1:address w:st="on"><st1:Street w:st="on">1525 Bernice St.</st1:Street>, <st1:City w:st="on">Honolulu</st1:City>, <st1:State w:st="on">HI</st1:State> <st1:PostalCode w:st="on">96817</st1:PostalCode></st1:address><br> Ph: (808)848-4115, Fax: (808)847-8252<br> email: deepreef@bishopmuseum.org<br>
http://hbs.bishopmuseum.org/staff/pylerichard.html<br> <br> <br> <br> <br> <br> Yahoo! Photos<br> Ring in the New Year with Photo Calendars. Add photos, events, holidays,<br> whatever.<br> <br> <o:p></o:p></deepreef></span></font></div> <div class="MsoNormal"><font face="Times New Roman" size="3"><span style="font-size: 12pt;"><o:p> </o:p></span></font></div> </div> <div class="MsoNormal" style="text-align: center;" align="center"><font face="Times New Roman" size="3"><span style="font-size: 12pt;"> <hr align="center" size="1" width="100%"> </span></font></div> <div class="MsoNormal"><font face="Times New Roman" size="3"><span style="font-size: 12pt;">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.<o:p></o:p></span></font></div> </div>
</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.