[data-protocols] Alternative Java Library

[Rufus Pollock]

On 20 June 2013 15:27, 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

This is great to hear. More material to add to http://data.okfn.org/tools :-)

> 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.


I do like this approach and it provides strong support for getting the
issue on inline data done and merged:

https://github.com/dataprotocols/dataprotocols/issues/36

I should point out you can also have CSV data inline but obviously
JSON is more natural.

Given this seems a strong pattern I wonder if we should have some
extension (or sibiling) to Simple Data Format that does have the JSON
approach - maybe JSON Simple Data Format :-)

Rufus

> 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
>



--

Rufus Pollock

Founder and Co-Director | skype: rufuspollock | @rufuspollock

The Open Knowledge Foundation

Empowering through Open Knowledge

http://okfn.org/ | @okfn | OKF on Facebook |  Blog  |  Newsletter