Perl 6 - the future is here, just unevenly distributed

IRC log for #opentreeoflife, 2015-07-28

| Channels | #opentreeoflife index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
01:48 ilbot3 joined #opentreeoflife
01:48 Topic for #opentreeoflife is now Open Tree Of Life | opentreeoflife.org | github.com/opentreeoflife | http://irclog.perlgeek.de/opentreeoflife/today
03:59 jimallman joined #opentreeoflife
12:10 jar286 joined #opentreeoflife
13:32 kcranstn joined #opentreeoflife
13:39 jar286 joined #opentreeoflife
13:44 kcranstn joined #opentreeoflife
14:40 kcranstn joined #opentreeoflife
14:40 jar286 joined #opentreeoflife
15:22 kcranstn jimallman?
15:22 jimallman good morning
15:22 kcranstn mornin!
15:22 kcranstn Looking at https://github.com/OpenTreeOfLife/opentree/issues/673
15:22 jimallman yes, i’m hoping to check off two more boxes this afternoon.
15:23 kcranstn for a first version of the collections feature, do we need oti
15:23 kcranstn ?
15:23 kcranstn vs phylesystem APIs
15:23 jimallman yes, or a decent substitute. i’m looking into using the GitHub API for this
15:23 kcranstn i.e. if the first version only implements “add this tree to my collection”
15:24 kcranstn then we get the tree directly from phylesystem and it doesn’t matter if oti isn’t indexing all of the properites
15:24 jimallman true, but the metadata is all we need to (a) confirm the tree’s existence and (b) fill in default name and description.
15:25 jimallman at the moment we’re missing the ‘@label’ property, so we don’t really get a default name.
15:25 kcranstn I think I am missing something. Curator is sitting on the study, and hits a “add tree to collection” button. We get nexson from phylesystem
15:25 jimallman there’s an ‘ot:originalLabel’ property, but it seems to be just a taxon name (perhaps the original root node?)
15:26 jimallman ah, in that case we will have the name, true.
15:26 jimallman i’ve been focused on the “enter a URL or study+tree IDs” method of adding trees.
15:26 kcranstn even then, if we have the study + tree ID, we don’t need oti
15:26 jimallman the original “cherry-picking” scenario (from the study’s page) will be easier to implement
15:27 jimallman since (as you point out) all the information is handy
15:27 kcranstn I don’t want to get stuck on oti issues
15:27 kcranstn when we can use phylesystem-api
15:28 jimallman agreed. the biggest missing piece is a simple list of collections that we can filter on the client side. that’s why i’m looking at GitHub API to fetch these.
15:29 jimallman or more likely, phylesystem-api using peyotl to list all collections in its “local” repo.
15:29 kcranstn +1 for that
15:29 jimallman this should suffice until we have LOTS of collections
15:29 kcranstn the only UI I have seen is the collections attached to a curator
15:30 jimallman there’s also a Collections tab in the tree viewer/editor (open a study, pick a tree, see popup)
15:30 kcranstn is that on dev right now?
15:31 jimallman and a filtered list under the main nav (‘Tree collections’)… i’ll bet we have another branch deployed to devtree… checking now…
15:32 jimallman yes, it’s deployed: https://devtree.opentreeoflife.org/curator/study/view/pg_2762/?tab=trees&tree=tree6384
15:32 jimallman see Collections sub-tab
15:32 kcranstn just a sec, need to switch over from localhost
15:33 jimallman but i haven’t yet deployed most of my recent work on the single-collection editing UI (hopefully this afternoon)
15:34 jimallman the collection lists here are still mockups, with dummy data, pending a working index.
15:35 jimallman in my local branch, clicking any collection in the Profile page will launch a single test collection in the editor.
15:35 jimallman (ie, the same one every time): https://github.com/OpenTreeOfLife/collections-0/blob/master/collections-by-owner/jimallman/my-test-collection.json
15:36 jimallman this is enough to test the UI and API calls. then i’ll focus on a basic index/list of collections
15:37 jimallman that’s enough to get to work building our collections for trees used in synthesis, so no need for a stopgap solution there.
15:37 kcranstn yay
15:43 jar286 joined #opentreeoflife
15:54 kcranstn joined #opentreeoflife
16:47 jimallman joined #opentreeoflife
17:00 jar286 joined #opentreeoflife
18:53 jar286 kcranstn, I don’t understand your prejudice - it would be one thing if you disliked nosql and triple stores equally, but you don’t seem to.  i don’t see the difference  (other than the way triple stores seem better, which is not relevant to this point)
18:54 kcranstn I think triple stores are more difficult to understand than SQL or nosql
18:55 kcranstn although I suspect that SQL is probably the best choice for us
18:56 kcranstn nobody else on the project has experience with triple stores
18:57 jar286 nobody has experience with nosql either, and IMO triple stores are simpler
18:57 jar286 agreed about SQL, athough I wonder how much experience we all have with that
18:59 kcranstn we did start down a nosql path for the annotation database
19:00 kcranstn although taht was a hackathon project, so certainly not a thoroughly planned example
19:02 jar286 and I’ve loaded open tree taxonomies into a triple store… so … ?  what’s the difference? is it that it was multiple people starting down the path?
19:03 kcranstn I think that the arguments for / against nosql & triple stores are going to be similar and we will end up with SQL
19:04 kcranstn but want others to weigh in
19:05 jar286 well that’s just my point.  it seems you’ve been treating them unequally, and I’m just asking you to be fair
19:05 jar286 if I had suggested couch instead of a triple store today, would you have reacted the same way?  that’s what’s bugging me
19:08 kcranstn probably not, because 1) a few of us have at least played around with couch before (indicating at least an interest in trying it out) and 2) you are the only one with triple store experience, which means a big learning curve for the rest of us
19:09 kcranstn import into couch for data already in JSON involves no work at all, which is appealing
19:09 jar286 who besides you has played with couch?  and why would the learning curve for triple store be any steeper than that for couch?
19:11 jar286 converting json to triples is trivial.  syntax conversion is rarely the major problem in adopting any system like this.  it’s the hard stuff like understanding performance that gets you
19:15 kcranstn the two of us aren’t going to decide this over irc. Might be worth an email thread to see what experience everyone has with various databases
19:16 kcranstn and query languages
19:18 jar286 Im not looking for a decision.
19:19 jar286 I’m just saying I don’t think you’re being fair and I respectfully request you be more evenhanded.
19:21 kcranstn You think triple stores are easy to understand. I do not (despite many introductions via various nescent and tdwg meetings).
19:21 jar286 So that’s a matter of opinion. I respect yours, I’m asking you to respect mine.
19:22 jar286 I think my opinion is informed as well, but we both could probably benefit from more education, if any resolution is needed, which I think is not.
19:23 kcranstn I certainly would never accuse you of having an uninformed opinion :)
19:27 kcranstn I’ve always had a hard time with discussions of RDF and triple stores. It’s never really clicked for me, and my eyes eventually glaze over. I *get* SQL.
19:28 jar286 I understand, that’s not my point
19:32 kcranstn that’s why I am treating them unequally
19:34 jar286 you would not take it kindly if you suggested nosql for some hypothetical purpose and I reacted “gack”
19:35 kcranstn I would ask why (which is what you have done here)
19:39 jar286 by the way, do you *get* when and whether to create an index in a SQL database, how you would know it’s time, and which one to create?
19:40 jar286 that’s the missing piece for me  (that is solved with practically work by a triple store, so that’s how my expectations have been set)
19:40 jar286 s/work/no work/
20:08 jar286 kcranstn, if we have budget, I’ll provision another back end server, ok? as a temporary spare?
20:09 kcranstn ok
20:34 kcranstn did everyone receive the email from PNAS about the license to publish, or just me?
20:45 kcranstn joined #opentreeoflife
20:57 kcranstn joined #opentreeoflife
21:14 jimallman kcranstn: i received an email yesterday that discussed this, with the subject ‘Receipt of revised PNAS MS# 2014-23041RR’
21:15 jimallman then another one today saying that the paper was accepted (yay!) and will be under embargo
21:34 kcranstn joined #opentreeoflife

| Channels | #opentreeoflife index | Today | | Search | Google Search | Plain-Text | summary