[data-protocols] Alternative Java Library

[Xavier Badosa]

Jeff,

in the web service model, it made much more sense from the standpoint of
> performance and simplicity to keep all the data in a single JSON file.


I agree with you (besides, I never liked CSV as the format is not very
international-friendly). I'd be interested to know the schema you're using
in such a single JSON file (as you know, this is also the approach of
JSON-stat.org, a standard that Statistics Norway is already using in its
web service http://data.ssb.no/api/?lang=en).

X.



On Thu, Jun 20, 2013 at 4:27 PM, Jeffrey Allen <
Jeffrey.Allen at utsouthwestern.edu> wrote:

>  As an alternative to yesterday’s Java library, I wanted to make you
> aware of JSON Table Schema library on which we’ve been working.
>
>
>
> Jacksonate (https://github.com/QBRC/Jacksonate) is built as a custom
> serializer for the Jackson JSON library in Java – essentially, you continue
> to interact with the serializer as you always have, but instead of
> outputting traditional JSON, it will create a JSON-Table-Schema-encoded
> version of the data.
>
>
>
> It was initially created to facilitate the use of JSON Table Schemas in
> REST web services, so it integrates well into the RESTEasy web service
> framework in Java. It also supports the proposed Foreign Key feature of
> JSON Table Schemas.
>
>
>
> Our “Guiberest” project takes this one step further and adds Hibernate
> integration – meaning that you can now trivially expose any database into
> JSON Table Schema (complete with automated support for Foreign Keys). See
> the readme (https://github.com/QBRC/Guiberest) of this project for more
> details and examples. We have an additional plugin for handling
> authentication, if that’s desired.
>
>
>
> Initially, we needed this server to be supported by our RODProt (JSON
> Table Schema in R, https://github.com/QBRC/RODProt) client, so the
> integration there is fairly well tested at this point. Of course, please
> report any issues you find to the relevant project on GitHub so we can
> improve the quality of the software.
>
>
>
> The one potential downside for this library is that we have made the
> decision to directly encode the data in JSON alongside the JSON Table
> Schema. So we are not relying as heavily on the CSV architecture suggested
> in the Simple Data Format. It shouldn’t be difficult to add, but in the web
> service model, it made much more sense from the standpoint of performance
> and simplicity to keep all the data in a single JSON file.
>
>
>
> The software is freely available under the MIT open source license.
>
>
>
> Please feel free to respond to myself or Jonathan Yoder (CC’d), who is the
> principal author of these libraries.
>
>
>
> Best,
>
>
>
> *Jeff Allen*
>
> Computational Biologist II
>
> Quantitative Biomedical Research Center
>
> UT Southwestern Medical Center
>
> 214.648.4171 - NC8.512A
>
> Jeffrey.Allen at UTSouthwestern.edu
>
>
>
> ------------------------------
>
> UT Southwestern Medical Center
> The future of medicine, today.
>
> _______________________________________________
> data-protocols mailing list
> data-protocols at lists.okfn.org
> http://lists.okfn.org/mailman/listinfo/data-protocols
> Unsubscribe: http://lists.okfn.org/mailman/options/data-protocols
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/data-protocols/attachments/20130620/2c62c8b9/attachment.htm>