uima-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hugues de Mazancourt <hug...@mazancourt.com>
Subject Re: Ruta conflicts with DKPro typesystem
Date Tue, 11 Apr 2017 11:47:32 GMT
>> The advantage over « renaming » the annotation is that it allows to keep syntax
highlighting in  Ruta Workbench.
> 
> Do you mean the highlighting for being a seeding type (bold grey), or
> semantic highlighting for usage in a script?

Simply the bold grey. It helps beginners to know where to find the definition of the annotation.

> 
> 
> 
>> 
>> Your answer raises another question: you wrote 
>>> If you create the CAS with uimaFIT,
>>> then there are also types that are not imported in you script. Well, you
>>> would not even need to import the types in order to use them in your script.
>> I did create the CAS with uimaFIT. What kind of types are not imported in the script
?
> 
> It's about what the import statement really do.
> 
> By default, strictImport is deactivated. Here, the mentions of type
> references are resolved against the type system of the CAS given to the
> RutaEngine. This means that the import statements do not matter at all.
> They could not change the type system in the CAS anyway during
> processing the CAS. You could write rules using DKPro Core types in your
> rules without importing any type system since the DKPro Core types are
> included in the type system of the CAS because you created the CAS using
> uimaFIT, and uimaFIT adds the type system with its classpath scanning
> functionality (of course only if the type systems and types.txt are in
> the classpath).
[…]

That’s perfectly clear, thank you.


— Hugues



Mime
View raw message