treebase-devel — TreeBASE developer mailing list

Re: [Treebase-devel] [PhyloWS] query predicate vocabulary

[Rutger V. <rut...@gm...>]

> I'm wondering actually what the rule is for DOIs - Ryan, can you enlighten
> us on that?

I was wondering about that too, turns out they are - to my surprise -
case-insensitive (or so says wikipedia...)

-- 
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://www.nexml.org
http://rutgervos.blogspot.com

Re: [Treebase-devel] [PhyloWS] query predicate vocabulary

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

On Oct 8, 2010, at 12:41 AM, William Piel wrote:

> So I was wondering... is case sensitivity (e.g. the CamelCase  
> discussed) an expectation for Linked Data identifiers and URIs?

Yes. Which doesn't mean that some identifier schemes can't decide to  
be case-insensitive. But someone linking by identifier should never  
assume that the identifier is case-insensitive.

I'm wondering actually what the rule is for DOIs - Ryan, can you  
enlighten us on that?

> Or should TreeBASE be modified to accept both S10645 and s10645?


You may wish to decide that independently of the issue at hand. No  
matter what the decision, I would first get in touch with Am Nat (or  
Chicago Press) whether they can fix that. I was going to pull out an  
article that links to a dataset in Dryad, but it occurs to me that  
Dryad DOIs are entirely lowercase, and so it wouldn't show anything.  
Though you could take that as a hint to make all TB identifiers  
lowercase as well, which would avoid this issue.

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

Re: [Treebase-devel] [PhyloWS] query predicate vocabulary

[Rutger V. <rut...@gm...>]

> So I was wondering... is case sensitivity (e.g. the CamelCase discussed) an expectation for Linked Data identifiers and URIs? Or should TreeBASE be modified to accept both S10645 and s10645?
>

The W3 says:

"Two RDF URI references are equal if and only if they compare as
equal, character by character, as Unicode strings."
(http://www.w3.org/TR/rdf-concepts/#section-Graph-URIref)

Allowing case-insensitive URIs in PhyloWS is likely to give problems
when they occur in RDF serializations so I am no fan of allowing them.

-- 
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://www.nexml.org
http://rutgervos.blogspot.com

Re: [Treebase-devel] [PhyloWS] query predicate vocabulary

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

On Oct 4, 2010, at 6:24 AM, Rutger Vos wrote:

>> 1) The pattern for constructing the label uses a dot to delimit "words"
>> (e.g., identifier.tree), whereas normally the pattern I've seen uses
>> CamelCase (which would yield treeIdentifier). For the standard vocabulary
>> I'd rather stick with common conventions, so what were the reasons or
>> examples that motivated the dot pattern?
> 
> No reason. If CamelCase is the convention, we should stick with that.
> I simply did not know that.

Speaking of case... I notice that in this recent Am Nat article:

http://dx.doi.org/10.1086/656486

... the PDF has the TreeBASE URI displayed at the top of the page:

http://www.journals.uchicago.edu/doi/pdf/10.1086/656486

... which is nice, but while the URI is correctly written:  

http://purl.org/phylo/treebase/phylows/study/TB2:S10645

... the clickable link actually returns this string in lower case:  

http://purl.org/phylo/treebase/phylows/study/tb2:s10645

... which causes a "HTTP Status 400 - Bad ID string" error. i.e., our phylows implementation is case sensitive when it comes to identifiers. 

So I was wondering... is case sensitivity (e.g. the CamelCase discussed) an expectation for Linked Data identifiers and URIs? Or should TreeBASE be modified to accept both S10645 and s10645?

bp

Re: [Treebase-devel] current best practices for publishing trees electronically

[Rutger V. <rut...@gm...>]

> We'd appreciate your help in making sure that we are making the best
> use of TreeBase and any other technologies that you might recommend
> for making trees available electronically.   At the TDWG meeting,
> several of us experimented with the TreeBase submission process.  We
> were impressed with the support for representing the 3 kinds of
> linkable quantities that we targeted in our assessment: species names
> (or LSIDs or other taxonomic identifiers), accession numbers, and
> geographic coordinates.  The only weakness we have noticed so far is
> the lack of access to all of these data though treebase interfaces.

Looking at what you have up on the wiki, it looks like you are hitting
the right buttons, i.e. you are making the best use of TreeBASE.
W.r.t. access to the metada (e.g. DwC coordinates, accession numbers)
the way forward would be a two-step process:

1. the CQL query interface would need to be re-designed/expanded such
that more predicates are recognized and supported for searching.
Whether this would be on a predicate-by-predicate basis or something
more generic remains to be seen. Hopefully the latter, but it's not
immediately obvious to me how that would work.

2. a simple search box (a bit like the clever entrez search (Rod Page
has been begging for this)) would need to be developed that knows how
to construct any relevant CQL search queries and call them, returning
all hits from the different search sections. I have some ideas for how
to do this, but it wouldn't be trivial.

In any case, thanks for pointing out these weaknesses. They should be
resolved, and they are resolvable in principle :)

Rutger

-- 
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://www.nexml.org
http://rutgervos.blogspot.com

[Treebase-devel] current best practices for publishing trees electronically

[Arlin S. <ar...@um...>]

Dear treebase developers--

Hello.  As you know, in the next few years, we can expect thousands or  
tens of thousands of trees to be archived or published electronically  
in share-able ways (as opposed to the current situation in which most  
trees are just graphic images of trees, or they can't be linked to  
anything because the information in the tree consists only of  
arbitrary labels for things).  So, now is a good time to think about  
best practices for publishing trees electronically, and to identify  
strengths and weaknesses so as to help the phylogenetic community move  
toward greater re-use, sharing, and integration of data.

Last week, at the TDWG (Biodiversity Information Standards) meeting,  
the TDWG Phylogenetic Standards working group started a project to  
assess current best practices for publishing trees electronically. The  
work we have done so far is described here:

http://wiki.tdwg.org/twiki/bin/view/Phylogenetics/LinkingTrees2010

