You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@uima.apache.org by Bonnie MacKellar <bk...@gmail.com> on 2016/09/13 23:20:56 UTC
trying to understand an example in the Ruta manual
Hi,
I need to create annotations with features, but I am struggling to
understand the one example given in the manual
DECLARE Annotation EmplRelation
(Employee employeeRef, Employer employerRef);
Sentence{CONTAINS(EmploymentIndicator) -> CREATE(EmplRelation,
"employeeRef" = Employee, "employerRef" = Employer)};
I understand that this declares an Annotation with two features, one of
type Employee and one of type Employer. I am assuming these are Annotations
that have also been declared in the script? The second part really baffles
me. The way I am reading this, if a sentence contains an annotation of type
EmploymentIndicator, then create a EmplRelation annotation - and assign the
type Employer to feature employeeRef???? That makes no sense. It looks
like this assigns a type to a feature. I would have assumed we would want
some text as the value, no? Could anyone explain this in more detail?
thanks,
Bonnie MacKellar
Re: trying to understand an example in the Ruta manual
Posted by Peter Klügl <pe...@averbis.com>.
Hi,
Am 20.09.2016 um 21:51 schrieb Bonnie MacKellar:
> Hi,
>
> Just getting back to this since I was off at a conference. Thanks again for
> the details. This is realy helpful. I beleive that Ruta 2.5 is not yet out,
> right?
Yes, 2.5.0 is not yet release, but it will be soon, hopefully.
>
> As convenient as this rule seems
> "(?i).*(must be (?:receiving|undergoing|using) (.*) for) (.*)" ->
> R3Dot1CurrentPurposeConstraint ("group1" = 2, "group2" = 3);
>
> I do need to be able to distinguish between group1 and group2 in a Java
> program that walks through the features. If they are both plain
> Annotations, I am assuming I would not be able to do that, so the first
> setup is probably still best. Thanks for all your help
Just wanted to mention that you can distinguish between both since they
are in different features.
Best,
Peter
> Bonnie MacKellar
>
> On Thu, Sep 15, 2016 at 7:32 AM, Peter Kl�gl <pe...@averbis.com>
> wrote:
>
>> Hi,
>>
>>
>> Am 14.09.2016 um 22:58 schrieb Bonnie MacKellar:
>>> OK, thanks. I played around a little bit today with my own rules
>>>
>>> DECLARE Group1;
>>> DECLARE Group2;
>>> DECLARE R3Dot1CurrentPurposeConstraint(Annotation group1, Annotation
>>> group2);
>>>
>>> BLOCK(eachEC) EC{}{
>>> "(?i).*(must be (?:receiving|undergoing|using) (.*) for) (.*)" ->
>>> R3Dot1CurrentPurposeConstraint,2=Group1, 3=Group2;
>>> "(?i).*(ongoing (.*(?:therapy|treatment).*) for) (.*)" ->
>>> R3Dot1CurrentPurposeConstraint;
>>> }
>>>
>>> I want to end up with the text marked by Group1 to be the value for the
>>> group1 feature in R3Dot1CurrentPurposeConstraint (and likewise group2),
>> but
>>> I couldn't find a way to do it in my rules above, so I added this
>>>
>>> R3Dot1CurrentPurposeConstraint {->
>>> R3Dot1CurrentPurposeConstraint.group1=Group1,
>>> R3Dot1CurrentPurposeConstraint.group2=Group2};
>>>
>>> It appears to work on a small test case. Does that seem correct to you?
>> Is
>>> there a better way to do this, preferably right in the rules with the
>>> regular expressions?
>> Yes, this looks correct to me and it should do what you want, if there
>> is only exactly one annotation of each type (Group1 and Group2) within
>> the current R3Dot1CurrentPurposeConstraint annotation, or if only the
>> first one matters. And if the is no sequential dependency between Group1
>> and Group2, e.g., Group1 must occur before Group2. This should be the
>> case in your example.
>> I personally prefer labels more and more, especially because they become
>> even more powerful in ruta 2.5.0. Which is the best way to assign
>> features depends on the specific situation. The examples in my last mail
>> have all their advantages.
>>
>> I personally would write the rule this way (but this will work only in
>> 2.5.0):
>> c:R3Dot1CurrentPurposeConstraint{-> c.group1 = Group1, c.group2 = Group2};
>>
>> Here, the annotation R3Dot1CurrentPurposeConstraint in the action part
>> does not need to be resolved by the given type, but the annotation that
>> was matched by the type of the rule element is directly used. If there
>> are two R3Dot1CurrentPurposeConstraint annotations with the same
>> offsets, your rule would cause problems.
>>
>>
>> You can also assign the features directly in a simple regex rule, but
>> regex rules do not on given annotations at all but only on text. So if
>> you replace your rule with:
>>
>> "(?i).*(must be (?:receiving|undergoing|using) (.*) for) (.*)" ->
>> R3Dot1CurrentPurposeConstraint ("group1" = 2, "group2" = 3),
>> 2=Group1, 3=Group2;
>>
>> the two features of the created R3Dot1CurrentPurposeConstraint
>> annotation will be filled with annotations. However, these annotations
>> are of type Annotation and not Group1 and Group2. If you do not care
>> about the actual type of the annotation, e.g., because you won't use
>> additional features. You can simple write
>>
>> "(?i).*(must be (?:receiving|undergoing|using) (.*) for) (.*)" ->
>> R3Dot1CurrentPurposeConstraint ("group1" = 2, "group2" = 3);
>>
>> else you need an additional rule based on annotations like above.
>>
>>> Also, why did you declare your features as Annotation rather than
>> Employee
>>> and Employer?
>>> DECLARE EmplRelation (Annotation employee, Annotation employer);
>>>
>>> I imitated this, but to me it would seem better to use
>>> DECLARE EmplRelation (Employee employee, Employer employer);
>>> I am sure there is a good reason for this, but I don't see it!
>> Nope, there was no good reason :-)
>>
>> It just did not matter for the example.
>>
>> When I explain these examples, I normally also explain the situation
>> when there are no Employer and Employee annotations but only Person
>> annotations. Then, only a subset of the rules will work, e.g., GATHER,
>> annotation variables, labels. In this case, I would not need to modify
>> the declare statement.
>>
>> Best,
>>
>> Peter
>>
>>
>>
>>> Thanks, this cleared up some amount of confusion
>>>
>>> Bonnie MacKellar
>>>
>>> On Wed, Sep 14, 2016 at 5:58 AM, Peter Kl�gl <pe...@averbis.com>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>>
>>>> yes, the types need to be declared before. The DECLARE statements have
>>>> been omitted in the example.
>>>>
>>>>
>>>> Ruta 2.4.0 introduced annotation expressions. Before that, annotations
>>>> have only ben e referenced by type expressons. Ruta tries to guess which
>>>> annotation is meant by the given type expression using the context.
>>>>
>>>> So, if you "assign" a type to a feature that expects one annotation,
>>>> then the first annotation of that type within the matching window of the
>>>> rule element is selected. In that example, this is the first annotation
>>>> of the type Employee within the currently matched sentence annotation.
>>>>
>>>> Here are some more (with declare, but without the Indicator annotation)
>>>> examples how to assign feature values for the trivial text "Peter works
>>>> for Frank.":
>>>>
>>>>
>>>> DECLARE Employer, Employee;
>>>> DECLARE EmplRelation (Annotation employee, Annotation employer);
>>>> "Peter"-> Employee;
>>>> "Frank"-> Employer;
>>>>
>>>> // CREATE
>>>> Document{-> CREATE(EmplRelation, "employee" = Employee, "employer" =
>>>> Employer)};
>>>>
>>>> // GATHER
>>>> Employee # Employer{-> GATHER(EmplRelation, 1, 3, "employee" = 1,
>>>> "employer" = 3)};
>>>>
>>>> // implicit actions
>>>> (Employee # Employer){-> EmplRelation,
>>>> EmplRelation.employee = Employee,
>>>> EmplRelation.employer = Employer};
>>>>
>>>> // annotation variables
>>>> ANNOTATION e1,e2;
>>>> (Employee{-> ASSIGN(e1, Employee)} # Employer{-> ASSIGN(e2, Employer)})
>>>> {-> CREATE(EmplRelation, "employee" = e1, "employer" = e2)};
>>>>
>>>> // labels
>>>> (e1:Employee # e2:Employer)
>>>> {-> CREATE(EmplRelation, "employee" = e1, "employer" = e2)};
>>>>
>>>> Best,
>>>>
>>>>
>>>> Peter
>>>>
>>>> Am 14.09.2016 um 01:20 schrieb Bonnie MacKellar:
>>>>> Hi,
>>>>>
>>>>> I need to create annotations with features, but I am struggling to
>>>>> understand the one example given in the manual
>>>>>
>>>>> DECLARE Annotation EmplRelation
>>>>> (Employee employeeRef, Employer employerRef);
>>>>> Sentence{CONTAINS(EmploymentIndicator) -> CREATE(EmplRelation,
>>>>> "employeeRef" = Employee, "employerRef" = Employer)};
>>>>>
>>>>> I understand that this declares an Annotation with two features, one of
>>>>> type Employee and one of type Employer. I am assuming these are
>>>> Annotations
>>>>> that have also been declared in the script? The second part really
>>>> baffles
>>>>> me. The way I am reading this, if a sentence contains an annotation of
>>>> type
>>>>> EmploymentIndicator, then create a EmplRelation annotation - and assign
>>>> the
>>>>> type Employer to feature employeeRef???? That makes no sense. It looks
>>>>> like this assigns a type to a feature. I would have assumed we would
>> want
>>>>> some text as the value, no? Could anyone explain this in more detail?
>>>>>
>>>>> thanks,
>>>>> Bonnie MacKellar
>>>>>
>>
Re: trying to understand an example in the Ruta manual
Posted by Bonnie MacKellar <bk...@gmail.com>.
Hi,
Just getting back to this since I was off at a conference. Thanks again for
the details. This is realy helpful. I beleive that Ruta 2.5 is not yet out,
right?
As convenient as this rule seems
"(?i).*(must be (?:receiving|undergoing|using) (.*) for) (.*)" ->
R3Dot1CurrentPurposeConstraint ("group1" = 2, "group2" = 3);
I do need to be able to distinguish between group1 and group2 in a Java
program that walks through the features. If they are both plain
Annotations, I am assuming I would not be able to do that, so the first
setup is probably still best. Thanks for all your help
Bonnie MacKellar
On Thu, Sep 15, 2016 at 7:32 AM, Peter Klügl <pe...@averbis.com>
wrote:
> Hi,
>
>
> Am 14.09.2016 um 22:58 schrieb Bonnie MacKellar:
> > OK, thanks. I played around a little bit today with my own rules
> >
> > DECLARE Group1;
> > DECLARE Group2;
> > DECLARE R3Dot1CurrentPurposeConstraint(Annotation group1, Annotation
> > group2);
> >
> > BLOCK(eachEC) EC{}{
> > "(?i).*(must be (?:receiving|undergoing|using) (.*) for) (.*)" ->
> > R3Dot1CurrentPurposeConstraint,2=Group1, 3=Group2;
> > "(?i).*(ongoing (.*(?:therapy|treatment).*) for) (.*)" ->
> > R3Dot1CurrentPurposeConstraint;
> > }
> >
> > I want to end up with the text marked by Group1 to be the value for the
> > group1 feature in R3Dot1CurrentPurposeConstraint (and likewise group2),
> but
> > I couldn't find a way to do it in my rules above, so I added this
> >
> > R3Dot1CurrentPurposeConstraint {->
> > R3Dot1CurrentPurposeConstraint.group1=Group1,
> > R3Dot1CurrentPurposeConstraint.group2=Group2};
> >
> > It appears to work on a small test case. Does that seem correct to you?
> Is
> > there a better way to do this, preferably right in the rules with the
> > regular expressions?
>
> Yes, this looks correct to me and it should do what you want, if there
> is only exactly one annotation of each type (Group1 and Group2) within
> the current R3Dot1CurrentPurposeConstraint annotation, or if only the
> first one matters. And if the is no sequential dependency between Group1
> and Group2, e.g., Group1 must occur before Group2. This should be the
> case in your example.
> I personally prefer labels more and more, especially because they become
> even more powerful in ruta 2.5.0. Which is the best way to assign
> features depends on the specific situation. The examples in my last mail
> have all their advantages.
>
> I personally would write the rule this way (but this will work only in
> 2.5.0):
> c:R3Dot1CurrentPurposeConstraint{-> c.group1 = Group1, c.group2 = Group2};
>
> Here, the annotation R3Dot1CurrentPurposeConstraint in the action part
> does not need to be resolved by the given type, but the annotation that
> was matched by the type of the rule element is directly used. If there
> are two R3Dot1CurrentPurposeConstraint annotations with the same
> offsets, your rule would cause problems.
>
>
> You can also assign the features directly in a simple regex rule, but
> regex rules do not on given annotations at all but only on text. So if
> you replace your rule with:
>
> "(?i).*(must be (?:receiving|undergoing|using) (.*) for) (.*)" ->
> R3Dot1CurrentPurposeConstraint ("group1" = 2, "group2" = 3),
> 2=Group1, 3=Group2;
>
> the two features of the created R3Dot1CurrentPurposeConstraint
> annotation will be filled with annotations. However, these annotations
> are of type Annotation and not Group1 and Group2. If you do not care
> about the actual type of the annotation, e.g., because you won't use
> additional features. You can simple write
>
> "(?i).*(must be (?:receiving|undergoing|using) (.*) for) (.*)" ->
> R3Dot1CurrentPurposeConstraint ("group1" = 2, "group2" = 3);
>
> else you need an additional rule based on annotations like above.
>
> >
> > Also, why did you declare your features as Annotation rather than
> Employee
> > and Employer?
> > DECLARE EmplRelation (Annotation employee, Annotation employer);
> >
> > I imitated this, but to me it would seem better to use
> > DECLARE EmplRelation (Employee employee, Employer employer);
> > I am sure there is a good reason for this, but I don't see it!
>
> Nope, there was no good reason :-)
>
> It just did not matter for the example.
>
> When I explain these examples, I normally also explain the situation
> when there are no Employer and Employee annotations but only Person
> annotations. Then, only a subset of the rules will work, e.g., GATHER,
> annotation variables, labels. In this case, I would not need to modify
> the declare statement.
>
> Best,
>
> Peter
>
>
>
> >
> > Thanks, this cleared up some amount of confusion
> >
> > Bonnie MacKellar
> >
> > On Wed, Sep 14, 2016 at 5:58 AM, Peter Klügl <pe...@averbis.com>
> > wrote:
> >
> >> Hi,
> >>
> >>
> >> yes, the types need to be declared before. The DECLARE statements have
> >> been omitted in the example.
> >>
> >>
> >> Ruta 2.4.0 introduced annotation expressions. Before that, annotations
> >> have only ben e referenced by type expressons. Ruta tries to guess which
> >> annotation is meant by the given type expression using the context.
> >>
> >> So, if you "assign" a type to a feature that expects one annotation,
> >> then the first annotation of that type within the matching window of the
> >> rule element is selected. In that example, this is the first annotation
> >> of the type Employee within the currently matched sentence annotation.
> >>
> >> Here are some more (with declare, but without the Indicator annotation)
> >> examples how to assign feature values for the trivial text "Peter works
> >> for Frank.":
> >>
> >>
> >> DECLARE Employer, Employee;
> >> DECLARE EmplRelation (Annotation employee, Annotation employer);
> >> "Peter"-> Employee;
> >> "Frank"-> Employer;
> >>
> >> // CREATE
> >> Document{-> CREATE(EmplRelation, "employee" = Employee, "employer" =
> >> Employer)};
> >>
> >> // GATHER
> >> Employee # Employer{-> GATHER(EmplRelation, 1, 3, "employee" = 1,
> >> "employer" = 3)};
> >>
> >> // implicit actions
> >> (Employee # Employer){-> EmplRelation,
> >> EmplRelation.employee = Employee,
> >> EmplRelation.employer = Employer};
> >>
> >> // annotation variables
> >> ANNOTATION e1,e2;
> >> (Employee{-> ASSIGN(e1, Employee)} # Employer{-> ASSIGN(e2, Employer)})
> >> {-> CREATE(EmplRelation, "employee" = e1, "employer" = e2)};
> >>
> >> // labels
> >> (e1:Employee # e2:Employer)
> >> {-> CREATE(EmplRelation, "employee" = e1, "employer" = e2)};
> >>
> >> Best,
> >>
> >>
> >> Peter
> >>
> >> Am 14.09.2016 um 01:20 schrieb Bonnie MacKellar:
> >>> Hi,
> >>>
> >>> I need to create annotations with features, but I am struggling to
> >>> understand the one example given in the manual
> >>>
> >>> DECLARE Annotation EmplRelation
> >>> (Employee employeeRef, Employer employerRef);
> >>> Sentence{CONTAINS(EmploymentIndicator) -> CREATE(EmplRelation,
> >>> "employeeRef" = Employee, "employerRef" = Employer)};
> >>>
> >>> I understand that this declares an Annotation with two features, one of
> >>> type Employee and one of type Employer. I am assuming these are
> >> Annotations
> >>> that have also been declared in the script? The second part really
> >> baffles
> >>> me. The way I am reading this, if a sentence contains an annotation of
> >> type
> >>> EmploymentIndicator, then create a EmplRelation annotation - and assign
> >> the
> >>> type Employer to feature employeeRef???? That makes no sense. It looks
> >>> like this assigns a type to a feature. I would have assumed we would
> want
> >>> some text as the value, no? Could anyone explain this in more detail?
> >>>
> >>> thanks,
> >>> Bonnie MacKellar
> >>>
> >>
>
>
Re: trying to understand an example in the Ruta manual
Posted by Peter Klügl <pe...@averbis.com>.
Hi,
Am 14.09.2016 um 22:58 schrieb Bonnie MacKellar:
> OK, thanks. I played around a little bit today with my own rules
>
> DECLARE Group1;
> DECLARE Group2;
> DECLARE R3Dot1CurrentPurposeConstraint(Annotation group1, Annotation
> group2);
>
> BLOCK(eachEC) EC{}{
> "(?i).*(must be (?:receiving|undergoing|using) (.*) for) (.*)" ->
> R3Dot1CurrentPurposeConstraint,2=Group1, 3=Group2;
> "(?i).*(ongoing (.*(?:therapy|treatment).*) for) (.*)" ->
> R3Dot1CurrentPurposeConstraint;
> }
>
> I want to end up with the text marked by Group1 to be the value for the
> group1 feature in R3Dot1CurrentPurposeConstraint (and likewise group2), but
> I couldn't find a way to do it in my rules above, so I added this
>
> R3Dot1CurrentPurposeConstraint {->
> R3Dot1CurrentPurposeConstraint.group1=Group1,
> R3Dot1CurrentPurposeConstraint.group2=Group2};
>
> It appears to work on a small test case. Does that seem correct to you? Is
> there a better way to do this, preferably right in the rules with the
> regular expressions?
Yes, this looks correct to me and it should do what you want, if there
is only exactly one annotation of each type (Group1 and Group2) within
the current R3Dot1CurrentPurposeConstraint annotation, or if only the
first one matters. And if the is no sequential dependency between Group1
and Group2, e.g., Group1 must occur before Group2. This should be the
case in your example.
I personally prefer labels more and more, especially because they become
even more powerful in ruta 2.5.0. Which is the best way to assign
features depends on the specific situation. The examples in my last mail
have all their advantages.
I personally would write the rule this way (but this will work only in
2.5.0):
c:R3Dot1CurrentPurposeConstraint{-> c.group1 = Group1, c.group2 = Group2};
Here, the annotation R3Dot1CurrentPurposeConstraint in the action part
does not need to be resolved by the given type, but the annotation that
was matched by the type of the rule element is directly used. If there
are two R3Dot1CurrentPurposeConstraint annotations with the same
offsets, your rule would cause problems.
You can also assign the features directly in a simple regex rule, but
regex rules do not on given annotations at all but only on text. So if
you replace your rule with:
"(?i).*(must be (?:receiving|undergoing|using) (.*) for) (.*)" ->
R3Dot1CurrentPurposeConstraint ("group1" = 2, "group2" = 3),
2=Group1, 3=Group2;
the two features of the created R3Dot1CurrentPurposeConstraint
annotation will be filled with annotations. However, these annotations
are of type Annotation and not Group1 and Group2. If you do not care
about the actual type of the annotation, e.g., because you won't use
additional features. You can simple write
"(?i).*(must be (?:receiving|undergoing|using) (.*) for) (.*)" ->
R3Dot1CurrentPurposeConstraint ("group1" = 2, "group2" = 3);
else you need an additional rule based on annotations like above.
>
> Also, why did you declare your features as Annotation rather than Employee
> and Employer?
> DECLARE EmplRelation (Annotation employee, Annotation employer);
>
> I imitated this, but to me it would seem better to use
> DECLARE EmplRelation (Employee employee, Employer employer);
> I am sure there is a good reason for this, but I don't see it!
Nope, there was no good reason :-)
It just did not matter for the example.
When I explain these examples, I normally also explain the situation
when there are no Employer and Employee annotations but only Person
annotations. Then, only a subset of the rules will work, e.g., GATHER,
annotation variables, labels. In this case, I would not need to modify
the declare statement.
Best,
Peter
>
> Thanks, this cleared up some amount of confusion
>
> Bonnie MacKellar
>
> On Wed, Sep 14, 2016 at 5:58 AM, Peter Kl�gl <pe...@averbis.com>
> wrote:
>
>> Hi,
>>
>>
>> yes, the types need to be declared before. The DECLARE statements have
>> been omitted in the example.
>>
>>
>> Ruta 2.4.0 introduced annotation expressions. Before that, annotations
>> have only ben e referenced by type expressons. Ruta tries to guess which
>> annotation is meant by the given type expression using the context.
>>
>> So, if you "assign" a type to a feature that expects one annotation,
>> then the first annotation of that type within the matching window of the
>> rule element is selected. In that example, this is the first annotation
>> of the type Employee within the currently matched sentence annotation.
>>
>> Here are some more (with declare, but without the Indicator annotation)
>> examples how to assign feature values for the trivial text "Peter works
>> for Frank.":
>>
>>
>> DECLARE Employer, Employee;
>> DECLARE EmplRelation (Annotation employee, Annotation employer);
>> "Peter"-> Employee;
>> "Frank"-> Employer;
>>
>> // CREATE
>> Document{-> CREATE(EmplRelation, "employee" = Employee, "employer" =
>> Employer)};
>>
>> // GATHER
>> Employee # Employer{-> GATHER(EmplRelation, 1, 3, "employee" = 1,
>> "employer" = 3)};
>>
>> // implicit actions
>> (Employee # Employer){-> EmplRelation,
>> EmplRelation.employee = Employee,
>> EmplRelation.employer = Employer};
>>
>> // annotation variables
>> ANNOTATION e1,e2;
>> (Employee{-> ASSIGN(e1, Employee)} # Employer{-> ASSIGN(e2, Employer)})
>> {-> CREATE(EmplRelation, "employee" = e1, "employer" = e2)};
>>
>> // labels
>> (e1:Employee # e2:Employer)
>> {-> CREATE(EmplRelation, "employee" = e1, "employer" = e2)};
>>
>> Best,
>>
>>
>> Peter
>>
>> Am 14.09.2016 um 01:20 schrieb Bonnie MacKellar:
>>> Hi,
>>>
>>> I need to create annotations with features, but I am struggling to
>>> understand the one example given in the manual
>>>
>>> DECLARE Annotation EmplRelation
>>> (Employee employeeRef, Employer employerRef);
>>> Sentence{CONTAINS(EmploymentIndicator) -> CREATE(EmplRelation,
>>> "employeeRef" = Employee, "employerRef" = Employer)};
>>>
>>> I understand that this declares an Annotation with two features, one of
>>> type Employee and one of type Employer. I am assuming these are
>> Annotations
>>> that have also been declared in the script? The second part really
>> baffles
>>> me. The way I am reading this, if a sentence contains an annotation of
>> type
>>> EmploymentIndicator, then create a EmplRelation annotation - and assign
>> the
>>> type Employer to feature employeeRef???? That makes no sense. It looks
>>> like this assigns a type to a feature. I would have assumed we would want
>>> some text as the value, no? Could anyone explain this in more detail?
>>>
>>> thanks,
>>> Bonnie MacKellar
>>>
>>
Re: trying to understand an example in the Ruta manual
Posted by Bonnie MacKellar <bk...@gmail.com>.
OK, thanks. I played around a little bit today with my own rules
DECLARE Group1;
DECLARE Group2;
DECLARE R3Dot1CurrentPurposeConstraint(Annotation group1, Annotation
group2);
BLOCK(eachEC) EC{}{
"(?i).*(must be (?:receiving|undergoing|using) (.*) for) (.*)" ->
R3Dot1CurrentPurposeConstraint,2=Group1, 3=Group2;
"(?i).*(ongoing (.*(?:therapy|treatment).*) for) (.*)" ->
R3Dot1CurrentPurposeConstraint;
}
I want to end up with the text marked by Group1 to be the value for the
group1 feature in R3Dot1CurrentPurposeConstraint (and likewise group2), but
I couldn't find a way to do it in my rules above, so I added this
R3Dot1CurrentPurposeConstraint {->
R3Dot1CurrentPurposeConstraint.group1=Group1,
R3Dot1CurrentPurposeConstraint.group2=Group2};
It appears to work on a small test case. Does that seem correct to you? Is
there a better way to do this, preferably right in the rules with the
regular expressions?
Also, why did you declare your features as Annotation rather than Employee
and Employer?
DECLARE EmplRelation (Annotation employee, Annotation employer);
I imitated this, but to me it would seem better to use
DECLARE EmplRelation (Employee employee, Employer employer);
I am sure there is a good reason for this, but I don't see it!
Thanks, this cleared up some amount of confusion
Bonnie MacKellar
On Wed, Sep 14, 2016 at 5:58 AM, Peter Klügl <pe...@averbis.com>
wrote:
> Hi,
>
>
> yes, the types need to be declared before. The DECLARE statements have
> been omitted in the example.
>
>
> Ruta 2.4.0 introduced annotation expressions. Before that, annotations
> have only ben e referenced by type expressons. Ruta tries to guess which
> annotation is meant by the given type expression using the context.
>
> So, if you "assign" a type to a feature that expects one annotation,
> then the first annotation of that type within the matching window of the
> rule element is selected. In that example, this is the first annotation
> of the type Employee within the currently matched sentence annotation.
>
> Here are some more (with declare, but without the Indicator annotation)
> examples how to assign feature values for the trivial text "Peter works
> for Frank.":
>
>
> DECLARE Employer, Employee;
> DECLARE EmplRelation (Annotation employee, Annotation employer);
> "Peter"-> Employee;
> "Frank"-> Employer;
>
> // CREATE
> Document{-> CREATE(EmplRelation, "employee" = Employee, "employer" =
> Employer)};
>
> // GATHER
> Employee # Employer{-> GATHER(EmplRelation, 1, 3, "employee" = 1,
> "employer" = 3)};
>
> // implicit actions
> (Employee # Employer){-> EmplRelation,
> EmplRelation.employee = Employee,
> EmplRelation.employer = Employer};
>
> // annotation variables
> ANNOTATION e1,e2;
> (Employee{-> ASSIGN(e1, Employee)} # Employer{-> ASSIGN(e2, Employer)})
> {-> CREATE(EmplRelation, "employee" = e1, "employer" = e2)};
>
> // labels
> (e1:Employee # e2:Employer)
> {-> CREATE(EmplRelation, "employee" = e1, "employer" = e2)};
>
> Best,
>
>
> Peter
>
> Am 14.09.2016 um 01:20 schrieb Bonnie MacKellar:
> > Hi,
> >
> > I need to create annotations with features, but I am struggling to
> > understand the one example given in the manual
> >
> > DECLARE Annotation EmplRelation
> > (Employee employeeRef, Employer employerRef);
> > Sentence{CONTAINS(EmploymentIndicator) -> CREATE(EmplRelation,
> > "employeeRef" = Employee, "employerRef" = Employer)};
> >
> > I understand that this declares an Annotation with two features, one of
> > type Employee and one of type Employer. I am assuming these are
> Annotations
> > that have also been declared in the script? The second part really
> baffles
> > me. The way I am reading this, if a sentence contains an annotation of
> type
> > EmploymentIndicator, then create a EmplRelation annotation - and assign
> the
> > type Employer to feature employeeRef???? That makes no sense. It looks
> > like this assigns a type to a feature. I would have assumed we would want
> > some text as the value, no? Could anyone explain this in more detail?
> >
> > thanks,
> > Bonnie MacKellar
> >
>
>
Re: trying to understand an example in the Ruta manual
Posted by Peter Klügl <pe...@averbis.com>.
Hi,
yes, the types need to be declared before. The DECLARE statements have
been omitted in the example.
Ruta 2.4.0 introduced annotation expressions. Before that, annotations
have only ben e referenced by type expressons. Ruta tries to guess which
annotation is meant by the given type expression using the context.
So, if you "assign" a type to a feature that expects one annotation,
then the first annotation of that type within the matching window of the
rule element is selected. In that example, this is the first annotation
of the type Employee within the currently matched sentence annotation.
Here are some more (with declare, but without the Indicator annotation)
examples how to assign feature values for the trivial text "Peter works
for Frank.":
DECLARE Employer, Employee;
DECLARE EmplRelation (Annotation employee, Annotation employer);
"Peter"-> Employee;
"Frank"-> Employer;
// CREATE
Document{-> CREATE(EmplRelation, "employee" = Employee, "employer" =
Employer)};
// GATHER
Employee # Employer{-> GATHER(EmplRelation, 1, 3, "employee" = 1,
"employer" = 3)};
// implicit actions
(Employee # Employer){-> EmplRelation,
EmplRelation.employee = Employee,
EmplRelation.employer = Employer};
// annotation variables
ANNOTATION e1,e2;
(Employee{-> ASSIGN(e1, Employee)} # Employer{-> ASSIGN(e2, Employer)})
{-> CREATE(EmplRelation, "employee" = e1, "employer" = e2)};
// labels
(e1:Employee # e2:Employer)
{-> CREATE(EmplRelation, "employee" = e1, "employer" = e2)};
Best,
Peter
Am 14.09.2016 um 01:20 schrieb Bonnie MacKellar:
> Hi,
>
> I need to create annotations with features, but I am struggling to
> understand the one example given in the manual
>
> DECLARE Annotation EmplRelation
> (Employee employeeRef, Employer employerRef);
> Sentence{CONTAINS(EmploymentIndicator) -> CREATE(EmplRelation,
> "employeeRef" = Employee, "employerRef" = Employer)};
>
> I understand that this declares an Annotation with two features, one of
> type Employee and one of type Employer. I am assuming these are Annotations
> that have also been declared in the script? The second part really baffles
> me. The way I am reading this, if a sentence contains an annotation of type
> EmploymentIndicator, then create a EmplRelation annotation - and assign the
> type Employer to feature employeeRef???? That makes no sense. It looks
> like this assigns a type to a feature. I would have assumed we would want
> some text as the value, no? Could anyone explain this in more detail?
>
> thanks,
> Bonnie MacKellar
>