treebase-devel — TreeBASE developer mailing list

[Treebase-devel] TreeBASE annotations

[William P. <wil...@ya...>]

Dear Mesquite:

TreeBASE currently offers the ability to store valuable metadata annotations to sections of rows in the MATRIX of a CHARACTERS block. This is like a row-specific CHARSET range.  So, for example, if a CHARACTERS block consists of, say, five concatenated genes, then for each row we can store five Genbank accession numbers, each with its own "begin" and "end" character number.  A piece of annotation linked to a "begin" and "end" section of a row of characters can have the following tags:

Title (free text)
GenBank Accession Number
Other Accession Num (free text, e.g. culture number, etc)
Sample Taxon Label (i.e., if the taxon used to sequence part of the matrix row is different from the taxon label for the entire row and tree OTU)
Basic Darwin Core and biorepositories.org museum specimen triple: Inst. Acronym; Collection Code; Catalog Number
Basic Darwin Core specimen info: Collector; Sample Date; Country; State; Locality; Latitude-Longitude; Elevation
Notes (free text)

Aside from NeXML, these annotations are downloaded via a tab-separated text file. For example, to obtain the annotations for this dataset, you need to use this link. 

My question is, is there a way for us to download the NEXUS so that these annotations are readable/viewable by Mesquite? 

The logical place is in the NOTES block, and I notice that you offer this syntax:

SUTM  T = 4 N = genBankNumber S = AF284000;

... but I think this obliges the Genbank number to (1) apply to the entire row in the matrix, and (2) to be attached to the TAXA block instead of to the CHARACTERS block. We frequently have instances where several CHARACTERS blocks hang off of the same TAXA block, as well as instances where a single row of a MATRIX has several Genbank accession numbers, each associated with different subsections of sequence. 

An alternative is to put something like this:

AN T = 4 C = 1  AU = TreeBASE TF = ( CM AF284000 ) TF = ( R genBankNumber );

But that implies that the Genbank number only attaches to the first character in the row (instead of a larger chunk of the row, if not the entirety of it), so is not ideal. 


Can you recommend a syntax for attaching annotations to a range of characters of a particular row? Or do you have plans to offer this functionality? 

regards,

Bill

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

[Hilmar L. <hl...@ne...>]

On May 13, 2011, at 6:47 AM, Ryan Scherle wrote:

> 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 it would place a high (and not well justifiable in terms of  
gain) burden on prospective users of the API if they had to know which  
of several possible ways a Dryad package got connected to a TreeBASE  
study. It sounds like a bad idea to me, frankly.

	-hilmar
-- 
===========================================================
: Hilmar Lapp  -:- Durham, NC -:- informatics.nescent.org :
===========================================================

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

[Treebase-devel] Dryad/TreeBASE metadata relationships

[Ryan S. <rsc...@gm...>]

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

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

[Ryan S. <rsc...@gm...>]

On Fri, May 13, 2011 at 11:01 AM, Ryan Scherle <rsc...@gm...> wrote:

>
> Not yet, but you can obtain the file extensions easily through the DataONE
> API:
> http://datadryad.org/mn/object
>

Oops, I forgot the DataONE API *does* support search by MIME type:

http://datadryad.org/mn/object?objectFormat=text/plain
-- Ryan

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

[Ryan S. <rsc...@gm...>]

On Fri, May 13, 2011 at 12:30 AM, Carl Boettiger <cbo...@gm...> wrote:

>
> |That just worked fine for me given the dryad short from identifier to the
> data.  I'm curious what the flow would look like from a Dryad identifier to
> a study, i.e. if that would go through METS or OAI-PMH to get the
> identifiers for each data file.  i.e. If I followed the discussion earlier,
> treeBASE would be able to provide the short form dryad identifer to the
> study.  It looks like I could enter that into METS as outlined in (2) on the
> wiki, extract the identifiers to the data, enter each those into METS, and
> proceed as on the wiki to get the files?