Dan Rosauer, Torsten Ericksson and I are going to finish up a  
preliminary report for TDWG, and then we would like to move on to  
develop a manuscript for publication in the next 6 to 8 weeks.

We'd appreciate your help in making sure that we are making the best  
use of TreeBase and any other technologies that you might recommend  
for making trees available electronically.   At the TDWG meeting,  
several of us experimented with the TreeBase submission process.  We  
were impressed with the support for representing the 3 kinds of  
linkable quantities that we targeted in our assessment: species names  
(or LSIDs or other taxonomic identifiers), accession numbers, and  
geographic coordinates.  The only weakness we have noticed so far is  
the lack of access to all of these data though treebase interfaces.

Arlin
-------
Arlin Stoltzfus (ar...@um...)
Fellow, IBBR; Adj. Assoc. Prof., UMCP; Research Biologist, NIST
IBBR, 9600 Gudelsky Drive, Rockville, MD
tel: 240 314 6208; web: www.molevol.org

Re: [Treebase-devel] [PhyloWS] query predicate vocabulary

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

On Oct 4, 2010, at 4:32 PM, Arlin Stoltzfus wrote:

> Are all those references to "identifer" (tree identifier,  matrix  
> identifier) going to be anchored in some way by  
> dcterms:identifier?   And likewise with all those references to  
> "title"?


Yes. They are already declared as sub-properties of dc:identifier and  
dc:title, respectively.

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

Re: [Treebase-devel] [PhyloWS] query predicate vocabulary

[Arlin S. <ar...@um...>]

Are all those references to "identifer" (tree identifier,  matrix  
identifier) going to be anchored in some way by dcterms:identifier?    
And likewise with all those references to "title"?

Terms such as "study" appear in various ontologies (search http://bioportal.bioontology.org 
).

Arlin

On Oct 2, 2010, at 6:15 PM, Hilmar Lapp wrote:

> (Sorry for cross-posting - this does concern both treebase and phylows
> groups though)
>
> Rutger et al,
>
> I assume that the TreeBASE terms and predicate vocabulary terms
> spreadsheet [1] is the basis for the treebase.owl [2] ontology in the
> TreeBASE codebase? If so, I was happy to see the tb. prefix removed
> from the property labels in the OWL file. If not, what is the relation
> between the two? (BTW neither vocabulary artifact is linked from the
> TreeBASE API documentation [3] - shouldn't they, or at least one of
> them, possibly the OWL file?)
>
> One of the outcomes of the Phylogenetics Standards working meeting at
> the 2010 TDWG conference [4] is that we need to move forward on a
> standard PhyloWS query predicate vocabulary. Obviously, the one
> created for TreeBASE would be a template for that, and ultimately
> TreeBASE could import that vocabulary, and add its own custom
> predicates (similarly as it now imports Dublin Core and then adds its
> own predicates). I think this approach (standard ontology that
> individual data providers import into theirs and then add to) would
> also allow data providers to add annotations indicating which
> predicates they actually support.
>
> Are there concerns or considerations that could make this a bad idea?
>
> Assuming for a moment that it's not a bad idea, here are some initial
> thoughts I had when looking at the treebase.owl file as the presumed
> starting point.
> 1) The pattern for constructing the label uses a dot to delimit
> "words" (e.g., identifier.tree), whereas normally the pattern I've
> seen uses CamelCase (which would yield treeIdentifier). For the
> standard vocabulary I'd rather stick with common conventions, so what
> were the reasons or examples that motivated the dot pattern?
> 2) None of the properties seems to have a definition. I think in the
> standard one we should aim for all properties to have good
> definitions. Do others agree that this is worthwhile, or do you think
> this wouldn't gain anything. (There are initial definitions in the
> spreadsheet, for example.)
> 3) The spreadsheet has additional information that looks actually
> useful, such as the Xpath expression for NeXML. Wouldn't that be worth
> retaining to?
>
> Nico - I don't know whether you're subscribed to the phylows group -
> if not, you may want to if you want to stay in the loop on this.
>
> 	-hilmar
>
> [1] https://spreadsheets.google.com/pub?key=0Av8UW3JvZsgcckwtLU83cHloUjhGY25uRzUtb2ZBbHc&hl=en&single=true&gid=0&output=html
> [2] http://treebase.svn.sourceforge.net/viewvc/treebase/trunk/treebase-core/src/main/resources/treebase.owl
> [3] https://sourceforge.net/apps/mediawiki/treebase/index.php? 
> title=API
> [4] http://wiki.tdwg.org/twiki/bin/view/Phylogenetics/WorkingMeeting2010#Further_develop_thePhyloreferenc
> -- 
> ===========================================================
> : Hilmar Lapp  -:- Durham, NC -:- informatics.nescent.org :
> ===========================================================
>
>
>
> -- 
> You received this message because you are subscribed to the Google  
> Groups "PhyloWS" group.
> To post to this group, send email to ph...@go....
> To unsubscribe from this group, send email to phy...@go... 
> .
> For more options, visit this group at http://groups.google.com/group/phylows?hl=en 
> .
>

-------
Arlin Stoltzfus (ar...@um...)
Fellow, IBBR; Adj. Assoc. Prof., UMCP; Research Biologist, NIST
IBBR, 9600 Gudelsky Drive, Rockville, MD
tel: 240 314 6208; web: www.molevol.org

Re: [Treebase-devel] [PhyloWS] query predicate vocabulary

[Rutger V. <rut...@gm...>]

> 1) The pattern for constructing the label uses a dot to delimit "words"
> (e.g., identifier.tree), whereas normally the pattern I've seen uses
> CamelCase (which would yield treeIdentifier). For the standard vocabulary
> I'd rather stick with common conventions, so what were the reasons or
> examples that motivated the dot pattern?

No reason. If CamelCase is the convention, we should stick with that.
I simply did not know that.

> 2) None of the properties seems to have a definition. I think in the
> standard one we should aim for all properties to have good definitions. Do
> others agree that this is worthwhile, or do you think this wouldn't gain
> anything. (There are initial definitions in the spreadsheet, for example.)

