Thread: Re: [Treebase-devel] Dryad API, advice on cyberinfastructure

Status: Beta

Brought to you by: hlapp, naturalis, rvos, sfrgpiel

treebase-devel

Re: [Treebase-devel] Dryad API, advice on cyberinfastructure

From: Carl B. <cbo...@gm...> - 2011-05-11 16:10:20

Hi Dryad team, Treebase team,

Thanks Hilmar, here's an example:

For instance, this Dryad
entry<http://datadryad.org/handle/10255/dryad.8661> does
not point to this treebase
entry,<http://treebase.org/treebase-web/search/study/anyObjectAsRDF.rdf?namespacedGUID=TB2:S11266>
Perhaps
this is just because it is a recent entry?
The treebase entry in this cahas the Dryad id under a tag I didn't
expect: <tb:title.study
xmlns:tb="http://treebase.org/terms#">dryad_8661</tb:title.study>

Meanwhile this Dryad
entry<http://datadryad.org/handle/10255/dryad.4939?show=full> does
have the treebase identifer, but the treebase entry doesn't have the dryad
identifier<http://treebase.org/treebase-web/search/study/anyObjectAsRDF.rdf?namespacedGUID=TB2:S84>
.

-Carl

On Wed, May 11, 2011 at 7:04 AM, Hilmar Lapp <hl...@ne...> wrote:

> Hi Carl -
>
> first off, the perfect place to ask these and related questions is the
> Dryad Developers Google Group [1], which is public. I'm copying some of this
> thread there.
>
> The DataONE API implementation in R is as far as I understand not pretty
> and far from mature, but in principle functional. I'm copying Dave Vieglais,
> who should be able to point you to the appropriate places in the DataONE svn
> repository.
>
> Our handshaking mechanism with TreeBASE is in principle designed (or was in
> my understanding) such that TreeBASE studyIDs and Dryad DOIs are harvested
> and updated on the respective ends. (Completing a TreeBASE submission is
> asynchronous from, and can take a lot longer than, completing the
> "containing" Dryad submission.) If you have an example for where that
> doesn't seem to have worked, can you post that here?
>
> Cheers,
>
> -hilmar
>
> [1] http://groups.google.com/group/dryad-dev
>
> On May 10, 2011, at 1:30 AM, Carl Boettiger wrote:
>
> Hi Ryan,
>
> I am working on implementing the TreeBASE API in R, and am implemented in
> extending this to the DataDryad and DataONE APIs.  (In case you're curious,
> the project development is currently hosted on github<https://github.com/cboettig/treeBASE>.
> Pretty straight forward, so far just done the PhyloWS side, hoping to do the
> OAI-PMH side next).
>
> Todd suggests that there is already an implementation of the DataONE API in
> R, which is great to hear.  Do you know who's involved in this, and what
> state it's in?  I'd be happy to help test or whatnot.  I've started looking
> at what's available for the investigator-level API<http://mule1.dataone.org/ArchitectureDocs-current/apis/index.html>for DataONE; is this the current documentation?
>
> William Piel also forwarded you a question from my about getting the
> treebase and dryad data better integrated -- the treebase metadata doesn't
> currently include the dryad dois, and it seems the dryad dois don't include
> the treebase study ids.  Certainly this would be a pretty valuable to have,
> though I suppose a work-around might be possible by matching other metadata
> in the search?
>
> Anyway, nice to meet you, and look forward to hearing a bit more about what
> directions you're heading with this.  Is there an appropriate forum /
> mailing list to discuss the APIs for Dryad and DataONE?
>
> Thanks much,
>
> Carl
>
> --
> Carl Boettiger
> UC Davis
> http://www.carlboettiger.info/
>
>
>  --
> ===========================================================
> : Hilmar Lapp  -:- Durham, NC -:- informatics.nescent.org :
> ===========================================================
>
>
>
>


-- 
Carl Boettiger
UC Davis
http://www.carlboettiger.info/

Re: [Treebase-devel] Dryad API, advice on cyberinfastructure

From: William P. <wil...@ya...> - 2011-05-11 17:09:44

On May 11, 2011, at 12:10 PM, Carl Boettiger wrote:

> Hi Dryad team, Treebase team,
> 
> Thanks Hilmar, here's an example:
> 
> For instance, this Dryad entry does not point to this treebase entry, Perhaps this is just because it is a recent entry?
> The treebase entry in this cahas the Dryad id under a tag I didn't expect: <tb:title.study xmlns:tb="http://treebase.org/terms#">dryad_8661</tb:title.study>
> 
> Meanwhile this Dryad entry does have the treebase identifer, but the treebase entry doesn't have the dryad identifier. 
> 
> -Carl

Hi Carl,

With respect the TreeBASE:

<tb:title.study> is not the intended location for a dryad cross-reference -- it happens to be there because the title of the study is pre-populated with "dryad_8661", but the submitter can easily change this. 

Currently, TreeBASE exposes a DOI like so: 

<prism:doi xmlns:prism="http://prismstandard.org/namespaces/1.2/basic/">10.1111/j.1469-8137.2011.03677.x</prism:doi>

... but that is for the doi to the publication, so we wouldn't want to use that for Dryad.  

