I really like using jbrowse, but one thing I don't like is having to
use bioperl to produce the JSON structures. Would you consider
publishing a brief spec of the JSON expected by jbrowse so that I can
consider publishing my own JSON nested lists?
One reason I want to do this is I have some data already in JSON style
format (using mongodb) and I would rather not go SON -> GFF3 ->
bioperl -> JSON. If you're interested, here is some (very) rough code
doing a proof of principle here:
On 3 June 2010 09:50, James Casbon <[hidden email]> wrote:
> I really like using jbrowse, but one thing I don't like is having to
> use bioperl to produce the JSON structures. Would you consider
> publishing a brief spec of the JSON expected by jbrowse so that I can
> consider publishing my own JSON nested lists?
No response, so I'll try this instead...
Is the JSON data format that JBrowse uses stable enough that it is
worth creating my own JSON, or do you anticipate it changing it?
Could it represent an interface to the program, or is it an internal
On 06/07/2010 05:47 AM, James Casbon wrote:
> Is the JSON data format that JBrowse uses stable enough that it is
> worth creating my own JSON, or do you anticipate it changing it?
> Could it represent an interface to the program, or is it an internal
> only part?
Sorry for the slow reply. The short answer is, the feature JSON was
just an internal interface, but you've caught me right in the middle of
thinking about whether and how to make it an external interface.
I originally wanted it to be just an internal interface for a couple of
1. it was changing a lot, and
2. there are already so many genomics file formats; I would have felt
guilty about making another one.
However, things have changed a bit:
1. it's no longer changing quite as much
2. it may be possible to separate the parts that I expect to change from
the parts that probably won't change
3. web browsers impose their own set of limitations that I think may
justify having a new format
4. people keep asking for it
So now I'm thinking that we should probably do as you're asking, with
the caveat that I haven't yet separated the likely-to-change bits from
the unlikely-to-change bits. And there's not a perfectly clear-cut
boundary between those things.
The feature JSON currently contains:
1. feature data
2. feature density histogram counts
3. information on how to visually present the features, and
4. a bunch of parameters that tell the client how to behave (e.g., the
zoom threshold where the client switches from showing feature density
histograms to showing actual features)
I'm think #1 and #2 are pretty stable, and #4 is very likely to change.
But I'm not sure about #3.
So I'd be comfortable with describing and documenting #1 and #2 and
having that be an external interface. But right now all those things
are combined together in one file.
I've also got a paper deadline coming up very soon, so it may be a
little while before that documentation is fully fleshed out. I'll send
a message to gmod-ajax when it's more complete. Or, if you're really
keen, you could, of course, look at the code and the generated files to
get a more direct view of it. I could certainly answer questions about
what's in there and why.