I think this would be useful.

> 3) The spreadsheet has additional information that looks actually useful,
> such as the Xpath expression for NeXML. Wouldn't that be worth retaining to?

Yes.

-- 
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://www.nexml.org
http://rutgervos.blogspot.com

[Treebase-devel] query predicate vocabulary

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

(Sorry for cross-posting - this does concern both treebase and phylows  
groups though)

Rutger et al,

I assume that the TreeBASE terms and predicate vocabulary terms  
spreadsheet [1] is the basis for the treebase.owl [2] ontology in the  
TreeBASE codebase? If so, I was happy to see the tb. prefix removed  
from the property labels in the OWL file. If not, what is the relation  
between the two? (BTW neither vocabulary artifact is linked from the  
TreeBASE API documentation [3] - shouldn't they, or at least one of  
them, possibly the OWL file?)

One of the outcomes of the Phylogenetics Standards working meeting at  
the 2010 TDWG conference [4] is that we need to move forward on a  
standard PhyloWS query predicate vocabulary. Obviously, the one  
created for TreeBASE would be a template for that, and ultimately  
TreeBASE could import that vocabulary, and add its own custom  
predicates (similarly as it now imports Dublin Core and then adds its  
own predicates). I think this approach (standard ontology that  
individual data providers import into theirs and then add to) would  
also allow data providers to add annotations indicating which  
predicates they actually support.

Are there concerns or considerations that could make this a bad idea?

Assuming for a moment that it's not a bad idea, here are some initial  
thoughts I had when looking at the treebase.owl file as the presumed  
starting point.
1) The pattern for constructing the label uses a dot to delimit  
"words" (e.g., identifier.tree), whereas normally the pattern I've  
seen uses CamelCase (which would yield treeIdentifier). For the  
standard vocabulary I'd rather stick with common conventions, so what  
were the reasons or examples that motivated the dot pattern?
2) None of the properties seems to have a definition. I think in the  
standard one we should aim for all properties to have good  
definitions. Do others agree that this is worthwhile, or do you think  
this wouldn't gain anything. (There are initial definitions in the  
spreadsheet, for example.)
3) The spreadsheet has additional information that looks actually  
useful, such as the Xpath expression for NeXML. Wouldn't that be worth  
retaining to?

Nico - I don't know whether you're subscribed to the phylows group -  
if not, you may want to if you want to stay in the loop on this.

	-hilmar

[1] https://spreadsheets.google.com/pub?key=0Av8UW3JvZsgcckwtLU83cHloUjhGY25uRzUtb2ZBbHc&hl=en&single=true&gid=0&output=html
[2] http://treebase.svn.sourceforge.net/viewvc/treebase/trunk/treebase-core/src/main/resources/treebase.owl
[3] https://sourceforge.net/apps/mediawiki/treebase/index.php?title=API
[4] http://wiki.tdwg.org/twiki/bin/view/Phylogenetics/WorkingMeeting2010#Further_develop_thePhyloreferenc
-- 
===========================================================
: Hilmar Lapp  -:- Durham, NC -:- informatics.nescent.org :
===========================================================

Re: [Treebase-devel] Fwd: new services from the UC Curation Center at the California Digital Library

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

Dryad is not paying for the DOI cost yet. When we do start paying I expect it to be substantially less that $1, likely under 10 cents.

The primary advantages of using DOIs are:
* Authors know what they are and understand some of the benefits.
* DOIs assigned through EZID will be widely promoted (e.g., available in Google Scholar)
* Due to the creation of the DataCite consortium, DOIs will become more common (and more commonly expected) for data content.

Possible reasons not to use DOIs in TreeBASE:
* Identifier proliferation is messy. It complicates tracking of re-use.
* From a purely technical standpoint, PURLs are just as good as DOIs.

--- Ryan

On Sep 27, 2010, at 4:46 PM, William Piel wrote:

> 
> hmm..  given that we're already advertising purls, if we issued yet another handle that would produce yet more redundancy, unless there are special advantages to these alternatives. So it it the case that the $1 per DOI cost is absorbed by someone else? (and forever?)
> 
> bp
> 
> 
> On Sep 23, 2010, at 10:09 AM, Hilmar Lapp wrote:
> 
>> Any thoughts about possibly assigning DOIs to studies, or even trees, in TreeBASE? Perhaps something for the TreeBASE BoD to discuss at their upcoming meeting?
>> 
>> 	-hilmar
>> 
>> Begin forwarded message:
>> 
>> EZID (ee-zee-eye-dee) http://www.cdlib.org/services/uc3/ezid/index.html  is a service providing researchers and others a way to manage identifiers persistently for datasets, files, and resources of all types. The service is available via a machine to machine programming interface (an API) and as a web user interface. 
>>  
>> What’s so important about identifier management? Persistent identification of and access to a scholar’s research is critical to the long-term distribution and availability of her or his work. EZID lets you update not only a description of the work, but also its “forwarding address,” so no matter where the work moves, the citable, clickable link to the resource will continue to provide access.
>>  
>> Currently, EZID allows you to acquire DataCite <www.datacite.org <http://www.datacite.org> > Digital Object Identifiers (DOIs) or Archival Resource Keys (ARKs), and we plan to add other identifier schemes going forward. In the future, we will also support object deposit options.
>>  
>> All disciplines can benefit from using EZID. It transcends domain boundaries and is applicable to the sciences, humanities and the social sciences.  It will work with a range of data types including numerical, images, text sequences, text, digital audio, digital video, modeling data and more.
>>  
>> Dryad is an EZID user and we would like to open this service to the DataONE community.  You can test the service at: http://n2t.net/ezid/help 
>>  
>> 
>> -- 
>> ===========================================================
>> : Hilmar Lapp  -:- Durham, NC -:- informatics.nescent.org :
>> ===========================================================
>> 
>> 
>> 
>> ------------------------------------------------------------------------------
>> Nokia and AT&T present the 2010 Calling All Innovators-North America contest
>> Create new apps & games for the Nokia N8 for consumers in  U.S. and Canada
>> $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
>> Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store 
>> http://p.sf.net/sfu/nokia-dev2dev_______________________________________________
>> Treebase-devel mailing list
>> Tre...@li...
>> https://lists.sourceforge.net/lists/listinfo/treebase-devel
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev_______________________________________________
> Treebase-devel mailing list
> Tre...@li...
> https://lists.sourceforge.net/lists/listinfo/treebase-devel

