Am 05.08.2011 11:46, schrieb Jörn Kottmann:
On 8/5/11 11:33 AM, Peter Klügl (JIRA) wrote:
... or something like that. However, when taking a look at the other
UIMA Eclipse Tooling projects, maybe the project names should also
change? Some projects can also merge.
We maybe should follow the current convention which contains ep in the
project name.
Any opinions?
I have applied domain reverse engineering for eclispe plugins because I
read somewhere that this is the common approach. However, I think the
TextMarker plugins should adapt to the UIMA convention of plugins naming.
Would it be possible to merge some of the dltk plugins? Because that
will make a maven build
simpler, and if there is no reason to have so many project we should
not do it.
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 think the functionality of the CEV plugins should be integrated in
the CAS Editor in future, because actively using two different
editors for xmis is really annoying. Therefore its namespace isn't
really important.
+1 to replace CEV with our Cas Editor. I will help with the
integration and any issues which
pop up.
What features do you think are missing from the Cas Editor?
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.
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.
Then there are also some application specific views that are not part of
the contribution. Those need some interfaces to create annotations
themselves. One example is a view that enables the user to annotated
selected text with instances of terminology or ontology, storing an id
in a defined feature.
There is definitely some other stuff. However, I have to take a closer
look at CAS Editor. I don't even know if views added by other plugins
are supported. However, before I start with that task, I want to
reimplement the rule inference. So all that will have to wait for 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: [email protected]
http://www.is.informatik.uni-wuerzburg.de/en/staff/kluegl_peter/
---------------------------------------------------------------------