Yes, you could do that. If you're interested in getting the files directly
(without going through the Dryad package objects), you could use the DataONE
API, which is still a bit rough, but focuses more on the data files. The
documentation (also a bit rough) is here:
http://code.google.com/p/dryad/wiki/D1RESTfulAPI


>  I see I can check the MIMETYPE once I'm on the METS page for a datafile.
>  I don't suppose I can query by MIMETYPE?
>

Not yet, but you can obtain the file extensions easily through the DataONE
API:
http://datadryad.org/mn/object

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

[Carl B. <cbo...@gm...>]

On Thu, May 12, 2011 at 3:17 PM, Hilmar Lapp <hl...@ne...> wrote:

>
> On May 12, 2011, at 5:50 PM, Carl Boettiger <cbo...@gm...> wrote:
>
> > Is there anything more clever than a bunch of grep rules for
> distinguishing between these?
>
> Well, you can pack the semantics into the property, or into the resources
> that they connect. Personally, I loath RDF models that have a baroque number
> of properties because typically you end up having to hardcode these into
> applications that try to do something meaningful with the RDF. I.e., there
> is no good way to infer or deduce much about the semantics of properties.
> Conversely, the Semantic Web and LOD already provide the conventions and
> standards For resources to describe themselves on the web, so while figuring
> out what it is that a property connects a subject to requires a HTTP GET on
> the resource URI, it is the recommended (and I think most extensible) way of
> doing this. (Though unfortunately in our case this doesn't quite hold - yet;
> however, Crossref is finally starting to implement LOD-compliant DOI
> resolution, and the question is when DataCite DOIs will play ball too.)
>

I think most of that went over my head for the moment.

>
> > 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.
>
> Yes, it's documented on the Data Access API page on the Dryad wiki that I
> referred to earlier.
>
Thanks, that's excellent, sorry I didn't realize what it was before.

That just worked fine for me given the dryad short from identifier to the
data.  I'm curious what the flow would look like from a Dryad identifier to
a study, i.e. if that would go through METS or OAI-PMH to get the
identifiers for each data file.  i.e. If I followed the discussion earlier,
treeBASE would be able to provide the short form dryad identifer to the
study.  It looks like I could enter that into METS as outlined in (2) on the
wiki, extract the identifiers to the data, enter each those into METS, and
proceed as on the wiki to get the files?

I see I can check the MIMETYPE once I'm on the METS page for a datafile.  I
don't suppose I can query by MIMETYPE?

Thanks for the help, just started learning my way around the api.

-Carl

>
> -hilmar
>
> Sent with a tap.
>



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

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

[Hilmar L. <hl...@ne...>]

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

> Is there anything more clever than a bunch of grep rules for distinguishing between these?  

