<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>[This is now beyond an IPT discussion]</div><div><br></div>Ultimately a simple KVP store handles this nicely, but the actual implementation is yet to be decided upon. By parsing and storing the individual fields separately, one can rewrite in XML, RDF, CSV etc easily.<div><br></div><div>For a small DB (50million records or so) I would probably look to Berkeley DB to provide this functionality. For the kind of volume and throughput we strive for at the global index, we will likely look beyond that, and potentially towards a column oriented DB (e.g. BigTable clone), such as HBase or Cassandra. I know the Atlas of Living Australia are making nice use of Cassandra.</div><div><br></div><div>Thanks,</div><div>Tim</div><div><br></div><div><br></div><div><br></div><div><div><br><div><div>On Sep 15, 2010, at 1:59 PM, Holetschek, Jörg wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"> <div style="WORD-WRAP: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space"> <div dir="ltr" align="left"><font color="#0000ff" size="2" face="Verdana"><span class="842375711-15092010">Tim,</span></font></div> <div dir="ltr" align="left"><font color="#0000ff" size="2" face="Verdana"><span class="842375711-15092010"></span></font> </div> <div dir="ltr" align="left"><font color="#0000ff" size="2" face="Verdana"><span class="842375711-15092010">how will the GBIF Indexer store the original DwC record? Is it kept in a text field in the Index database? In the original DwC archive?</span></font></div> <div dir="ltr" align="left"><font color="#0000ff" size="2" face="Verdana"><span class="842375711-15092010"></span></font> </div> <div dir="ltr" align="left"><font color="#0000ff" size="2" face="Verdana"><span class="842375711-15092010">Jörg</span></font></div><br> <div dir="ltr" lang="de" class="OutlookMessageHeader" align="left"> <hr tabindex="-1"> <font size="2" face="Tahoma"><b>Von:</b> ipt-bounces@lists.gbif.org [<a href="mailto:ipt-bounces@lists.gbif.org">mailto:ipt-bounces@lists.gbif.org</a>] <b>Im Auftrag von </b>Tim Robertson (GBIF)<br><b>Gesendet:</b> Mittwoch, 15. September 2010 13:29<br><b>An:</b> <a href="mailto:ipt@lists.gbif.org">ipt@lists.gbif.org</a><br><b>Betreff:</b> Re: [IPT] Functionality request: ADMIN checking data before GBIFregistration<br></font><br></div> <div></div>Thanks all for the comments, which I will try and collate here with some resolutions: <div><br></div> <div><b>Propose resolved:</b></div> <div>a) The preference would be to allow the ADMIN to provide Registration privileges to individual MANAGERS</div> <div><br></div> <div><b>Outstanding issues:</b></div> <div>b) Visualisations are important, and will need discussion and potentially further IPT modules developed, or deployment of external services. </div> <div>I know of one group considering the development of DwC-A visualisations already, and technologies like Google Fusion tables makes this kind of thing trivial. </div> <div><br></div> <div> <div>c) record resolution is something that has been indicated as important. This can be achieved in one of 2 ways:</div> <div> > implementation in the IPT, and requires research into technologies to perform satisfactorily</div> <div> Potential technologies might be</div> <div> - Berkeley DB</div> <div> - A relational database, such as Mysql or H2</div> <div> - Lucene indexing </div> <div> > reliance on a "stable cache" for record serving</div> <div><br></div> <div>The first release (for test purposes) of the revised IPT software will not have record level serving, but while this is being developed, I would like to ask people to start discussing what kind of record level serving is truly a requirement in the IPT, as opposed to a "nice to have". We support DwC-A in the GBIF portal, and the intention is to simply reserve the record that came from the DwC-A directly, unless the record indicates there is further information on a URL (e.g. if the record identifier is an LSID). Would this strategy not be suitable for the likes of the BioCASe portals as often there is no further information to redirect to? in the case of the IPT, there is no extra information, and I propose should the source be a DwC-A, that individual records be cached in the harvesting portal. With this approach, there would be no individual record serving needs in the IPT.</div> <div><br></div> <div>Ultimately, we might consider aiming for data owners offering single records on a resolvable URL, and conforming to Linked/Open Data requirements, along with a DwC-A effectively providing a single "index" view of the dataset. The DwC-A records would reference the originals by resolvable ID so any search system would always be able to point back to the authoritative source. This would effectively be distributed indexing, and not dissimilar to the sharing of sitemaps, but with extra information to enable better discovery. </div> <div><br></div> <div>Thank you all for this feedback, and please correct any misunderstandings on my part</div> <div><br></div> <div>Tim</div> <div><br></div> <div><br></div> <div><br></div> <div><br></div> <div> </div> <div> </div> <div><br> <div> <div>On Sep 15, 2010, at 12:03 PM, Mihail-Constantin Carausu wrote:</div><br class="Apple-interchange-newline"> <blockquote type="cite"> <div>Dear Tim<br><br>I think the development team's mentioned approach is a workable solution<br>to cover both requirements at this stage.<br>However, I think Hannu (and me) had in mind a kind of "Basket of<br>approvals"-alike functionality in the Admin's (owner of the provider)<br>administration section side: When a Manager has been published a dataset<br>through the IPT, this will automatically trigger a request for approval<br>or submits an yes/no event in the Admin's administration section. The<br>Admin must finally active interfere and approve the dataset publication<br>(e.g. by checking an "Approved" check box in the basket of approvals<br>list with events/datasets in the administration section) at the absolute<br>latest stage (e.g. when GBIF just needs to start to index it, or<br>something like that). Without this final approval the dataset will still<br>be published and visible through the IPT but not visible/searchable on<br>the GBIF data portal. This approach is not necessarily in contradiction<br>with the Manager's ability to autonomously publish datasets within the<br>IPT, only it puts this ability always under control from the central<br>administration section when the dataset has to go to the GBIF data<br>portal. <br>I think both solutions/approaches have obvious advantages and<br>disadvantages while none of them provides a 100% protection against<br>publishing something odd by a (test) user.<br>I have a little question regarding the development team's proposed<br>solutions: is it not possible for the central Admin to enable the<br>publishing ability for some "trusted" managers and disable this for<br>others inside the same instance of the IPT.<br><br>Now I saw Hannu's new message just arrived, sorry for eventually<br>unsynchronized double-crossing messages, but I will send this anyhow.<br><br>Best regards,<br>Mihail<br><br>---------------------------- <br>Mihail Carausu<br>MSc.Eng., Informatics Manager<br>Danish Biodiversity Information Facility (DanBIF)<br>-------------------------------------------- <br><br><br>-----Original Message-----<br>From: <a href="mailto:ipt-bounces@lists.gbif.org">ipt-bounces@lists.gbif.org</a> [<a href="mailto:ipt-bounces@lists.gbif.org">mailto:ipt-bounces@lists.gbif.org</a>] On<br>Behalf Of Tim Robertson (GBIF)<br>Sent: 15. september 2010 09:43<br>To: <a href="mailto:ipt@lists.gbif.org">ipt@lists.gbif.org</a><br>Subject: [IPT] Functionality request: ADMIN checking data before<br>GBIFregistration<br><br>Hi all,<br><br>Hannu has raised a request for the following to be satisfied by the IPT:<br><span style="WHITE-SPACE: pre" class="Apple-tab-span"></span>"- Publishing a resource must be accepted by the owner of the <br>provider. It has happened that a test user publishes something odd <br>which goes all the way to the data portal without nobody controlling <br>it."<br><br>This is a contradiction to the requests of others, and specifically <br>those wishing to promote basic "data hosting centers", who request <br>that a data MANAGER should be able to work autonomously.<br><br>After discussion with the developers the proposal is to implement the <br>following, which we hope satisfies both requirements:<br>In the Administration section, an ADMIN can choose to enable or <br>disable the ability for MANAGERS to register resources with GBIF. By <br>default MANAGERS can register a resource, but an ADMIN can disable <br>this through this check box.<br><br>If anyone has any concerns or comments on this approach, please can <br>you raise them on this list?<br><br>Many thanks,<br>Tim<br><br><br><br><br><br><br>_______________________________________________<br>IPT mailing list<br><a href="mailto:IPT@lists.gbif.org">IPT@lists.gbif.org</a><br><a href="http://lists.gbif.org/mailman/listinfo/ipt">http://lists.gbif.org/mailman/listinfo/ipt</a><br><br></div></blockquote></div><br></div></div></div></blockquote></div><br></div></div></body></html>