Parse Nexson study file

[opentreeoflife]

Parse Nexson study file

[blackrim]

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

[jar398]

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]

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

[jar398]

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]

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" [email protected] 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//issues/7#issuecomment-14622847
.

[josephwb]

Cody and I will figure this out soon.

Joseph.

On Fri, Mar 8, 2013 at 10:16 AM, Stephen Smith [email protected]:

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" [email protected]
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//issues/7#issuecomment-14625169
.

[jar398]

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]

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]

On Fri, Mar 8, 2013 at 5:02 PM, Stephen Smith [email protected]:

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//issues/7#issuecomment-14648245
.

[jar398]

On Fri, Mar 8, 2013 at 5:06 PM, Jonathan A Rees [email protected] wrote:

On Fri, Mar 8, 2013 at 5:02 PM, Stephen Smith [email protected]:

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.