uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Gruhl <daniel.gr...@gmail.com>
Subject Re: graphQL and UIMA
Date Fri, 12 Jul 2019 14:31:22 GMT
Richard - I second the UIMA JSON format discussion. We've been kicking
around a "simplified JSON" format for a couple of years for our projects.
Basically it seeks to be "curl friendly" with a lot of sane defaults.

e.g., If you POST a "string", that gets promoted to the sofaText of a sofa
feature in an otherwise empty CAS. If you are developing a trivial
annotator this is a great way to test it and for others to consume it.

It might be nice to pull together a more formal, implementation language
agnostic spec of what a UIMA REST JSON Api might look like?

        -= Dan

On Thu, Jul 11, 2019 at 11:07 AM Richard Eckart de Castilho <rec@apache.org>
wrote:

> Hi Marshall,
>
> thanks for the pointer to GraphQL. I think I'll have a look into that
> in relation to the annotation editors I'm working on. We are looking
> there for a nice solution to allow building custom UIs without having to
> do backend coding.
>
> > Some time ago, we added JSON serialization to UIMA, with some
> complexities
> > around enabling accurate representation of the complete complexities of
> > interlinked UIMA features.
>
> Yep :) And I regularly get asked by people for a reader for this data
> because
> at the moment UIMA can only write JSON. For the purpose of communicating
> with
> a UI, the JSON format provided by UIMA probably is way too complex, but I
> think
> for people who wish to exchange data with UIMA it would be very convenient
> if
> there would also be a reader. JSON is the new XML...
>
> > It strikes me that users frequently are interested in much simpler kinds
> of
> > things, and sometimes roll their own simple json serializers of some
> small part
> > of the CAS.
>
> ... and not even of the entire CAS but maybe only of parts of it, e.g.
> restricted
> to particular annotation types, restricted to particular parts of a
> document or
> otherwise.
>
> > I'm wondering if we could figure out and implement some general kind of
> graphQL
> > support, to enable users to easily spec-out and retrieve what they
> wanted, and
> > whether or not the user community would find that of interest?
>
> It seems to me that the UV3 select API goes a long way already. Maybe it
> is
> straightforward to expose it via a GraphQL API?
>
> Should UIMA actually implement some kind of CAS server with a GraphQL
> remote API? Not sure.
>
> My intuition from working on the annotation tools would be that at least
> in that applications scenario, there is so much extra functionality
> specific
> to a particular annotation tool (e.g. coloring, displaying of validation
> warnings,
> etc.) that I'd probably want to write my own GraphQL wrapper anyway which
> might
> not directly access the CAS but maybe some intermediate representation.
>
> So I think it would be a great idea to add a reader for the existing UIMA
> JSON format.
>
> I also think it would be nice to switch from Velocity to something more
> modern for the
> UIMA website ;)
>
> Cheers,
>
> -- Richard
>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message