Re: [Treebase-devel] Dryad/TreeBASE metadata relationships

[Rutger V. <R....@re...>]

> 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?

I think that depends on whether the data themselves are different. If
a submission to Dryad that is forwarded to TreeBASE contains more or
different data than the converse case I think this should be indicated
by using two different predicates - though they don't have to be
mutually exclusive, e.g. there could be one that always works and one
to indicate there is more data to discover.


> 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)?
>> I'm sometimes puzzled in how to parse the returns when very different
>> content is all included as dc:relation
>> i.e. this example, 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
>>
>
>
> ------------------------------------------------------------------------------
> 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
>
>



-- 
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