Re: trying to understand an example in the Ruta manual
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 > 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
Re: trying to understand an example in the Ruta manual
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 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 > > 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
Re: trying to understand an example in the Ruta manual
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 > 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" =
Re: trying to understand an example in the Ruta manual
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 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
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 >
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