uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jörn Kottmann <kottm...@gmail.com>
Subject Cas Editor API
Date Thu, 30 Jun 2011 10:59:27 GMT
Hi all,

I would like to make some progress to define a more stable Cas Editor API,
which can be used for the following cases.

- Implement a view which shows (and edits) pieces of the CAS shown in 
the open editor
- Implement a custom Cas Editor
- Integrate Cas Editors into a RCP application

I believe to achieve this we need to create  / refine the following 
interfaces:

ICasEditor
Every CAS handling EditorPart needs to implements this interface.
The interface is used by views to detect that the current Editor Part shows
a CAS, and can retrieve an ICasDocument to access to opened CAS.

ICasDocument
It wraps a CAS to make it suitable for UI tools.
It has a method to retrieve the wrapped CAS object and has methods
to propagte changes to the Feature Structures of the CAS to other UI 
elements
which display it.
We decided on this list to not add any change notification system
to the CAS APIs itself, that why it is necessary to do this in this 
interface.

ICasDocumentProvider
The ICasDocumentProvider maps between the IEditorInput an a ICasDocument,
it knows how to create and store an ICasDocument based on the input.
It also needs to resolve a type system for a specific IEditorInput.
Or a seperate interface is defined to specify a ITypeSystemProvider, 
which can
retrieve a type system for an IEditorInput.

Many views and editors need to store configuration which is usually 
dependent on
the type system. For example the Annotation Editor needs to store the 
configured
configuration styles for a specific type system.

The current implementation just defined a couple of type safe 
configuration parameters,
which cannot be extended by views or new editors.
I suggest that we define some kind of API to safe configuration 
parameters which are related to
a type system.
This limitation makes it difficult to define new plugins which requires 
this, for example an OpenNLP
Name Finder plugin which needs to know which types represent Token, 
Sentence and the desired Entity
annotation. It also needs to store the location of the statistical model.

As part of the API definition I believe we should create documentation 
which explains
how to do the above mentioned use cases.

Any opinions or suggestion are very welcome!

Jörn

Mime
View raw message