On the other hand, I'd rather not do a schema change. But we have a field called "URL", which we could pre-populate with "http://dx.doi.org/10.5061/dryad.8661". This field is usually used for publications that don't have a doi, and instead have a particular url -- and it's rarely used.  So one kluge (short of a schema change) is to pre-populate the url field with "http://dx.doi.org/10.5061/dryad.8661" and then expose that under the "prism:url" element.  What would be a good element to use other than "prism:url" or "prism:doi"?

bp

Re: [Treebase-devel] Dryad API, advice on cyberinfastructure

From: Rutger V. <R....@re...> - 2011-05-12 12:41:28

> On the other hand, I'd rather not do a schema change. But we have a field
> called "URL", which we could pre-populate with
> "http://dx.doi.org/10.5061/dryad.8661". This field is usually used for
> publications that don't have a doi, and instead have a particular url -- and
> it's rarely used.  So one kluge (short of a schema change) is to
> pre-populate the url field with "http://dx.doi.org/10.5061/dryad.8661" and
> then expose that under the "prism:url" element.  What would be a good
> element to use other than "prism:url" or "prism:doi"?

Citation.url is a string so we can put whatever we like there in order
to store it. As for the element to store it under, maybe:

- dcterms:source, defined as "A related resource from which the
described resource is derived. The described resource may be derived
from the related resource in whole or in part. Recommended best
practice is to identify the related resource by means of a string
conforming to a formal identification system." (or a subclass thereof,
e.g. tb.source.study.dryad)

- dcterms:isReferencedBy, defined as "A related resource that
references, cites, or otherwise points to the described resource.", or
dcterms:references, depending on how you would qualify the
relationship between the two. Or prism:isReferencedBy

- dcterms:identifier, defined as "An unambiguous reference to the
resource within a given context."
 (or a subclass thereof, e.g. tb.identifier.study.dryad)

- prism:isVersionOf, defined as "The described resource is a version,
edition, or adaptation of the referenced resource."

To me, dcterms:source sounds like a sensible candidate.

-- 
Dr. Rutger A. Vos
School of Biological Sciences
Philip Lyle Building, Level 4
University of Reading
Reading, RG6 6BX, United Kingdom
Tel: +44 (0) 118 378 7535
http://rutgervos.blogspot.com

Re: [Treebase-devel] Dryad API, advice on cyberinfastructure

From: Hilmar L. <hl...@ne...> - 2011-05-12 13:05:53

Or perhaps simply dc:relation, or dcterms:isPartOf [1], which is actually a refinement of the former? 

I agree though that the relationship ought to be general enough that a DC or dcterms property will probably best facilitate use, and I also wouldn't kludge this - these become de-factor standards sooner than you want, and then you're stuck with them.

-hilmar

[1] http://dublincore.org/documents/dcmi-terms/#terms-isPartOf

Sent with a tap.

On May 12, 2011, at 8:41 AM, Rutger Vos <R....@re...> wrote:

>> On the other hand, I'd rather not do a schema change. But we have a field
>> called "URL", which we could pre-populate with
>> "http://dx.doi.org/10.5061/dryad.8661". This field is usually used for
>> publications that don't have a doi, and instead have a particular url -- and
>> it's rarely used.  So one kluge (short of a schema change) is to
>> pre-populate the url field with "http://dx.doi.org/10.5061/dryad.8661" and
>> then expose that under the "prism:url" element.  What would be a good
>> element to use other than "prism:url" or "prism:doi"?
> 
> Citation.url is a string so we can put whatever we like there in order
> to store it. As for the element to store it under, maybe:
> 
> - dcterms:source, defined as "A related resource from which the
> described resource is derived. The described resource may be derived
> from the related resource in whole or in part. Recommended best
> practice is to identify the related resource by means of a string
> conforming to a formal identification system." (or a subclass thereof,
> e.g. tb.source.study.dryad)
> 
> - dcterms:isReferencedBy, defined as "A related resource that
> references, cites, or otherwise points to the described resource.", or
> dcterms:references, depending on how you would qualify the
> relationship between the two. Or prism:isReferencedBy
> 
> - dcterms:identifier, defined as "An unambiguous reference to the
> resource within a given context."
> (or a subclass thereof, e.g. tb.identifier.study.dryad)
> 
> - prism:isVersionOf, defined as "The described resource is a version,
> edition, or adaptation of the referenced resource."
> 
> To me, dcterms:source sounds like a sensible candidate.
> 
> -- 
> Dr. Rutger A. Vos
> School of Biological Sciences
> Philip Lyle Building, Level 4
> University of Reading
> Reading, RG6 6BX, United Kingdom
> Tel: +44 (0) 118 378 7535
> http://rutgervos.blogspot.com
> 
> ------------------------------------------------------------------------------
> Achieve unprecedented app performance and reliability
> What every C/C++ and Fortran developer should know.
> Learn how Intel has extended the reach of its next-generation tools
> to help boost performance applications - inlcuding clusters.
> http://p.sf.net/sfu/intel-dev2devmay
> _______________________________________________
> Treebase-devel mailing list
> Tre...@li...
> https://lists.sourceforge.net/lists/listinfo/treebase-devel