uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Klügl <pklu...@uni-wuerzburg.de>
Subject Re: [jira] [Commented] (UIMA-2201) TextMarker IDE functionality missing due to renaming
Date Fri, 05 Aug 2011 12:00:02 GMT
  Some other things:

What about the licence and notice files? Should I open an issues and add 

Probably the provider in the plugin manifests should be changed to 
Apache UIMA?


Am 05.08.2011 13:52, schrieb Peter Klügl:
>  Am 05.08.2011 13:37, schrieb Jörn Kottmann:
>> On 8/5/11 1:18 PM, Peter Klügl wrote:
>>> I think so. As for the DLTK plugins, maybe two plugins can remain, 
>>> one for core one for ui stuff. The TextRuler plugins should not 
>>> merge since they are really extensions with new functionality and 
>>> independent of each other. Right now you also need to knoe what you 
>>> are doing to use the framework at all. So it's not so interesting 
>>> for other users. Besides that we have here also two new rule 
>>> learning algorithms that work better with the rule engineering 
>>> approach than the well known algorithms and should maybe join the 
>>> other extension sometime.
>> I would even go further to join the DLTK ui and core plugins, or is 
>> there a motivation not to do it?
> I don't know right now. I don't have a good feeling that it will be 
> done without problems. I'll just try and we'll see if there are some 
> reason against it.
>> ...
>>> There some really useful views for my use cases, e.g, selection 
>>> displays all annotations that cover the click position or the 
>>> annotation browser that has a field for filtering types. I often 
>>> have more than 20 overlapping annotations and more than 100 
>>> different types.
>> We can improve the existing Cas Editor views to handle this, maybe 
>> add a new one to work with many overlapping
>> annotations.
> Yes.
>>> Then there is the explanation component. Information about the rule 
>>> execution is stored in the cas and there are some special views that 
>>> display this information in a special manner. Other general views 
>>> should ignore these feature structures since there might be really 
>>> many of them. The CEV needs to be capable to open xmis of more then 
>>> 200MB because of that. So an extension point for the definition of 
>>> ignored type would come handy.
>> That sounds more like a new view, which should not be part of the Cas 
>> Editor itself. The Cas Editor
>> supports adding of new views which can visualize and change an aspect 
>> of the CAS opened in the
>> editor.
> Yes, there need to be extra views, because they also communicate 
> between each other. An example: if you click an a node in the "applied 
> rule" view, the views for matched and not matched display where the 
> selected rule tried to apply. If you click on one element of these 
> views, then the "rule elements" view displays what rule elements tried 
> to match on what text passages and how the conditions were evaluated.
>> I guess it will be easy for you to port these views to the Cas 
>> Editor. It is actually very simple, an ICasEditor has
>> a method to retrieve an ICasDocument which can retrieve the CAS 
>> object, and has a few method to track
>> changes done to the CAS.
>> If you create a new annotation, you need to call a method on the 
>> ICasDocment to signal that to other views.
> Yes, I will do that, but it will take some time :-)
> Peter

Dipl.-Inf. Peter Klügl
Universität Würzburg        Tel.: +49-(0)931-31-86741
Am Hubland                  Fax.: +49-(0)931-31-86732
97074 Würzburg              mail: pkluegl@informatik.uni-wuerzburg.de

View raw message