Re: [Treebase-devel] Treebase database has been migrated to new storage space

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

On Sep 24, 2010, at 10:59 AM, Jon Auman wrote:

> It took about 12 hours.  The migration started out quite fast, then slowed down as it was rebuilding the matrixelement index. Good news is that we also recovered 40 GB of disk space during the restore.  looks like the autovacuum in postgres 8.4 is not working as advertised (I'll look into it). 
> 
> The database now takes up about 140 GB, down from 180. We are on 400 GB volume, which can be expanded in future if needed.
> 
> I've reenabled login.
> 
> -Jon

Sounds great. Performance, so far, feels okay. 



One problem that has cropped up is that someone uploaded two batches of 5,000 trees -- and they can't be deleted except one-by-one, which is a royal pain. When trying to delete the two treeblocks (treeblock_id 12016 and 12113), I get some sort of null pointer exception. So instead, can you delete this manually?  I uploaded two blocks to a test submission in treebaseprod, and the below scripts worked -- so they should work okay for you too. In the "DELETE FROM taxonlabel" you may get zero lines affected, but that doesn't seem to be a problem. 

Can you go ahead and give this a try? In the event that you get some sort of error, you can rollback. 

thanks,

Bill


SELECT phylotree_id FROM phylotree WHERE treeblock_id IN (12016, 12113);
-- this should result in slightly less than 10,000 trees. If not, please abort.


-- Below are two sets of identical update/delete statements, which I suppose could 
-- be fused into one, if "treeblock_id = 12016" is replaced with "treeblock_id IN (12016, 12113)" 
-- but I have not tested that.

begin work;

-- Here we delete the trees in "treeblock_id = 12016"
-- --------------------------------------------------

UPDATE phylotree SET rootnode_id = DEFAULT WHERE treeblock_id = 12016 ;

DELETE FROM phylotreenode WHERE phylotree_id IN (
   SELECT phylotree_id FROM phylotree WHERE treeblock_id = 12016 
) ;

DELETE FROM sub_taxonlabel WHERE taxonlabel_id IN (
   SELECT DISTINCT taxonlabel_id 
   FROM taxonlabelset_taxonlabel JOIN taxonlabelset USING (taxonlabelset_id) 
   JOIN treeblock USING (taxonlabelset_id) 
   WHERE treeblock_id = 12016 
) ;

DELETE FROM taxonlabelset_taxonlabel WHERE taxonlabelset_id IN (
   SELECT taxonlabelset_id FROM treeblock WHERE treeblock_id = 12016 
) ;

-- delete taxonlabel records after having deleted the taxonlabelset_taxonlabel records
DELETE FROM taxonlabel WHERE taxonlabel_id IN (
   SELECT taxonlabel_id 
   FROM taxonlabel LEFT JOIN taxonlabelset_taxonlabel USING (taxonlabel_id) 
   WHERE study_id = (SELECT DISTINCT study_id FROM phylotree  WHERE treeblock_id = 12016) 
   AND taxonlabelset_id IS NULL
) ;

UPDATE treeblock SET taxonlabelset_id = DEFAULT WHERE treeblock_id = 12016 ;

-- Allows us to delete from taxonlabelset even after fk in treeblock 
-- has been reset to NULL 
DELETE FROM taxonlabelset WHERE taxonlabelset_id IN (
   SELECT DISTINCT taxonlabelset_id 
   FROM taxonlabelset LEFT JOIN taxonlabelset_taxonlabel tltl USING (taxonlabelset_id) 
   WHERE study_id = (
      SELECT DISTINCT study_id FROM phylotree  
      WHERE treeblock_id = 12016
      ) 
   AND tltl.taxonlabel_id IS NULL
) ;

DELETE FROM phylotree WHERE treeblock_id = 12016 ;

DELETE FROM sub_treeblock WHERE treeblock_id = 12016 ;

DELETE FROM treeblock WHERE treeblock_id = 12016 ;


-- Here we delete the trees in "treeblock_id = 12113"
-- --------------------------------------------------

UPDATE phylotree SET rootnode_id = DEFAULT WHERE treeblock_id = 12113 ;

DELETE FROM phylotreenode WHERE phylotree_id IN (
   SELECT phylotree_id FROM phylotree WHERE treeblock_id = 12113 
) ;

DELETE FROM sub_taxonlabel WHERE taxonlabel_id IN (
   SELECT DISTINCT taxonlabel_id 
   FROM taxonlabelset_taxonlabel JOIN taxonlabelset USING (taxonlabelset_id) 
   JOIN treeblock USING (taxonlabelset_id) 
   WHERE treeblock_id = 12113 
) ;

DELETE FROM taxonlabelset_taxonlabel WHERE taxonlabelset_id IN (
   SELECT taxonlabelset_id FROM treeblock WHERE treeblock_id = 12113 
) ;

-- delete taxonlabel records after having deleted the taxonlabelset_taxonlabel records
DELETE FROM taxonlabel WHERE taxonlabel_id IN (
   SELECT taxonlabel_id 
   FROM taxonlabel LEFT JOIN taxonlabelset_taxonlabel USING (taxonlabel_id) 
   WHERE study_id = (SELECT DISTINCT study_id FROM phylotree  WHERE treeblock_id = 12113) 
   AND taxonlabelset_id IS NULL
) ;

UPDATE treeblock SET taxonlabelset_id = DEFAULT WHERE treeblock_id = 12113 ;

-- Allows us to delete from taxonlabelset even after fk in treeblock 
-- has been reset to NULL 
DELETE FROM taxonlabelset WHERE taxonlabelset_id IN (
   SELECT DISTINCT taxonlabelset_id 
   FROM taxonlabelset LEFT JOIN taxonlabelset_taxonlabel tltl USING (taxonlabelset_id) 
   WHERE study_id = (
      SELECT DISTINCT study_id FROM phylotree  
      WHERE treeblock_id = 12113
      ) 
   AND tltl.taxonlabel_id IS NULL
) ;

DELETE FROM phylotree WHERE treeblock_id = 12113 ;

DELETE FROM sub_treeblock WHERE treeblock_id = 12113 ;

DELETE FROM treeblock WHERE treeblock_id = 12113 ;

commit; 

Re: [Treebase-devel] Fwd: new services from the UC Curation Center at the California Digital Library

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

hmm..  given that we're already advertising purls, if we issued yet another handle that would produce yet more redundancy, unless there are special advantages to these alternatives. So it it the case that the $1 per DOI cost is absorbed by someone else? (and forever?)

bp


On Sep 23, 2010, at 10:09 AM, Hilmar Lapp wrote:

> Any thoughts about possibly assigning DOIs to studies, or even trees, in TreeBASE? Perhaps something for the TreeBASE BoD to discuss at their upcoming meeting?
> 
> 	-hilmar
> 
> Begin forwarded message:
> 
> EZID (ee-zee-eye-dee) http://www.cdlib.org/services/uc3/ezid/index.html  is a service providing researchers and others a way to manage identifiers persistently for datasets, files, and resources of all types. The service is available via a machine to machine programming interface (an API) and as a web user interface. 
>  
> What’s so important about identifier management? Persistent identification of and access to a scholar’s research is critical to the long-term distribution and availability of her or his work. EZID lets you update not only a description of the work, but also its “forwarding address,” so no matter where the work moves, the citable, clickable link to the resource will continue to provide access.
>  
> Currently, EZID allows you to acquire DataCite <www.datacite.org <http://www.datacite.org> > Digital Object Identifiers (DOIs) or Archival Resource Keys (ARKs), and we plan to add other identifier schemes going forward. In the future, we will also support object deposit options.
>  
> All disciplines can benefit from using EZID. It transcends domain boundaries and is applicable to the sciences, humanities and the social sciences.  It will work with a range of data types including numerical, images, text sequences, text, digital audio, digital video, modeling data and more.
>  
> Dryad is an EZID user and we would like to open this service to the DataONE community.  You can test the service at: http://n2t.net/ezid/help 
>  
> 
> -- 
> ===========================================================
> : Hilmar Lapp  -:- Durham, NC -:- informatics.nescent.org :
> ===========================================================
> 
> 
> 
> ------------------------------------------------------------------------------
> Nokia and AT&T present the 2010 Calling All Innovators-North America contest
> Create new apps & games for the Nokia N8 for consumers in  U.S. and Canada
> $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
> Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store 
> http://p.sf.net/sfu/nokia-dev2dev_______________________________________________
> Treebase-devel mailing list
> Tre...@li...
> https://lists.sourceforge.net/lists/listinfo/treebase-devel

Re: [Treebase-devel] R, apTreeshape, and dbtree

[Rutger V. <rut...@gm...>]

Hi Mick,

that's great news!

Rutger

On Sat, Sep 25, 2010 at 12:48 AM, Michael Elliot <mi...@sf...> wrote:
> Hi,
>
> I had a busy month or two with various admin things around here, but I plan to get back to working on NCL starting at the beginning of October.
>
> Mick
>
>
>
> ----- Original Message -----
> From: "Rutger Vos" <rut...@gm...>
> To: "Todd Vision" <tj...@bi...>
> Cc: tre...@li..., "Aaron J. Mackey" <ajm...@gm...>, "Mark Holder" <mth...@ku...>, "Michael Elliot" <mi...@sf...>
> Sent: Friday, September 24, 2010 3:37:57 PM
> Subject: Re: [Treebase-devel] R, apTreeshape, and dbtree
>
> Interesting idea. I don't see Aaron's NeXML code in the phylobase
> repository (though I may be overlooking it?). What I did see is that
> it uses NCL, so perhaps this is contingent on NCL supporting NeXML.
> What is the status of the latter? Has this gone completely on ice?
>
> On Fri, Sep 24, 2010 at 7:27 PM, Todd Vision <tj...@bi...> wrote:
>>
>> All,
>>
>> An interesting thread from the R-sig-phylo list below.   I believe the only databases that dbtree formerly supported were treebase and pandit.  It might be worthwhile dusting off Aaron Mackey's code for reading NeXML in the R phylobase module and building in support for web service access to TreeBase directly.
>>
>> Todd
>>
>> Begin forwarded message:
>>
>>> From: Eric Durand <eri...@be...>
>>> Date: September 24, 2010 12:20:15 PM EDT
>>> To: Andre Levy <and...@gm...>
>>> Cc: "r-s...@r-..." <r-s...@r-...>
>>> Subject: Re: [R-sig-phylo] dbtrees
>>>
>>> Hi Andre,
>>>
>>> You are correct, we removed the dbtree function. This is because tree databases were changing too fast and too much, so this function was too difficult to maintain. The best way to access trees is, imo, to go online to the database web interface directly, then download the trees to a local file before reading them into R.
>>>
>>> Cheers,
>>> Eric
>>>
>>> On Sep 24, 2010, at 9:16 AM, Andre Levy wrote:
>>>
>>>> Hi All
>>>> I'm new to R and to APE. Am starting by reading and going through Paradis' book, and have already stumbled on the changes to apTreeshape. Have already found the new pdf package description (dated April 23, 2010; most recent?) and found an older one from 2007. (Also found a pdf describing Ape dated June 2010)
>>>>
>>>> By comparing the two pdfs of apTreeshape I gather that the "dbtrees" function is no longer incorporated. Is there another alternative for grabbing trees from a tree database?
>>>>
>>>> Cheers
>>>> André Levy
>>>>
>>>> Unidade de Investigação em Eco-Etologia / Eco-Ethology Research Unit
>>>> ISPA - Instituto Universitário
>>>> Rua Jardim do Tabaco 34, 1149-041 LISBOA Portugal
>>>> Tel: ++351 218 811 700  Fax: ++351 218 860 954
>>>> http://www.ispa.pt/ui/uie/bcao/andre_levy.asp
>>>>
>>>> Centro de Biociências / Biosciences Center
>>>> (same mailing address)
>>>> http://centrodebiociencias.webnode.com/
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Start uncovering the many advantages of virtual appliances
>> and start using them to simplify application deployment and
>> accelerate your shift to cloud computing.
>> http://p.sf.net/sfu/novell-sfdev2dev
>> _______________________________________________
>> 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://www.nexml.org
> http://rutgervos.blogspot.com
>



-- 
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://www.nexml.org
http://rutgervos.blogspot.com

Re: [Treebase-devel] R, apTreeshape, and dbtree

[Michael E. <mi...@sf...>]

Hi, 

I had a busy month or two with various admin things around here, but I plan to get back to working on NCL starting at the beginning of October.

Mick



----- Original Message -----
From: "Rutger Vos" <rut...@gm...>
To: "Todd Vision" <tj...@bi...>
Cc: tre...@li..., "Aaron J. Mackey" <ajm...@gm...>, "Mark Holder" <mth...@ku...>, "Michael Elliot" <mi...@sf...>
Sent: Friday, September 24, 2010 3:37:57 PM
Subject: Re: [Treebase-devel] R, apTreeshape, and dbtree

Interesting idea. I don't see Aaron's NeXML code in the phylobase
repository (though I may be overlooking it?). What I did see is that
it uses NCL, so perhaps this is contingent on NCL supporting NeXML.
What is the status of the latter? Has this gone completely on ice?

On Fri, Sep 24, 2010 at 7:27 PM, Todd Vision <tj...@bi...> wrote:
>
> All,
>
> An interesting thread from the R-sig-phylo list below.   I believe the only databases that dbtree formerly supported were treebase and pandit.  It might be worthwhile dusting off Aaron Mackey's code for reading NeXML in the R phylobase module and building in support for web service access to TreeBase directly.
>
> Todd
>
> Begin forwarded message:
>
>> From: Eric Durand <eri...@be...>
>> Date: September 24, 2010 12:20:15 PM EDT
>> To: Andre Levy <and...@gm...>
>> Cc: "r-s...@r-..." <r-s...@r-...>
>> Subject: Re: [R-sig-phylo] dbtrees
>>
>> Hi Andre,
>>
>> You are correct, we removed the dbtree function. This is because tree databases were changing too fast and too much, so this function was too difficult to maintain. The best way to access trees is, imo, to go online to the database web interface directly, then download the trees to a local file before reading them into R.
>>
>> Cheers,
>> Eric
>>
>> On Sep 24, 2010, at 9:16 AM, Andre Levy wrote:
>>
>>> Hi All
>>> I'm new to R and to APE. Am starting by reading and going through Paradis' book, and have already stumbled on the changes to apTreeshape. Have already found the new pdf package description (dated April 23, 2010; most recent?) and found an older one from 2007. (Also found a pdf describing Ape dated June 2010)
>>>
>>> By comparing the two pdfs of apTreeshape I gather that the "dbtrees" function is no longer incorporated. Is there another alternative for grabbing trees from a tree database?
>>>
>>> Cheers
>>> André Levy
>>>
>>> Unidade de Investigação em Eco-Etologia / Eco-Ethology Research Unit
>>> ISPA - Instituto Universitário
>>> Rua Jardim do Tabaco 34, 1149-041 LISBOA Portugal
>>> Tel: ++351 218 811 700  Fax: ++351 218 860 954
>>> http://www.ispa.pt/ui/uie/bcao/andre_levy.asp
>>>
>>> Centro de Biociências / Biosciences Center
>>> (same mailing address)
>>> http://centrodebiociencias.webnode.com/
>
>
>
>
> ------------------------------------------------------------------------------
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> 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://www.nexml.org
http://rutgervos.blogspot.com

Re: [Treebase-devel] R, apTreeshape, and dbtree

[Rutger V. <rut...@gm...>]

Interesting idea. I don't see Aaron's NeXML code in the phylobase
repository (though I may be overlooking it?). What I did see is that
it uses NCL, so perhaps this is contingent on NCL supporting NeXML.
What is the status of the latter? Has this gone completely on ice?

On Fri, Sep 24, 2010 at 7:27 PM, Todd Vision <tj...@bi...> wrote:
>
> All,
>
> An interesting thread from the R-sig-phylo list below.   I believe the only databases that dbtree formerly supported were treebase and pandit.  It might be worthwhile dusting off Aaron Mackey's code for reading NeXML in the R phylobase module and building in support for web service access to TreeBase directly.
>
> Todd
>
> Begin forwarded message:
>
>> From: Eric Durand <eri...@be...>
>> Date: September 24, 2010 12:20:15 PM EDT
>> To: Andre Levy <and...@gm...>
>> Cc: "r-s...@r-..." <r-s...@r-...>
>> Subject: Re: [R-sig-phylo] dbtrees
>>
>> Hi Andre,
>>
>> You are correct, we removed the dbtree function. This is because tree databases were changing too fast and too much, so this function was too difficult to maintain. The best way to access trees is, imo, to go online to the database web interface directly, then download the trees to a local file before reading them into R.
>>
>> Cheers,
>> Eric
>>
>> On Sep 24, 2010, at 9:16 AM, Andre Levy wrote:
>>
>>> Hi All
>>> I'm new to R and to APE. Am starting by reading and going through Paradis' book, and have already stumbled on the changes to apTreeshape. Have already found the new pdf package description (dated April 23, 2010; most recent?) and found an older one from 2007. (Also found a pdf describing Ape dated June 2010)
>>>
>>> By comparing the two pdfs of apTreeshape I gather that the "dbtrees" function is no longer incorporated. Is there another alternative for grabbing trees from a tree database?
>>>
>>> Cheers
>>> André Levy
>>>
>>> Unidade de Investigação em Eco-Etologia / Eco-Ethology Research Unit
>>> ISPA - Instituto Universitário
>>> Rua Jardim do Tabaco 34, 1149-041 LISBOA Portugal
>>> Tel: ++351 218 811 700  Fax: ++351 218 860 954
>>> http://www.ispa.pt/ui/uie/bcao/andre_levy.asp
>>>
>>> Centro de Biociências / Biosciences Center
>>> (same mailing address)
>>> http://centrodebiociencias.webnode.com/
>
>
>
>
> ------------------------------------------------------------------------------
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> 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://www.nexml.org
http://rutgervos.blogspot.com

[Treebase-devel] R, apTreeshape, and dbtree

[Todd V. <tj...@bi...>]

All,

An interesting thread from the R-sig-phylo list below.   I believe the only databases that dbtree formerly supported were treebase and pandit.  It might be worthwhile dusting off Aaron Mackey's code for reading NeXML in the R phylobase module and building in support for web service access to TreeBase directly.

Todd

Begin forwarded message:

> From: Eric Durand <eri...@be...>
> Date: September 24, 2010 12:20:15 PM EDT
> To: Andre Levy <and...@gm...>
> Cc: "r-s...@r-..." <r-s...@r-...>
> Subject: Re: [R-sig-phylo] dbtrees
> 
> Hi Andre,
> 
> You are correct, we removed the dbtree function. This is because tree databases were changing too fast and too much, so this function was too difficult to maintain. The best way to access trees is, imo, to go online to the database web interface directly, then download the trees to a local file before reading them into R. 
> 
> Cheers,
> Eric
> 
> On Sep 24, 2010, at 9:16 AM, Andre Levy wrote:
> 
>> Hi All
>> I'm new to R and to APE. Am starting by reading and going through Paradis' book, and have already stumbled on the changes to apTreeshape. Have already found the new pdf package description (dated April 23, 2010; most recent?) and found an older one from 2007. (Also found a pdf describing Ape dated June 2010)
>> 
>> By comparing the two pdfs of apTreeshape I gather that the "dbtrees" function is no longer incorporated. Is there another alternative for grabbing trees from a tree database?
>> 
>> Cheers
>> André Levy
>> 
>> Unidade de Investigação em Eco-Etologia / Eco-Ethology Research Unit
>> ISPA - Instituto Universitário
>> Rua Jardim do Tabaco 34, 1149-041 LISBOA Portugal
>> Tel: ++351 218 811 700  Fax: ++351 218 860 954 
>> http://www.ispa.pt/ui/uie/bcao/andre_levy.asp
>> 
>> Centro de Biociências / Biosciences Center
>> (same mailing address)
>> http://centrodebiociencias.webnode.com/

[Treebase-devel] Treebase database has been migrated to new storage space

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

It took about 12 hours.  The migration started out quite fast, then slowed down as it was rebuilding the matrixelement index. Good news is that we also recovered 40 GB of disk space during the restore.  looks like the autovacuum in postgres 8.4 is not working as advertised (I'll look into it). 

The database now takes up about 140 GB, down from 180. We are on 400 GB volume, which can be expanded in future if needed.

I've reenabled login.

-Jon

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

Re: [Treebase-devel] crossdomain.xml

[Rutger V. <rut...@gm...>]

I agree with closing this tracker issue.

On Thu, Sep 23, 2010 at 1:16 PM, Jon Auman <jon...@ne...> wrote:
> I therefore recommend we NOT institute a crossdomain.xml for treebase.org.
> It would not be difficult for a user to get access to embargoed data, and
> treebase could lose its credibility if that happened. It also may be
> possible for a hacker to redirect treebase users to a malicious web
> application.
> The following post states that cookie based authentication is particularly
> vulnerable:
> http://www.jamesward.com/2009/11/08/how-bad-crossdomain-policies-expose-protected-data-to-malicious-applications/
> If all I agree, I recommend we close the following issue in tracker with
> security concerns as the reason:
> https://sourceforge.net/tracker/?func=detail&aid=2977283&group_id=248804&atid=1126676
>
> thanks,
> -Jon
> On Sep 23, 2010, at 7:14 AM, Rutger Vos wrote:
>
> There is data that is under embargo and should only be accessible by
> the submitter(s) and reviewer(s). Session is maintained using cookies.
>
> On Wed, Sep 22, 2010 at 9:57 PM, Jon Auman <jon...@ne...> wrote:
>
> I looked some more into the crossdomain.xml file that allows Adobe Flash
>
> applications to access phylows data. The security implication is that all
>
> data on the treebase server could become public. Is that OK? Is there any
>
> data that should not become public?
>
> Also, does treebase application use cookies for session maintenance or web
>
> service tokens or some other means for authentication?
>
> Thanks,
>
> Jon
>
> -------------------------------------------------------
>
> Jon Auman
>
> Systems Administrator
>
> National Evolutionary Synthesis Center
>
> Duke University
>
> http:www.nescent.org
>
> jon...@ne...
>
> ------------------------------------------------------
>
>
>
> ------------------------------------------------------------------------------
>
> Start uncovering the many advantages of virtual appliances
>
> and start using them to simplify application deployment and
>
> accelerate your shift to cloud computing.
>
> http://p.sf.net/sfu/novell-sfdev2dev
>
> _______________________________________________
>
> 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://www.nexml.org
> http://rutgervos.blogspot.com
>
> ------------------------------------------------------------------------------
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> 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...
> ------------------------------------------------------
>
>
>



-- 
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://www.nexml.org
http://rutgervos.blogspot.com

[Treebase-devel] Fwd: new services from the UC Curation Center at the California Digital Library

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

Any thoughts about possibly assigning DOIs to studies, or even trees,  
in TreeBASE? Perhaps something for the TreeBASE BoD to discuss at  
their upcoming meeting?

	-hilmar

Begin forwarded message:

EZID (ee-zee-eye-dee) http://www.cdlib.org/services/uc3/ezid/ 
index.html  is a service providing researchers and others a way to  
manage identifiers persistently for datasets, files, and resources of  
all types. The service is available via a machine to machine  
programming interface (an API) and as a web user interface.

What’s so important about identifier management? Persistent  
identification of and access to a scholar’s research is critical to  
the long-term distribution and availability of her or his work. EZID  
lets you update not only a description of the work, but also its  
“forwarding address,” so no matter where the work moves, the citable,  
clickable link to the resource will continue to provide access.

Currently, EZID allows you to acquire DataCite <www.datacite.org <http://www.datacite.org 
 > > Digital Object Identifiers (DOIs) or Archival Resource Keys  
(ARKs), and we plan to add other identifier schemes going forward. In  
the future, we will also support object deposit options.

All disciplines can benefit from using EZID. It transcends domain  
boundaries and is applicable to the sciences, humanities and the  
social sciences.  It will work with a range of data types including  
numerical, images, text sequences, text, digital audio, digital video,  
modeling data and more.

Dryad is an EZID user and we would like to open this service to the  
DataONE community.  You can test the service at: http://n2t.net/ezid/help


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

Re: [Treebase-devel] Disk space for treebase production database

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

On Sep 22, 2010, at 5:51 PM, Vladimir Gapeyev wrote:

> SVN 752 comments out the login form on login.jsp, as suggested.  To  
> see how it looks, go to
> http://treebase-dev.nescent.org/treebase-web/login.jsp
> 
> If that's fine, Jon will build this version on production and then  
> proceed migrating to the new disk.
> 
> --Vladimir

looks good.

bp

Re: [Treebase-devel] crossdomain.xml

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

I therefore recommend we NOT institute a crossdomain.xml for treebase.org. It would not be difficult for a user to get access to embargoed data, and treebase could lose its credibility if that happened. It also may be possible for a hacker to redirect treebase users to a malicious web application.

The following post states that cookie based authentication is particularly vulnerable: 

http://www.jamesward.com/2009/11/08/how-bad-crossdomain-policies-expose-protected-data-to-malicious-applications/

If all I agree, I recommend we close the following issue in tracker with security concerns as the reason:
https://sourceforge.net/tracker/?func=detail&aid=2977283&group_id=248804&atid=1126676

thanks,
-Jon

On Sep 23, 2010, at 7:14 AM, Rutger Vos wrote:

> There is data that is under embargo and should only be accessible by
> the submitter(s) and reviewer(s). Session is maintained using cookies.
> 
> On Wed, Sep 22, 2010 at 9:57 PM, Jon Auman <jon...@ne...> wrote:
>> I looked some more into the crossdomain.xml file that allows Adobe Flash
>> applications to access phylows data. The security implication is that all
>> data on the treebase server could become public. Is that OK? Is there any
>> data that should not become public?
>> Also, does treebase application use cookies for session maintenance or web
>> service tokens or some other means for authentication?
>> Thanks,
>> Jon
>> -------------------------------------------------------
>> Jon Auman
>> Systems Administrator
>> National Evolutionary Synthesis Center
>> Duke University
>> http:www.nescent.org
>> jon...@ne...
>> ------------------------------------------------------
>> 
>> 
>> 
>> ------------------------------------------------------------------------------
>> Start uncovering the many advantages of virtual appliances
>> and start using them to simplify application deployment and
>> accelerate your shift to cloud computing.
>> http://p.sf.net/sfu/novell-sfdev2dev
>> _______________________________________________
>> 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://www.nexml.org
> http://rutgervos.blogspot.com
> 
> ------------------------------------------------------------------------------
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> 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...
------------------------------------------------------

Re: [Treebase-devel] crossdomain.xml

[Rutger V. <rut...@gm...>]

There is data that is under embargo and should only be accessible by
the submitter(s) and reviewer(s). Session is maintained using cookies.

On Wed, Sep 22, 2010 at 9:57 PM, Jon Auman <jon...@ne...> wrote:
> I looked some more into the crossdomain.xml file that allows Adobe Flash
> applications to access phylows data. The security implication is that all
> data on the treebase server could become public. Is that OK? Is there any
> data that should not become public?
> Also, does treebase application use cookies for session maintenance or web
> service tokens or some other means for authentication?
> Thanks,
> Jon
> -------------------------------------------------------
> Jon Auman
> Systems Administrator
> National Evolutionary Synthesis Center
> Duke University
> http:www.nescent.org
> jon...@ne...
> ------------------------------------------------------
>
>
>
> ------------------------------------------------------------------------------
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> 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://www.nexml.org
http://rutgervos.blogspot.com

Re: [Treebase-devel] Disk space for treebase production database

[Vladimir G. <vla...@du...>]

SVN 752 comments out the login form on login.jsp, as suggested.  To  
see how it looks, go to
http://treebase-dev.nescent.org/treebase-web/login.jsp

If that's fine, Jon will build this version on production and then  
proceed migrating to the new disk.

--Vladimir


On Sep 14, 2010, at 9:22 AM, Hilmar Lapp wrote:

>
> On Sep 14, 2010, at 6:34 AM, Rutger Vos wrote:
>
>>> I don't think we have an easy toggle for turning off submissions --
>>> other than temporarily commenting out the login.jsp code. Do the
>>> developers see that as an adequate measure?
>>>
>>
>> That seems like the easiest way to do it, yes.
>
> And it would seem worth the (presumably moderate to little) effort to
> have TreeBASE not go entirely offline for 2 days.
>
> 	-hilmar
>
> -- 
> ===========================================================
> : Hilmar Lapp  -:- Durham, NC -:- informatics.nescent.org :
> ===========================================================
>
>
>
>
> ------------------------------------------------------------------------------
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> Treebase-devel mailing list
> Tre...@li...
> https://lists.sourceforge.net/lists/listinfo/treebase-devel

[Treebase-devel] crossdomain.xml

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

I looked some more into the crossdomain.xml file that allows Adobe Flash applications to access phylows data. The security implication is that all data on the treebase server could become public. Is that OK? Is there any data that should not become public?

Also, does treebase application use cookies for session maintenance or web service tokens or some other means for authentication?

Thanks,
Jon

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