Home » Modeling » Epsilon » Accessing MapInfo structure from ECL(Writing data from within a compare)
| | | | |
Re: Accessing MapInfo structure from ECL [message #544891 is a reply to message #544888] |
Mon, 05 July 2010 22:20 |
Dimitrios Kolovos Messages: 1776 Registered: July 2009 |
Senior Member |
|
|
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 20:24 |
Dimitrios Kolovos Messages: 1776 Registered: July 2009 |
Senior Member |
|
|
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 22:20 |
Dimitrios Kolovos Messages: 1776 Registered: July 2009 |
Senior Member |
|
|
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 20:24 |
Dimitrios Kolovos Messages: 1776 Registered: July 2009 |
Senior Member |
|
|
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: Fri Apr 26 14:04:02 GMT 2024
Powered by FUDForum. Page generated in 0.03695 seconds
|