[
https://issues.apache.org/jira/browse/UIMA-3292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13778348#comment-13778348
]
Alexandre Patry edited comment on UIMA-3292 at 9/26/13 1:37 AM:
----------------------------------------------------------------
{quote}
This is a very important issue and the problem was neglegted for a long time.
We need to provide some solutions for user to handle type systems with
conflicting short names and I do not know if the current best practice with a
type variable is good enough (it's annyoing to defined many variables if there
are many conflicts like in the DKPro type system). Richard suggested something
like an "import as". Maybe this could add a short prefix to the type names or
something. However, this would not solve the problem if the imported type
system contains conflicting types, but only if the conlicts are caused by the
import of two valid type systems.
{quote}
I also think that an "import as" facility would make for a clean solution. I
can opened UIMA-3303 so we do not forget about it.
{quote}
I just tried to run some scripts of the tutorial yesterday and the analysis
engine failed (I used NUM, directly without namespace or variable wrapper.
There is one in Ruta and one in DKPro)
{quote}
Glad to know that those checks are already useful :)
{quote}
The syntax checker should be extended and should report an error in the
Workbench, thus users will see in the editor that such rules are not allowed
and will cause an exception. I could make the changes to the validators, but
you can also do them if you want.
{quote}
Right now, there is no robust way to show this in the UI because all types
known to the cas at runtime are imported. A script can have conflicts when it
is used in one aggregate and not when it is used in another aggregate. My next
step right now would be to only import the basic type system and type systems
that are declared in the script. Once it is done, all possible conflicts will
be known just by parsing the script and type error reporting will be easier in
eclipse. What do you think about this road map?
was (Author: apatry):
> This is a very important issue and the problem was neglegted for a long
time. We need to provide some solutions for user to handle type systems with
conflicting short names and I do not know if the current best practice with a
type variable is good enough (it's annyoing to defined many variables if there
are many conflicts like in the DKPro type system). Richard suggested something
like an "import as". Maybe this could add a short prefix to the type names or
something. However, this would not solve the problem if the imported type
system contains conflicting types, but only if the conlicts are caused by the
import of two valid type systems.
I also think that an "import as" facility would make for a clean solution. I
can opened UIMA-3303 so we do not forget about it.
> I just tried to run some scripts of the tutorial yesterday and the analysis
> engine failed (I used NUM, directly without namespace or variable wrapper.
> There is one in Ruta and one in DKPro)
Glad to know that those checks are already useful :)
> The syntax checker should be extended and should report an error in the
> Workbench, thus users will see in the editor that such rules are not allowed
> and will cause an exception. I could make the changes to the validators, but
> you can also do them if you want.
Right now, there is no robust way to show this in the UI because all types
known to the cas at runtime are imported. A script can have conflicts when it
is used in one aggregate and not when it is used in another aggregate. My next
step right now would be to only import the basic type system and type systems
that are declared in the script. Once it is done, all possible conflicts will
be known just by parsing the script and type error reporting will be easier in
eclipse. What do you think about this road map?
> Conflicting types are not flagged by RUTA
> -----------------------------------------
>
> Key: UIMA-3292
> URL: https://issues.apache.org/jira/browse/UIMA-3292
> Project: UIMA
> Issue Type: Bug
> Components: ruta
> Reporter: Alexandre Patry
> Assignee: Alexandre Patry
>
> *Steps to reproduce*
> # Create a RUTA script containing the rule {{W {-> T1}}}
> # Add this script to an aggregate whose type system contains {{conflicting.W}}
> # Run the script on the text _word_
> *Expected behaviour*
> _word_ is annotated with {{T1}}
> *Observed behaviour*
> Depending on the on the order in which the types iterated on in
> RutaEnvironment#initializeTypes, one of the following is observed:
> * {{W}} is resolved to {{org.apache.uima.ruta.type.W}} and _word_ is
> annotated with {{T1}}
> * {{W}} is resolved to {{conflicting.W}} and no {{T1}} annotation is created.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
