search

OpenTreeOfLife / treemachine

Source tree graph database
Other
16 stars 6 forks source link

Parse Nexson study file #7

Closed jar398 closed 11 years ago

jar398 commented 11 years ago

There has to be a way to read in a phylogenetic tree coming from Phylografter and represented in Nexson (i.e. NeXML in JSON) format.

[Renamed issue, was "Nexson tree import]

blackrim commented 11 years ago

can you post a nexson file here so it can be used for writing the code

jar398 commented 11 years ago

Here is study 15 https://gist.github.com/jar398/5100472

You should feel free to merge in my branch. I didn't submit a pull request yet because Peter and I are still working out the metadata properties details, but the code is in a consistent state and works with this example. (branch: JSONimport)

jar398 commented 11 years ago

Warning, some OTU labels are missing from the example. Known problem, fixed, just haven't updated the file yet.

jar398 commented 11 years ago

Decision to be made: Where/how to store the ottol id inside the JadeNode. (The id ultimately comes from phylografter, is transmitted as an OTU metadata property in the Nexson file, and will have to be used for node unification when the tree gets incorporated into the graph db.) Should it be a new field? Or a property? Or should it go into the 'number' field? Also is it an integer or a string, i.e. what format would treemachine be happiest with?

(help please Stephen.)

blackrim commented 11 years ago

Sorry for the lack of response. I am traveling at virginia tech right now and dont have much access to the machine. Maybe joseph or cody could help answer that real quick until I can get to it this weekend. On Mar 8, 2013 9:29 AM, "Jonathan A Rees" notifications@github.com wrote:

Decision to be made: Where/how to store the ottol id inside the JadeNode. (The id ultimately comes from phylografter, is transmitted as an OTU metadata property in the Nexson file, and will have to be used for node unification when the tree gets incorporated into the graph db.) Should it be a new field? Or a property? Or should it go into the 'number' field? Also is it an integer or a string, i.e. what format would treemachine be happiest with?

(help please Stephen.)

— Reply to this email directly or view it on GitHubhttps://github.com/OpenTreeOfLife/treemachine/issues/7#issuecomment-14622847 .

josephwb commented 11 years ago

Cody and I will figure this out soon.

Joseph.

On Fri, Mar 8, 2013 at 10:16 AM, Stephen Smith notifications@github.comwrote:

Sorry for the lack of response. I am traveling at virginia tech right now and dont have much access to the machine. Maybe joseph or cody could help answer that real quick until I can get to it this weekend. On Mar 8, 2013 9:29 AM, "Jonathan A Rees" notifications@github.com wrote:

Decision to be made: Where/how to store the ottol id inside the JadeNode. (The id ultimately comes from phylografter, is transmitted as an OTU metadata property in the Nexson file, and will have to be used for node unification when the tree gets incorporated into the graph db.) Should it be a new field? Or a property? Or should it go into the 'number' field? Also is it an integer or a string, i.e. what format would treemachine be happiest with?

(help please Stephen.)

— Reply to this email directly or view it on GitHub< https://github.com/OpenTreeOfLife/treemachine/issues/7#issuecomment-14622847>

.

— Reply to this email directly or view it on GitHubhttps://github.com/OpenTreeOfLife/treemachine/issues/7#issuecomment-14625169 .

jar398 commented 11 years ago

OK, I'm going to put the ottol id as a Long-valued property of the JadeNode, so you can get it using jadenode.getObject("ot:ottolid")

Note that not all JadeNodes coming from phylografter will have ottol ids - some OTUs from the original data set won't have mapped to ottol. The ones that don't will only have labels. It would be nice to be able to make use of them in spite of this, and that shouldn't be too hard given that their place in the phylogeny is known.

blackrim commented 11 years ago

This makes sense (a long) as that is the native format. What is left to resolve this issue? (starting to look at these now)

jar398 commented 11 years ago

On Fri, Mar 8, 2013 at 5:02 PM, Stephen Smith notifications@github.comwrote:

This makes sense (a long) as that is the native format. What is left to resolve this issue? (starting to look at these now)

Nothing, it's agreed... except I made a mistake in my commit, it's currently a String. Will fix.

— Reply to this email directly or view it on GitHubhttps://github.com/OpenTreeOfLife/treemachine/issues/7#issuecomment-14648245 .

jar398 commented 11 years ago

On Fri, Mar 8, 2013 at 5:06 PM, Jonathan A Rees rees@mumble.net wrote:

On Fri, Mar 8, 2013 at 5:02 PM, Stephen Smith notifications@github.comwrote:

This makes sense (a long) as that is the native format. What is left to resolve this issue? (starting to look at these now)

Nothing, it's agreed... except I made a mistake in my commit, it's currently a String. Will fix.

Fixed. I also fixed the example nexson that was checked into the repo. The ids are made up but at least now they're decimal integers in the nexson and Longs after reading into Java. So y'all should be enabled to work on issue

11.