Home » Modeling » Epsilon » Accessing MapInfo structure from ECL(Writing data from within a compare)
| Accessing MapInfo structure from ECL [message #541771] |
Tue, 22 June 2010 09:42  |
Eclipse User |
|
|
|
Hi guys,
I can't figure out how to put a value into a match's info map after a successful compare. I can see the (empty) structure in the debugger, but can't access it from ECL.
The Epsilon Book states that it is possible to do so from within the do part of a compare for the established match. Trouble is, I don't know how to get a hold of the "established match".
Many thanks,
--Stephen
|
|
| | | | |
| Re: Accessing MapInfo structure from ECL [message #544891 is a reply to message #544888] |
Mon, 05 July 2010 18:20  |
| Eclipse User |
|
|
|
Hi Stephen,
On 05/07/2010 22:52, Stephen Barrett wrote:
> Okay,
>
> I am now passing values back to my application from match rules by
> adding do-parts of the following form to each rule:
>
>
> do {
> matchInfo.put("mirador", 0.7);
> }
>
>
> with the key being the name of my application. Do you think that this
> robust enough, or are there some gotchas I may be unaware of?
That should be fine indeed.
>
> Also, Dimitirs you mentioned to me that after matching a pair of model
> elements with ECL, that I might want to recalculate overall similarity
> measures for the remaining element pairs in my model. Trouble is, I
> can't remember why this is so. Could you please refresh my memory?
I think I was referring to recalculating matches whenever the user
establishes an explicit (i.e. manual) match - if that's supported by
Mirador.
>
> Many thanks,
> --Stephen
>
Cheers,
Dimitris
|
|
| |
| Re: Accessing MapInfo structure from ECL [message #545164 is a reply to message #545160] |
Tue, 06 July 2010 16:24 |
| Eclipse User |
|
|
|
Hi Stephen,
Suppose that you're comparing trees and you have the following sample trees:
[a]
-- [b]
and
[c]
-- [b]
and the following rule
rule MatchTrees
match l : Left!Tree
with r : Right!Tree {
compare : l.label = r.label and
l.parent.matches(r.parent)
}
In the initial comparison, the two [b]'s won't match because their
parents don't match ([a] <> [c]). However, if the user explicitly
declares that [a] matches with [c] then the two [b]'s should now match.
Does this make any sense?
Cheers,
Dimitris
On 06/07/2010 21:07, Stephen Barrett wrote:
>> I think I was referring to recalculating matches whenever the user
>> establishes an explicit (i.e. manual) match - if that's supported by
>> Mirador.
>
> Yes, that's what you were referring to. So, I suppose, my real question
> is, why do you think a recalculation might be needed? And by
> recalculation, I assume you mean redoing all the element similarity
> measures, and then rematching the elements based on the new measures. Is
> that accurate?
>
> Regards,
> --Stephen
|
|
| | | | |
| Re: Accessing MapInfo structure from ECL [message #590450 is a reply to message #544888] |
Mon, 05 July 2010 18:20 |
| Eclipse User |
|
|
|
Hi Stephen,
On 05/07/2010 22:52, Stephen Barrett wrote:
> Okay,
>
> I am now passing values back to my application from match rules by
> adding do-parts of the following form to each rule:
>
>
> do {
> matchInfo.put("mirador", 0.7);
> }
>
>
> with the key being the name of my application. Do you think that this
> robust enough, or are there some gotchas I may be unaware of?
That should be fine indeed.
>
> Also, Dimitirs you mentioned to me that after matching a pair of model
> elements with ECL, that I might want to recalculate overall similarity
> measures for the remaining element pairs in my model. Trouble is, I
> can't remember why this is so. Could you please refresh my memory?
I think I was referring to recalculating matches whenever the user
establishes an explicit (i.e. manual) match - if that's supported by
Mirador.
>
> Many thanks,
> --Stephen
>
Cheers,
Dimitris
|
|
| |
| Re: Accessing MapInfo structure from ECL [message #590512 is a reply to message #545160] |
Tue, 06 July 2010 16:24 |
| Eclipse User |
|
|
|
Hi Stephen,
Suppose that you're comparing trees and you have the following sample trees:
[a]
-- [b]
and
[c]
-- [b]
and the following rule
rule MatchTrees
match l : Left!Tree
with r : Right!Tree {
compare : l.label = r.label and
l.parent.matches(r.parent)
}
In the initial comparison, the two [b]'s won't match because their
parents don't match ([a] <> [c]). However, if the user explicitly
declares that [a] matches with [c] then the two [b]'s should now match.
Does this make any sense?
Cheers,
Dimitris
On 06/07/2010 21:07, Stephen Barrett wrote:
>> I think I was referring to recalculating matches whenever the user
>> establishes an explicit (i.e. manual) match - if that's supported by
>> Mirador.
>
> Yes, that's what you were referring to. So, I suppose, my real question
> is, why do you think a recalculation might be needed? And by
> recalculation, I assume you mean redoing all the element similarity
> measures, and then rematching the elements based on the new measures. Is
> that accurate?
>
> Regards,
> --Stephen
|
|
| |
Goto Forum:
Current Time: Wed Jul 23 10:55:32 EDT 2025
Powered by FUDForum. Page generated in 0.31076 seconds |
Home