[Treebase-devel] Dryad/TreeBASE metadata relationships

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

(splitting this off from the old thread, because it is a separate issue --
and limiting the CC to the two lists, which I believe covers all of the
relevant people)

Bill suggested that TreeBASE studies should reference Dryad data packages
using dcterms:isPartOf. Rutger suggested using dcterms:source. Although I
like the semantics of "source" better than "isPartOf", I think "isPartOf"
will work better, particularly for keeping the relationships consistent
regardless of whether the initial submission. But then I'm not sure whether
we want this to be consistent.....

QUESTION: Should the metadata differ based on the repository where an item
was first deposited? In other words, should the Dryad/TreeBASE metadata look
different for items that were submitted to Dryad then forwarded to TreeBASE,
vs. items that were first submitted to TreeBASE then included in a Dryad
data package?

For the metadata on the Dryad end, we still need to correct some issues
with the relationships to TreeBASE objects. We do not currently "complete
the loop" when an item is submitted to Dryad and forwarded to TreeBASE -- we
don't yet place the TreeBASE study ID back in the Dryad metadata. On the
other hand, if a depositor submits to TreeBASE first, then creates a Dryad
submission, the TreeBASE study ID can be placed in the submission. It is
stored as a Dryad data file object, which references the TreeBASE study
using a custom metadata field of dryad:externalIdentifier
dryad:externalIdentifier. This is far from perfect, and can be revisited,
but first I would like to have concensus on the above question, so we can
design something that covers all the use cases.

--- Ryan

On Thu, May 12, 2011 at 10:50 PM, Carl Boettiger <cbo...@gm...> wrote:

> Hi Hilmar, William, List,
>
> Isn't Dryad already using dc:identifier to reference TreeBASE (i.e. this
> example <http://datadryad.org/handle/10255/dryad.4939?show=full>)?
> I'm sometimes puzzled in how to parse the returns when very different
> content is all included as dc:relation
> i.e. this example<http://www.datadryad.org/oai/request?verb=GetRecord&identifier=oai:datadryad.org:10255/dryad.1619&metadataPrefix=oai_dc>,
> dc:relation is sometimes a handle, sometimes a doi, a journal title, or a
> number I don't recognize.
> Is there anything more clever than a bunch of grep rules for distinguishing
> between these?
>
>
> Is there a way to get the URL of the actual data file (i.e. some csv file)
> through the dryad API?  So far I can only return the website that contains
> the data file.
>
> Thanks much.
> Carl
>
> On Thu, May 12, 2011 at 2:34 PM, Hilmar Lapp <hl...@ne...> wrote:
> > The mutual cross-referencing at the level of data package and TB study
> makes
> > sense. Please don't use the Dryad handles or handle URIs - the use of
> > handles within Dryad is legacy and being phased out (except perhaps for
> > individual files, which are not relevant here).
> > If we use isPartOf for both references, then that suggests that the Dryad
> > package and the TB study are semantically equivalent objects, which I
> think
> > they are cleary not. I would think that Dryas would reference the TB
> study
> > through a dcterms:hasPart property if TB references the Dryad package
> > through dcterms:isPartOf. Or again the simpler dc.relation.
> >
> > -hilmar
> > Sent with a tap.
> > On May 12, 2011, at 10:04 AM, William Piel <wil...@ya...>
> wrote:
> >
> >
> > Is there a consensus, then, that TreeBASE should express the
> corresponding
> > Dryad DOIs, prefixed with http://dx.doi.org/,
> using dcterms:isPartOf  via
> > both OAI and PhyloWS ?
> > Or, for that matter, express the handle that Dryad labels
> dc:identifier.uri
> > (e.g. http://hdl.handle.net/10255/dryad.15417).
> > Meanwhile Dryad should express the corresponding TreeBASE URI also
> > using dcterms:isPartOf ?
> > A slight wrinkle is to make sure we are mutually cross-referencing the
> > proper "level" of object.
> > Dryad issues "Data Package" identifiers, which I guess is synonymous with
> a
> > TreeBASE URI to a "study".  These two identifiers point to the same
> package:
> > dc:identifier: doi: 10.5061/dryad.tf48r
> > dc:identifier.uri: http://hdl.handle.net/10255/dryad.15415
> > But in addition, Dryad issues identifiers for particular data sets. These
> > two identifiers point to the same data set within the above package:
> > dc:identifier: doi: 10.5061/dryad.tf48r/2
> > dc:identifier.uri: http://hdl.handle.net/10255/dryad.15417
> > There is no one-to-one equivalency between these data set identifiers and
> > TreeBASE's URIs, because TreeBASE's URIs point to matrix objects and tree
> > objects, which are all extracted from the same or different data set(s).
> > Hence I think that for both TreeBASE and Dryad, the cross-referencing of
> > identifiers should be at the level of "package" and "study"
> respectively.
> > bp
> >
> > On May 12, 2011, at 9:32 AM, Greenberg, Jane wrote:
> >
> > All -- I am not sure I've followed this conversation all the way, but
> > Hilmar's interpretation of dcterms:isPartOf (or simple/unqualified DC
> > w/dc:relation) makes  good sense to me; and will help w/interoperabilty.
> >
> > W.r.t. PRISM, the Drayd 3.0 ap (application profile) has moved away from
> > PRISM to BIBO, see: http://bibliontology.com/specification.  There seems
> to
> > be increased interest in and discussion of this scheme on various
> metadata
> > lists.  I am a tad wary about the overall upkeep (latest version,
> etc.)....
> > but it is Sematic Web compatible, rdf, etc...
> >
> > Hope this helps.
> >
> > ~ jane
> >
> > -----Original Message-----
> > From: dry...@go... [mailto:dry...@go...] On
> > Behalf Of Hilmar Lapp
> > Sent: Thursday, May 12, 2011 9:06 AM
> > To: Rutger Vos
> > Cc: William Piel; Tre...@li...; Vision, Todd J;
> > DaveVieglais; Ryan Scherle; Dryad Developers
> > Subject: [dryad-dev] Re: [Treebase-devel] Dryad API, advice on
> > cyberinfastructure
> >
> > 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.
> >
> >
> >
> ------------------------------------------------------------------------------
> > 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
> >
> >
> ------------------------------------------------------------------------------
> > 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
> >
> >
>
>
>
> --
> Carl Boettiger
> UC Davis
> http://www.carlboettiger.info/
>
>
>
>
> ------------------------------------------------------------------------------
> 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
>
>