[
https://issues.apache.org/jira/browse/UIMA-6110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16903093#comment-16903093
]
Marshall Schor commented on UIMA-6110:
--------------------------------------
Hi, thanks for working on this :).
One correction: in general, type systems do not have to extend Annotation. One
might have a type system which doesn't use Annotations at all.
UIMA has a notion in its type system of allowing one type system to "include"
another. It also has a notion of allowing multiple type systems to be "merged"
together. The resulting type system might not correspond to any particular
type system descriptor (because of the merging, etc.)
It seems that a typical use case is the picking of a subset of the
types/features of a typesystem, to "expose" for graphql access.
So an implementation would likely consist of 2 parts:
# A way for an application designer to select the specific subset of types and
features they wanted to be exposed.
## I like the idea of integrating this with some existing Eclipse plugin
tooling,
## I think there also ought to be a simple way (a yaml file, a graphql spec
file?) of doing this without any extra tooling (other than a text editor)
# An addition to uimaj, which could read some description like the above,
validate it for a particular running pipeline's type system, and "hook up" a
graphql server impl to the data to make graphql queries work.
## Part of this might entail supporting a safe/secure/lightweight (?) web
server as an add on to UIMA.
## We already have this (but as a quite older technology; might need updating)
see the UIMA add on project [http://uima.apache.org/sandbox.html#simple-server]
The hard part of JSON representation has been the modelling the capability of
the value of a field to be a reference to another Feature Structure. This
required setting up unique ids, and identifying things with them, etc.
Although this would be nice to do, it may be complex, so perhaps work could
proceed in stages, where an initial simple (but useful) approach would skip
this harder part, and just support fields whose values were simple - like
strings, numbers, and so forth.
> UIMA & GraphQL Tool
> -------------------
>
> Key: UIMA-6110
> URL: https://issues.apache.org/jira/browse/UIMA-6110
> Project: UIMA
> Issue Type: Brainstorming
> Components: Tools
> Reporter: Hai-Son Nguyen
> Priority: Minor
>
> To gather ideas and discuss tasks related to creating a GraphQL tool to work
> with UIMA.
> Initiated by Marshall's email 7/8/2019
> "...
>
> 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"
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