Well, you can pack the semantics into the property, or into the resources that they connect. Personally, I loath RDF models that have a baroque number of properties because typically you end up having to hardcode these into applications that try to do something meaningful with the RDF. I.e., there is no good way to infer or deduce much about the semantics of properties. Conversely, the Semantic Web and LOD already provide the conventions and standards For resources to describe themselves on the web, so while figuring out what it is that a property connects a subject to requires a HTTP GET on the resource URI, it is the recommended (and I think most extensible) way of doing this. (Though unfortunately in our case this doesn't quite hold - yet; however, Crossref is finally starting to implement LOD-compliant DOI resolution, and the question is when DataCite DOIs will play ball too.)

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

Yes, it's documented on the Data Access API page on the Dryad wiki that I referred to earlier.

-hilmar

Sent with a tap.

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

[Carl B. <cbo...@gm...>]

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/

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

[Hilmar L. <hl...@ne...>]

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

Re: [Treebase-devel] NEXUS output problems

[Mark H. <mth...@gm...>]

Hi,
	Yes.  That appears to works for my NEXUS parser.

thanks,
Mark


On May 10, 2011, at 4:07 PM, William Piel wrote:

> Hi Mark,
> 
> Could you try our dev server?  Harry recently committed a bug fix for this.
> 
> http://purl.org/phylo/treebase/dev/phylows/study/TB2:S2012
> 
> regards,
> 
> Bill
> 
> On Apr 21, 2011, at 11:09 PM, Mark Holder wrote:
> 
>> Hi,
>> 	I just downloaded S2012.nex (I can send it along if needed, but I won't clutter your inboxes unless it is needed. The url ishttp://purl.org/phylo/treebase/phylows/study/TB2:S2012 ).
>> 
>> 	My NEXUS parser is choking on a couple of things:
>> 		1. The names of the CHARSET commands in the SETS block have spaces, but the names have not been "escaped" to convert them to single NEXUS tokens.  
>> 
>> 		2. There are multiple TAXA blocks but the TREES blocks do not use the LINK command to disambiguate.  Mesquite is smart enough to figure out which TAXA block is correct.  I suppose I could add taxa-block-detection code to NCL (the NEXUS parsing library that I use), but it would be much easier if TreeBase used LINK to clarify the connections.
>> 
>> all the best,
>> Mark
> 

Re: [Treebase-devel] Understanding OAI-PMH Verbs

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

I think I got publicationDate to work as well, should be available on
the dev shortly.

On Thu, May 12, 2011 at 3:11 PM, William Piel <wil...@ya...> wrote:
>
> On May 12, 2011, at 9:40 AM, Rutger Vos wrote:
>
> http://treebase-dev.nescent.org/treebase-web/phylows/study/find?query=prism.creationDate>"May
> 5, 2011"&format=rss1
>
> http://treebase-dev.nescent.org/treebase-web/phylows/study/find?query=prism.modificationDate>"May
> 5, 2011"&format=rss1
>
> http://treebase-dev.nescent.org/treebase-web/phylows/study/find?query=prism.publicationDate>"May
> 5, 2011"&format=rss1
>
> still ironing out the bugs with prism.publicationDate, but
> prism.modificationDate seems to work.
>
> Hey -- this is excellent.  Presently I have an RSS feed in my Apple Mail
> client program that lists all (new) submissions to TreeBASE, but the PhyloWS
> query is a silly kluge, like finding all articles with the letter "e" in the
> title. Once your changes are rebuilt on production, I'll change this to find
> all after modification date x.
> bp
>
>
> ------------------------------------------------------------------------------
> 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

Re: [Treebase-devel] Understanding OAI-PMH Verbs

[William P. <wil...@ya...>]

On May 12, 2011, at 9:40 AM, Rutger Vos wrote:

> http://treebase-dev.nescent.org/treebase-web/phylows/study/find?query=prism.creationDate>"May
> 5, 2011"&format=rss1
> 
> http://treebase-dev.nescent.org/treebase-web/phylows/study/find?query=prism.modificationDate>"May
> 5, 2011"&format=rss1
> 
> http://treebase-dev.nescent.org/treebase-web/phylows/study/find?query=prism.publicationDate>"May
> 5, 2011"&format=rss1
> 
> still ironing out the bugs with prism.publicationDate, but
> prism.modificationDate seems to work.

Hey -- this is excellent.  Presently I have an RSS feed in my Apple Mail client program that lists all (new) submissions to TreeBASE, but the PhyloWS query is a silly kluge, like finding all articles with the letter "e" in the title. Once your changes are rebuilt on production, I'll change this to find all after modification date x. 

bp

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

[William P. <wil...@ya...>]

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

Re: [Treebase-devel] Understanding OAI-PMH Verbs

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

http://treebase-dev.nescent.org/treebase-web/phylows/study/find?query=prism.creationDate>"May
5, 2011"&format=rss1

http://treebase-dev.nescent.org/treebase-web/phylows/study/find?query=prism.modificationDate>"May
5, 2011"&format=rss1

http://treebase-dev.nescent.org/treebase-web/phylows/study/find?query=prism.publicationDate>"May
5, 2011"&format=rss1

still ironing out the bugs with prism.publicationDate, but
prism.modificationDate seems to work.

On Thu, May 12, 2011 at 2:10 AM, William Piel <wil...@ya...> wrote:
>
> On May 11, 2011, at 8:24 PM, Carl Boettiger wrote:
>
>> hmm, I don't think I have the right adjective, seems that "after"
>> gives me the whole of treebase independent of the date.  Same with
>> "since" Can I look up the vocabulary somewhere?
>
> the mot juste in OAI lingo is "from".  I just added this example to the wiki:
>
> http://treebase.org/treebase-web/top/oai?verb=ListRecords&metadataPrefix=oai_dc&from=2011-04-30T00:00:00Z
>
>> So I guess the only way to query by author date is to pull the
>> metadata for all studies and filter from there?  Fine for treebase at
>> it's current size I suppose...
>
> I also wish the phylows API had the ability to search by publication year.  Alas, not yet.
>
> bp
>
>
>
> ------------------------------------------------------------------------------
> 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

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

[Greenberg, J. <ja...@em...>]

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

--
You received this message because you are subscribed to the Google Groups "dryad-dev" group.
To post to this group, send email to dry...@go....
To unsubscribe from this group, send email to dry...@go....
For more options, visit this group at http://groups.google.com/group/dryad-dev?hl=en.

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

[Hilmar L. <hl...@ne...>]

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

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

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

> 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] Understanding OAI-PMH Verbs

[William P. <wil...@ya...>]

On May 11, 2011, at 8:24 PM, Carl Boettiger wrote:

> hmm, I don't think I have the right adjective, seems that "after"
> gives me the whole of treebase independent of the date.  Same with
> "since" Can I look up the vocabulary somewhere?

the mot juste in OAI lingo is "from".  I just added this example to the wiki:

http://treebase.org/treebase-web/top/oai?verb=ListRecords&metadataPrefix=oai_dc&from=2011-04-30T00:00:00Z

> So I guess the only way to query by author date is to pull the
> metadata for all studies and filter from there?  Fine for treebase at
> it's current size I suppose...

I also wish the phylows API had the ability to search by publication year.  Alas, not yet. 

bp

Re: [Treebase-devel] Understanding OAI-PMH Verbs

[Carl B. <cbo...@gm...>]

On Wed, May 11, 2011 at 5:16 PM, William Piel <wil...@ya...> wrote:
>
> On May 11, 2011, at 8:03 PM, Carl Boettiger wrote:
>
>> For instance, it will ListRecord will take "after" as well as "until"?
>
> it should...
hmm, I don't think I have the right adjective, seems that "after"
gives me the whole of treebase independent of the date.  Same with
"since" Can I look up the vocabulary somewhere?

I was extracting dates from <dc:dates> but pulling with
ListRecord=until, which was using the <datestamp> date instead, which
is why I got 1980s dates.    Sorry about that.

So I guess the only way to query by author date is to pull the
metadata for all studies and filter from there?  Fine for treebase at
it's current size I suppose...

-Carl

>
>> It seems that the date used by ListRecord corresponds to the datestamp
>> in the header, which isn't the year of the publication?
>
> that's right... so the main motivation for creating this service was to allow Dryad to mirror TreeBASE -- any modifications to old records get an updated time-stamp, which allows Dryad to not just suck down new records, but also update existing records that have changed.
>
>>  I thought it might be the date added to TreeBASE, but some go back to 1980?
>
> Oh... whoops. Maybe I'm wrong about this. The earliest date should be 1995-11-04. I'll have to check this.
>
>>  Is this spelled out a bit more anywhere?
>
> It ought to be...
>
> bp
>
>
>



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

Re: [Treebase-devel] Understanding OAI-PMH Verbs

[William P. <wil...@ya...>]

On May 11, 2011, at 8:03 PM, Carl Boettiger wrote:

> For instance, it will ListRecord will take "after" as well as "until"?

it should...

> It seems that the date used by ListRecord corresponds to the datestamp
> in the header, which isn't the year of the publication?

that's right... so the main motivation for creating this service was to allow Dryad to mirror TreeBASE -- any modifications to old records get an updated time-stamp, which allows Dryad to not just suck down new records, but also update existing records that have changed. 

>  I thought it might be the date added to TreeBASE, but some go back to 1980?

Oh... whoops. Maybe I'm wrong about this. The earliest date should be 1995-11-04. I'll have to check this. 

>  Is this spelled out a bit more anywhere?

It ought to be...

bp

[Treebase-devel] Understanding OAI-PMH Verbs

[Carl B. <cbo...@gm...>]

Hi list,

I'm trying to get a better idea of what's available in terms of
OAI-PMH verbs described on the wiki:
http://sourceforge.net/apps/mediawiki/treebase/index.php?title=OAI-PMH

(I promise to help update the wiki once I get this right ;-)

For instance, it will ListRecord will take "after" as well as "until"?
It seems that the date used by ListRecord corresponds to the datestamp
in the header, which isn't the year of the publication?  I thought it
might be the date added to TreeBASE, but some go back to 1980?  Is
this spelled out a bit more anywhere?  It would be great to be able to
query by publication date, but mostly just curious about what's
possible here. Thanks much,

-Carl



On Wed, May 11, 2011 at 4:35 PM, Carl Boettiger <cbo...@gm...> wrote:
> Working for me now too.
>
> On Wed, May 11, 2011 at 4:21 PM, William Piel <wil...@ya...> wrote:
>> It works for me (?)
>>
>> bp
>>
>>
>> On May 11, 2011, at 5:25 PM, Jon Auman wrote:
>>
>>> Bill,
>>>
>>> I updated the application around 5 PM today. Should I rollback to the previous version?
>>>
>>> -Jon
>>>
>>> On May 11, 2011, at 5:10 PM, Carl Boettiger wrote:
>>>
>>>> Hi Treebase,
>>>>
>>>>
>>>> This worked a moment ago:
>>>> http://treebase.org/treebase-web/top/oai?verb=GetRecord&metadataPrefix=oai_dc&identifier=TB:s1234
>>>>
>>>>
>>>> Now I get an error:
>>>> Uncaught Exception Encountered
>>>> java.lang.reflect.InvocationTargetException at
>>>> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
>>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>>> at java.lang.reflect.Method.invoke(Method.java:616) at
>>>> org.cipres.treebase.web.controllers.OAIPMHController.handle(OAIPMHController.java:117)
>>>> at org.springframework.web.servlet.mvc.AbstractCommandController.handleRequestInternal(AbstractCommandController.java:84)
>>>> at
>>>> [...]
>>>>
>>>>
>>>> basic queries are still there:
>>>> http://treebase.org/treebase-web/top/oai?verb=Identify
>>>> but not and GetRecord queries.
>>>>
>>>> Just curious if this is a problem at my end or just a temporary interruption.
>>>>
>>>> Thanks,
>>>> Carl
>>>> --
>>>> Carl Boettiger
>>>> UC Davis
>>>> http://www.carlboettiger.info/
>>>>
>>>> -
>>
>
>
>
> --
> Carl Boettiger
> UC Davis
> http://www.carlboettiger.info/
>



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

Re: [Treebase-devel] Is the OAI-PMH service down?

[Carl B. <cbo...@gm...>]

Working for me now too.

On Wed, May 11, 2011 at 4:21 PM, William Piel <wil...@ya...> wrote:
> It works for me (?)
>
> bp
>
>
> On May 11, 2011, at 5:25 PM, Jon Auman wrote:
>
>> Bill,
>>
>> I updated the application around 5 PM today. Should I rollback to the previous version?
>>
>> -Jon
>>
>> On May 11, 2011, at 5:10 PM, Carl Boettiger wrote:
>>
>>> Hi Treebase,
>>>
>>>
>>> This worked a moment ago:
>>> http://treebase.org/treebase-web/top/oai?verb=GetRecord&metadataPrefix=oai_dc&identifier=TB:s1234
>>>
>>>
>>> Now I get an error:
>>> Uncaught Exception Encountered
>>> java.lang.reflect.InvocationTargetException at
>>> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>> at java.lang.reflect.Method.invoke(Method.java:616) at
>>> org.cipres.treebase.web.controllers.OAIPMHController.handle(OAIPMHController.java:117)
>>> at org.springframework.web.servlet.mvc.AbstractCommandController.handleRequestInternal(AbstractCommandController.java:84)
>>> at
>>> [...]
>>>
>>>
>>> basic queries are still there:
>>> http://treebase.org/treebase-web/top/oai?verb=Identify
>>> but not and GetRecord queries.
>>>
>>> Just curious if this is a problem at my end or just a temporary interruption.
>>>
>>> Thanks,
>>> Carl
>>> --
>>> Carl Boettiger
>>> UC Davis
>>> http://www.carlboettiger.info/
>>>
>>> -
>



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

Re: [Treebase-devel] Is the OAI-PMH service down?

[William P. <wil...@ya...>]

It works for me (?)

bp


On May 11, 2011, at 5:25 PM, Jon Auman wrote:

> Bill,
> 
> I updated the application around 5 PM today. Should I rollback to the previous version?
> 
> -Jon
> 
> On May 11, 2011, at 5:10 PM, Carl Boettiger wrote:
> 
>> Hi Treebase,
>> 
>> 
>> This worked a moment ago:
>> http://treebase.org/treebase-web/top/oai?verb=GetRecord&metadataPrefix=oai_dc&identifier=TB:s1234
>> 
>> 
>> Now I get an error:
>> Uncaught Exception Encountered
>> java.lang.reflect.InvocationTargetException at
>> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>> at java.lang.reflect.Method.invoke(Method.java:616) at
>> org.cipres.treebase.web.controllers.OAIPMHController.handle(OAIPMHController.java:117)
>> at org.springframework.web.servlet.mvc.AbstractCommandController.handleRequestInternal(AbstractCommandController.java:84)
>> at
>> [...]
>> 
>> 
>> basic queries are still there:
>> http://treebase.org/treebase-web/top/oai?verb=Identify
>> but not and GetRecord queries.
>> 
>> Just curious if this is a problem at my end or just a temporary interruption.
>> 
>> Thanks,
>> Carl
>> -- 
>> Carl Boettiger
>> UC Davis
>> http://www.carlboettiger.info/
>> 
>> -

Re: [Treebase-devel] Is the OAI-PMH service down?

[Jon A. <jon...@ne...>]

Bill,

I updated the application around 5 PM today. Should I rollback to the previous version?

-Jon

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

> Hi Treebase,
> 
> 
> This worked a moment ago:
> http://treebase.org/treebase-web/top/oai?verb=GetRecord&metadataPrefix=oai_dc&identifier=TB:s1234
> 
> 
> Now I get an error:
> Uncaught Exception Encountered
> java.lang.reflect.InvocationTargetException at
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:616) at
> org.cipres.treebase.web.controllers.OAIPMHController.handle(OAIPMHController.java:117)
> at org.springframework.web.servlet.mvc.AbstractCommandController.handleRequestInternal(AbstractCommandController.java:84)
> at
> [...]
> 
> 
> basic queries are still there:
> http://treebase.org/treebase-web/top/oai?verb=Identify
> but not and GetRecord queries.
> 
> Just curious if this is a problem at my end or just a temporary interruption.
> 
> Thanks,
> Carl
> -- 
> 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

-------------------------------------------------------
Jon Auman
Systems Administrator
National Evolutionary Synthesis Center
Duke University
http:www.nescent.org
jon...@ne...
------------------------------------------------------