[Treebase-devel] Some results of testing with a user

[Vladimir G. <vga...@ne...>]

I had a Treebase session with a NESCenet postdoc, Eric Schuettpelz.   
Besides several usability issues that might be interesting for future,  
here are the more prominent issues that might bear on the release  
decisions, in increasing order of my perceived importance.

A note: treebase.nescent.org is currently the only properly operating  
instance of the application, see (3).  It is currently connected to  
the development database at treebase-dev.nescent.org/treebasedev.


(1) Unexpected different results on the Taxa tab -- a feature or a  
bug? E.g., find a single study, e.g. 10051.
     -- Click the study (which goes to Citation tab), then to Taxa tab  
==> "Nothing to display"
     -- Go to Matrices tab; click on "View Taxa" in the table ==> it  
goes back to the Taxa tab, showing lots of stuff
     -- Go back to Citation tab; then Taxa tab  ==> "Nothing found to  
display"
    -- Go to Trees tab; click on "View Taxa" in the table ==> it goes  
back to the Taxa tab, showing lots of stuff.


(2) An ominous message when Phylowidget loads: "An applet requires  
access to your computer.  The digital signature could not be verified."


(3) Havoc from purls.  Since sometime recently, *some* links that are  
crucial for the functionality of the application contain purls instead  
of urls pointing to the current application instance.  Due to the  
current resolution of the purls, this makes all instances to  
eventually drift to the treebase.nescent.org instance.

For example, in search results > Matrices tab:
     the columns ID, Download NeXML, Download RDF, and Download  
Reconstructed, and Matrix Row List contain purl links  (Wrong!),
     while the columns Taxa and Download Original have links to the  
current instance (Right!)
Interestingly, in the Trees tab all the similarly appearing links  
point to the current instance. (Right!)

My wrong/right assessment above derives from this:
    - A purl is just a canonical unique identifier for a data object.  
Resolvability of a purl is a bonus, but should not be required.
    - A purl occurrence on a page of an application is for  
informational purposes only, i.e. operation of an application instance  
should not depend on the purl being resolvable.
Consequently, I think the only legitimate purl occurrences are the  
places where the purls are spelled out in text, as e.g.,  the  
"Canonical resource URI" for the study on the Citation tab.


(4)  We noticed that some many tree and matrix entries had original  
files missing. It seemed like a big data problem to me initially, but  
the more I look into it, the less I understand how things are intended  
to be, so I'll just enumerate the bothersome issues.

    - In some studies, e.g. #10065, the "Download original file" link,  
both for matrices and trees, brings up a text file that contains  
something like "File Not Found. File Name is: M4552.nex".  This study  
does no have an entry in the study_nexusfile table (which, I think, is  
supposed to contain the original files), and there are many such  
studies.

   - The temporary study 10215, which was used for migration uploads,  
is associated with 492 files in study_nexus file. This might be the  
missing files, but isn't the number too low?

   - On the other hand, migration dumps only contained tree or matrix  
files, while original files are expected to be mixed in general,  
right? Then the migration was not supposed to put original files into  
the DB, how could it?

  - I checked a few studies that do have files in study_nexusfile.  
E.g., #823. They do return these files through the  the "Download  
original file" link, but the tree and matrix entries for these studies  
do not offer links to download NeXML and RDF.


Of these, (1) and (2) might be passable for the release. With (4), it  
is either a huge problem or not a big deal.

With (3), we can go to production tomorrow by just re-pointing  
treebase.nescent.org to the production database.  However, after that  
we will not have an instance where to test newer versions of the  
application (since many links on treebase-dev.nescent.org resolve, via  
purls, to treebase.nescent.org).  If it were up to me, I'd prefer the  
purls issue resolved before Treebase goes live.  I can probably track  
down and correct the wrong links myself, within about a day of work.  
However, my understanding of the role of purls was not orthodox in the  
past.

--Vladimir