Re: Extract text from line below/above annotated keyword using RUTA

[Peter Klügl]

Hi,


here are some quick rules. It could be solved with fewer rules and also
with better or faster rules. You need essentially a rule for detecting
the structure and a rule for assigning the semantics. The rules would
also work if you have a plain text table with more rows.


Let me know if you have questions about some parts.


Best,

Peter

TYPESYSTEM utils.PlainTextTypeSystem;
ENGINE utils.PlainTextAnnotator;

DECLARE Header;
DECLARE ColumnDelimiter;
DECLARE Cell(INT column);

DECLARE Keyword (STRING label);
DECLARE Keyword UnderWriterNameKeyword, AppraiserNameLicenseKeyword,
AppraisalCompanyNameKeyword;

"Underwriter's Name" -> UnderWriterNameKeyword ( "label" = "UnderWriter
Name");
"Appraiser's Name/License" -> AppraiserNameLicenseKeyword ( "label" =
"Appraiser Name");
"Appraisal Company Name" -> AppraisalCompanyNameKeyword ( "label" =
"Appraisal Company Name");

DECLARE Entry(Keyword keyword);

EXEC(PlainTextAnnotator, {Line,Paragraph});

ADDRETAINTYPE(WS);
Line{->TRIM(WS)};
Paragraph{->TRIM(WS)};

SPACE[3,100]{-PARTOF(ColumnDelimiter) -> ColumnDelimiter};
Line -> {ANY+{-PARTOF(Cell),-PARTOF(ColumnDelimiter) -> Cell};};
REMOVERETAINTYPE(WS);

INT index = 0;
BLOCK(structure) Line{}{
    ASSIGN(index, 0);
    Line{STARTSWITH(Paragraph) -> Header};
    c:Cell{-> c.column = index, index = index + 1};
}

Header<-{hc:Cell{hc.column == c.column}<-{k:Keyword;};}
    # c:@Cell{-PARTOF(Header) -> e:Entry, e.keyword = k};

DECLARE Entity (STRING label, STRING value);
DECLARE Entity UnderWriterName, AppraiserNameLicense, AppraisalCompanyName;

FOREACH(entry) Entry{}{
    entry{ -> CREATE(UnderWriterName, "label" = k.label, "value" =
entry.ct)}<-{k:entry.keyword{PARTOF(UnderWriterNameKeyword)};};
    entry{ -> CREATE(AppraiserNameLicense, "label" = k.label, "value" =
entry.ct)}<-{k:entry.keyword{PARTOF(AppraiserNameLicenseKeyword)};};
    entry{ -> CREATE(AppraisalCompanyName, "label" = k.label, "value" =
entry.ct)}<-{k:entry.keyword{PARTOF(AppraisalCompanyNameKeyword)};};
}



Am 06.11.2019 um 12:45 schrieb Shashank Pathak:
> Hi Peter,
>
> I am trying to get information from a indented text file.
>
> Input file text:
> Underwriter's Name  Appraiser's Name/License  Appraisal
> Company Name
> Alice Wheaton   Bruce Banner  Stark
> Industries
>
> Approach:
>I am trying to annotate fixed keywords like "Underwriter's Name" and
> then go to line next to this annotated keyword.
>But I am not able to fetch UnderWriter's Name. It is giving all
> instances which are matched(Alice Wheaton  Bruce, Wheaton Bruce Banner,
> etc).
>
>
> Code :
>
> TYPESYSTEM utils.PlainTextTypeSystem;
> ENGINE utils.PlainTextAnnotator;
>
> EXEC(PlainTextAnnotator, {Line});
> ADDRETAINTYPE(WS);
> Line{->TRIM(WS)};
> REMOVERETAINTYPE(WS);
> Document{->FILTERTYPE(SPECIAL)};
>
> DECLARE UnderWriterKeyword, NameKeyword, UnderWriterNameKeyword;
> DECLARE UnderWriterName(String label, String value);
>
> CW{REGEXP("\\bUnderwriter") -> UnderWriterKeyword};
> CW{REGEXP("Name")->NameKeyword};
> (UnderWriterKeyword SW NameKeyword){->UnderWriterNameKeyword};
> Line{CONTAINS(UnderWriterNameKeyword)} Line -> {
>n:CW[1,3]{-> CREATE(UnderWriterName, "label"="UnderWriter Name",
> "value"=n.ct)};
>};
>
> Please tell me whether it is possible to achieve this using RUTA or not.
> Also share steps to get Underwriter's Name, Appraiser's Name/License and
> Appraisal Comapny Name.
> I have already posted question similar to this on stackoverflow
> https://stackoverflow.com/questions/58726610/using-ruta-get-a-data-present-in-next-line-of-annotated-keyword/58728364#58728364
>
> Thanks,
>
> Shashank Pathak
>
-- 
Dr. Peter Klügl
R Text Mining/Machine Learning

Averbis GmbH
Salzstr. 15
79098 Freiburg
Germany

Fon: +49 761 708 394 0
Fax: +49 761 708 394 10
Email: peter.klu...@averbis.com
Web: https://averbis.com

Headquarters: Freiburg im Breisgau
Register Court: Amtsgericht Freiburg im Breisgau, HRB 701080
Managing Directors: Dr. med. Philipp Daumke, Dr. Kornél Markó

Extract text from line below/above annotated keyword using RUTA

[Shashank Pathak]

Hi Peter,

I am trying to get information from a indented text file.

Input file text:
Underwriter's Name  Appraiser's Name/License  Appraisal
Company Name
Alice Wheaton   Bruce Banner  Stark
Industries

Approach:
   I am trying to annotate fixed keywords like "Underwriter's Name" and
then go to line next to this annotated keyword.
   But I am not able to fetch UnderWriter's Name. It is giving all
instances which are matched(Alice Wheaton  Bruce, Wheaton Bruce Banner,
etc).


Code :

TYPESYSTEM utils.PlainTextTypeSystem;
ENGINE utils.PlainTextAnnotator;

EXEC(PlainTextAnnotator, {Line});
ADDRETAINTYPE(WS);
Line{->TRIM(WS)};
REMOVERETAINTYPE(WS);
Document{->FILTERTYPE(SPECIAL)};

DECLARE UnderWriterKeyword, NameKeyword, UnderWriterNameKeyword;
DECLARE UnderWriterName(String label, String value);

CW{REGEXP("\\bUnderwriter") -> UnderWriterKeyword};
CW{REGEXP("Name")->NameKeyword};
(UnderWriterKeyword SW NameKeyword){->UnderWriterNameKeyword};
Line{CONTAINS(UnderWriterNameKeyword)} Line -> {
   n:CW[1,3]{-> CREATE(UnderWriterName, "label"="UnderWriter Name",
"value"=n.ct)};
   };

Please tell me whether it is possible to achieve this using RUTA or not.
Also share steps to get Underwriter's Name, Appraiser's Name/License and
Appraisal Comapny Name.
I have already posted question similar to this on stackoverflow
https://stackoverflow.com/questions/58726610/using-ruta-get-a-data-present-in-next-line-of-annotated-keyword/58728364#58728364

Thanks,

Shashank Pathak

Re: Using RUTA

[José Vicente Moyano Murillo]

Hi,

Thanks Peter for your hard work.

Right now we are using BLOCKs and boolean variables to acomplish our
objective. And we can say that all works great.

Regarding the labels and what can be done; we agree that it is difficult to
make a decision.

Once again many thanks.

2017-03-22 17:34 GMT+01:00 Peter Klügl :

> Hi,
>
>
> Am 15.03.2017 um 10:24 schrieb José Vicente Moyano Murillo:
> > Great explanation Peter, we see all your comments.
> > Maybe we are doing something wrong to accomplish our pourpouse.
> >
> > But regarding labels. Can we discuss this example?
> >
> > Document{ -> ADD(list, w1), ADD(list, w2), ADD(list, w3), ADD(list, w4),
> > CREATE(Detection, "anchors" = list)} <- {
> > w1:CW{w1.ct=="A" }
> > %
> > w2:CW{w2.ct=="B" }
> > %
> > w3:CW{w3.ct=="B"  }
> > %
> > w4:CW{w4.ct=="A" };
> >};
> >
> > In our mind conjuntion rules are aplyed using something like this
> pattern:
> >
> > FOR (PERMUTATION(w1, w2, w3, w4))
> >   IF(CONJUNCTION) -> THEN
> >
> >
> > In other words we spect some kind of "interruption" to execute the THEN
> > statement
>
> There is not explicit interruption. The execution is much more
> "brute-force" using the usual ruta rule behavior.
>
> I just summarize my interpretation a bit although you probably know all
> of that already:
>
> There are two special language constructs: an inlined rule as condition
> and a conjunct rule element. For validating the condition of the main
> rule element (Document), the inlined rules need to be validated, meaning
> one of the inlined rules sto match. So, Ruta starts by trying to apply
> the first rule, which is the only rule in this example. The rule
> consists of some conjunct rule elements. Therefore, the rule element
> starts to apply each conjunct rule element separately and all rule
> element matches are remembered/stored. If at least one rule element
> match for each of the conjunct rule elements matched successfully, then
> the actions of all successful rule element matches are executed. If the
> inlined rule was able to match, then the actual rule element matched
> successfully, and the rule matched successfully, and the actions of the
> actual rule are executed.
>
>
> > But it seems that right now, all the permutations are inspected and then
> > the necessary annotations are created and, obviously, w1, w2, w3, w4 have
> > the values of the last iteration.
>
> Yes, since the matching conditions of the conjuncted rule elements are
> equal, the successful rule element matches should build all
> permutations. The variables of the labels (w1,w2...) have the value of
> the last match of the rule element even if it was not successful, the X.
>
> > What do you think?
> >
> >
>
> I am still wondering about what should/can be done to improve this
> situation/use case. If I override the value of  the label variables with
> null for an unsuccessful match, it would not solve the problem in this
> current example. Resetting the value to the last valid one makes only
> sense for the conjunct rule, but will be very problematic in all other
> cases.
>
> What I previously did in such cases, was to introduce a new language
> construct that supports the current need, e.g., the conjunct rules.
> Right now, the expressiveness of ruta is high enough that this should
> not happen too often. On the other hand, maybe stepping back a bit and
> looking at the problem to be solved from a different perspective is a
> better approach. Maybe this should not be solved with labels and
> conjunct rules, but maybe rather with something else like
> ONLYONCE/ONLYFIRST, a boolean variable, or a new inlined rule
>
> Best,
>
> Peter
>
> >
> >
> >
> >
> >
> >
> > 2017-03-13 18:05 GMT+01:00 Peter Klügl :
> >
> >> Hi,
> >>
> >>
> >> Am 13.03.2017 um 17:41 schrieb José Vicente Moyano Murillo:
> >>> From our point of view we would expect the same result using # or %
> >> Yes, I thought the same, but after investigating the problem I changed
> >> my mind a bit.
> >> Even if we ignore the label expression overriding the values with 'X's,
> >> there is still a difference. The wildcard # introduces a sequential
> >> constraint, and the conjunction % does not. The former implies a match
> >> only for the next occureence of a valid annotation. And the latter? I
> >> would initially say that the match should not be restricted to the first
> >> one, meaning the first rule element for example will match twice as does
> >> the fourth rule element. This would result in four 'A's in the list
> >> compared to the two for the wildcard.
> >>
> >> And there is also the difference that the execution of the action is
> >> decoupled from the specific rule elements in the conjunct element
> >> (causing the initial problem with the label expression)
> >>
> >>> In any case it is our idea and the truth is that we do not know how to
> >>> predict the impact.
> >> I can 

Re: Using RUTA

[Peter Klügl]

Hi,


Am 15.03.2017 um 10:24 schrieb José Vicente Moyano Murillo:
> Great explanation Peter, we see all your comments.
> Maybe we are doing something wrong to accomplish our pourpouse.
>
> But regarding labels. Can we discuss this example?
>
> Document{ -> ADD(list, w1), ADD(list, w2), ADD(list, w3), ADD(list, w4),
> CREATE(Detection, "anchors" = list)} <- {
> w1:CW{w1.ct=="A" }
> %
> w2:CW{w2.ct=="B" }
> %
> w3:CW{w3.ct=="B"  }
> %
> w4:CW{w4.ct=="A" };
>};
>
> In our mind conjuntion rules are aplyed using something like this pattern:
>
> FOR (PERMUTATION(w1, w2, w3, w4))
>   IF(CONJUNCTION) -> THEN
>
>
> In other words we spect some kind of "interruption" to execute the THEN
> statement

There is not explicit interruption. The execution is much more
"brute-force" using the usual ruta rule behavior.

I just summarize my interpretation a bit although you probably know all
of that already:

There are two special language constructs: an inlined rule as condition
and a conjunct rule element. For validating the condition of the main
rule element (Document), the inlined rules need to be validated, meaning
one of the inlined rules sto match. So, Ruta starts by trying to apply
the first rule, which is the only rule in this example. The rule
consists of some conjunct rule elements. Therefore, the rule element
starts to apply each conjunct rule element separately and all rule
element matches are remembered/stored. If at least one rule element
match for each of the conjunct rule elements matched successfully, then
the actions of all successful rule element matches are executed. If the
inlined rule was able to match, then the actual rule element matched
successfully, and the rule matched successfully, and the actions of the
actual rule are executed.


> But it seems that right now, all the permutations are inspected and then
> the necessary annotations are created and, obviously, w1, w2, w3, w4 have
> the values of the last iteration.

Yes, since the matching conditions of the conjuncted rule elements are
equal, the successful rule element matches should build all
permutations. The variables of the labels (w1,w2...) have the value of
the last match of the rule element even if it was not successful, the X.

> What do you think?
>
>

I am still wondering about what should/can be done to improve this
situation/use case. If I override the value of  the label variables with
null for an unsuccessful match, it would not solve the problem in this
current example. Resetting the value to the last valid one makes only
sense for the conjunct rule, but will be very problematic in all other
cases.

What I previously did in such cases, was to introduce a new language
construct that supports the current need, e.g., the conjunct rules.
Right now, the expressiveness of ruta is high enough that this should
not happen too often. On the other hand, maybe stepping back a bit and
looking at the problem to be solved from a different perspective is a
better approach. Maybe this should not be solved with labels and
conjunct rules, but maybe rather with something else like
ONLYONCE/ONLYFIRST, a boolean variable, or a new inlined rule

Best,

Peter

>
>
>
>
>
>
> 2017-03-13 18:05 GMT+01:00 Peter Klügl :
>
>> Hi,
>>
>>
>> Am 13.03.2017 um 17:41 schrieb José Vicente Moyano Murillo:
>>> From our point of view we would expect the same result using # or %
>> Yes, I thought the same, but after investigating the problem I changed
>> my mind a bit.
>> Even if we ignore the label expression overriding the values with 'X's,
>> there is still a difference. The wildcard # introduces a sequential
>> constraint, and the conjunction % does not. The former implies a match
>> only for the next occureence of a valid annotation. And the latter? I
>> would initially say that the match should not be restricted to the first
>> one, meaning the first rule element for example will match twice as does
>> the fourth rule element. This would result in four 'A's in the list
>> compared to the two for the wildcard.
>>
>> And there is also the difference that the execution of the action is
>> decoupled from the specific rule elements in the conjunct element
>> (causing the initial problem with the label expression)
>>
>>> In any case it is our idea and the truth is that we do not know how to
>>> predict the impact.
>> I can totally understand that. I had to debug the implementation myself
>> quite a bit in order to get to know what is going on. That does not
>> happen too often to me concerning ruta.
>>
>> I am open to suggestions how this situation can be improved. I am not
>> sure yet what should/can be done.
>>
>> Best,
>>
>> Peter
>>
>>> regards
>>>
>>> 2017-03-13 10:56 GMT+01:00 Peter Klügl :
>>>
 Hi,


 there is a conceptual problem when using label expressions in those
 conjunct rules. The label expression stores the value 

Re: Using RUTA

[Peter Klügl]

Hi,


sorry, I am quite busy these days. Could be that it will take some more
days until I can reply to your mail.


Best,


Peter


Am 15.03.2017 um 10:24 schrieb José Vicente Moyano Murillo:
> Great explanation Peter, we see all your comments.
> Maybe we are doing something wrong to accomplish our pourpouse.
>
> But regarding labels. Can we discuss this example?
>
> Document{ -> ADD(list, w1), ADD(list, w2), ADD(list, w3), ADD(list, w4),
> CREATE(Detection, "anchors" = list)} <- {
> w1:CW{w1.ct=="A" }
> %
> w2:CW{w2.ct=="B" }
> %
> w3:CW{w3.ct=="B"  }
> %
> w4:CW{w4.ct=="A" };
>};
>
> In our mind conjuntion rules are aplyed using something like this pattern:
>
> FOR (PERMUTATION(w1, w2, w3, w4))
>   IF(CONJUNCTION) -> THEN
>
>
> In other words we spect some kind of "interruption" to execute the THEN
> statement
>
> But it seems that right now, all the permutations are inspected and then
> the necessary annotations are created and, obviously, w1, w2, w3, w4 have
> the values of the last iteration.
>
> What do you think?
>
>
>
>
>
>
>
>
>
> 2017-03-13 18:05 GMT+01:00 Peter Klügl :
>
>> Hi,
>>
>>
>> Am 13.03.2017 um 17:41 schrieb José Vicente Moyano Murillo:
>>> From our point of view we would expect the same result using # or %
>> Yes, I thought the same, but after investigating the problem I changed
>> my mind a bit.
>> Even if we ignore the label expression overriding the values with 'X's,
>> there is still a difference. The wildcard # introduces a sequential
>> constraint, and the conjunction % does not. The former implies a match
>> only for the next occureence of a valid annotation. And the latter? I
>> would initially say that the match should not be restricted to the first
>> one, meaning the first rule element for example will match twice as does
>> the fourth rule element. This would result in four 'A's in the list
>> compared to the two for the wildcard.
>>
>> And there is also the difference that the execution of the action is
>> decoupled from the specific rule elements in the conjunct element
>> (causing the initial problem with the label expression)
>>
>>> In any case it is our idea and the truth is that we do not know how to
>>> predict the impact.
>> I can totally understand that. I had to debug the implementation myself
>> quite a bit in order to get to know what is going on. That does not
>> happen too often to me concerning ruta.
>>
>> I am open to suggestions how this situation can be improved. I am not
>> sure yet what should/can be done.
>>
>> Best,
>>
>> Peter
>>
>>> regards
>>>
>>> 2017-03-13 10:56 GMT+01:00 Peter Klügl :
>>>
 Hi,


 there is a conceptual problem when using label expressions in those
 conjunct rules. The label expression stores the value of the matched
 annotations even if the rule element does not match. It has to since the
 matched annotation may be used to validate the conditions as you do.

 Maybe the value should be reset if the rule element does not match
 correctly, but I have to investigate the consequences furhter before I
 implement this change. Are there opinions?


 If you change the rule to not use the label expression in the action,
 there still seems to be a problem with the conjunct rules. e.g. like:

 Document{ -> CREATE(Detection, "anchors" = list)} <- {
 w1:CW{w1.ct=="A" -> ADD(list, CW)}
 %
 w2:CW{w2.ct=="B" -> ADD(list, CW)}
%
w3:CW{w3.ct=="B" -> ADD(list, CW)}
%
w4:CW{w4.ct=="A" -> ADD(list, CW)};
};


 This looks like a bug when validating the match itself depednent on the
 element matches. I need to investigate that further...


 I'll create a jira ticket for both.


 Best,


 Peter



 Am 09.03.2017 um 11:23 schrieb José Vicente Moyano Murillo:
> Hi Peter
>
> We have prepared a short test with 2 methods.
> The first one is using #, the second one is using %
>
> We expect the same behaviour. But as you will see there are diferences.
>
> Regards
>
> 2017-02-28 16:00 GMT+01:00 Peter Klügl  >:
>
> hmmm ok, maybe my example for testing the rule was too simple.
>
> I will create a more complex example and check the results
>
>
> Peter
>
>
> Am 28.02.2017 um 15:38 schrieb José Vicente Moyano Murillo:
> > Hi Peter,
> >
> > I'm sorry but this example does not work properly. It seems that
> it is a
> > problem regarding conjunction rules (%)
> >
> > This is our test case and result.
> >
> > We have a book with 5 attributes
> > - name
> > - author
> > - 

Re: Using RUTA

[José Vicente Moyano Murillo]

Great explanation Peter, we see all your comments.
Maybe we are doing something wrong to accomplish our pourpouse.

But regarding labels. Can we discuss this example?

Document{ -> ADD(list, w1), ADD(list, w2), ADD(list, w3), ADD(list, w4),
CREATE(Detection, "anchors" = list)} <- {
w1:CW{w1.ct=="A" }
%
w2:CW{w2.ct=="B" }
%
w3:CW{w3.ct=="B"  }
%
w4:CW{w4.ct=="A" };
   };

In our mind conjuntion rules are aplyed using something like this pattern:

FOR (PERMUTATION(w1, w2, w3, w4))
  IF(CONJUNCTION) -> THEN


In other words we spect some kind of "interruption" to execute the THEN
statement

But it seems that right now, all the permutations are inspected and then
the necessary annotations are created and, obviously, w1, w2, w3, w4 have
the values of the last iteration.

What do you think?









2017-03-13 18:05 GMT+01:00 Peter Klügl :

> Hi,
>
>
> Am 13.03.2017 um 17:41 schrieb José Vicente Moyano Murillo:
> > From our point of view we would expect the same result using # or %
>
> Yes, I thought the same, but after investigating the problem I changed
> my mind a bit.
> Even if we ignore the label expression overriding the values with 'X's,
> there is still a difference. The wildcard # introduces a sequential
> constraint, and the conjunction % does not. The former implies a match
> only for the next occureence of a valid annotation. And the latter? I
> would initially say that the match should not be restricted to the first
> one, meaning the first rule element for example will match twice as does
> the fourth rule element. This would result in four 'A's in the list
> compared to the two for the wildcard.
>
> And there is also the difference that the execution of the action is
> decoupled from the specific rule elements in the conjunct element
> (causing the initial problem with the label expression)
>
> > In any case it is our idea and the truth is that we do not know how to
> > predict the impact.
>
> I can totally understand that. I had to debug the implementation myself
> quite a bit in order to get to know what is going on. That does not
> happen too often to me concerning ruta.
>
> I am open to suggestions how this situation can be improved. I am not
> sure yet what should/can be done.
>
> Best,
>
> Peter
>
> >
> > regards
> >
> > 2017-03-13 10:56 GMT+01:00 Peter Klügl :
> >
> >> Hi,
> >>
> >>
> >> there is a conceptual problem when using label expressions in those
> >> conjunct rules. The label expression stores the value of the matched
> >> annotations even if the rule element does not match. It has to since the
> >> matched annotation may be used to validate the conditions as you do.
> >>
> >> Maybe the value should be reset if the rule element does not match
> >> correctly, but I have to investigate the consequences furhter before I
> >> implement this change. Are there opinions?
> >>
> >>
> >> If you change the rule to not use the label expression in the action,
> >> there still seems to be a problem with the conjunct rules. e.g. like:
> >>
> >> Document{ -> CREATE(Detection, "anchors" = list)} <- {
> >> w1:CW{w1.ct=="A" -> ADD(list, CW)}
> >> %
> >> w2:CW{w2.ct=="B" -> ADD(list, CW)}
> >>%
> >>w3:CW{w3.ct=="B" -> ADD(list, CW)}
> >>%
> >>w4:CW{w4.ct=="A" -> ADD(list, CW)};
> >>};
> >>
> >>
> >> This looks like a bug when validating the match itself depednent on the
> >> element matches. I need to investigate that further...
> >>
> >>
> >> I'll create a jira ticket for both.
> >>
> >>
> >> Best,
> >>
> >>
> >> Peter
> >>
> >>
> >>
> >> Am 09.03.2017 um 11:23 schrieb José Vicente Moyano Murillo:
> >>> Hi Peter
> >>>
> >>> We have prepared a short test with 2 methods.
> >>> The first one is using #, the second one is using %
> >>>
> >>> We expect the same behaviour. But as you will see there are diferences.
> >>>
> >>> Regards
> >>>
> >>> 2017-02-28 16:00 GMT+01:00 Peter Klügl  >>> >:
> >>>
> >>> hmmm ok, maybe my example for testing the rule was too simple.
> >>>
> >>> I will create a more complex example and check the results
> >>>
> >>>
> >>> Peter
> >>>
> >>>
> >>> Am 28.02.2017 um 15:38 schrieb José Vicente Moyano Murillo:
> >>> > Hi Peter,
> >>> >
> >>> > I'm sorry but this example does not work properly. It seems that
> >>> it is a
> >>> > problem regarding conjunction rules (%)
> >>> >
> >>> > This is our test case and result.
> >>> >
> >>> > We have a book with 5 attributes
> >>> > - name
> >>> > - author
> >>> > - pages
> >>> > - ISBN
> >>> > - Category
> >>> >
> >>> > The rule is validatin name and author.
> >>> >
> >>> > RUTA creates the annotation with the list but the list contains
> >>> 20 times
> >>> > the las attribute (Category).
> >>> >
> >>>

Re: Using RUTA

[Peter Klügl]

Hi,


Am 13.03.2017 um 17:41 schrieb José Vicente Moyano Murillo:
> From our point of view we would expect the same result using # or %

Yes, I thought the same, but after investigating the problem I changed
my mind a bit.
Even if we ignore the label expression overriding the values with 'X's,
there is still a difference. The wildcard # introduces a sequential
constraint, and the conjunction % does not. The former implies a match
only for the next occureence of a valid annotation. And the latter? I
would initially say that the match should not be restricted to the first
one, meaning the first rule element for example will match twice as does
the fourth rule element. This would result in four 'A's in the list
compared to the two for the wildcard.

And there is also the difference that the execution of the action is
decoupled from the specific rule elements in the conjunct element
(causing the initial problem with the label expression)

> In any case it is our idea and the truth is that we do not know how to
> predict the impact.

I can totally understand that. I had to debug the implementation myself
quite a bit in order to get to know what is going on. That does not
happen too often to me concerning ruta.

I am open to suggestions how this situation can be improved. I am not
sure yet what should/can be done.

Best,

Peter

>
> regards
>
> 2017-03-13 10:56 GMT+01:00 Peter Klügl :
>
>> Hi,
>>
>>
>> there is a conceptual problem when using label expressions in those
>> conjunct rules. The label expression stores the value of the matched
>> annotations even if the rule element does not match. It has to since the
>> matched annotation may be used to validate the conditions as you do.
>>
>> Maybe the value should be reset if the rule element does not match
>> correctly, but I have to investigate the consequences furhter before I
>> implement this change. Are there opinions?
>>
>>
>> If you change the rule to not use the label expression in the action,
>> there still seems to be a problem with the conjunct rules. e.g. like:
>>
>> Document{ -> CREATE(Detection, "anchors" = list)} <- {
>> w1:CW{w1.ct=="A" -> ADD(list, CW)}
>> %
>> w2:CW{w2.ct=="B" -> ADD(list, CW)}
>>%
>>w3:CW{w3.ct=="B" -> ADD(list, CW)}
>>%
>>w4:CW{w4.ct=="A" -> ADD(list, CW)};
>>};
>>
>>
>> This looks like a bug when validating the match itself depednent on the
>> element matches. I need to investigate that further...
>>
>>
>> I'll create a jira ticket for both.
>>
>>
>> Best,
>>
>>
>> Peter
>>
>>
>>
>> Am 09.03.2017 um 11:23 schrieb José Vicente Moyano Murillo:
>>> Hi Peter
>>>
>>> We have prepared a short test with 2 methods.
>>> The first one is using #, the second one is using %
>>>
>>> We expect the same behaviour. But as you will see there are diferences.
>>>
>>> Regards
>>>
>>> 2017-02-28 16:00 GMT+01:00 Peter Klügl >> >:
>>>
>>> hmmm ok, maybe my example for testing the rule was too simple.
>>>
>>> I will create a more complex example and check the results
>>>
>>>
>>> Peter
>>>
>>>
>>> Am 28.02.2017 um 15:38 schrieb José Vicente Moyano Murillo:
>>> > Hi Peter,
>>> >
>>> > I'm sorry but this example does not work properly. It seems that
>>> it is a
>>> > problem regarding conjunction rules (%)
>>> >
>>> > This is our test case and result.
>>> >
>>> > We have a book with 5 attributes
>>> > - name
>>> > - author
>>> > - pages
>>> > - ISBN
>>> > - Category
>>> >
>>> > The rule is validatin name and author.
>>> >
>>> > RUTA creates the annotation with the list but the list contains
>>> 20 times
>>> > the las attribute (Category).
>>> >
>>> > If we use # it works perfectly. But in general we must use %
>>> >
>>> > May be this information will help you.
>>> >
>>> > Many thanks
>>> >
>>> >
>>> >
>>> > 2017-02-28 14:23 GMT+01:00 Peter Kluegl >> >:
>>> >
>>> >> Hi,
>>> >>
>>> >>
>>> >> operations directly on lists and arrays are on my todo list but
>>> not yet
>>> >> implemented.
>>> >>
>>> >>
>>> >> Right now, there are still some options like a variable or
>>> restricted
>>> >> assignments.
>>> >>
>>> >>
>>> >> Here's an example with an ANNOTATIONLIST variable:
>>> >>
>>> >>
>>> >> ANNOTATIONLIST list;
>>> >> Book{-> CREATE(NeilsBook, "attributes" = list)}<-{
>>> >> a1:Attribute{a1.name =="title",
>>> a1.ct=="Norse Mythology" ->
>>> >> ADD(list,a1)}
>>> >> % a2:Attribute{a2.name =="author",
>>> a2.ct=="Neil Gaiman" ->
>>> >> ADD(list,a2)};
>>> >> };
>>> >>
>>> >>
>>> >> Variables are global, so you need to clear the list maybe
>>> somewhere,
>>> >> 

Re: Using RUTA

[José Vicente Moyano Murillo]

>From our point of view we would expect the same result using # or %

In any case it is our idea and the truth is that we do not know how to
predict the impact.

regards

2017-03-13 10:56 GMT+01:00 Peter Klügl :

> Hi,
>
>
> there is a conceptual problem when using label expressions in those
> conjunct rules. The label expression stores the value of the matched
> annotations even if the rule element does not match. It has to since the
> matched annotation may be used to validate the conditions as you do.
>
> Maybe the value should be reset if the rule element does not match
> correctly, but I have to investigate the consequences furhter before I
> implement this change. Are there opinions?
>
>
> If you change the rule to not use the label expression in the action,
> there still seems to be a problem with the conjunct rules. e.g. like:
>
> Document{ -> CREATE(Detection, "anchors" = list)} <- {
> w1:CW{w1.ct=="A" -> ADD(list, CW)}
> %
> w2:CW{w2.ct=="B" -> ADD(list, CW)}
>%
>w3:CW{w3.ct=="B" -> ADD(list, CW)}
>%
>w4:CW{w4.ct=="A" -> ADD(list, CW)};
>};
>
>
> This looks like a bug when validating the match itself depednent on the
> element matches. I need to investigate that further...
>
>
> I'll create a jira ticket for both.
>
>
> Best,
>
>
> Peter
>
>
>
> Am 09.03.2017 um 11:23 schrieb José Vicente Moyano Murillo:
> > Hi Peter
> >
> > We have prepared a short test with 2 methods.
> > The first one is using #, the second one is using %
> >
> > We expect the same behaviour. But as you will see there are diferences.
> >
> > Regards
> >
> > 2017-02-28 16:00 GMT+01:00 Peter Klügl  > >:
> >
> > hmmm ok, maybe my example for testing the rule was too simple.
> >
> > I will create a more complex example and check the results
> >
> >
> > Peter
> >
> >
> > Am 28.02.2017 um 15:38 schrieb José Vicente Moyano Murillo:
> > > Hi Peter,
> > >
> > > I'm sorry but this example does not work properly. It seems that
> > it is a
> > > problem regarding conjunction rules (%)
> > >
> > > This is our test case and result.
> > >
> > > We have a book with 5 attributes
> > > - name
> > > - author
> > > - pages
> > > - ISBN
> > > - Category
> > >
> > > The rule is validatin name and author.
> > >
> > > RUTA creates the annotation with the list but the list contains
> > 20 times
> > > the las attribute (Category).
> > >
> > > If we use # it works perfectly. But in general we must use %
> > >
> > > May be this information will help you.
> > >
> > > Many thanks
> > >
> > >
> > >
> > > 2017-02-28 14:23 GMT+01:00 Peter Kluegl  > >:
> > >
> > >> Hi,
> > >>
> > >>
> > >> operations directly on lists and arrays are on my todo list but
> > not yet
> > >> implemented.
> > >>
> > >>
> > >> Right now, there are still some options like a variable or
> > restricted
> > >> assignments.
> > >>
> > >>
> > >> Here's an example with an ANNOTATIONLIST variable:
> > >>
> > >>
> > >> ANNOTATIONLIST list;
> > >> Book{-> CREATE(NeilsBook, "attributes" = list)}<-{
> > >> a1:Attribute{a1.name =="title",
> > a1.ct=="Norse Mythology" ->
> > >> ADD(list,a1)}
> > >> % a2:Attribute{a2.name =="author",
> > a2.ct=="Neil Gaiman" ->
> > >> ADD(list,a2)};
> > >> };
> > >>
> > >>
> > >> Variables are global, so you need to clear the list maybe
> > somewhere,
> > >> e.g. before the first ADD.
> > >>
> > >>
> > >> In the current trunk, something like the following is also
> > possible:
> > >>
> > >> Book{-> NeilsBook("attributes" = Attribute{OR(Attribute
> > >> .name=="title", Attribute.name=="author")})}
> > >>
> > >>
> > >> Best,
> > >>
> > >>
> > >> Peter
> > >>
> > >>
> > >> Am 28.02.2017 um 14:06 schrieb José Vicente Moyano Murillo:
> > >>> Hi Peter, we have another question regarding the same example.
> > >>>
> > >>> Right now all is working properly (many thanks) and it seems that
> > >>> 2.5.1-SNAPSHOT it's fine.
> > >>>
> > >>> Now we are planning to store some information in the created
> > annotation.
> > >> We
> > >>> want to store all the attributes that matches the RUTA rule.
> > >>>
> > >>> It is possible to store a1 and a2 in a feature (attributes) of
> > NeilsBook?
> > >>>
> > >>> The example:
> > >>>
> > >>> Book{-> NeilsBook}<-{
> > >>> a1:Attribute{a1.name =="title",
> > a1.ct=="Norse Mythology"}
> > >>> %
> > >>> a2:Attribute{a2.name =="author", a2.ct=="Neil
> > 

Re: Using RUTA

[Peter Klügl]

Hi,


there is a conceptual problem when using label expressions in those
conjunct rules. The label expression stores the value of the matched
annotations even if the rule element does not match. It has to since the
matched annotation may be used to validate the conditions as you do.

Maybe the value should be reset if the rule element does not match
correctly, but I have to investigate the consequences furhter before I
implement this change. Are there opinions?


If you change the rule to not use the label expression in the action,
there still seems to be a problem with the conjunct rules. e.g. like:

Document{ -> CREATE(Detection, "anchors" = list)} <- {
w1:CW{w1.ct=="A" -> ADD(list, CW)}
%
w2:CW{w2.ct=="B" -> ADD(list, CW)}
   %
   w3:CW{w3.ct=="B" -> ADD(list, CW)}
   %
   w4:CW{w4.ct=="A" -> ADD(list, CW)};
   };


This looks like a bug when validating the match itself depednent on the
element matches. I need to investigate that further...


I'll create a jira ticket for both.


Best,


Peter



Am 09.03.2017 um 11:23 schrieb José Vicente Moyano Murillo:
> Hi Peter 
>
> We have prepared a short test with 2 methods.
> The first one is using #, the second one is using %
>
> We expect the same behaviour. But as you will see there are diferences.
>
> Regards
>
> 2017-02-28 16:00 GMT+01:00 Peter Klügl  >:
>
> hmmm ok, maybe my example for testing the rule was too simple.
>
> I will create a more complex example and check the results
>
>
> Peter
>
>
> Am 28.02.2017 um 15:38 schrieb José Vicente Moyano Murillo:
> > Hi Peter,
> >
> > I'm sorry but this example does not work properly. It seems that
> it is a
> > problem regarding conjunction rules (%)
> >
> > This is our test case and result.
> >
> > We have a book with 5 attributes
> > - name
> > - author
> > - pages
> > - ISBN
> > - Category
> >
> > The rule is validatin name and author.
> >
> > RUTA creates the annotation with the list but the list contains
> 20 times
> > the las attribute (Category).
> >
> > If we use # it works perfectly. But in general we must use %
> >
> > May be this information will help you.
> >
> > Many thanks
> >
> >
> >
> > 2017-02-28 14:23 GMT+01:00 Peter Kluegl  >:
> >
> >> Hi,
> >>
> >>
> >> operations directly on lists and arrays are on my todo list but
> not yet
> >> implemented.
> >>
> >>
> >> Right now, there are still some options like a variable or
> restricted
> >> assignments.
> >>
> >>
> >> Here's an example with an ANNOTATIONLIST variable:
> >>
> >>
> >> ANNOTATIONLIST list;
> >> Book{-> CREATE(NeilsBook, "attributes" = list)}<-{
> >> a1:Attribute{a1.name =="title",
> a1.ct=="Norse Mythology" ->
> >> ADD(list,a1)}
> >> % a2:Attribute{a2.name =="author",
> a2.ct=="Neil Gaiman" ->
> >> ADD(list,a2)};
> >> };
> >>
> >>
> >> Variables are global, so you need to clear the list maybe
> somewhere,
> >> e.g. before the first ADD.
> >>
> >>
> >> In the current trunk, something like the following is also
> possible:
> >>
> >> Book{-> NeilsBook("attributes" = Attribute{OR(Attribute
> >> .name=="title", Attribute.name=="author")})}
> >>
> >>
> >> Best,
> >>
> >>
> >> Peter
> >>
> >>
> >> Am 28.02.2017 um 14:06 schrieb José Vicente Moyano Murillo:
> >>> Hi Peter, we have another question regarding the same example.
> >>>
> >>> Right now all is working properly (many thanks) and it seems that
> >>> 2.5.1-SNAPSHOT it's fine.
> >>>
> >>> Now we are planning to store some information in the created
> annotation.
> >> We
> >>> want to store all the attributes that matches the RUTA rule.
> >>>
> >>> It is possible to store a1 and a2 in a feature (attributes) of
> NeilsBook?
> >>>
> >>> The example:
> >>>
> >>> Book{-> NeilsBook}<-{
> >>> a1:Attribute{a1.name =="title",
> a1.ct=="Norse Mythology"}
> >>> %
> >>> a2:Attribute{a2.name =="author", a2.ct=="Neil
> Gaiman"};
> >>> };
> >>>
> >>> We are using this aproach:
> >>>
> >>> Book{-> NeilsBook("attributes" = Attribute )}<-{
> >>>  a1:Attribute{a1.name =="title",
> a1.ct=="Norse Mythology"}
> >>>  %
> >>> a2:Attribute{a2.name =="author", a2.ct=="Neil
> Gaiman"};
> >>> };
> >>>
> >>> This example works but it is storing all the annotations
> "Attribute"
> >>> covered by "Book" and we just want the attributes that matches
> the rule.
> >>>
> 

Re: Using RUTA

[Peter Klügl]

hmmm ok, maybe my example for testing the rule was too simple.

I will create a more complex example and check the results


Peter


Am 28.02.2017 um 15:38 schrieb José Vicente Moyano Murillo:
> Hi Peter,
>
> I'm sorry but this example does not work properly. It seems that it is a
> problem regarding conjunction rules (%)
>
> This is our test case and result.
>
> We have a book with 5 attributes
> - name
> - author
> - pages
> - ISBN
> - Category
>
> The rule is validatin name and author.
>
> RUTA creates the annotation with the list but the list contains 20 times
> the las attribute (Category).
>
> If we use # it works perfectly. But in general we must use %
>
> May be this information will help you.
>
> Many thanks
>
>
>
> 2017-02-28 14:23 GMT+01:00 Peter Kluegl :
>
>> Hi,
>>
>>
>> operations directly on lists and arrays are on my todo list but not yet
>> implemented.
>>
>>
>> Right now, there are still some options like a variable or restricted
>> assignments.
>>
>>
>> Here's an example with an ANNOTATIONLIST variable:
>>
>>
>> ANNOTATIONLIST list;
>> Book{-> CREATE(NeilsBook, "attributes" = list)}<-{
>> a1:Attribute{a1.name=="title", a1.ct=="Norse Mythology" ->
>> ADD(list,a1)}
>> % a2:Attribute{a2.name=="author", a2.ct=="Neil Gaiman" ->
>> ADD(list,a2)};
>> };
>>
>>
>> Variables are global, so you need to clear the list maybe somewhere,
>> e.g. before the first ADD.
>>
>>
>> In the current trunk, something like the following is also possible:
>>
>> Book{-> NeilsBook("attributes" = Attribute{OR(Attribute
>> .name=="title", Attribute.name=="author")})}
>>
>>
>> Best,
>>
>>
>> Peter
>>
>>
>> Am 28.02.2017 um 14:06 schrieb José Vicente Moyano Murillo:
>>> Hi Peter, we have another question regarding the same example.
>>>
>>> Right now all is working properly (many thanks) and it seems that
>>> 2.5.1-SNAPSHOT it's fine.
>>>
>>> Now we are planning to store some information in the created annotation.
>> We
>>> want to store all the attributes that matches the RUTA rule.
>>>
>>> It is possible to store a1 and a2 in a feature (attributes) of NeilsBook?
>>>
>>> The example:
>>>
>>> Book{-> NeilsBook}<-{
>>> a1:Attribute{a1.name=="title", a1.ct=="Norse Mythology"}
>>> %
>>> a2:Attribute{a2.name=="author", a2.ct=="Neil Gaiman"};
>>> };
>>>
>>> We are using this aproach:
>>>
>>> Book{-> NeilsBook("attributes" = Attribute )}<-{
>>>  a1:Attribute{a1.name=="title", a1.ct=="Norse Mythology"}
>>>  %
>>> a2:Attribute{a2.name=="author", a2.ct=="Neil Gaiman"};
>>> };
>>>
>>> This example works but it is storing all the annotations "Attribute"
>>> covered by "Book" and we just want the attributes that matches the rule.
>>>
>>> Thanks in advance.
>>>
>>>
>>>
>>>
>>> 2017-02-24 10:29 GMT+01:00 José Vicente Moyano Murillo :
>>>
 Many thanks Peter ¡¡¡

 2017-02-24 9:46 GMT+01:00 Peter Klügl :

> Hi,
>
>
> the repo:
>
> 
>   apache.snapshots
>   Apache Snapshot Repository
>   http://repository.apache.org/snapshots
>   
> false
>   
> 
>
>
> the folder:
>
> https://repository.apache.org/content/groups/snapshots/org/a
> pache/uima/ruta-core/2.5.1-SNAPSHOT/
>
>
> Best,
>
> Peter
>
>
>
> Am 23.02.2017 um 13:47 schrieb José Vicente Moyano Murillo:
>> Hi,
>>
>> ruta-core.jar it's enough.
>>
>> It will be fantastic if i could access the snapshot repository.
>>
>> 2017-02-23 13:03 GMT+01:00 Peter Klügl :
>>
>>> Hi,
>>>
>>>
>>> what do you need? Only ruta-core.jar or also the Eclipse
>> plugins/update
>>> site?
>>>
>>> I will prepare a new RC for the next release soon.
>>>
>>> There should be snapshot artifacts built by jenkins in the snapshot
>>> repository. I am out-of-office today so do not have the link right
> now. (If
>>> you want to build it yourself, the svn source repo can be accessed by
>>> anyone)
>>>
>>>
>>> Best,
>>>
>>>
>>> Peter
>>>
>>>
>>>
>>>
>>> Am 23.02.2017 um 08:06 schrieb José Vicente Moyano Murillo:
>>>
 Hi Peter, good morning.

 Have we any opportunity to get a fixed version? I mean a snapshot or
> an
 access to the repo.

 Regards

 2017-02-22 10:38 GMT+01:00 José Vicente Moyano Murillo <
> moya...@aia.es>:
 you're right
> % is performing some kind of "or".
>
> So we will wait for the new release.
>
> Many thanks
>
> 2017-02-22 9:54 GMT+01:00 Peter Klügl :
>
> I actually wonder why your rules work. I am quite sure that they
> match
>> too often, i. e. they match also if only one of the conjunct rule
>> elements 

Re: Using RUTA

[Peter Kluegl]

hmmm ok, maybe my example for testing the rule was too simple.

I will create a more complex example and check the results


Peter


Am 28.02.2017 um 15:38 schrieb José Vicente Moyano Murillo:
> Hi Peter,
>
> I'm sorry but this example does not work properly. It seems that it is a
> problem regarding conjunction rules (%)
>
> This is our test case and result.
>
> We have a book with 5 attributes
> - name
> - author
> - pages
> - ISBN
> - Category
>
> The rule is validatin name and author.
>
> RUTA creates the annotation with the list but the list contains 20 times
> the las attribute (Category).
>
> If we use # it works perfectly. But in general we must use %
>
> May be this information will help you.
>
> Many thanks
>
>
>
> 2017-02-28 14:23 GMT+01:00 Peter Kluegl :
>
>> Hi,
>>
>>
>> operations directly on lists and arrays are on my todo list but not yet
>> implemented.
>>
>>
>> Right now, there are still some options like a variable or restricted
>> assignments.
>>
>>
>> Here's an example with an ANNOTATIONLIST variable:
>>
>>
>> ANNOTATIONLIST list;
>> Book{-> CREATE(NeilsBook, "attributes" = list)}<-{
>> a1:Attribute{a1.name=="title", a1.ct=="Norse Mythology" ->
>> ADD(list,a1)}
>> % a2:Attribute{a2.name=="author", a2.ct=="Neil Gaiman" ->
>> ADD(list,a2)};
>> };
>>
>>
>> Variables are global, so you need to clear the list maybe somewhere,
>> e.g. before the first ADD.
>>
>>
>> In the current trunk, something like the following is also possible:
>>
>> Book{-> NeilsBook("attributes" = Attribute{OR(Attribute
>> .name=="title", Attribute.name=="author")})}
>>
>>
>> Best,
>>
>>
>> Peter
>>
>>
>> Am 28.02.2017 um 14:06 schrieb José Vicente Moyano Murillo:
>>> Hi Peter, we have another question regarding the same example.
>>>
>>> Right now all is working properly (many thanks) and it seems that
>>> 2.5.1-SNAPSHOT it's fine.
>>>
>>> Now we are planning to store some information in the created annotation.
>> We
>>> want to store all the attributes that matches the RUTA rule.
>>>
>>> It is possible to store a1 and a2 in a feature (attributes) of NeilsBook?
>>>
>>> The example:
>>>
>>> Book{-> NeilsBook}<-{
>>> a1:Attribute{a1.name=="title", a1.ct=="Norse Mythology"}
>>> %
>>> a2:Attribute{a2.name=="author", a2.ct=="Neil Gaiman"};
>>> };
>>>
>>> We are using this aproach:
>>>
>>> Book{-> NeilsBook("attributes" = Attribute )}<-{
>>>  a1:Attribute{a1.name=="title", a1.ct=="Norse Mythology"}
>>>  %
>>> a2:Attribute{a2.name=="author", a2.ct=="Neil Gaiman"};
>>> };
>>>
>>> This example works but it is storing all the annotations "Attribute"
>>> covered by "Book" and we just want the attributes that matches the rule.
>>>
>>> Thanks in advance.
>>>
>>>
>>>
>>>
>>> 2017-02-24 10:29 GMT+01:00 José Vicente Moyano Murillo :
>>>
 Many thanks Peter ¡¡¡

 2017-02-24 9:46 GMT+01:00 Peter Klügl :

> Hi,
>
>
> the repo:
>
> 
>   apache.snapshots
>   Apache Snapshot Repository
>   http://repository.apache.org/snapshots
>   
> false
>   
> 
>
>
> the folder:
>
> https://repository.apache.org/content/groups/snapshots/org/a
> pache/uima/ruta-core/2.5.1-SNAPSHOT/
>
>
> Best,
>
> Peter
>
>
>
> Am 23.02.2017 um 13:47 schrieb José Vicente Moyano Murillo:
>> Hi,
>>
>> ruta-core.jar it's enough.
>>
>> It will be fantastic if i could access the snapshot repository.
>>
>> 2017-02-23 13:03 GMT+01:00 Peter Klügl :
>>
>>> Hi,
>>>
>>>
>>> what do you need? Only ruta-core.jar or also the Eclipse
>> plugins/update
>>> site?
>>>
>>> I will prepare a new RC for the next release soon.
>>>
>>> There should be snapshot artifacts built by jenkins in the snapshot
>>> repository. I am out-of-office today so do not have the link right
> now. (If
>>> you want to build it yourself, the svn source repo can be accessed by
>>> anyone)
>>>
>>>
>>> Best,
>>>
>>>
>>> Peter
>>>
>>>
>>>
>>>
>>> Am 23.02.2017 um 08:06 schrieb José Vicente Moyano Murillo:
>>>
 Hi Peter, good morning.

 Have we any opportunity to get a fixed version? I mean a snapshot or
> an
 access to the repo.

 Regards

 2017-02-22 10:38 GMT+01:00 José Vicente Moyano Murillo <
> moya...@aia.es>:
 you're right
> % is performing some kind of "or".
>
> So we will wait for the new release.
>
> Many thanks
>
> 2017-02-22 9:54 GMT+01:00 Peter Klügl :
>
> I actually wonder why your rules work. I am quite sure that they
> match
>> too often, i. e. they match also if only one of the conjunct rule
>> elements 

Re: Using RUTA

[José Vicente Moyano Murillo]

Hi Peter,

I'm sorry but this example does not work properly. It seems that it is a
problem regarding conjunction rules (%)

This is our test case and result.

We have a book with 5 attributes
- name
- author
- pages
- ISBN
- Category

The rule is validatin name and author.

RUTA creates the annotation with the list but the list contains 20 times
the las attribute (Category).

If we use # it works perfectly. But in general we must use %

May be this information will help you.

Many thanks



2017-02-28 14:23 GMT+01:00 Peter Kluegl :

> Hi,
>
>
> operations directly on lists and arrays are on my todo list but not yet
> implemented.
>
>
> Right now, there are still some options like a variable or restricted
> assignments.
>
>
> Here's an example with an ANNOTATIONLIST variable:
>
>
> ANNOTATIONLIST list;
> Book{-> CREATE(NeilsBook, "attributes" = list)}<-{
> a1:Attribute{a1.name=="title", a1.ct=="Norse Mythology" ->
> ADD(list,a1)}
> % a2:Attribute{a2.name=="author", a2.ct=="Neil Gaiman" ->
> ADD(list,a2)};
> };
>
>
> Variables are global, so you need to clear the list maybe somewhere,
> e.g. before the first ADD.
>
>
> In the current trunk, something like the following is also possible:
>
> Book{-> NeilsBook("attributes" = Attribute{OR(Attribute
> .name=="title", Attribute.name=="author")})}
>
>
> Best,
>
>
> Peter
>
>
> Am 28.02.2017 um 14:06 schrieb José Vicente Moyano Murillo:
> > Hi Peter, we have another question regarding the same example.
> >
> > Right now all is working properly (many thanks) and it seems that
> > 2.5.1-SNAPSHOT it's fine.
> >
> > Now we are planning to store some information in the created annotation.
> We
> > want to store all the attributes that matches the RUTA rule.
> >
> > It is possible to store a1 and a2 in a feature (attributes) of NeilsBook?
> >
> > The example:
> >
> > Book{-> NeilsBook}<-{
> > a1:Attribute{a1.name=="title", a1.ct=="Norse Mythology"}
> > %
> > a2:Attribute{a2.name=="author", a2.ct=="Neil Gaiman"};
> > };
> >
> > We are using this aproach:
> >
> > Book{-> NeilsBook("attributes" = Attribute )}<-{
> >  a1:Attribute{a1.name=="title", a1.ct=="Norse Mythology"}
> >  %
> > a2:Attribute{a2.name=="author", a2.ct=="Neil Gaiman"};
> > };
> >
> > This example works but it is storing all the annotations "Attribute"
> > covered by "Book" and we just want the attributes that matches the rule.
> >
> > Thanks in advance.
> >
> >
> >
> >
> > 2017-02-24 10:29 GMT+01:00 José Vicente Moyano Murillo :
> >
> >> Many thanks Peter ¡¡¡
> >>
> >> 2017-02-24 9:46 GMT+01:00 Peter Klügl :
> >>
> >>> Hi,
> >>>
> >>>
> >>> the repo:
> >>>
> >>> 
> >>>   apache.snapshots
> >>>   Apache Snapshot Repository
> >>>   http://repository.apache.org/snapshots
> >>>   
> >>> false
> >>>   
> >>> 
> >>>
> >>>
> >>> the folder:
> >>>
> >>> https://repository.apache.org/content/groups/snapshots/org/a
> >>> pache/uima/ruta-core/2.5.1-SNAPSHOT/
> >>>
> >>>
> >>> Best,
> >>>
> >>> Peter
> >>>
> >>>
> >>>
> >>> Am 23.02.2017 um 13:47 schrieb José Vicente Moyano Murillo:
>  Hi,
> 
>  ruta-core.jar it's enough.
> 
>  It will be fantastic if i could access the snapshot repository.
> 
>  2017-02-23 13:03 GMT+01:00 Peter Klügl :
> 
> > Hi,
> >
> >
> > what do you need? Only ruta-core.jar or also the Eclipse
> plugins/update
> > site?
> >
> > I will prepare a new RC for the next release soon.
> >
> > There should be snapshot artifacts built by jenkins in the snapshot
> > repository. I am out-of-office today so do not have the link right
> >>> now. (If
> > you want to build it yourself, the svn source repo can be accessed by
> > anyone)
> >
> >
> > Best,
> >
> >
> > Peter
> >
> >
> >
> >
> > Am 23.02.2017 um 08:06 schrieb José Vicente Moyano Murillo:
> >
> >> Hi Peter, good morning.
> >>
> >> Have we any opportunity to get a fixed version? I mean a snapshot or
> >>> an
> >> access to the repo.
> >>
> >> Regards
> >>
> >> 2017-02-22 10:38 GMT+01:00 José Vicente Moyano Murillo <
> >>> moya...@aia.es>:
> >> you're right
> >>> % is performing some kind of "or".
> >>>
> >>> So we will wait for the new release.
> >>>
> >>> Many thanks
> >>>
> >>> 2017-02-22 9:54 GMT+01:00 Peter Klügl :
> >>>
> >>> I actually wonder why your rules work. I am quite sure that they
> >>> match
>  too often, i. e. they match also if only one of the conjunct rule
>  elements match.
> 
>  You can simply try that by using a wrong string in the check like
> >>> "NG"
>  instead of "Neil Gaiman"
> 
>  Anyways, the problem will be fixed in a few minutes and will be
> >>> part of
>  the next release.
> 

Re: Using RUTA

[Peter Kluegl]

Hi,


operations directly on lists and arrays are on my todo list but not yet
implemented.


Right now, there are still some options like a variable or restricted
assignments.


Here's an example with an ANNOTATIONLIST variable:


ANNOTATIONLIST list;
Book{-> CREATE(NeilsBook, "attributes" = list)}<-{
a1:Attribute{a1.name=="title", a1.ct=="Norse Mythology" -> ADD(list,a1)}
% a2:Attribute{a2.name=="author", a2.ct=="Neil Gaiman" -> ADD(list,a2)};
};


Variables are global, so you need to clear the list maybe somewhere,
e.g. before the first ADD.


In the current trunk, something like the following is also possible:

Book{-> NeilsBook("attributes" = Attribute{OR(Attribute
.name=="title", Attribute.name=="author")})}


Best,


Peter


Am 28.02.2017 um 14:06 schrieb José Vicente Moyano Murillo:
> Hi Peter, we have another question regarding the same example.
>
> Right now all is working properly (many thanks) and it seems that
> 2.5.1-SNAPSHOT it's fine.
>
> Now we are planning to store some information in the created annotation. We
> want to store all the attributes that matches the RUTA rule.
>
> It is possible to store a1 and a2 in a feature (attributes) of NeilsBook?
>
> The example:
>
> Book{-> NeilsBook}<-{
> a1:Attribute{a1.name=="title", a1.ct=="Norse Mythology"}
> %
> a2:Attribute{a2.name=="author", a2.ct=="Neil Gaiman"};
> };
>
> We are using this aproach:
>
> Book{-> NeilsBook("attributes" = Attribute )}<-{
>  a1:Attribute{a1.name=="title", a1.ct=="Norse Mythology"}
>  %
> a2:Attribute{a2.name=="author", a2.ct=="Neil Gaiman"};
> };
>
> This example works but it is storing all the annotations "Attribute"
> covered by "Book" and we just want the attributes that matches the rule.
>
> Thanks in advance.
>
>
>
>
> 2017-02-24 10:29 GMT+01:00 José Vicente Moyano Murillo :
>
>> Many thanks Peter ¡¡¡
>>
>> 2017-02-24 9:46 GMT+01:00 Peter Klügl :
>>
>>> Hi,
>>>
>>>
>>> the repo:
>>>
>>> 
>>>   apache.snapshots
>>>   Apache Snapshot Repository
>>>   http://repository.apache.org/snapshots
>>>   
>>> false
>>>   
>>> 
>>>
>>>
>>> the folder:
>>>
>>> https://repository.apache.org/content/groups/snapshots/org/a
>>> pache/uima/ruta-core/2.5.1-SNAPSHOT/
>>>
>>>
>>> Best,
>>>
>>> Peter
>>>
>>>
>>>
>>> Am 23.02.2017 um 13:47 schrieb José Vicente Moyano Murillo:
 Hi,

 ruta-core.jar it's enough.

 It will be fantastic if i could access the snapshot repository.

 2017-02-23 13:03 GMT+01:00 Peter Klügl :

> Hi,
>
>
> what do you need? Only ruta-core.jar or also the Eclipse plugins/update
> site?
>
> I will prepare a new RC for the next release soon.
>
> There should be snapshot artifacts built by jenkins in the snapshot
> repository. I am out-of-office today so do not have the link right
>>> now. (If
> you want to build it yourself, the svn source repo can be accessed by
> anyone)
>
>
> Best,
>
>
> Peter
>
>
>
>
> Am 23.02.2017 um 08:06 schrieb José Vicente Moyano Murillo:
>
>> Hi Peter, good morning.
>>
>> Have we any opportunity to get a fixed version? I mean a snapshot or
>>> an
>> access to the repo.
>>
>> Regards
>>
>> 2017-02-22 10:38 GMT+01:00 José Vicente Moyano Murillo <
>>> moya...@aia.es>:
>> you're right
>>> % is performing some kind of "or".
>>>
>>> So we will wait for the new release.
>>>
>>> Many thanks
>>>
>>> 2017-02-22 9:54 GMT+01:00 Peter Klügl :
>>>
>>> I actually wonder why your rules work. I am quite sure that they
>>> match
 too often, i. e. they match also if only one of the conjunct rule
 elements match.

 You can simply try that by using a wrong string in the check like
>>> "NG"
 instead of "Neil Gaiman"

 Anyways, the problem will be fixed in a few minutes and will be
>>> part of
 the next release.


 Best,


 Peter


 Am 22.02.2017 um 09:38 schrieb Peter Klügl:

> Thanks. Maybe its just a bug in 2.5.0 I already fixed. I'll
>>> investigate
 it.

> Am 22.02.2017 um 09:24 schrieb José Vicente Moyano Murillo:
>
>> Thank you very much Peter. Your advice was amazing.
>>
>> We tried the first option using Conjunct rules and as you said it
>>> does
> not
> work with version 2.5.0. But we change a little your example and it
> works
> perfectly witn 2.4.0 and 2.5.0
>> We use theses examples with success:
>>
>> DECLARE Annotation RuleDetection;
>>   Book{ -> CREATE(NeilsBook) } <- {
>>Attribute{Attribute.name=="title", Attribute.ct=="Norse
>>
> 

Re: Using RUTA

[José Vicente Moyano Murillo]

Many thanks Peter ¡¡¡

2017-02-24 9:46 GMT+01:00 Peter Klügl :

> Hi,
>
>
> the repo:
>
> 
>   apache.snapshots
>   Apache Snapshot Repository
>   http://repository.apache.org/snapshots
>   
> false
>   
> 
>
>
> the folder:
>
> https://repository.apache.org/content/groups/snapshots/org/
> apache/uima/ruta-core/2.5.1-SNAPSHOT/
>
>
> Best,
>
> Peter
>
>
>
> Am 23.02.2017 um 13:47 schrieb José Vicente Moyano Murillo:
> > Hi,
> >
> > ruta-core.jar it's enough.
> >
> > It will be fantastic if i could access the snapshot repository.
> >
> > 2017-02-23 13:03 GMT+01:00 Peter Klügl :
> >
> >> Hi,
> >>
> >>
> >> what do you need? Only ruta-core.jar or also the Eclipse plugins/update
> >> site?
> >>
> >> I will prepare a new RC for the next release soon.
> >>
> >> There should be snapshot artifacts built by jenkins in the snapshot
> >> repository. I am out-of-office today so do not have the link right now.
> (If
> >> you want to build it yourself, the svn source repo can be accessed by
> >> anyone)
> >>
> >>
> >> Best,
> >>
> >>
> >> Peter
> >>
> >>
> >>
> >>
> >> Am 23.02.2017 um 08:06 schrieb José Vicente Moyano Murillo:
> >>
> >>> Hi Peter, good morning.
> >>>
> >>> Have we any opportunity to get a fixed version? I mean a snapshot or an
> >>> access to the repo.
> >>>
> >>> Regards
> >>>
> >>> 2017-02-22 10:38 GMT+01:00 José Vicente Moyano Murillo  >:
> >>>
> >>> you're right
>  % is performing some kind of "or".
> 
>  So we will wait for the new release.
> 
>  Many thanks
> 
>  2017-02-22 9:54 GMT+01:00 Peter Klügl :
> 
>  I actually wonder why your rules work. I am quite sure that they match
> > too often, i. e. they match also if only one of the conjunct rule
> > elements match.
> >
> > You can simply try that by using a wrong string in the check like
> "NG"
> > instead of "Neil Gaiman"
> >
> > Anyways, the problem will be fixed in a few minutes and will be part
> of
> > the next release.
> >
> >
> > Best,
> >
> >
> > Peter
> >
> >
> > Am 22.02.2017 um 09:38 schrieb Peter Klügl:
> >
> >> Thanks. Maybe its just a bug in 2.5.0 I already fixed. I'll
> investigate
> >>
> > it.
> >
> >> Am 22.02.2017 um 09:24 schrieb José Vicente Moyano Murillo:
> >>
> >>> Thank you very much Peter. Your advice was amazing.
> >>>
> >>> We tried the first option using Conjunct rules and as you said it
> does
> >>>
> >> not
> >> work with version 2.5.0. But we change a little your example and it
> >> works
> >> perfectly witn 2.4.0 and 2.5.0
> >>> We use theses examples with success:
> >>>
> >>> DECLARE Annotation RuleDetection;
> >>>   Book{ -> CREATE(NeilsBook) } <- {
> >>>Attribute{Attribute.name=="title", Attribute.ct=="Norse
> >>>
> >> Mythology"}"
> >>%
> >>>Attribute{Attribute.name=="author",
> >>> Attribute.ct=="Neil
> >>> Gaiman"};"
> >>>   };
> >>>
> >>>
> >>> DECLARE Annotation RuleDetection;
> >>>   Book{ -> CREATE(NeilsBook) } <- {
> >>> Attribute{FEATURE("name","title"), FEATURE("ct", "Norse
> >>>
> >> Mythology")}"
> >>%
> >>> Attribute{FEATURE("name","author"), FEATURE("ct",
> >>> "Neil
> >>> Gaiman")};
> >>>   };
> >>>
> >>> DECLARE Annotation RuleDetection;
> >>>   Book{ -> CREATE(NeilsBook) } <- {
> >>>Attribute{Attribute.name=="title", Attribute.ct=="Norse
> >>>
> >> Mythology"}"
> >>%
> >>> Attribute{FEATURE("name","author"), FEATURE("ct",
> >>> "Neil
> >>> Gaiman")};
> >>>   };
> >>>
> >>>
> >>> May be the problem is with when we use Identifiers:
> >>> a1:Attribute and  a2:Attribute
> >>>
> >>> In any case thank you very much for your help.
> >>>
> >>>
> >>> 2017-02-21 17:46 GMT+01:00 Peter Klügl :
> >>>
> >>> Hi,
> 
>  I'd normally say that you need the conjunt rules construct to
> specify
> 
> >>> an
> >> AND between two rule element independent of the position:
> 
>  Book{-> NeilsBook}<-{
>   a1:Attribute{a1.name=="title", a1.ct=="Norse Mythology"}
>   % a2:Attribute{a2.name=="author", a2.ct=="Neil Gaiman"};
>   };
> 
> 
>  However, I just noted that there is a problem with conjunct
> rules. I
>  haven't used it in a long time and the test coverage much lower
> than
> 
> >>> the
> >> other constructs. I'll create a ticket for it and fix it.
> 
>  Without conjunct rules, you need some boolean variables for
> cheking
> 
> >>> the
> >> AND, which looks all but 

Re: Using RUTA

[Peter Klügl]

Hi,


the repo:


  apache.snapshots
  Apache Snapshot Repository
  http://repository.apache.org/snapshots
  
false
  



the folder:

https://repository.apache.org/content/groups/snapshots/org/apache/uima/ruta-core/2.5.1-SNAPSHOT/


Best,

Peter



Am 23.02.2017 um 13:47 schrieb José Vicente Moyano Murillo:
> Hi,
>
> ruta-core.jar it's enough.
>
> It will be fantastic if i could access the snapshot repository.
>
> 2017-02-23 13:03 GMT+01:00 Peter Klügl :
>
>> Hi,
>>
>>
>> what do you need? Only ruta-core.jar or also the Eclipse plugins/update
>> site?
>>
>> I will prepare a new RC for the next release soon.
>>
>> There should be snapshot artifacts built by jenkins in the snapshot
>> repository. I am out-of-office today so do not have the link right now. (If
>> you want to build it yourself, the svn source repo can be accessed by
>> anyone)
>>
>>
>> Best,
>>
>>
>> Peter
>>
>>
>>
>>
>> Am 23.02.2017 um 08:06 schrieb José Vicente Moyano Murillo:
>>
>>> Hi Peter, good morning.
>>>
>>> Have we any opportunity to get a fixed version? I mean a snapshot or an
>>> access to the repo.
>>>
>>> Regards
>>>
>>> 2017-02-22 10:38 GMT+01:00 José Vicente Moyano Murillo :
>>>
>>> you're right
 % is performing some kind of "or".

 So we will wait for the new release.

 Many thanks

 2017-02-22 9:54 GMT+01:00 Peter Klügl :

 I actually wonder why your rules work. I am quite sure that they match
> too often, i. e. they match also if only one of the conjunct rule
> elements match.
>
> You can simply try that by using a wrong string in the check like "NG"
> instead of "Neil Gaiman"
>
> Anyways, the problem will be fixed in a few minutes and will be part of
> the next release.
>
>
> Best,
>
>
> Peter
>
>
> Am 22.02.2017 um 09:38 schrieb Peter Klügl:
>
>> Thanks. Maybe its just a bug in 2.5.0 I already fixed. I'll investigate
>>
> it.
>
>> Am 22.02.2017 um 09:24 schrieb José Vicente Moyano Murillo:
>>
>>> Thank you very much Peter. Your advice was amazing.
>>>
>>> We tried the first option using Conjunct rules and as you said it does
>>>
>> not
>> work with version 2.5.0. But we change a little your example and it
>> works
>> perfectly witn 2.4.0 and 2.5.0
>>> We use theses examples with success:
>>>
>>> DECLARE Annotation RuleDetection;
>>>   Book{ -> CREATE(NeilsBook) } <- {
>>>Attribute{Attribute.name=="title", Attribute.ct=="Norse
>>>
>> Mythology"}"
>>%
>>>Attribute{Attribute.name=="author",
>>> Attribute.ct=="Neil
>>> Gaiman"};"
>>>   };
>>>
>>>
>>> DECLARE Annotation RuleDetection;
>>>   Book{ -> CREATE(NeilsBook) } <- {
>>> Attribute{FEATURE("name","title"), FEATURE("ct", "Norse
>>>
>> Mythology")}"
>>%
>>> Attribute{FEATURE("name","author"), FEATURE("ct",
>>> "Neil
>>> Gaiman")};
>>>   };
>>>
>>> DECLARE Annotation RuleDetection;
>>>   Book{ -> CREATE(NeilsBook) } <- {
>>>Attribute{Attribute.name=="title", Attribute.ct=="Norse
>>>
>> Mythology"}"
>>%
>>> Attribute{FEATURE("name","author"), FEATURE("ct",
>>> "Neil
>>> Gaiman")};
>>>   };
>>>
>>>
>>> May be the problem is with when we use Identifiers:
>>> a1:Attribute and  a2:Attribute
>>>
>>> In any case thank you very much for your help.
>>>
>>>
>>> 2017-02-21 17:46 GMT+01:00 Peter Klügl :
>>>
>>> Hi,

 I'd normally say that you need the conjunt rules construct to specify

>>> an
>> AND between two rule element independent of the position:

 Book{-> NeilsBook}<-{
  a1:Attribute{a1.name=="title", a1.ct=="Norse Mythology"}
  % a2:Attribute{a2.name=="author", a2.ct=="Neil Gaiman"};
  };


 However, I just noted that there is a problem with conjunct rules. I
 haven't used it in a long time and the test coverage much lower than

>>> the
>> other constructs. I'll create a ticket for it and fix it.

 Without conjunct rules, you need some boolean variables for cheking

>>> the
>> AND, which looks all but declarative:

 BOOLEAN ft, fa;
 FOREACH(book) Book{}{
  book{-> ft = false, fa = false};
  book->{a1:Attribute{a1.name=="title", a1.ct=="Norse
 Mythology"->
 ft=true};};
  book->{a2:Attribute{a2.name=="author", a2.ct=="Neil Gaiman"->
 fa=true};};
  book{ft,fa -> NeilsBook};
 }


 ... or with a BLOCK...


 

Re: Using RUTA

[José Vicente Moyano Murillo]

Hi,

ruta-core.jar it's enough.

It will be fantastic if i could access the snapshot repository.

2017-02-23 13:03 GMT+01:00 Peter Klügl :

> Hi,
>
>
> what do you need? Only ruta-core.jar or also the Eclipse plugins/update
> site?
>
> I will prepare a new RC for the next release soon.
>
> There should be snapshot artifacts built by jenkins in the snapshot
> repository. I am out-of-office today so do not have the link right now. (If
> you want to build it yourself, the svn source repo can be accessed by
> anyone)
>
>
> Best,
>
>
> Peter
>
>
>
>
> Am 23.02.2017 um 08:06 schrieb José Vicente Moyano Murillo:
>
>> Hi Peter, good morning.
>>
>> Have we any opportunity to get a fixed version? I mean a snapshot or an
>> access to the repo.
>>
>> Regards
>>
>> 2017-02-22 10:38 GMT+01:00 José Vicente Moyano Murillo :
>>
>> you're right
>>>
>>> % is performing some kind of "or".
>>>
>>> So we will wait for the new release.
>>>
>>> Many thanks
>>>
>>> 2017-02-22 9:54 GMT+01:00 Peter Klügl :
>>>
>>> I actually wonder why your rules work. I am quite sure that they match
 too often, i. e. they match also if only one of the conjunct rule
 elements match.

 You can simply try that by using a wrong string in the check like "NG"
 instead of "Neil Gaiman"

 Anyways, the problem will be fixed in a few minutes and will be part of
 the next release.


 Best,


 Peter


 Am 22.02.2017 um 09:38 schrieb Peter Klügl:

> Thanks. Maybe its just a bug in 2.5.0 I already fixed. I'll investigate
>
 it.

>
> Am 22.02.2017 um 09:24 schrieb José Vicente Moyano Murillo:
>
>> Thank you very much Peter. Your advice was amazing.
>>
>> We tried the first option using Conjunct rules and as you said it does
>>
> not

> work with version 2.5.0. But we change a little your example and it
>>
> works

> perfectly witn 2.4.0 and 2.5.0
>>
>> We use theses examples with success:
>>
>> DECLARE Annotation RuleDetection;
>>   Book{ -> CREATE(NeilsBook) } <- {
>>Attribute{Attribute.name=="title", Attribute.ct=="Norse
>>
> Mythology"}"

>%
>>Attribute{Attribute.name=="author",
>> Attribute.ct=="Neil
>> Gaiman"};"
>>   };
>>
>>
>> DECLARE Annotation RuleDetection;
>>   Book{ -> CREATE(NeilsBook) } <- {
>> Attribute{FEATURE("name","title"), FEATURE("ct", "Norse
>>
> Mythology")}"

>%
>> Attribute{FEATURE("name","author"), FEATURE("ct",
>> "Neil
>> Gaiman")};
>>   };
>>
>> DECLARE Annotation RuleDetection;
>>   Book{ -> CREATE(NeilsBook) } <- {
>>Attribute{Attribute.name=="title", Attribute.ct=="Norse
>>
> Mythology"}"

>%
>> Attribute{FEATURE("name","author"), FEATURE("ct",
>> "Neil
>> Gaiman")};
>>   };
>>
>>
>> May be the problem is with when we use Identifiers:
>> a1:Attribute and  a2:Attribute
>>
>> In any case thank you very much for your help.
>>
>>
>> 2017-02-21 17:46 GMT+01:00 Peter Klügl :
>>
>> Hi,
>>>
>>>
>>> I'd normally say that you need the conjunt rules construct to specify
>>>
>> an

> AND between two rule element independent of the position:
>>>
>>>
>>> Book{-> NeilsBook}<-{
>>>  a1:Attribute{a1.name=="title", a1.ct=="Norse Mythology"}
>>>  % a2:Attribute{a2.name=="author", a2.ct=="Neil Gaiman"};
>>>  };
>>>
>>>
>>> However, I just noted that there is a problem with conjunct rules. I
>>> haven't used it in a long time and the test coverage much lower than
>>>
>> the

> other constructs. I'll create a ticket for it and fix it.
>>>
>>>
>>> Without conjunct rules, you need some boolean variables for cheking
>>>
>> the

> AND, which looks all but declarative:
>>>
>>>
>>> BOOLEAN ft, fa;
>>> FOREACH(book) Book{}{
>>>  book{-> ft = false, fa = false};
>>>  book->{a1:Attribute{a1.name=="title", a1.ct=="Norse
>>> Mythology"->
>>> ft=true};};
>>>  book->{a2:Attribute{a2.name=="author", a2.ct=="Neil Gaiman"->
>>> fa=true};};
>>>  book{ft,fa -> NeilsBook};
>>> }
>>>
>>>
>>> ... or with a BLOCK...
>>>
>>>
>>> BLOCK(book) Book{}{
>>>  Document{-> ft = false, fa = false};
>>>  a1:Attribute{a1.name=="title", a1.ct=="Norse Mythology"->
>>>
>> ft=true};

>  a2:Attribute{a2.name=="author", a2.ct=="Neil Gaiman"-> fa=true};
>>>  Document{ft,fa -> NeilsBook};
>>> }
>>>
>>>
>>> If the order of the attributes is known, you can avoid the AND check
>>>
>> and

Re: Using RUTA

[Peter Klügl]

Hi,


what do you need? Only ruta-core.jar or also the Eclipse plugins/update 
site?


I will prepare a new RC for the next release soon.

There should be snapshot artifacts built by jenkins in the snapshot 
repository. I am out-of-office today so do not have the link right now. 
(If you want to build it yourself, the svn source repo can be accessed 
by anyone)



Best,


Peter



Am 23.02.2017 um 08:06 schrieb José Vicente Moyano Murillo:

Hi Peter, good morning.

Have we any opportunity to get a fixed version? I mean a snapshot or an
access to the repo.

Regards

2017-02-22 10:38 GMT+01:00 José Vicente Moyano Murillo :


you're right

% is performing some kind of "or".

So we will wait for the new release.

Many thanks

2017-02-22 9:54 GMT+01:00 Peter Klügl :


I actually wonder why your rules work. I am quite sure that they match
too often, i. e. they match also if only one of the conjunct rule
elements match.

You can simply try that by using a wrong string in the check like "NG"
instead of "Neil Gaiman"

Anyways, the problem will be fixed in a few minutes and will be part of
the next release.


Best,


Peter


Am 22.02.2017 um 09:38 schrieb Peter Klügl:

Thanks. Maybe its just a bug in 2.5.0 I already fixed. I'll investigate

it.


Am 22.02.2017 um 09:24 schrieb José Vicente Moyano Murillo:

Thank you very much Peter. Your advice was amazing.

We tried the first option using Conjunct rules and as you said it does

not

work with version 2.5.0. But we change a little your example and it

works

perfectly witn 2.4.0 and 2.5.0

We use theses examples with success:

DECLARE Annotation RuleDetection;
  Book{ -> CREATE(NeilsBook) } <- {
   Attribute{Attribute.name=="title", Attribute.ct=="Norse

Mythology"}"

   %
   Attribute{Attribute.name=="author", Attribute.ct=="Neil
Gaiman"};"
  };


DECLARE Annotation RuleDetection;
  Book{ -> CREATE(NeilsBook) } <- {
Attribute{FEATURE("name","title"), FEATURE("ct", "Norse

Mythology")}"

   %
Attribute{FEATURE("name","author"), FEATURE("ct", "Neil
Gaiman")};
  };

DECLARE Annotation RuleDetection;
  Book{ -> CREATE(NeilsBook) } <- {
   Attribute{Attribute.name=="title", Attribute.ct=="Norse

Mythology"}"

   %
Attribute{FEATURE("name","author"), FEATURE("ct", "Neil
Gaiman")};
  };


May be the problem is with when we use Identifiers:
a1:Attribute and  a2:Attribute

In any case thank you very much for your help.


2017-02-21 17:46 GMT+01:00 Peter Klügl :


Hi,


I'd normally say that you need the conjunt rules construct to specify

an

AND between two rule element independent of the position:


Book{-> NeilsBook}<-{
 a1:Attribute{a1.name=="title", a1.ct=="Norse Mythology"}
 % a2:Attribute{a2.name=="author", a2.ct=="Neil Gaiman"};
 };


However, I just noted that there is a problem with conjunct rules. I
haven't used it in a long time and the test coverage much lower than

the

other constructs. I'll create a ticket for it and fix it.


Without conjunct rules, you need some boolean variables for cheking

the

AND, which looks all but declarative:


BOOLEAN ft, fa;
FOREACH(book) Book{}{
 book{-> ft = false, fa = false};
 book->{a1:Attribute{a1.name=="title", a1.ct=="Norse Mythology"->
ft=true};};
 book->{a2:Attribute{a2.name=="author", a2.ct=="Neil Gaiman"->
fa=true};};
 book{ft,fa -> NeilsBook};
}


... or with a BLOCK...


BLOCK(book) Book{}{
 Document{-> ft = false, fa = false};
 a1:Attribute{a1.name=="title", a1.ct=="Norse Mythology"->

ft=true};

 a2:Attribute{a2.name=="author", a2.ct=="Neil Gaiman"-> fa=true};
 Document{ft,fa -> NeilsBook};
}


If the order of the attributes is known, you can avoid the AND check

and

just specify a sequential constraint:


Book{-> NeilsBook}<-{
 a1:Attribute{a1.name=="title", a1.ct=="Norse Mythology"}
 # a2:Attribute{a2.name=="author", a2.ct=="Neil Gaiman"};
 };


If you need to check on the complete title with the URL, you can

replace

the coveredText comparison with a REGEXP condition.


(tested with UIMA Ruta 2.5.0)


Best,


Peter



Am 21.02.2017 um 13:58 schrieb José Vicente Moyano Murillo:

Hello everyone

I'm planning to use RUTA to create some annotations. But i'm not

able to

accomplish my objective.

This is my case right now:

I have a text annotated with some annotations "*Book*".

Under "*Book*" annotation i have a few annotations "*Attribute*" that
stores some information about the book. Each "*Attribute*" has a

feature

"

*name*" and a feature "*parent*" to its parent (one "*Book*"

annotation).

And example could be a text with 2 "*Book*" annotations:

"*Book*" annotation number 1 with 3 nested attributes
1.- *Attribute* with name feature equals "title" -> covered text:

"Norse

Mythology

Re: Using RUTA

[José Vicente Moyano Murillo]

Hi Peter, good morning.

Have we any opportunity to get a fixed version? I mean a snapshot or an
access to the repo.

Regards

2017-02-22 10:38 GMT+01:00 José Vicente Moyano Murillo :

> you're right
>
> % is performing some kind of "or".
>
> So we will wait for the new release.
>
> Many thanks
>
> 2017-02-22 9:54 GMT+01:00 Peter Klügl :
>
>> I actually wonder why your rules work. I am quite sure that they match
>> too often, i. e. they match also if only one of the conjunct rule
>> elements match.
>>
>> You can simply try that by using a wrong string in the check like "NG"
>> instead of "Neil Gaiman"
>>
>> Anyways, the problem will be fixed in a few minutes and will be part of
>> the next release.
>>
>>
>> Best,
>>
>>
>> Peter
>>
>>
>> Am 22.02.2017 um 09:38 schrieb Peter Klügl:
>> > Thanks. Maybe its just a bug in 2.5.0 I already fixed. I'll investigate
>> it.
>> >
>> >
>> > Am 22.02.2017 um 09:24 schrieb José Vicente Moyano Murillo:
>> >> Thank you very much Peter. Your advice was amazing.
>> >>
>> >> We tried the first option using Conjunct rules and as you said it does
>> not
>> >> work with version 2.5.0. But we change a little your example and it
>> works
>> >> perfectly witn 2.4.0 and 2.5.0
>> >>
>> >> We use theses examples with success:
>> >>
>> >> DECLARE Annotation RuleDetection;
>> >>  Book{ -> CREATE(NeilsBook) } <- {
>> >>   Attribute{Attribute.name=="title", Attribute.ct=="Norse
>> Mythology"}"
>> >>   %
>> >>   Attribute{Attribute.name=="author", Attribute.ct=="Neil
>> >> Gaiman"};"
>> >>  };
>> >>
>> >>
>> >> DECLARE Annotation RuleDetection;
>> >>  Book{ -> CREATE(NeilsBook) } <- {
>> >>Attribute{FEATURE("name","title"), FEATURE("ct", "Norse
>> Mythology")}"
>> >>   %
>> >>Attribute{FEATURE("name","author"), FEATURE("ct", "Neil
>> >> Gaiman")};
>> >>  };
>> >>
>> >> DECLARE Annotation RuleDetection;
>> >>  Book{ -> CREATE(NeilsBook) } <- {
>> >>   Attribute{Attribute.name=="title", Attribute.ct=="Norse
>> Mythology"}"
>> >>   %
>> >>Attribute{FEATURE("name","author"), FEATURE("ct", "Neil
>> >> Gaiman")};
>> >>  };
>> >>
>> >>
>> >> May be the problem is with when we use Identifiers:
>> >>a1:Attribute and  a2:Attribute
>> >>
>> >> In any case thank you very much for your help.
>> >>
>> >>
>> >> 2017-02-21 17:46 GMT+01:00 Peter Klügl :
>> >>
>> >>> Hi,
>> >>>
>> >>>
>> >>> I'd normally say that you need the conjunt rules construct to specify
>> an
>> >>> AND between two rule element independent of the position:
>> >>>
>> >>>
>> >>> Book{-> NeilsBook}<-{
>> >>> a1:Attribute{a1.name=="title", a1.ct=="Norse Mythology"}
>> >>> % a2:Attribute{a2.name=="author", a2.ct=="Neil Gaiman"};
>> >>> };
>> >>>
>> >>>
>> >>> However, I just noted that there is a problem with conjunct rules. I
>> >>> haven't used it in a long time and the test coverage much lower than
>> the
>> >>> other constructs. I'll create a ticket for it and fix it.
>> >>>
>> >>>
>> >>> Without conjunct rules, you need some boolean variables for cheking
>> the
>> >>> AND, which looks all but declarative:
>> >>>
>> >>>
>> >>> BOOLEAN ft, fa;
>> >>> FOREACH(book) Book{}{
>> >>> book{-> ft = false, fa = false};
>> >>> book->{a1:Attribute{a1.name=="title", a1.ct=="Norse Mythology"->
>> >>> ft=true};};
>> >>> book->{a2:Attribute{a2.name=="author", a2.ct=="Neil Gaiman"->
>> >>> fa=true};};
>> >>> book{ft,fa -> NeilsBook};
>> >>> }
>> >>>
>> >>>
>> >>> ... or with a BLOCK...
>> >>>
>> >>>
>> >>> BLOCK(book) Book{}{
>> >>> Document{-> ft = false, fa = false};
>> >>> a1:Attribute{a1.name=="title", a1.ct=="Norse Mythology"->
>> ft=true};
>> >>> a2:Attribute{a2.name=="author", a2.ct=="Neil Gaiman"-> fa=true};
>> >>> Document{ft,fa -> NeilsBook};
>> >>> }
>> >>>
>> >>>
>> >>> If the order of the attributes is known, you can avoid the AND check
>> and
>> >>> just specify a sequential constraint:
>> >>>
>> >>>
>> >>> Book{-> NeilsBook}<-{
>> >>> a1:Attribute{a1.name=="title", a1.ct=="Norse Mythology"}
>> >>> # a2:Attribute{a2.name=="author", a2.ct=="Neil Gaiman"};
>> >>> };
>> >>>
>> >>>
>> >>> If you need to check on the complete title with the URL, you can
>> replace
>> >>> the coveredText comparison with a REGEXP condition.
>> >>>
>> >>>
>> >>> (tested with UIMA Ruta 2.5.0)
>> >>>
>> >>>
>> >>> Best,
>> >>>
>> >>>
>> >>> Peter
>> >>>
>> >>>
>> >>>
>> >>> Am 21.02.2017 um 13:58 schrieb José Vicente Moyano Murillo:
>>  Hello everyone
>> 
>>  I'm planning to use RUTA to create some annotations. But i'm not
>> able to
>>  accomplish my objective.
>> 
>>  This is my case right now:
>> 
>>  I have a text annotated with some annotations "*Book*".
>> 
>>  Under "*Book*" annotation i have a few annotations "*Attribute*" that
>>  stores some information about the book. Each "*Attribute*" has a
>> feature
>> >>> "

Re: Using RUTA

[José Vicente Moyano Murillo]

you're right

% is performing some kind of "or".

So we will wait for the new release.

Many thanks

2017-02-22 9:54 GMT+01:00 Peter Klügl :

> I actually wonder why your rules work. I am quite sure that they match
> too often, i. e. they match also if only one of the conjunct rule
> elements match.
>
> You can simply try that by using a wrong string in the check like "NG"
> instead of "Neil Gaiman"
>
> Anyways, the problem will be fixed in a few minutes and will be part of
> the next release.
>
>
> Best,
>
>
> Peter
>
>
> Am 22.02.2017 um 09:38 schrieb Peter Klügl:
> > Thanks. Maybe its just a bug in 2.5.0 I already fixed. I'll investigate
> it.
> >
> >
> > Am 22.02.2017 um 09:24 schrieb José Vicente Moyano Murillo:
> >> Thank you very much Peter. Your advice was amazing.
> >>
> >> We tried the first option using Conjunct rules and as you said it does
> not
> >> work with version 2.5.0. But we change a little your example and it
> works
> >> perfectly witn 2.4.0 and 2.5.0
> >>
> >> We use theses examples with success:
> >>
> >> DECLARE Annotation RuleDetection;
> >>  Book{ -> CREATE(NeilsBook) } <- {
> >>   Attribute{Attribute.name=="title", Attribute.ct=="Norse
> Mythology"}"
> >>   %
> >>   Attribute{Attribute.name=="author", Attribute.ct=="Neil
> >> Gaiman"};"
> >>  };
> >>
> >>
> >> DECLARE Annotation RuleDetection;
> >>  Book{ -> CREATE(NeilsBook) } <- {
> >>Attribute{FEATURE("name","title"), FEATURE("ct", "Norse
> Mythology")}"
> >>   %
> >>Attribute{FEATURE("name","author"), FEATURE("ct", "Neil
> >> Gaiman")};
> >>  };
> >>
> >> DECLARE Annotation RuleDetection;
> >>  Book{ -> CREATE(NeilsBook) } <- {
> >>   Attribute{Attribute.name=="title", Attribute.ct=="Norse
> Mythology"}"
> >>   %
> >>Attribute{FEATURE("name","author"), FEATURE("ct", "Neil
> >> Gaiman")};
> >>  };
> >>
> >>
> >> May be the problem is with when we use Identifiers:
> >>a1:Attribute and  a2:Attribute
> >>
> >> In any case thank you very much for your help.
> >>
> >>
> >> 2017-02-21 17:46 GMT+01:00 Peter Klügl :
> >>
> >>> Hi,
> >>>
> >>>
> >>> I'd normally say that you need the conjunt rules construct to specify
> an
> >>> AND between two rule element independent of the position:
> >>>
> >>>
> >>> Book{-> NeilsBook}<-{
> >>> a1:Attribute{a1.name=="title", a1.ct=="Norse Mythology"}
> >>> % a2:Attribute{a2.name=="author", a2.ct=="Neil Gaiman"};
> >>> };
> >>>
> >>>
> >>> However, I just noted that there is a problem with conjunct rules. I
> >>> haven't used it in a long time and the test coverage much lower than
> the
> >>> other constructs. I'll create a ticket for it and fix it.
> >>>
> >>>
> >>> Without conjunct rules, you need some boolean variables for cheking the
> >>> AND, which looks all but declarative:
> >>>
> >>>
> >>> BOOLEAN ft, fa;
> >>> FOREACH(book) Book{}{
> >>> book{-> ft = false, fa = false};
> >>> book->{a1:Attribute{a1.name=="title", a1.ct=="Norse Mythology"->
> >>> ft=true};};
> >>> book->{a2:Attribute{a2.name=="author", a2.ct=="Neil Gaiman"->
> >>> fa=true};};
> >>> book{ft,fa -> NeilsBook};
> >>> }
> >>>
> >>>
> >>> ... or with a BLOCK...
> >>>
> >>>
> >>> BLOCK(book) Book{}{
> >>> Document{-> ft = false, fa = false};
> >>> a1:Attribute{a1.name=="title", a1.ct=="Norse Mythology"->
> ft=true};
> >>> a2:Attribute{a2.name=="author", a2.ct=="Neil Gaiman"-> fa=true};
> >>> Document{ft,fa -> NeilsBook};
> >>> }
> >>>
> >>>
> >>> If the order of the attributes is known, you can avoid the AND check
> and
> >>> just specify a sequential constraint:
> >>>
> >>>
> >>> Book{-> NeilsBook}<-{
> >>> a1:Attribute{a1.name=="title", a1.ct=="Norse Mythology"}
> >>> # a2:Attribute{a2.name=="author", a2.ct=="Neil Gaiman"};
> >>> };
> >>>
> >>>
> >>> If you need to check on the complete title with the URL, you can
> replace
> >>> the coveredText comparison with a REGEXP condition.
> >>>
> >>>
> >>> (tested with UIMA Ruta 2.5.0)
> >>>
> >>>
> >>> Best,
> >>>
> >>>
> >>> Peter
> >>>
> >>>
> >>>
> >>> Am 21.02.2017 um 13:58 schrieb José Vicente Moyano Murillo:
>  Hello everyone
> 
>  I'm planning to use RUTA to create some annotations. But i'm not able
> to
>  accomplish my objective.
> 
>  This is my case right now:
> 
>  I have a text annotated with some annotations "*Book*".
> 
>  Under "*Book*" annotation i have a few annotations "*Attribute*" that
>  stores some information about the book. Each "*Attribute*" has a
> feature
> >>> "
>  *name*" and a feature "*parent*" to its parent (one "*Book*"
> annotation).
> 
>  And example could be a text with 2 "*Book*" annotations:
> 
>  "*Book*" annotation number 1 with 3 nested attributes
>  1.- *Attribute* with name feature equals "title" -> covered text:
> "Norse
>  Mythology
>  

Re: Using RUTA

[Peter Klügl]

I actually wonder why your rules work. I am quite sure that they match
too often, i. e. they match also if only one of the conjunct rule
elements match.

You can simply try that by using a wrong string in the check like "NG"
instead of "Neil Gaiman"

Anyways, the problem will be fixed in a few minutes and will be part of
the next release.


Best,


Peter

 
Am 22.02.2017 um 09:38 schrieb Peter Klügl:
> Thanks. Maybe its just a bug in 2.5.0 I already fixed. I'll investigate it.
>
>
> Am 22.02.2017 um 09:24 schrieb José Vicente Moyano Murillo:
>> Thank you very much Peter. Your advice was amazing.
>>
>> We tried the first option using Conjunct rules and as you said it does not
>> work with version 2.5.0. But we change a little your example and it works
>> perfectly witn 2.4.0 and 2.5.0
>>
>> We use theses examples with success:
>>
>> DECLARE Annotation RuleDetection;
>>  Book{ -> CREATE(NeilsBook) } <- {
>>   Attribute{Attribute.name=="title", Attribute.ct=="Norse Mythology"}"
>>   %
>>   Attribute{Attribute.name=="author", Attribute.ct=="Neil
>> Gaiman"};"
>>  };
>>
>>
>> DECLARE Annotation RuleDetection;
>>  Book{ -> CREATE(NeilsBook) } <- {
>>Attribute{FEATURE("name","title"), FEATURE("ct", "Norse Mythology")}"
>>   %
>>Attribute{FEATURE("name","author"), FEATURE("ct", "Neil
>> Gaiman")};
>>  };
>>
>> DECLARE Annotation RuleDetection;
>>  Book{ -> CREATE(NeilsBook) } <- {
>>   Attribute{Attribute.name=="title", Attribute.ct=="Norse Mythology"}"
>>   %
>>Attribute{FEATURE("name","author"), FEATURE("ct", "Neil
>> Gaiman")};
>>  };
>>
>>
>> May be the problem is with when we use Identifiers:
>>a1:Attribute and  a2:Attribute
>>
>> In any case thank you very much for your help.
>>
>>
>> 2017-02-21 17:46 GMT+01:00 Peter Klügl :
>>
>>> Hi,
>>>
>>>
>>> I'd normally say that you need the conjunt rules construct to specify an
>>> AND between two rule element independent of the position:
>>>
>>>
>>> Book{-> NeilsBook}<-{
>>> a1:Attribute{a1.name=="title", a1.ct=="Norse Mythology"}
>>> % a2:Attribute{a2.name=="author", a2.ct=="Neil Gaiman"};
>>> };
>>>
>>>
>>> However, I just noted that there is a problem with conjunct rules. I
>>> haven't used it in a long time and the test coverage much lower than the
>>> other constructs. I'll create a ticket for it and fix it.
>>>
>>>
>>> Without conjunct rules, you need some boolean variables for cheking the
>>> AND, which looks all but declarative:
>>>
>>>
>>> BOOLEAN ft, fa;
>>> FOREACH(book) Book{}{
>>> book{-> ft = false, fa = false};
>>> book->{a1:Attribute{a1.name=="title", a1.ct=="Norse Mythology"->
>>> ft=true};};
>>> book->{a2:Attribute{a2.name=="author", a2.ct=="Neil Gaiman"->
>>> fa=true};};
>>> book{ft,fa -> NeilsBook};
>>> }
>>>
>>>
>>> ... or with a BLOCK...
>>>
>>>
>>> BLOCK(book) Book{}{
>>> Document{-> ft = false, fa = false};
>>> a1:Attribute{a1.name=="title", a1.ct=="Norse Mythology"-> ft=true};
>>> a2:Attribute{a2.name=="author", a2.ct=="Neil Gaiman"-> fa=true};
>>> Document{ft,fa -> NeilsBook};
>>> }
>>>
>>>
>>> If the order of the attributes is known, you can avoid the AND check and
>>> just specify a sequential constraint:
>>>
>>>
>>> Book{-> NeilsBook}<-{
>>> a1:Attribute{a1.name=="title", a1.ct=="Norse Mythology"}
>>> # a2:Attribute{a2.name=="author", a2.ct=="Neil Gaiman"};
>>> };
>>>
>>>
>>> If you need to check on the complete title with the URL, you can replace
>>> the coveredText comparison with a REGEXP condition.
>>>
>>>
>>> (tested with UIMA Ruta 2.5.0)
>>>
>>>
>>> Best,
>>>
>>>
>>> Peter
>>>
>>>
>>>
>>> Am 21.02.2017 um 13:58 schrieb José Vicente Moyano Murillo:
 Hello everyone

 I'm planning to use RUTA to create some annotations. But i'm not able to
 accomplish my objective.

 This is my case right now:

 I have a text annotated with some annotations "*Book*".

 Under "*Book*" annotation i have a few annotations "*Attribute*" that
 stores some information about the book. Each "*Attribute*" has a feature
>>> "
 *name*" and a feature "*parent*" to its parent (one "*Book*" annotation).

 And example could be a text with 2 "*Book*" annotations:

 "*Book*" annotation number 1 with 3 nested attributes
 1.- *Attribute* with name feature equals "title" -> covered text: "Norse
 Mythology
 >> gaiman/1124023596;jsessionid=FD1D8F9690602616CA59B38CFE9290
>>> 06.prodny_store02-atgap08?ean=9780393609097>
 "
 2.- *Attribute* with name feature equals "author" ->  covered text: "Neil
 Gaiman"
 3.- *Attribute* with name feature equals "language" - > covered text:
 "English"


 "*Book*" annotation number 2 with 3 nested attributes
 1.- *Attribute* with name feature equals "title" -> covered text: "Never
 Never
 

Re: Using RUTA

[Peter Klügl]

Thanks. Maybe its just a bug in 2.5.0 I already fixed. I'll investigate it.


Am 22.02.2017 um 09:24 schrieb José Vicente Moyano Murillo:
> Thank you very much Peter. Your advice was amazing.
>
> We tried the first option using Conjunct rules and as you said it does not
> work with version 2.5.0. But we change a little your example and it works
> perfectly witn 2.4.0 and 2.5.0
>
> We use theses examples with success:
>
> DECLARE Annotation RuleDetection;
>  Book{ -> CREATE(NeilsBook) } <- {
>   Attribute{Attribute.name=="title", Attribute.ct=="Norse Mythology"}"
>   %
>   Attribute{Attribute.name=="author", Attribute.ct=="Neil
> Gaiman"};"
>  };
>
>
> DECLARE Annotation RuleDetection;
>  Book{ -> CREATE(NeilsBook) } <- {
>Attribute{FEATURE("name","title"), FEATURE("ct", "Norse Mythology")}"
>   %
>Attribute{FEATURE("name","author"), FEATURE("ct", "Neil
> Gaiman")};
>  };
>
> DECLARE Annotation RuleDetection;
>  Book{ -> CREATE(NeilsBook) } <- {
>   Attribute{Attribute.name=="title", Attribute.ct=="Norse Mythology"}"
>   %
>Attribute{FEATURE("name","author"), FEATURE("ct", "Neil
> Gaiman")};
>  };
>
>
> May be the problem is with when we use Identifiers:
>a1:Attribute and  a2:Attribute
>
> In any case thank you very much for your help.
>
>
> 2017-02-21 17:46 GMT+01:00 Peter Klügl :
>
>> Hi,
>>
>>
>> I'd normally say that you need the conjunt rules construct to specify an
>> AND between two rule element independent of the position:
>>
>>
>> Book{-> NeilsBook}<-{
>> a1:Attribute{a1.name=="title", a1.ct=="Norse Mythology"}
>> % a2:Attribute{a2.name=="author", a2.ct=="Neil Gaiman"};
>> };
>>
>>
>> However, I just noted that there is a problem with conjunct rules. I
>> haven't used it in a long time and the test coverage much lower than the
>> other constructs. I'll create a ticket for it and fix it.
>>
>>
>> Without conjunct rules, you need some boolean variables for cheking the
>> AND, which looks all but declarative:
>>
>>
>> BOOLEAN ft, fa;
>> FOREACH(book) Book{}{
>> book{-> ft = false, fa = false};
>> book->{a1:Attribute{a1.name=="title", a1.ct=="Norse Mythology"->
>> ft=true};};
>> book->{a2:Attribute{a2.name=="author", a2.ct=="Neil Gaiman"->
>> fa=true};};
>> book{ft,fa -> NeilsBook};
>> }
>>
>>
>> ... or with a BLOCK...
>>
>>
>> BLOCK(book) Book{}{
>> Document{-> ft = false, fa = false};
>> a1:Attribute{a1.name=="title", a1.ct=="Norse Mythology"-> ft=true};
>> a2:Attribute{a2.name=="author", a2.ct=="Neil Gaiman"-> fa=true};
>> Document{ft,fa -> NeilsBook};
>> }
>>
>>
>> If the order of the attributes is known, you can avoid the AND check and
>> just specify a sequential constraint:
>>
>>
>> Book{-> NeilsBook}<-{
>> a1:Attribute{a1.name=="title", a1.ct=="Norse Mythology"}
>> # a2:Attribute{a2.name=="author", a2.ct=="Neil Gaiman"};
>> };
>>
>>
>> If you need to check on the complete title with the URL, you can replace
>> the coveredText comparison with a REGEXP condition.
>>
>>
>> (tested with UIMA Ruta 2.5.0)
>>
>>
>> Best,
>>
>>
>> Peter
>>
>>
>>
>> Am 21.02.2017 um 13:58 schrieb José Vicente Moyano Murillo:
>>> Hello everyone
>>>
>>> I'm planning to use RUTA to create some annotations. But i'm not able to
>>> accomplish my objective.
>>>
>>> This is my case right now:
>>>
>>> I have a text annotated with some annotations "*Book*".
>>>
>>> Under "*Book*" annotation i have a few annotations "*Attribute*" that
>>> stores some information about the book. Each "*Attribute*" has a feature
>> "
>>> *name*" and a feature "*parent*" to its parent (one "*Book*" annotation).
>>>
>>> And example could be a text with 2 "*Book*" annotations:
>>>
>>> "*Book*" annotation number 1 with 3 nested attributes
>>> 1.- *Attribute* with name feature equals "title" -> covered text: "Norse
>>> Mythology
>>> > gaiman/1124023596;jsessionid=FD1D8F9690602616CA59B38CFE9290
>> 06.prodny_store02-atgap08?ean=9780393609097>
>>> "
>>> 2.- *Attribute* with name feature equals "author" ->  covered text: "Neil
>>> Gaiman"
>>> 3.- *Attribute* with name feature equals "language" - > covered text:
>>> "English"
>>>
>>>
>>> "*Book*" annotation number 2 with 3 nested attributes
>>> 1.- *Attribute* with name feature equals "title" -> covered text: "Never
>>> Never
>>> > jsessionid=FD1D8F9690602616CA59B38CFE929006.prodny_store02-atgap08?ean=
>> 9780316433174>
>>> "
>>> 2.- *Attribute* with name feature equals "author" ->  covered text:
>> "James
>>> Patterson"
>>> 3.- *Attribute* with name feature equals "language" - > covered text:
>>> "English"
>>>
>>> I need to respect this schema but i have this question:
>>> It is possible to create and annotation over a book for a given author
>> name
>>> and a given title name?
>>>
>>> Thank's in advance
>>>
>>

Re: Using RUTA

[José Vicente Moyano Murillo]

Thank you very much Peter. Your advice was amazing.

We tried the first option using Conjunct rules and as you said it does not
work with version 2.5.0. But we change a little your example and it works
perfectly witn 2.4.0 and 2.5.0

We use theses examples with success:

DECLARE Annotation RuleDetection;
 Book{ -> CREATE(NeilsBook) } <- {
  Attribute{Attribute.name=="title", Attribute.ct=="Norse Mythology"}"
  %
  Attribute{Attribute.name=="author", Attribute.ct=="Neil
Gaiman"};"
 };


DECLARE Annotation RuleDetection;
 Book{ -> CREATE(NeilsBook) } <- {
   Attribute{FEATURE("name","title"), FEATURE("ct", "Norse Mythology")}"
  %
   Attribute{FEATURE("name","author"), FEATURE("ct", "Neil
Gaiman")};
 };

DECLARE Annotation RuleDetection;
 Book{ -> CREATE(NeilsBook) } <- {
  Attribute{Attribute.name=="title", Attribute.ct=="Norse Mythology"}"
  %
   Attribute{FEATURE("name","author"), FEATURE("ct", "Neil
Gaiman")};
 };


May be the problem is with when we use Identifiers:
   a1:Attribute and  a2:Attribute

In any case thank you very much for your help.


2017-02-21 17:46 GMT+01:00 Peter Klügl :

> Hi,
>
>
> I'd normally say that you need the conjunt rules construct to specify an
> AND between two rule element independent of the position:
>
>
> Book{-> NeilsBook}<-{
> a1:Attribute{a1.name=="title", a1.ct=="Norse Mythology"}
> % a2:Attribute{a2.name=="author", a2.ct=="Neil Gaiman"};
> };
>
>
> However, I just noted that there is a problem with conjunct rules. I
> haven't used it in a long time and the test coverage much lower than the
> other constructs. I'll create a ticket for it and fix it.
>
>
> Without conjunct rules, you need some boolean variables for cheking the
> AND, which looks all but declarative:
>
>
> BOOLEAN ft, fa;
> FOREACH(book) Book{}{
> book{-> ft = false, fa = false};
> book->{a1:Attribute{a1.name=="title", a1.ct=="Norse Mythology"->
> ft=true};};
> book->{a2:Attribute{a2.name=="author", a2.ct=="Neil Gaiman"->
> fa=true};};
> book{ft,fa -> NeilsBook};
> }
>
>
> ... or with a BLOCK...
>
>
> BLOCK(book) Book{}{
> Document{-> ft = false, fa = false};
> a1:Attribute{a1.name=="title", a1.ct=="Norse Mythology"-> ft=true};
> a2:Attribute{a2.name=="author", a2.ct=="Neil Gaiman"-> fa=true};
> Document{ft,fa -> NeilsBook};
> }
>
>
> If the order of the attributes is known, you can avoid the AND check and
> just specify a sequential constraint:
>
>
> Book{-> NeilsBook}<-{
> a1:Attribute{a1.name=="title", a1.ct=="Norse Mythology"}
> # a2:Attribute{a2.name=="author", a2.ct=="Neil Gaiman"};
> };
>
>
> If you need to check on the complete title with the URL, you can replace
> the coveredText comparison with a REGEXP condition.
>
>
> (tested with UIMA Ruta 2.5.0)
>
>
> Best,
>
>
> Peter
>
>
>
> Am 21.02.2017 um 13:58 schrieb José Vicente Moyano Murillo:
> > Hello everyone
> >
> > I'm planning to use RUTA to create some annotations. But i'm not able to
> > accomplish my objective.
> >
> > This is my case right now:
> >
> > I have a text annotated with some annotations "*Book*".
> >
> > Under "*Book*" annotation i have a few annotations "*Attribute*" that
> > stores some information about the book. Each "*Attribute*" has a feature
> "
> > *name*" and a feature "*parent*" to its parent (one "*Book*" annotation).
> >
> > And example could be a text with 2 "*Book*" annotations:
> >
> > "*Book*" annotation number 1 with 3 nested attributes
> > 1.- *Attribute* with name feature equals "title" -> covered text: "Norse
> > Mythology
> >  gaiman/1124023596;jsessionid=FD1D8F9690602616CA59B38CFE9290
> 06.prodny_store02-atgap08?ean=9780393609097>
> > "
> > 2.- *Attribute* with name feature equals "author" ->  covered text: "Neil
> > Gaiman"
> > 3.- *Attribute* with name feature equals "language" - > covered text:
> > "English"
> >
> >
> > "*Book*" annotation number 2 with 3 nested attributes
> > 1.- *Attribute* with name feature equals "title" -> covered text: "Never
> > Never
> >  jsessionid=FD1D8F9690602616CA59B38CFE929006.prodny_store02-atgap08?ean=
> 9780316433174>
> > "
> > 2.- *Attribute* with name feature equals "author" ->  covered text:
> "James
> > Patterson"
> > 3.- *Attribute* with name feature equals "language" - > covered text:
> > "English"
> >
> > I need to respect this schema but i have this question:
> > It is possible to create and annotation over a book for a given author
> name
> > and a given title name?
> >
> > Thank's in advance
> >
>
>

Re: Using RUTA

[Peter Klügl]

Hi,


I'd normally say that you need the conjunt rules construct to specify an
AND between two rule element independent of the position:


Book{-> NeilsBook}<-{
a1:Attribute{a1.name=="title", a1.ct=="Norse Mythology"}
% a2:Attribute{a2.name=="author", a2.ct=="Neil Gaiman"};
};


However, I just noted that there is a problem with conjunct rules. I
haven't used it in a long time and the test coverage much lower than the
other constructs. I'll create a ticket for it and fix it.


Without conjunct rules, you need some boolean variables for cheking the
AND, which looks all but declarative:


BOOLEAN ft, fa;
FOREACH(book) Book{}{
book{-> ft = false, fa = false};
book->{a1:Attribute{a1.name=="title", a1.ct=="Norse Mythology"->
ft=true};};
book->{a2:Attribute{a2.name=="author", a2.ct=="Neil Gaiman"->
fa=true};};
book{ft,fa -> NeilsBook};
}


... or with a BLOCK...


BLOCK(book) Book{}{
Document{-> ft = false, fa = false};
a1:Attribute{a1.name=="title", a1.ct=="Norse Mythology"-> ft=true};
a2:Attribute{a2.name=="author", a2.ct=="Neil Gaiman"-> fa=true};
Document{ft,fa -> NeilsBook};
}


If the order of the attributes is known, you can avoid the AND check and
just specify a sequential constraint:


Book{-> NeilsBook}<-{
a1:Attribute{a1.name=="title", a1.ct=="Norse Mythology"}
# a2:Attribute{a2.name=="author", a2.ct=="Neil Gaiman"};
};


If you need to check on the complete title with the URL, you can replace
the coveredText comparison with a REGEXP condition.


(tested with UIMA Ruta 2.5.0)


Best,


Peter



Am 21.02.2017 um 13:58 schrieb José Vicente Moyano Murillo:
> Hello everyone
>
> I'm planning to use RUTA to create some annotations. But i'm not able to
> accomplish my objective.
>
> This is my case right now:
>
> I have a text annotated with some annotations "*Book*".
>
> Under "*Book*" annotation i have a few annotations "*Attribute*" that
> stores some information about the book. Each "*Attribute*" has a feature "
> *name*" and a feature "*parent*" to its parent (one "*Book*" annotation).
>
> And example could be a text with 2 "*Book*" annotations:
>
> "*Book*" annotation number 1 with 3 nested attributes
> 1.- *Attribute* with name feature equals "title" -> covered text: "Norse
> Mythology
> 
> "
> 2.- *Attribute* with name feature equals "author" ->  covered text: "Neil
> Gaiman"
> 3.- *Attribute* with name feature equals "language" - > covered text:
> "English"
>
>
> "*Book*" annotation number 2 with 3 nested attributes
> 1.- *Attribute* with name feature equals "title" -> covered text: "Never
> Never
> 
> "
> 2.- *Attribute* with name feature equals "author" ->  covered text: "James
> Patterson"
> 3.- *Attribute* with name feature equals "language" - > covered text:
> "English"
>
> I need to respect this schema but i have this question:
> It is possible to create and annotation over a book for a given author name
> and a given title name?
>
> Thank's in advance
>

Using RUTA

[José Vicente Moyano Murillo]

Hello everyone

I'm planning to use RUTA to create some annotations. But i'm not able to
accomplish my objective.

This is my case right now:

I have a text annotated with some annotations "*Book*".

Under "*Book*" annotation i have a few annotations "*Attribute*" that
stores some information about the book. Each "*Attribute*" has a feature "
*name*" and a feature "*parent*" to its parent (one "*Book*" annotation).

And example could be a text with 2 "*Book*" annotations:

"*Book*" annotation number 1 with 3 nested attributes
1.- *Attribute* with name feature equals "title" -> covered text: "Norse
Mythology

"
2.- *Attribute* with name feature equals "author" ->  covered text: "Neil
Gaiman"
3.- *Attribute* with name feature equals "language" - > covered text:
"English"


"*Book*" annotation number 2 with 3 nested attributes
1.- *Attribute* with name feature equals "title" -> covered text: "Never
Never

"
2.- *Attribute* with name feature equals "author" ->  covered text: "James
Patterson"
3.- *Attribute* with name feature equals "language" - > covered text:
"English"

I need to respect this schema but i have this question:
It is possible to create and annotation over a book for a given author name
and a given title name?

Thank's in advance

Re: Problem matching adjacent annotations using Ruta

[Mario Juric]

Hi Peter,

Seems we uncovered the problem. It is not directly related to Ruta. We 
construct our view by mapping content from another view and for the affected 
documents we insert some text in the same process. We messed up in the mapping 
process and accidentally mapped some ruta basic annotations created in the 
previous view to the new view. This caused the Ruta problems when we applied 
another set of Ruta rules to the new view.

Thanks for the support but we should be all good now.

Regarding the visibility I also think it might be a good idea to address this 
sometimes in future but it was not related to this problem. All our fault :)

Cheers
Mario







> On 14 Mar 2016, at 15:17 , Peter Klügl  wrote:
> 
> hmm, sounds like a bug. Can you add SPACE to the retained types:
> 
> RETAINTYPE(WS, SPACE, BREAK);
> This should not change anything, but...
> 
> Why did A PERIOD SPACE not match?
> 
> Do have a have a reproducible example?
> 
> I promise that I will do something about the visiblity in the next releses.
> 
> Best,
> 
> Peter
> 
> Am 14.03.2016 um 14:33 schrieb Mario Juric:
>> Hi,
>> 
>> We try to do a simple match on two adjacent annotations but for some reason 
>> it dosen’t always work. The rule looks like this:
>> 
>> A B { -> CREATE(C, 2, "prop"="val")};
>> 
>> This work for many documents but not for all. Looking at a failed example 
>> document we can see that B starts exactly where A stops i.e. a.end == 
>> b.begin. Yet, the rule is never fired. Its a view with text content, A and B 
>> are our own custom annotation types, there are no invisible characters or 
>> markup in these particular cases and we set RETAINTYPE(WS, BREAK).
>> 
>> B annotates a period followed by a singe space in these cases whereas A 
>> covers the preceding sentence up to where B begins so I also tried to match 
>> on periods and spaces like this:
>> 
>> A PERIOD SPACE { -> CREATE(C, 2, 3, "prop"="val")};
>> 
>> This didn’t change the outcome.
>> 
>> I appreciate any suggestions to help me find the cause.
>> 
>> 
>> Cheers,
>> Mario
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
> 

Re: Problem matching adjacent annotations using Ruta

[Peter Klügl]

hmm, sounds like a bug. Can you add SPACE to the retained types:

RETAINTYPE(WS, SPACE, BREAK);
This should not change anything, but...

Why did A PERIOD SPACE not match?

Do have a have a reproducible example?

I promise that I will do something about the visiblity in the next releses.

Best,

Peter

Am 14.03.2016 um 14:33 schrieb Mario Juric:
> Hi,
>
> We try to do a simple match on two adjacent annotations but for some reason 
> it dosen’t always work. The rule looks like this:
>
> A B { -> CREATE(C, 2, "prop"="val")};
>
> This work for many documents but not for all. Looking at a failed example 
> document we can see that B starts exactly where A stops i.e. a.end == 
> b.begin. Yet, the rule is never fired. Its a view with text content, A and B 
> are our own custom annotation types, there are no invisible characters or 
> markup in these particular cases and we set RETAINTYPE(WS, BREAK).
>
> B annotates a period followed by a singe space in these cases whereas A 
> covers the preceding sentence up to where B begins so I also tried to match 
> on periods and spaces like this:
>
> A PERIOD SPACE { -> CREATE(C, 2, 3, "prop"="val")};
>
> This didn’t change the outcome.
>
> I appreciate any suggestions to help me find the cause.
>
>
> Cheers,
> Mario
>
>
>
>
>
>
>
>

Problem matching adjacent annotations using Ruta

[Mario Juric]

Hi,

We try to do a simple match on two adjacent annotations but for some reason it 
dosen’t always work. The rule looks like this:

A B { -> CREATE(C, 2, "prop"="val")};

This work for many documents but not for all. Looking at a failed example 
document we can see that B starts exactly where A stops i.e. a.end == b.begin. 
Yet, the rule is never fired. Its a view with text content, A and B are our own 
custom annotation types, there are no invisible characters or markup in these 
particular cases and we set RETAINTYPE(WS, BREAK).

B annotates a period followed by a singe space in these cases whereas A covers 
the preceding sentence up to where B begins so I also tried to match on periods 
and spaces like this:

A PERIOD SPACE { -> CREATE(C, 2, 3, "prop"="val")};

This didn’t change the outcome.

I appreciate any suggestions to help me find the cause.


Cheers,
Mario

Re: Error using RUTA from Java

[Peter Klügl]

Hi,

I must admit that I do not know the source of the problem yet.

Either RutaParser.file_input() (or RutaEngine.loadScript/IS()) returns
null, but this should cause some other exceptions. Or the linking of
mentioned/imported script names in the ruta file does not match the
names in the configuration parameters.

Some questions to narrow down the problem:
- Is the analysis engine configured correctly? Do the values of
additionalScripts match the scripts imported in the main ruta file?
- Are there any spaces in paths, or any period in file names?
- Do you use the UIMA Ruta Workbench? If yes, are there any problems
reported?
- Are you able to load/process the analysis engine of the imported
script for their own? Just to exclude some hidden parser error there.
- Can you check if there are any typos in the file names?
- Can you switch to absolute paths (scriptPaths, descriptorPaths,... )
to rule out problems with the classloader approach?
- Can you post the complete configuration of the analysis engine?

If all fails, we need to debug... my first guess would be to investigate
why there is a null value in RutaModule.setScriptDependencies() or why a
module is not assigned in that map.
If it is an option concerning non-disclosure, you can send me the files
(or a small project where the problem can be reproduced) and I will
debug it. (You can of course send it to me directly off-list).

Best,

Peter

Am 21.05.2015 um 01:26 schrieb William Colen:
 Thank you, Peter.

 I was using 2.2.1 and upgraded to 2.3.0 RC2 as you advised, but the error
 persists. Now I will post the complete stacktrace:

 Mai 20, 2015 6:56:23 PM
 org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl
 callAnalysisComponentProcess(417)
 GRAVE: Exception occurred
 org.apache.uima.analysis_engine.AnalysisEngineProcessException: Annotator
 processing failed.
 at
 org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.callAnalysisComponentProcess(PrimitiveAnalysisEngine_impl.java:401)
 at
 org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.processAndOutputNewCASes(PrimitiveAnalysisEngine_impl.java:308)
 at
 org.apache.uima.analysis_engine.impl.AnalysisEngineImplBase.process(AnalysisEngineImplBase.java:269)
 at org.cogroo.tools.checker.checkers.UIMAChecker.check(UIMAChecker.java:73)
 at org.cogroo.tools.checker.checkers.UIMAChecker.check(UIMAChecker.java:1)
 at
 org.cogroo.tools.checker.TypedCheckerComposite.check(TypedCheckerComposite.java:49)
 at org.cogroo.checker.GrammarChecker.analyze(GrammarChecker.java:252)
 at org.cogroo.checker.GrammarChecker.analyze(GrammarChecker.java:271)
 at org.cogroo.tools.checker.checkers.UIMAChecker.main(UIMAChecker.java:130)
 Caused by: java.lang.NullPointerException
 at
 org.apache.uima.ruta.engine.RutaEngine.resetEnvironment(RutaEngine.java:580)
 at
 org.apache.uima.ruta.engine.RutaEngine.resetEnvironments(RutaEngine.java:575)
 at org.apache.uima.ruta.engine.RutaEngine.process(RutaEngine.java:530)
 at
 org.apache.uima.analysis_component.JCasAnnotator_ImplBase.process(JCasAnnotator_ImplBase.java:48)
 at
 org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.callAnalysisComponentProcess(PrimitiveAnalysisEngine_impl.java:385)
 ... 8 more

 org.apache.uima.analysis_engine.AnalysisEngineProcessException: Annotator
 processing failed.
 at
 org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.callAnalysisComponentProcess(PrimitiveAnalysisEngine_impl.java:401)
 at
 org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.processAndOutputNewCASes(PrimitiveAnalysisEngine_impl.java:308)
 at
 org.apache.uima.analysis_engine.impl.AnalysisEngineImplBase.process(AnalysisEngineImplBase.java:269)
 at org.cogroo.tools.checker.checkers.UIMAChecker.check(UIMAChecker.java:73)
 at org.cogroo.tools.checker.checkers.UIMAChecker.check(UIMAChecker.java:1)
 at
 org.cogroo.tools.checker.TypedCheckerComposite.check(TypedCheckerComposite.java:49)
 at org.cogroo.checker.GrammarChecker.analyze(GrammarChecker.java:252)
 at org.cogroo.checker.GrammarChecker.analyze(GrammarChecker.java:271)
 at org.cogroo.tools.checker.checkers.UIMAChecker.main(UIMAChecker.java:130)
 Caused by: java.lang.NullPointerException
 at
 org.apache.uima.ruta.engine.RutaEngine.resetEnvironment(RutaEngine.java:580)
 at
 org.apache.uima.ruta.engine.RutaEngine.resetEnvironments(RutaEngine.java:575)
 at org.apache.uima.ruta.engine.RutaEngine.process(RutaEngine.java:530)
 at
 org.apache.uima.analysis_component.JCasAnnotator_ImplBase.process(JCasAnnotator_ImplBase.java:48)
 at
 org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.callAnalysisComponentProcess(PrimitiveAnalysisEngine_impl.java:385)
 ... 8 more
 Mai 20, 2015 6:56:23 PM
 org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl
 callAnalysisComponentProcess(417)
 GRAVE: Exception occurred
 org.apache.uima.analysis_engine.AnalysisEngineProcessException: Annotator
 processing failed.
 at
 

Re: Error using RUTA from Java

[William Colen]

Thank you, Peter.

Maybe that is the case. I am not setting any parameter, as follows:

TypeSystemDescription tsd =
 TypeSystemDescriptionFactory.createTypeSystemDescription(MainTypeSystem);
 URL url = Resources.getResource(Main.ruta);
 String scriptText = Resources.toString(url, Charsets.UTF_8);
 AnalysisEngineDescription aeDes =
 Ruta.createAnalysisEngineDescription(scriptText, tsd);
 AnalysisEngine ae = UIMAFramework.produceAnalysisEngine(aeDes);


Are there any tutorial explaining how to do that from command line? We can
execute everything correctly from Ruta tools for Eclipse.

The source code is open:

This is from where we call RUTA:
https://github.com/Fichberg/cogroo4/blob/labXP215_Will/cogroo-gc/src/main/java/org/cogroo/tools/checker/checkers/UIMAChecker.java

The scripts and the type system:

https://github.com/Fichberg/cogroo4/tree/labXP215_Will/cogroo-ruta


Thank you for your help!
William

2015-05-21 4:55 GMT-03:00 Peter Klügl peter.klu...@averbis.com:

 Hi,

 I must admit that I do not know the source of the problem yet.

 Either RutaParser.file_input() (or RutaEngine.loadScript/IS()) returns
 null, but this should cause some other exceptions. Or the linking of
 mentioned/imported script names in the ruta file does not match the
 names in the configuration parameters.

 Some questions to narrow down the problem:
 - Is the analysis engine configured correctly? Do the values of
 additionalScripts match the scripts imported in the main ruta file?
 - Are there any spaces in paths, or any period in file names?
 - Do you use the UIMA Ruta Workbench? If yes, are there any problems
 reported?
 - Are you able to load/process the analysis engine of the imported
 script for their own? Just to exclude some hidden parser error there.
 - Can you check if there are any typos in the file names?
 - Can you switch to absolute paths (scriptPaths, descriptorPaths,... )
 to rule out problems with the classloader approach?
 - Can you post the complete configuration of the analysis engine?

 If all fails, we need to debug... my first guess would be to investigate
 why there is a null value in RutaModule.setScriptDependencies() or why a
 module is not assigned in that map.
 If it is an option concerning non-disclosure, you can send me the files
 (or a small project where the problem can be reproduced) and I will
 debug it. (You can of course send it to me directly off-list).

 Best,

 Peter

 Am 21.05.2015 um 01:26 schrieb William Colen:
  Thank you, Peter.
 
  I was using 2.2.1 and upgraded to 2.3.0 RC2 as you advised, but the error
  persists. Now I will post the complete stacktrace:
 
  Mai 20, 2015 6:56:23 PM
  org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl
  callAnalysisComponentProcess(417)
  GRAVE: Exception occurred
  org.apache.uima.analysis_engine.AnalysisEngineProcessException: Annotator
  processing failed.
  at
 
 org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.callAnalysisComponentProcess(PrimitiveAnalysisEngine_impl.java:401)
  at
 
 org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.processAndOutputNewCASes(PrimitiveAnalysisEngine_impl.java:308)
  at
 
 org.apache.uima.analysis_engine.impl.AnalysisEngineImplBase.process(AnalysisEngineImplBase.java:269)
  at
 org.cogroo.tools.checker.checkers.UIMAChecker.check(UIMAChecker.java:73)
  at
 org.cogroo.tools.checker.checkers.UIMAChecker.check(UIMAChecker.java:1)
  at
 
 org.cogroo.tools.checker.TypedCheckerComposite.check(TypedCheckerComposite.java:49)
  at org.cogroo.checker.GrammarChecker.analyze(GrammarChecker.java:252)
  at org.cogroo.checker.GrammarChecker.analyze(GrammarChecker.java:271)
  at
 org.cogroo.tools.checker.checkers.UIMAChecker.main(UIMAChecker.java:130)
  Caused by: java.lang.NullPointerException
  at
 
 org.apache.uima.ruta.engine.RutaEngine.resetEnvironment(RutaEngine.java:580)
  at
 
 org.apache.uima.ruta.engine.RutaEngine.resetEnvironments(RutaEngine.java:575)
  at org.apache.uima.ruta.engine.RutaEngine.process(RutaEngine.java:530)
  at
 
 org.apache.uima.analysis_component.JCasAnnotator_ImplBase.process(JCasAnnotator_ImplBase.java:48)
  at
 
 org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.callAnalysisComponentProcess(PrimitiveAnalysisEngine_impl.java:385)
  ... 8 more
 
  org.apache.uima.analysis_engine.AnalysisEngineProcessException: Annotator
  processing failed.
  at
 
 org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.callAnalysisComponentProcess(PrimitiveAnalysisEngine_impl.java:401)
  at
 
 org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.processAndOutputNewCASes(PrimitiveAnalysisEngine_impl.java:308)
  at
 
 org.apache.uima.analysis_engine.impl.AnalysisEngineImplBase.process(AnalysisEngineImplBase.java:269)
  at
 org.cogroo.tools.checker.checkers.UIMAChecker.check(UIMAChecker.java:73)
  at
 org.cogroo.tools.checker.checkers.UIMAChecker.check(UIMAChecker.java:1)
  at
 
 

Re: Error using RUTA from Java

[Peter Klügl]

Hi,

unfortunately, Ruta.createAnalysisEngineDescription() does not provide
the functionality to create a valid descriptor for a multi-script
analysis engine. That should be changed and/or the documentation should
be extended/updated.

Here are some option right now (not tested yet, but I will test it when
I find the time):
1. use the descriptors built by the UIMA Ruta Workbench
2. set the configuration parameters manually
3. use a different method of creating the descriptor

1. There are absolute paths, but if the files are not found there, then
the classpath is used as fallback.

2. Something like:
...
AnalysisEngine ae = UIMAFramework.produceAnalysisEngine(aeDes);
ae.setConfigParameterValue(RutaEngine.PARAM_ADDITIONAL_SCRIPTS, new
String[] {Base, Crase});
ae.reconfigure();


3. In UIMA Ruta 2.3.0 there is/will be a lot of new functionality,
especially a maven plugin for building analysis engine and type system
descriptors from script files. The important code is in
RutaDescriptorFactory. There is a unit test that gives some hint how to
use the factory:
GenerateDescriptorTest.testCreateAnalysisEngineDescription()
There is also an exemplary maven project:
example-projects/ruta-maven-example

You could do something like the following:
...
RutaDescriptorFactory rdf = new RutaDescriptorFactory();
RutaDescriptorInformation descriptorInformation =
rdf.parseDescriptorInformation(scriptText);
RutaBuildOptions options = new RutaBuildOptions();
ClassLoader classLoader = UIMAChecker.class.getClassLoader();
AnalysisEngineDescription aed = rdf.createAnalysisEngineDescription(null,
descriptorInformation, options, null, null, null, classLoader);
AnalysisEngineMetaData metaData = aed.getAnalysisEngineMetaData();
metaData.setTypeSystem(tsd);
AnalysisEngine ae = UIMAFramework.produceAnalysisEngine(aeDes);

.. using createDescriptions() instead of
createAnalysisEngineDescription() is necessary if you define new types
in your scripts.

Best,

Peter





Am 21.05.2015 um 14:04 schrieb William Colen:
 Thank you, Peter.

 Maybe that is the case. I am not setting any parameter, as follows:

 TypeSystemDescription tsd =
 TypeSystemDescriptionFactory.createTypeSystemDescription(MainTypeSystem);
 URL url = Resources.getResource(Main.ruta);
 String scriptText = Resources.toString(url, Charsets.UTF_8);
 AnalysisEngineDescription aeDes =
 Ruta.createAnalysisEngineDescription(scriptText, tsd);
 AnalysisEngine ae = UIMAFramework.produceAnalysisEngine(aeDes);

 Are there any tutorial explaining how to do that from command line? We can
 execute everything correctly from Ruta tools for Eclipse.

 The source code is open:

 This is from where we call RUTA:
 https://github.com/Fichberg/cogroo4/blob/labXP215_Will/cogroo-gc/src/main/java/org/cogroo/tools/checker/checkers/UIMAChecker.java

 The scripts and the type system:

 https://github.com/Fichberg/cogroo4/tree/labXP215_Will/cogroo-ruta


 Thank you for your help!
 William

 2015-05-21 4:55 GMT-03:00 Peter Klügl peter.klu...@averbis.com:

 Hi,

 I must admit that I do not know the source of the problem yet.

 Either RutaParser.file_input() (or RutaEngine.loadScript/IS()) returns
 null, but this should cause some other exceptions. Or the linking of
 mentioned/imported script names in the ruta file does not match the
 names in the configuration parameters.

 Some questions to narrow down the problem:
 - Is the analysis engine configured correctly? Do the values of
 additionalScripts match the scripts imported in the main ruta file?
 - Are there any spaces in paths, or any period in file names?
 - Do you use the UIMA Ruta Workbench? If yes, are there any problems
 reported?
 - Are you able to load/process the analysis engine of the imported
 script for their own? Just to exclude some hidden parser error there.
 - Can you check if there are any typos in the file names?
 - Can you switch to absolute paths (scriptPaths, descriptorPaths,... )
 to rule out problems with the classloader approach?
 - Can you post the complete configuration of the analysis engine?

 If all fails, we need to debug... my first guess would be to investigate
 why there is a null value in RutaModule.setScriptDependencies() or why a
 module is not assigned in that map.
 If it is an option concerning non-disclosure, you can send me the files
 (or a small project where the problem can be reproduced) and I will
 debug it. (You can of course send it to me directly off-list).

 Best,

 Peter

 Am 21.05.2015 um 01:26 schrieb William Colen:
 Thank you, Peter.

 I was using 2.2.1 and upgraded to 2.3.0 RC2 as you advised, but the error
 persists. Now I will post the complete stacktrace:

 Mai 20, 2015 6:56:23 PM
 org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl
 callAnalysisComponentProcess(417)
 GRAVE: Exception occurred
 org.apache.uima.analysis_engine.AnalysisEngineProcessException: Annotator
 processing failed.
 at

 

Re: Error using RUTA from Java

[Peter Klügl]

Hi,

I assume that you use UIMA Ruta 2.2.1?

Are there any prior exception?

I had a similar problem, which should be fixed now. Could be related to 
the bugs reported in UIMA-4045 or UIMA-4046.
Normally, I would assume that there is a syntax error in the additional 
script causing the module to be null. If the script file is not found, 
then there should be a clear error message.


Could you try the UIMA Ruta 2.3.0 RC2, but upgrading the dependency 
version of uima-core to 2.3.0 and using the staging repository?


repositories
repository
  idstaged-release/id
urlhttps://repository.apache.org/content/repositories/orgapacheuima-1053//url
/repository
  /repositories

Best,

Peter

Am 20.05.2015 um 21:45 schrieb William Colen:

Hello,

We have a Main RUTA script that imports a few children scripts, as follows:

PACKAGE cogroo.ruta;

TYPESYSTEM BaseTypeSystem;
IMPORT opennlp.uima.Token FROM TypeSystem AS cgToken;
IMPORT opennlp.uima.Sentence FROM TypeSystem AS cgSentence;
SCRIPT Crase;
SCRIPT Base;
Document{- CALL(Base)};
Document{- CALL(Crase)};


All the scripts are in the root of the classpath.

We are trying to call it from Java, using the following code:

TypeSystemDescription tsd =

TypeSystemDescriptionFactory.createTypeSystemDescription(MainTypeSystem
);
URL url = Resources.getResource(Main.ruta);
String scriptText = Resources.toString(url, Charsets.UTF_8);
AnalysisEngineDescription aeDes =
Ruta.createAnalysisEngineDescription(scriptText, tsd);
AnalysisEngine ae = UIMAFramework.produceAnalysisEngine(aeDes);


  The error we are getting:

org.apache.uima.analysis_engine.AnalysisEngineProcessException: Annotator

processing failed.
at
org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.callAnalysisComponentProcess(PrimitiveAnalysisEngine_impl.java:401)
at
org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.processAndOutputNewCASes(PrimitiveAnalysisEngine_impl.java:309)
at
org.apache.uima.analysis_engine.impl.AnalysisEngineImplBase.process(AnalysisEngineImplBase.java:267)
at org.cogroo.tools.checker.checkers.UIMAChecker.check(UIMAChecker.java:74)
at org.cogroo.tools.checker.checkers.UIMAChecker.check(UIMAChecker.java:1)
at
org.cogroo.tools.checker.TypedCheckerComposite.check(TypedCheckerComposite.java:49)
at org.cogroo.checker.GrammarChecker.analyze(GrammarChecker.java:252)
at org.cogroo.checker.GrammarChecker.analyze(GrammarChecker.java:271)
at org.cogroo.tools.checker.checkers.UIMAChecker.main(UIMAChecker.java:131)
Caused by: java.lang.NullPointerException
at
org.apache.uima.ruta.engine.RutaEngine.resetEnvironment(RutaEngine.java:529)
at
org.apache.uima.ruta.engine.RutaEngine.resetEnvironments(RutaEngine.java:524)
at org.apache.uima.ruta.engine.RutaEngine.process(RutaEngine.java:480)
at
org.apache.uima.analysis_component.JCasAnnotator_ImplBase.process(JCasAnnotator_ImplBase.java:48)
at
org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.callAnalysisComponentProcess(PrimitiveAnalysisEngine_impl.java:385)
... 8 more


We have a feeling that RUTA can't find the child script files, and that
causes the error. Are we missing something?


Thank you,
William

Error using RUTA from Java

[William Colen]

Hello,

We have a Main RUTA script that imports a few children scripts, as follows:

PACKAGE cogroo.ruta;
 TYPESYSTEM BaseTypeSystem;
 IMPORT opennlp.uima.Token FROM TypeSystem AS cgToken;
 IMPORT opennlp.uima.Sentence FROM TypeSystem AS cgSentence;
 SCRIPT Crase;
 SCRIPT Base;
 Document{- CALL(Base)};
 Document{- CALL(Crase)};


All the scripts are in the root of the classpath.

We are trying to call it from Java, using the following code:

TypeSystemDescription tsd =
 TypeSystemDescriptionFactory.createTypeSystemDescription(MainTypeSystem
 );
 URL url = Resources.getResource(Main.ruta);
 String scriptText = Resources.toString(url, Charsets.UTF_8);
 AnalysisEngineDescription aeDes =
 Ruta.createAnalysisEngineDescription(scriptText, tsd);
 AnalysisEngine ae = UIMAFramework.produceAnalysisEngine(aeDes);


 The error we are getting:

org.apache.uima.analysis_engine.AnalysisEngineProcessException: Annotator
 processing failed.
 at
 org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.callAnalysisComponentProcess(PrimitiveAnalysisEngine_impl.java:401)
 at
 org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.processAndOutputNewCASes(PrimitiveAnalysisEngine_impl.java:309)
 at
 org.apache.uima.analysis_engine.impl.AnalysisEngineImplBase.process(AnalysisEngineImplBase.java:267)
 at org.cogroo.tools.checker.checkers.UIMAChecker.check(UIMAChecker.java:74)
 at org.cogroo.tools.checker.checkers.UIMAChecker.check(UIMAChecker.java:1)
 at
 org.cogroo.tools.checker.TypedCheckerComposite.check(TypedCheckerComposite.java:49)
 at org.cogroo.checker.GrammarChecker.analyze(GrammarChecker.java:252)
 at org.cogroo.checker.GrammarChecker.analyze(GrammarChecker.java:271)
 at org.cogroo.tools.checker.checkers.UIMAChecker.main(UIMAChecker.java:131)
 Caused by: java.lang.NullPointerException
 at
 org.apache.uima.ruta.engine.RutaEngine.resetEnvironment(RutaEngine.java:529)
 at
 org.apache.uima.ruta.engine.RutaEngine.resetEnvironments(RutaEngine.java:524)
 at org.apache.uima.ruta.engine.RutaEngine.process(RutaEngine.java:480)
 at
 org.apache.uima.analysis_component.JCasAnnotator_ImplBase.process(JCasAnnotator_ImplBase.java:48)
 at
 org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.callAnalysisComponentProcess(PrimitiveAnalysisEngine_impl.java:385)
 ... 8 more


We have a feeling that RUTA can't find the child script files, and that
causes the error. Are we missing something?


Thank you,
William

Re: Error using RUTA from Java

[William Colen]

Thank you, Peter.

I was using 2.2.1 and upgraded to 2.3.0 RC2 as you advised, but the error
persists. Now I will post the complete stacktrace:

Mai 20, 2015 6:56:23 PM
org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl
callAnalysisComponentProcess(417)
GRAVE: Exception occurred
org.apache.uima.analysis_engine.AnalysisEngineProcessException: Annotator
processing failed.
at
org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.callAnalysisComponentProcess(PrimitiveAnalysisEngine_impl.java:401)
at
org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.processAndOutputNewCASes(PrimitiveAnalysisEngine_impl.java:308)
at
org.apache.uima.analysis_engine.impl.AnalysisEngineImplBase.process(AnalysisEngineImplBase.java:269)
at org.cogroo.tools.checker.checkers.UIMAChecker.check(UIMAChecker.java:73)
at org.cogroo.tools.checker.checkers.UIMAChecker.check(UIMAChecker.java:1)
at
org.cogroo.tools.checker.TypedCheckerComposite.check(TypedCheckerComposite.java:49)
at org.cogroo.checker.GrammarChecker.analyze(GrammarChecker.java:252)
at org.cogroo.checker.GrammarChecker.analyze(GrammarChecker.java:271)
at org.cogroo.tools.checker.checkers.UIMAChecker.main(UIMAChecker.java:130)
Caused by: java.lang.NullPointerException
at
org.apache.uima.ruta.engine.RutaEngine.resetEnvironment(RutaEngine.java:580)
at
org.apache.uima.ruta.engine.RutaEngine.resetEnvironments(RutaEngine.java:575)
at org.apache.uima.ruta.engine.RutaEngine.process(RutaEngine.java:530)
at
org.apache.uima.analysis_component.JCasAnnotator_ImplBase.process(JCasAnnotator_ImplBase.java:48)
at
org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.callAnalysisComponentProcess(PrimitiveAnalysisEngine_impl.java:385)
... 8 more

org.apache.uima.analysis_engine.AnalysisEngineProcessException: Annotator
processing failed.
at
org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.callAnalysisComponentProcess(PrimitiveAnalysisEngine_impl.java:401)
at
org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.processAndOutputNewCASes(PrimitiveAnalysisEngine_impl.java:308)
at
org.apache.uima.analysis_engine.impl.AnalysisEngineImplBase.process(AnalysisEngineImplBase.java:269)
at org.cogroo.tools.checker.checkers.UIMAChecker.check(UIMAChecker.java:73)
at org.cogroo.tools.checker.checkers.UIMAChecker.check(UIMAChecker.java:1)
at
org.cogroo.tools.checker.TypedCheckerComposite.check(TypedCheckerComposite.java:49)
at org.cogroo.checker.GrammarChecker.analyze(GrammarChecker.java:252)
at org.cogroo.checker.GrammarChecker.analyze(GrammarChecker.java:271)
at org.cogroo.tools.checker.checkers.UIMAChecker.main(UIMAChecker.java:130)
Caused by: java.lang.NullPointerException
at
org.apache.uima.ruta.engine.RutaEngine.resetEnvironment(RutaEngine.java:580)
at
org.apache.uima.ruta.engine.RutaEngine.resetEnvironments(RutaEngine.java:575)
at org.apache.uima.ruta.engine.RutaEngine.process(RutaEngine.java:530)
at
org.apache.uima.analysis_component.JCasAnnotator_ImplBase.process(JCasAnnotator_ImplBase.java:48)
at
org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.callAnalysisComponentProcess(PrimitiveAnalysisEngine_impl.java:385)
... 8 more
Mai 20, 2015 6:56:23 PM
org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl
callAnalysisComponentProcess(417)
GRAVE: Exception occurred
org.apache.uima.analysis_engine.AnalysisEngineProcessException: Annotator
processing failed.
at
org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.callAnalysisComponentProcess(PrimitiveAnalysisEngine_impl.java:401)
at
org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.processAndOutputNewCASes(PrimitiveAnalysisEngine_impl.java:308)
at
org.apache.uima.analysis_engine.impl.AnalysisEngineImplBase.process(AnalysisEngineImplBase.java:269)
at org.cogroo.tools.checker.checkers.UIMAChecker.check(UIMAChecker.java:73)
at org.cogroo.tools.checker.checkers.UIMAChecker.check(UIMAChecker.java:1)
at
org.cogroo.tools.checker.TypedCheckerComposite.check(TypedCheckerComposite.java:49)
at org.cogroo.checker.GrammarChecker.analyze(GrammarChecker.java:252)
at org.cogroo.checker.GrammarChecker.analyze(GrammarChecker.java:271)
at org.cogroo.tools.checker.checkers.UIMAChecker.main(UIMAChecker.java:130)
Caused by: java.lang.NullPointerException
at
org.apache.uima.ruta.engine.RutaEngine.resetEnvironment(RutaEngine.java:580)
at
org.apache.uima.ruta.engine.RutaEngine.resetEnvironments(RutaEngine.java:575)
at org.apache.uima.ruta.engine.RutaEngine.process(RutaEngine.java:530)
at
org.apache.uima.analysis_component.JCasAnnotator_ImplBase.process(JCasAnnotator_ImplBase.java:48)
at
org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.callAnalysisComponentProcess(PrimitiveAnalysisEngine_impl.java:385)
... 8 more

org.apache.uima.analysis_engine.AnalysisEngineProcessException: Annotator
processing failed.
at