You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@uima.apache.org by Marshall Schor <ms...@schor.com> on 2019/07/08 22:10:10 UTC
graphQL and UIMA
I've recently reclimbed multiple learning curves (huff / puff !) learning about
"modern" technologies and eco-systems for building static web page sites (like
our uima site, done using velocity macros, designed about 12 years ago?)
One set of things I picked up on was using React and Gatsby. These come with an
approach for querying data that is better than most Rest APIs, because it allows
you to get just the data you want in one query, when the data is represented as
hierarchical JSON.
Some time ago, we added JSON serialization to UIMA, with some complexities
around enabling accurate representation of the complete complexities of
interlinked UIMA features.
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.
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?
-Marshall
Re: graphQL and UIMA
Posted by Marshall Schor <ms...@schor.com>.
hmmm, we have some votes pending, based on where these are at the moment.
How about waiting to do this until after those get released?
-Marshall
On 7/25/2019 11:04 AM, Richard Eckart de Castilho wrote:
> On 25. Jul 2019, at 16:20, Marshall Schor <ms...@schor.com> wrote:
>> I notice that uimaj-v3 is missing - I'll get that added right away...
> Could we please file the v3 branches under the regular uima branches in SVN so we get v2 and v3 it the same git mirror?
>
> I.e. move
>
> https://svn.apache.org/repos/asf/uima/uv3/uimaj-v3/trunk
>
> to
>
> https://svn.apache.org/repos/asf/uima/uimaj/branches/3.0.x
>
> and fold
>
> https://svn.apache.org/repos/asf/uima/uv3/uimaj-v3/tags
>
> into
>
> https://svn.apache.org/repos/asf/uima/uimaj/tags
>
> please?
>
> Best,
>
> -- Richard
Re: graphQL and UIMA
Posted by Richard Eckart de Castilho <re...@apache.org>.
On 25. Jul 2019, at 16:20, Marshall Schor <ms...@schor.com> wrote:
>
> I notice that uimaj-v3 is missing - I'll get that added right away...
Could we please file the v3 branches under the regular uima branches in SVN so we get v2 and v3 it the same git mirror?
I.e. move
https://svn.apache.org/repos/asf/uima/uv3/uimaj-v3/trunk
to
https://svn.apache.org/repos/asf/uima/uimaj/branches/3.0.x
and fold
https://svn.apache.org/repos/asf/uima/uv3/uimaj-v3/tags
into
https://svn.apache.org/repos/asf/uima/uimaj/tags
please?
Best,
-- Richard
Re: graphQL and UIMA
Posted by Marshall Schor <ms...@schor.com>.
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" <Ha...@kp.org> 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" <ms...@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?
>
> -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.
Re: graphQL and UIMA
Posted by Hai-son X Nguyen <Ha...@kp.org>.
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" <Ha...@kp.org> 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" <ms...@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?
-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.
Re: graphQL and UIMA
Posted by Hai-son X Nguyen <Ha...@kp.org>.
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" <ms...@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?
-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.
Re: graphQL and UIMA
Posted by Marshall Schor <ms...@schor.com>.
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
>
>
>
Re: graphQL and UIMA
Posted by Marshall Schor <ms...@schor.com>.
A key theme seems to be:
simplify - make consumable
using reasonable defaults
Sounds a bit like maven's "convention over configuration".
For those who have been working with consuming things, it would be helpful to
put down what you feel are the reasonable defaults - I see Dan has started
something here, and Richard has noted the possibly synergy between a graphGL
style query and the select APIs. Perhaps there are others useful defaulting
notions.
Cheers. -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
>
>
>
Re: graphQL and UIMA
Posted by Daniel Gruhl <da...@gmail.com>.
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 <re...@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
>
>
>
Re: graphQL and UIMA
Posted by Richard Eckart de Castilho <re...@apache.org>.
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