Menu
▾
▴
treebase-devel
|
From: Vladimir G. <vga...@ne...> - 2010-03-19 01:07:07
|
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 |
|
From: William P. <wil...@ya...> - 2010-03-19 03:10:28
|
On Mar 18, 2010, at 9:06 PM, Vladimir Gapeyev wrote: > (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. It looks as though the taxon intel data did not get uploaded properly. Study 10051 has the taxon label "Polystichum acutidens DQ202419" which in my latest TI dump maps to the taxon variant "Polystichum acutidens" (namebankid 5977443) and that, in turn, maps to the taxon "Polystichum acutidens" (taxid 265680). But going through the browser shows no results under the taxon tab. 10052 has no taxon mappings (even though my TI tables do) 10053 has no taxon mappings (even though my TI tables do) etc. I queried treebase-stage with this: select * from taxonlabel join taxonvariant using (taxonvariant_id) where taxonlabel = 'Coniothyrium clematidis-rectae CBS 507.63' Because 'Coniothyrium clematidis-rectae CBS 507.63' is one of the taxon labels in 10053 that fails to map to a taxonvariant. To my surprise, the results of the query show that the mapping is in place -- taxonlabel 'Coniothyrium clematidis-rectae CBS 507.63' is mapped to taxonvariant_id 562599 in the database. So something is quite wrong here. It looks like the March migration starts at S9931 -- I examined that one and the browser shows no taxon mapping. So then I looked prior to that, and only be the time I reached S2256 did the mapping work again. This is affecting too many records, and I'm worried that it is a harbinger of other problems. I think we need to resolve this. bp |
|
From: William P. <wil...@ya...> - 2010-03-19 03:36:44
|
On Mar 18, 2010, at 11:10 PM, William Piel wrote: > This is affecting too many records, and I'm worried that it is a harbinger of other problems. I think we need to resolve this. Does anyone known the function of the field called "linked" in the taxonlabel table? select count(*) from taxonlabel where linked = 'f' = 167,090 select count(*) from taxonlabel where linked = 't' = 1,228 On the one hand, this seems like a suspicious candidate for the TI mapping failure. On the other hand, *too* many records have "f" -- so it seemingly can't explain the problem. bp |
|
From: William P. <wil...@ya...> - 2010-03-19 03:26:08
|
On Mar 18, 2010, at 9:06 PM, Vladimir Gapeyev wrote: > (2) An ominous message when Phylowidget loads: "An applet requires access to your computer. The digital signature could not be verified." It does sound a little scary. Is there a workaround, or would we have to purchase something from Verisign (or whatever)? > (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. This should not be a problem when we serve from production, right? > Consequently, I think the only legitimate purl occurrences are the places where the purls are spelled out in text Good point. Let's make a mental note of this -- but for now it's probably not a show-stopper. > - 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? there were only 99 studies in the last migration -- so 492 files (some matrices others blocks of trees) sounds about right. > - 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? For TB1 data, we don't have the real original files, so we intended to use the migration files instead. We should fix this, but not a show-stopper IMO. > - 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. I see the NeXML and RDF links: http://treebase.nescent.org/treebase-web/search/study/matrices.html?id=823 > 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. I'm with you regarding fixing the purls, but maybe that's not a show-stopper seeing as the main benefit is to make it easier for us to de-bug the dev deployment. bp |
|
From: William P. <wil...@ya...> - 2010-03-19 04:13:28
|
On Mar 18, 2010, at 11:10 PM, William Piel wrote: > only be the time I reached S2256 did the mapping work again. It looks to me like the mis-mapping of taxa is concentrated between S2257 and S10215. Before S2257, the data look okay. After S10215, they also perform okay. bp |
|
From: William P. <wil...@ya...> - 2010-03-19 13:27:32
|
On Mar 19, 2010, at 12:13 AM, William Piel wrote: > On Mar 18, 2010, at 11:10 PM, William Piel wrote: > >> only be the time I reached S2256 did the mapping work again. > > It looks to me like the mis-mapping of taxa is concentrated between S2257 and S10215. Before S2257, the data look okay. After S10215, they also perform okay. Vladimir -- are you investigating this issue? bp |
|
From: Rutger V. <rut...@gm...> - 2010-03-19 08:47:45
|
> (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!) I implemented this. Since the re-configuration of tomcat to run multiple instances of the webapp some links had been pointing to localhost. After discussion on this list it was decided that it would be OK to have these links be purls instead, and I personally believe this is not just OK but actually important, especially if these download links point to RDF. So not "Wrong!", but just not to your liking. You're welcome to reopen the relevant ticket (2960909), restart the discussion (I believe agreement was reached roughly here: https://sourceforge.net/mailarchive/message.php?msg_name=04E...@ne...) and wait for me to fix the issue again, this time to your specification. |
|
From: William P. <wil...@ya...> - 2010-03-19 13:26:19
|
On Mar 19, 2010, at 4:47 AM, Rutger Vos wrote: > After discussion on this list it was decided that it would > be OK to have these links be purls instead it certainly helps prevent the proliferation of synonymous URIs if all /phylows/ urls have the same domain syntax. bp |
|
From: Hilmar L. <hl...@ne...> - 2010-03-19 14:34:32
|
The PURLs need to be thought of as the canonical, globally unique, and resolvable (yes!) identifier for data items in TreeBASE. The way to look at them I think should be as if they were DOIs, or Handles, or LSIDs. We are dispensing GUIDs for data items in TreeBASE, and rather than DOIs or Handles they happen to be HTTP URIs that resolve. This is the Right Thing (tm) from a SemWeb and Linked Data perspective. A GUID for a data item should resolve to one and only one location, so that they resolve to production is also the Right Thing, and in line with the behavior of DOIs. Publishers cannot test their article DOIs solely on development systems either: DOIs always resolve to their production sites. Dryad faces the same problem. What's important here is not to use canonical GUIDs frivolously. They must be advertised to the user in appropriate locations, and they must be used consistently in output that we emit to be consumed by machines. The question is less clear whether they should be used throughout by the application wherever it hyperlinks within the UI to a representation (in HTML, NeXML, or RDF) of a data item. A machine will not benefit from this, and I'm not sure how the human user would. Publishers don't link to article downloads through the DOI. Dryad does link through the DOI or Handle to data files that are part of a data package. However, that's primarily because the UI for this is just an HTML rendering of the data package's metadata, and the IDs of the constituent data files are their Handles (or DOIs). Bottom line from my perspective: 1) we shouldn't confuse data object GUID HTTP URIs with URLs that the application uses to allow a human user to navigate the web-app; 2) regardless we need to be able to test our HTTP URIs that serve as GUIDs. Re: #1, even if currently we overuse canonical GUIDs in the UI, I don't think we need to address this before release. Re: #2, we already have a configuration parameter to control the base URL for the GUIDs. Eventually I would like us to have our own PURL server at http://purl.treebase.org , but we're not going to accomplish that today or shortly. So instead I created the following alternative base URLs, with obvious redirection: http://purl.org/phylo/treebase/dev/phylows/ http://purl.org/phylo/treebase/stage/phylows/ -hilmar On Mar 19, 2010, at 3:47 AM, Rutger Vos wrote: >> (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!) > > I implemented this. Since the re-configuration of tomcat to run > multiple instances of the webapp some links had been pointing to > localhost. After discussion on this list it was decided that it would > be OK to have these links be purls instead, and I personally believe > this is not just OK but actually important, especially if these > download links point to RDF. So not "Wrong!", but just not to your > liking. You're welcome to reopen the relevant ticket (2960909), > restart the discussion (I believe agreement was reached roughly here: > https://sourceforge.net/mailarchive/message.php?msg_name=04E...@ne...) > and wait for me to fix the issue again, this time to your > specification. > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Treebase-devel mailing list > Tre...@li... > https://lists.sourceforge.net/lists/listinfo/treebase-devel -- =========================================================== : Hilmar Lapp -:- Durham, NC -:- informatics.nescent.org : =========================================================== |
|
From: Ryan S. <rsc...@ne...> - 2010-03-19 14:43:04
|
> (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. IMHO, the Purl should be used anywhere you can reasonably expect a user to copy-and-paste a URL. Definitely in the citations. The Purl should at least appear on each page that a user might link to. One tactic we use with Dryad is to prominently display which server is in use (for example, compare the logo at top-left for http://datadryad.org and http://demo.datadryad.org ). It doesn't keep you from bouncing between servers, but at least you have an idea where you are. A better solution is to replace the Purls with some other URL on the non-production servers, but this adds some complexity to the code. --- Ryan |
|
From: William P. <wil...@ya...> - 2010-03-19 15:02:11
|
On Mar 19, 2010, at 10:42 AM, Ryan Scherle wrote: > IMHO, the Purl should be used anywhere you can reasonably expect a user to copy-and-paste a URL. Definitely in the citations. The Purl should at least appear on each page that a user might link to. The only real "Havoc from purls" comes from people using treebase-stage and treebase-dev. One solution is to have new purl.org/phylo/treebase entries for these instance too (e.g. purl.org/phylo/treebase-stage and purl.org/phylo/treebase-dev) and then for each build, use a config file to enter which purl to use for that particular build. bp |
|
From: Rutger V. <rut...@gm...> - 2010-03-19 15:04:41
|
> The question is less clear whether they should be used throughout by the > application wherever it hyperlinks within the UI to a representation (in > HTML, NeXML, or RDF) of a data item. A machine will not benefit from this, > and I'm not sure how the human user would. My worry is that, by placing ugly webapp download links in the public GUI, the Rod Pages of this world will copy & paste those, distribute them, build hacks around them, etc. To discourage that, anything that looks like a context-free link to a resource (as opposed to something reasonably associated with search or submission) should be a purl, in my opinion. |
|
From: William P. <wil...@ya...> - 2010-03-19 15:11:29
|
On Mar 19, 2010, at 10:34 AM, Hilmar Lapp wrote: > A machine will not benefit from this, and I'm not sure how the human user would. Our current Web UI only explicitly advertises the purl-phylows URI to the submitter and only for the study_id. This means that some people, seeking to link to other objects in TreeBASE, will be using right-click-copy as a lazy shortcut instead of reading the documentation. To prevent proliferation of synonymous /phyows/ links getting out there, we decided to use purl.org links wherever /phylows/ links are present. So the lazy "human user" benefits because right-click-copy is a quick way for them to bookmark objects in TreeBASE without having to edit the copied link to comply with our purl.org standard. bp |
|
From: Hilmar L. <hl...@ne...> - 2010-03-19 15:18:55
|
On Mar 19, 2010, at 10:11 AM, William Piel wrote: > To prevent proliferation of synonymous /phyows/ links getting out > there, we decided to use purl.org links wherever /phylows/ links are > present. > > So the lazy "human user" benefits because right-click-copy is a > quick way for them to bookmark objects in TreeBASE without having to > edit the copied link to comply with our purl.org standard. Note that this is a use-case that's distinctly different from canonical resolvable GUIDs for data objects to play with the semweb. The above is basically saying that we want bookmarks that people make in their web browser to be protected from a future change in how the TreeBASE webapp is implemented. For example, if we change to RoR, those bookmarks should still work. This is a worthwhile use-case, but I think it's good to keep in mind that it ought to be far less in priority than getting canonical HTTP URIs communicated to machine clients. -hilmar -- =========================================================== : Hilmar Lapp -:- Durham, NC -:- informatics.nescent.org : =========================================================== |
|
From: Hilmar L. <hl...@ne...> - 2010-03-19 15:14:11
|
On Mar 19, 2010, at 10:04 AM, Rutger Vos wrote: > My worry is that, by placing ugly webapp download links in the public > GUI, the Rod Pages of this world will copy & paste those, distribute > them, build hacks around them, etc. I appreciate your point (even though I don't agree [1]). However, the current solution doesn't address it, because the URL that is easiest to copy&paste, namely the one in the address bar, still is an application URL. -hilmar [1] Especially the Rod Pages of this world understand the problem well enough to not do this, I'd worry about those who aren't trained enough, which basically translates to a need for more training. Making application programming more intricate and less easy to test isn't the right solution to this, in my opinion. I think we need to architect for the future, and in the future the majority of people will be well trained in this b/c the semantic web will be omnipresent. -- =========================================================== : Hilmar Lapp -:- Durham, NC -:- informatics.nescent.org : =========================================================== |
|
From: Rutger V. <rut...@gm...> - 2010-03-19 15:16:47
|
> [1] Especially the Rod Pages of this world understand the problem well > enough to not do this, I'd worry about those who aren't trained enough, > which basically translates to a need for more training. Making application > programming more intricate and less easy to test isn't the right solution to > this, in my opinion. I think we need to architect for the future, and in the > future the majority of people will be well trained in this b/c the semantic > web will be omnipresent. You're right, of course. I was going to make the caveat that these would be people one step down from the Rod Pages of this world, but you made my point for me already :) |
|
From: Vladimir G. <vga...@ne...> - 2010-03-19 15:40:42
|
It looks like the purls issue is as hot as before. Until we can meet face-to-face, fully explain to each other our concerns, and reach a consensus, here is a proposal for an interim hack. Till the release, we just use [treebase.nescent.org pointing to a non- production db] as our primary development front-end. Immediately after the release, if we need a development front end, we use treebase-dev, being mindful that some links jump to the production instance. Soon after the release, I'll figure out how use JNDI to pass the purl prefix to the application, so that we can configure each of our instances to use the appropriate one of these: On Mar 19, 2010, at 10:34 AM, Hilmar Lapp wrote: > So instead I created the following alternative base URLs, with > obvious redirection: > http://purl.org/phylo/treebase/dev/phylows/ > http://purl.org/phylo/treebase/stage/phylows/ This will relieve us from the need to change purls in application links to relative urls. Can we settle on this for the time being? --VG |
|
From: Hilmar L. <hl...@ne...> - 2010-03-19 15:45:06
|
On Mar 18, 2010, at 8:06 PM, Vladimir Gapeyev wrote: > (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. This is for Bill to judge in terms of what kind of problem it may signal, and hence how severe it is. > (2) An ominous message when Phylowidget loads: "An applet requires > access to your computer. The digital signature could not be > verified." The digital signature warning is because it is custom issued rather than by a trusted authority. What I wasn't sure of myself though when this dialog presented itself to me is what the applet wants to do that would require this seemingly unqualified access to the computer. Is this indeed necessary? If yes, we should add a dialog or a message somewhere that explains to the user what the applet will be doing that requires this permission to be granted. > (3) Havoc from purls. I think we've exhausted that discussion at this point. If you do want to subject these offending PURL links to testing, I appreciate that and have therefore created the additional purl.org base URLs - just use those when you deploy to dev and stage. Personally I would be willing to go public without this additional testing step, if you run out of time to perform it. > (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. It sounds too here like this is for Bill to judge in terms of kind of issue and severity it may signal. > If it were up to me, I'd prefer the purls issue resolved before > Treebase goes live. I don't see any harm with going live with the contentious ones. The only shortcoming from the perspective of release seems to be that it's nearly impossible to fully test them. I've enabled that now (see above), so if time permits we can do it. -hilmar -- =========================================================== : Hilmar Lapp -:- Durham, NC -:- informatics.nescent.org : =========================================================== |
|
From: Hilmar L. <hl...@ne...> - 2010-03-19 15:47:32
|
On Mar 19, 2010, at 10:40 AM, Vladimir Gapeyev wrote: > On Mar 19, 2010, at 10:34 AM, Hilmar Lapp wrote: >> So instead I created the following alternative base URLs, with >> obvious redirection: >> http://purl.org/phylo/treebase/dev/phylows/ >> http://purl.org/phylo/treebase/stage/phylows/ > > This will relieve us from the need to change purls in application > links to relative urls. > > Can we settle on this for the time being? Yes, please, and if we do then why do we need your extra steps re: treebase.nescent.org if then we don't jump from treebase-dev to production anymore? Let's just keep it simple and effective - any reason why using the above two base URLs for PURLs on dev and stage don't fully solve the issue for now? -hilmar -- =========================================================== : Hilmar Lapp -:- Durham, NC -:- informatics.nescent.org : =========================================================== |
|
From: Vladimir G. <vga...@ne...> - 2010-03-19 16:00:39
|
On Mar 19, 2010, at 11:47 AM, Hilmar Lapp wrote: > > On Mar 19, 2010, at 10:40 AM, Vladimir Gapeyev wrote: > >> On Mar 19, 2010, at 10:34 AM, Hilmar Lapp wrote: >>> So instead I created the following alternative base URLs, with >>> obvious redirection: >>> http://purl.org/phylo/treebase/dev/phylows/ >>> http://purl.org/phylo/treebase/stage/phylows/ >> >> This will relieve us from the need to change purls in application >> links to relative urls. >> >> Can we settle on this for the time being? > Yes, please, and if we do then why do we need your extra steps re: > treebase.nescent.org if then we don't jump from treebase-dev to > production anymore? What extra steps? > Let's just keep it simple and effective - any reason why using the > above two base URLs for PURLs on dev and stage don't fully solve the > issue for now? To make this work right now, I'd need to do 3 different builds with each update, and I am already going nuts. If I do feel I have a free hour today, I'll try to go ahead and set up JNDI to pass the purl prefix to the app, but it may take longer than that. --VG |
|
From: William P. <wil...@ya...> - 2010-03-19 16:07:42
|
On Mar 19, 2010, at 11:44 AM, Hilmar Lapp wrote: > On Mar 18, 2010, at 8:06 PM, Vladimir Gapeyev wrote: > >> (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. > > This is for Bill to judge in terms of what kind of problem it may signal, and hence how severe it is. This may be severe -- let's at least understand why it is happening. It is affecting a lot of studies. > >> (2) An ominous message when Phylowidget loads: "An applet requires access to your computer. The digital signature could not be verified." > > The digital signature warning is because it is custom issued rather than by a trusted authority. What I wasn't sure of myself though when this dialog presented itself to me is what the applet wants to do that would require this seemingly unqualified access to the computer. Is this indeed necessary? If yes, we should add a dialog or a message somewhere that explains to the user what the applet will be doing that requires this permission to be granted. yup, but not a show-stopper. >> (3) Havoc from purls. > > I think we've exhausted that discussion at this point. If you do want to subject these offending PURL links to testing, I appreciate that and have therefore created the additional purl.org base URLs - just use those when you deploy to dev and stage. > > Personally I would be willing to go public without this additional testing step, if you run out of time to perform it. Let's just leave the situation as-is for now. It's mostly us who do beta testing on stage and dev, and we know to edit these links accordingly. >> >> (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. > > It sounds too here like this is for Bill to judge in terms of kind of issue and severity it may signal. Not a show-stopper, IMO. We can come up with a plant to repopulate the missing files after release. >> >> If it were up to me, I'd prefer the purls issue resolved before Treebase goes live. > > I don't see any harm with going live with the contentious ones. The only shortcoming from the perspective of release seems to be that it's nearly impossible to fully test them. I've enabled that now (see above), so if time permits we can do it. yeah, this is not an artifact that public users of treebase.nescent.org will encounter. Let's let this dog lie, for now. bp |
|
From: Hilmar L. <hl...@ne...> - 2010-03-19 16:35:14
|
On Mar 19, 2010, at 11:07 AM, William Piel wrote: > On Mar 19, 2010, at 11:44 AM, Hilmar Lapp wrote: > >> On Mar 18, 2010, at 8:06 PM, Vladimir Gapeyev wrote: >> >>> (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. >> >> This is for Bill to judge in terms of what kind of problem it may >> signal, and hence how severe it is. > > This may be severe -- let's at least understand why it is happening. > It is affecting a lot of studies. OK - I am assuming that this is being investigated then right now. Vladimir or Bill - can you please keep me posted as to whether we are calling off or moving ahead with releasing tonight. -hilmar -- =========================================================== : Hilmar Lapp -:- Durham, NC -:- informatics.nescent.org : =========================================================== |
|
From: William P. <wil...@ya...> - 2010-03-19 19:25:31
|
On Mar 19, 2010, at 12:07 PM, William Piel wrote: > > On Mar 19, 2010, at 11:44 AM, Hilmar Lapp wrote: > >> On Mar 18, 2010, at 8:06 PM, Vladimir Gapeyev wrote: >> >>> (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. >> >> This is for Bill to judge in terms of what kind of problem it may signal, and hence how severe it is. > > This may be severe -- let's at least understand why it is happening. It is affecting a lot of studies. I think I've figured out what's going on here. I took one taxon label that maps nicely and compared it with another taxon label that does not map nicely, and then I ran queries on tables related to these taxon labels. The main difference is that in the good case the taxonlabelset table has the correct study_id, while in the bad case the taxonlabelset has "2264" as study_id instead of "10053", which is what it should be. Last weekend I had solved this problem using an update query that assumed that study_id 10215 was the only "placeholder" for migrated records. Turns out that there seems to be another one: 2264. Vladimir, can you confirm that study_id 2264 is another placeholder? And if so, can you let me know if there are any other placeholder study_ids that I'm not aware of. If this is the problem as I think it is, the solution is the following update: UPDATE taxonlabelset SET study_id = mx.study_id FROM matrix mx JOIN taxonlabelset tls USING (taxonlabelset_id) WHERE tls.study_id = 2264 AND mx.study_id <> 2264 AND taxonlabelset.taxonlabelset_id = tls.taxonlabelset_id I vote that we run this on stage -- if that solves the problem, then we hand it off to Jon to run it on production. Presumably Jon still has the data dump used in the transfer of data to production, so if anything screws up with can repopulate production. What do people think? The other difference is that the matrix associated with the bad one has version 0, while the other is version 1. Is there any rhyme or reason for the version fields that appear in lots of tables? Bill |
|
From: Hilmar L. <hl...@ne...> - 2010-03-19 19:41:02
|
On Mar 19, 2010, at 2:25 PM, William Piel wrote: > I vote that we run this on stage -- if that solves the problem, then > we hand it off to Jon to run it on production. Presumably Jon still > has the data dump used in the transfer of data to production, so if > anything screws up with can repopulate production. > > What do people think? Sounds good to me. -hilmar -- =========================================================== : Hilmar Lapp -:- Durham, NC -:- informatics.nescent.org : =========================================================== |
|
From: William P. <wil...@ya...> - 2010-03-19 19:41:05
|
I'm optimistic that this last sql update statement will solve the show-stopper bug, and that can be done today. Youjun tells me that with the new pages, CSS, etc, that he's working on, he predicts that he will be done by tomorrow at noon. So... Jon -- is it possible to get a rebuild on Saturday afternoon (this time with treebase.nescent.org pointing using the production database)? That would imply that after a last read-through of the web pages, I put in for a DNS change Saturday evening or Sunday. I think I have credentials to change the PURL records too -- else Hilmar can take care of that. bp |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X