Hi, Thanks for working on this.
In the past we have had "specs" for new things developed using our wiki https://cwiki.apache.org/confluence/display/UIMA/ There's a section "Development Mini Specs". Feel free to add a new page linked from there. If the work can be broken down into somewhat independent pieces, you might open a Jira issue for each one; this allows discussions (via comments) to be collected in one spot. The code itself can be put in anyplace of your choosing, for now. The UIMA code base has github "mirrors" which may be of use. Currently, these are the "read-only" mirrors, documented here: https://apache.org/dev/git.html <https://apache.org/dev/git.html> This page has a suggested workflow, as well. I notice that uimaj-v3 is missing - I'll get that added right away... -M On 7/24/2019 5:27 PM, Hai-son X Nguyen wrote: > Hi, > > I took a look and I think we can start with a UIMA type system to GraphQL > type system. After that we can start exploring the Query side and > instrumenting the data layer to access single/multiple XMI files. > > Can I get any direction on where to house the code and any specs for the > transform? > > Or can I start on the JSON reader initially? > > Thanks! > Hai-Son > > On 7/12/19, 10:17 AM, "Hai-son X Nguyen" <[email protected]> wrote: > > 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" <[email protected]> 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? > > -Marshall > > 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 the > > 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 > you. > 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 > you. > > > 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 you.
