Is it possible to make a rule to match the value of a FEATURE in an annotation that is a child of another Annotation?
Example:
Annotation Person
Annotation Doctor
Feature TYPE: xyz
something like Person.Doctor{FEATURE("TYPE","xyz")}
Also is it possible to create a rule that matches a FEATURE in an annotation that is PARTOF another annotation?
|-----------A1------------|
|-----A2-----| |---A3----|
Make a rule where
A3{FEATURE("X","1")} but also A3{PARTOF(A1)}
Thank you!
Assuming that there is a type Doctor and its parent type called Person which defined a feature kind of type uima.cas.String, you can simply write:
Doctor.kind=="xyz";
Doctor{Doctor.kind=="xyz"};
d:Doctor{d.kind=="xyz"};
Doctor<-{Person.kind=="xyz";};
Some short explanation of the label expression d: and the inlined rule as condition (<-{}). The label expression introduces a local annotation variable within the scope of the rule. In the above example d:Doctor matches on a annotation of the type Doctor and assigns it to a new variable called d. This variables can then be used in other parts of the rule in order to refer to this specific annotation. In the second rule, no label expression is used and the annotation is refered to by using the type (Doctor.kind). Here, the annotation is resolved anew in the context of the match of the rule, which could lead to a different one in case there are several annotations of the type Doctorwith the same offsets.
The inlined rule as condition works as a complex condition. The rule element Doctor matches only if the rule Person.kind=="xyz"; is able to match within the context/offsets/span of the matched Doctor annotation.
Concerning the second part of the question:
You cannot directly access the annotation which is used in a PARTOF condition because none is used actually. You need to match on the annotation in order to access its features. It depends on which annotation coveres which one, and which annotation should be checked for the feature value. Here are some examples:
a:A3{PARTOF(A1),a.x==1};
A1.x=="1"{CONTAINS(A3)};
A1<-{a:A3{a.x=="1"};};
DISCLAIMER: I am a developer of UIMA Ruta
Related
Can this be written as a single line?
assertThat(actualDeltas)
.filteredOn(delta -> delta instanceof Replacement)
.asInstanceOf(InstanceOfAssertFactories.list(Replacement.class))
I expected asInstanceOf to do the filtering. Alternatively, I searched for extractors or other concepts, but couldn't find any simple solution.
Is that possible with assertj?
By design, the purpose of asInstanceOf is only to provide type-narrowed assertions for cases where the type of the object under assertion is not visible at compile time.
When you provide InstanceOfAssertFactories.list(Replacement.class) as a parameter for asInstanceOf, you are telling AssertJ that you expect the object under assertion to be a List with elements of type Replacement.
While asInstanceOf will make sure that the object under test is a List, it will neither filter nor enforce that all the list elements are of type Replacement. The Replacement will ensure type-safety with subsequent methods that can be chained, for example with extracting(Function).
Currently, filteredOn(Predicate) or any other filteredOn variant is the right way to take out elements that should not be part of the assertion. If the filtering would happen outside (e.g., via Stream API), no asInstanceOf call would be needed as assertThat() could detect the proper element type based on the input declaration.
I am creating rules using Ruta as implemented in CLAMP ( https://clamp.uth.edu/ ). As one of the steps, I would like to identify all sentences that contain Temperature annotations.
So I would like to be able to specify attribute values for the annotation in CONTAINS function like this:
Sentence{CONTAINS(ClampNameEntityUIMA{"semanticTag", "Temperature"})
-> CREATE( ClampNameEntityUIMA , "semanticTag" = "TemperatureSentence")};
The statement that works is:
Sentence{CONTAINS(ClampNameEntityUIMA)
-> CREATE( ClampNameEntityUIMA , "semanticTag" = "TemperatureSentence")};
but that marks all sentences regardless of the contained annotation's feature value.
CLAMP does not allow creating types on the fly so I cannot declare a new type as a placeholder for annotations that meet conditions. So I have to use only the existing type - ClampNameEntityUIMA - and I can only check the feature values to differentiate the annotation classes.
Is there a way to include additional conditions in CONTAINS function? Or can I manipulate annotations without having to declare a new type?
The CONTAINS condition does not support what you need. If more complex condition are required as in your example, you need to switch to inlined rules as condition. A rule like the following could solve your problem:
Sentence{-> CREATE(ClampNameEntityUIMA, "semanticTag" = "TemperatureSentence")}
<- {e:ClampNameEntityUIMA{e.semanticTag == "Temperature"};};
DISCLAIMER: I am a developer of UIMA Ruta
this is my example to show you the problem I need to call two rules
generate umlDsl "http://www.xtext.org/example/umldsl/UmlDsl"
Model:
elements+=rule*
;
rule:
rul1 'and' rul2
;
rul1:
'rul1' action1=[uml::Action|FQN]
;
rul2:
'rul2' action2=[uml::Action|FQN]
;
FQN returns ecore::EString:
ID ("." ID)*
;
I have this error
Multiple markers at this line (rul1 'and' rul2)
An unassigned rule call is not allowed, when the 'current'
was already created.
Cannot change type twice within a rule
I want to know why I have this error and how to fix it please
These errors occurs because of your rule implementation of rule rule
rule:
rul1 'and' rul2
;
As I understand rule has two attributes, rul1 and rul2. But in your implementation rule does not have any attributes. To define rul1 and rul2 as attribuites you have assign these elements to an attribute. This could look like this:
rule:
rul1=rul1 'and' rul2=rul2
;
Have you looked into the Xtext documentation [1] to learn about the grammar language syntax and semantics?
The things you need to know for understanding your error are the following:
An attribute of a parser rule needs a name. To this name you assign a value, which is an other parser rules name. It is similar to assing values to a field in Java:
int i = 42;
A field declaration consists of the fields type (int) and the fields name (i) this normally is followd by the assignment operator (=) and the value (42). The attribute definiton of a parser rule follows this scheme:
RuleA: 'some syntax' attributeName=OtherRule 'more syntax';
OtherRule: 'other syntax' attribute=NextRule ... ;
...
A parser rule in Xtexts grammar language is like a Java class. RuleName corresponds to class ClassName. Then you can define some static syntax with 'keyword'. If any other rule should occur within any other rule, it can be understood as a field declaration. This rule is an attribute which is implemented like this:
attributeName=AnyRule
Where attributeName corresponds to the field name. But to an attribute the type of the value is assigned (AnyRule).
Btw. I strongly recommand that rule names should start with an Capital letter and attribute names should start with an lower case letter.
[1] https://www.eclipse.org/Xtext/documentation/301_grammarlanguage.html
The most basic use of from clause is not working, even when I know there are elements in the list and there is no conditions for the elements being extracted from that list, and I have other rules working properly.
Here is what happens, there are many variables in my problem, but I have simplified to this:
Having this two rules, the firstone is made to demostrate that fixedShipmentValueData list, has at least one element. However, the second rule isn't fired, even when the only different thing it does from the firstone, is to use the from clause and put a variable name.
rule "Print list value"
ruleflow-group "fixed-values"
no-loop
when
cParams: CustomerParameters(list: fixedShipmentValueData)
then
System.out.format("There are %s elements at fixedShipmentValue and fixed value is %s%n",list.size(),
((ParameterValues)list.get(0)).getFixedShipmentValue());
end
rule "Do something with the list"
ruleflow-group "fixed-values"
no-loop
when
cParams: CustomerParameters(list: fixedShipmentValueData)
ParameterValues($fixedShipmentValue: fixedShipmentValue) from list
then
System.out.format("fixed Shipment Value is %s%n", $fixedShipmentValue);
end
This looks so simple... I have expent enough time as to be out of ideas.
Without seeing the Java code for CustomerParameters, ParameterValues and the application part that creates, composes and inserts the fact(s) there's just one scenario I know that can reproduce the effect as you have told it. Consider this:
A List<Base> is field list in class X. There are subclasses SubA and SubB both extending Base. Create X, add objects of class SubA to list. A rule (like "Print list value") will show that the list is not empty.
However, a rule using a pattern such as
X( $list: list )
SubB() from $list
will never fire, since there are no SubB's in Base.list.
Under Window > Preferences > General > Search, there is the option Ignore potential matches
What does it do? Whether I activate it or not, I never see a difference.
Is it an option that only makes sense for Java development (which I never do, but I do develop in C, Python and PHP using Eclipse)?
See bug 127442 for examples: depending on what you are searching (a class, a method, ...), the Search engine can find instances which could match (but it cannot say for certain).
Those instances are marked "POTENTIAL_MATCH":
A method with different number of parameters is not a potential match.
(see bug 97322 )
A potential match is a match where the resolution failed (e.g. the method binding is null).
If the user searches for "foo(String)" (without qualifying String), then "foo(java.lang.String)" and "foo(p.String)" are both exact matches.
For the .class file case, I think we can only have potential matches in the case of the missing type case (see bug 196200), i.e if the .class file was compiled and some types it references were missing.
A current example of potential match misbehavior is found in bug 382778:
I have a public static void method printIt(String name).
When I open its call hierarchy, some callers are missing.
I am guessing the callers are missing because java search marks them as potential instead of exact matches for the printIt(String) reference.
The following code is sometimes marked as potential, and sometimes exact:
// Listing 1
PublicInterface2 impl2 = new Impl2("Name Broken");
Static.printIt(impl2.getName());
When the search result is marked potential, the caller is missing from the printIt() call hierarchy.
PublicInterface2 is an empty public interface which extends PackageInterface2Getters.
PackageInterface2Getters is an empty default-scoped interface which extends PackageInterface1Getters.
PackageInterface1Getters is a default-scoped interface which declares String getName().
So impl2.getName() above returns a String.
There are some problems reported which I guess make the matches be marked as potential:
...
Filename : \D:\workspace\eclipse\_runtimes\jdt\call-hierarchy-bug\src\main\PublicInterface2.java
COMPILED type(s)
2 PROBLEM(s) detected
- Pb(2) PackageInterface1Getters cannot be resolved to a type
- Pb(327) The hierarchy of the type PublicInterface2 is inconsistent
Turns out that:
The compiler asks the "NameEnvironment" to get the type information of any dependent type.
Search has it's own NameEnvironment implementation in JavaSearchNameEnvironment and it is not looking for secondary types.
This is bad and it is surprising that we haven't run into this problem until now.
In Eclipse Luna (Service Release 1 (4.4.1)) I searched just for references to this Java method:
merge(DashboardConfigurationModel template, DashboardModel custom)
It returns two references. One of these calls to the merge() method passes in a DashboardConfigurationModel and a DashboardModel, as befits the method signature. This is a match all right!
The other reference to a merge() method passes in a String and a Map. It is marked in Eclipse as a "potential match" but in my mind, since the argument types don't match, this has zero potential to be a match.
I then checked Ignore potential matches, did the search again, and this noise went away.