uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hai-son X Nguyen <Hai-Son.Ngu...@kp.org>
Subject Re: graphQL and UIMA
Date Fri, 12 Jul 2019 17:12:36 GMT
I can provide some help and am interested in both GraphQL and JSON (possibly for Elastic Search).

My specific use case is clinical NLP and we have tools that support our end results (SQL DB)
but lack a good ability to see intermediate annotation and changes caused by changing ML models.

Been tossing around ideas to use both GraphQL and/or Elastic Search without regression processes.

Maybe a consistent few hours a week?

´╗┐On 7/12/19, 8:45 AM, "Marshall Schor" <msa@schor.com> wrote:

    Caution: This email came from outside Kaiser Permanente. Do not open attachments or click
on links if you do not recognize the sender.

    Re: Reader for UIMA JSON xml format

    This of course could be done.  It wasn't done initially, because:
      - workload management (people were busy...)
      - it was new, and perhaps would change based on initial feedback
        (that hasn't happened)

    So, it's probably a good time to do this.

    Any volunteers?


    On 7/11/2019 2:07 PM, Richard Eckart de Castilho 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
    > UIMA website ;)
    > Cheers,
    > -- Richard

NOTICE TO RECIPIENT:  If you are not the intended recipient of this e-mail, you are prohibited
from sharing, copying, or otherwise using or disclosing its contents.  If you have received
this e-mail in error, please notify the sender immediately by reply e-mail and permanently
delete this e-mail and any attachments without reading, forwarding or saving them.  Thank
View raw message