Eclipse Community Forums: EMF "Technology" (Ecore Tools, EMFatic, etc) » [EMF Compare] Innacuracies while comparing lists of very similar elements

Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc) » [EMF Compare] Innacuracies while comparing lists of very similar elements

[EMF Compare] Innacuracies while comparing lists of very similar elements [message #123712]

Thu, 29 May 2008 12:49

Eclipse User

Sorry to bother again about EMF Compare. I hope to help while reporting
my findings.

Try to imagine a multivalued referenced with lots of referenced
children. These elements are simple named elements. Take a look at the
following example (I'll put just 2 lists of names of these elements):

ELEMENT01 -- ELEMENT01
ELEMENT02 -- ELEMENT02
ELEMENT03 -- ELEMENT03
ELEMENT04 -- ELEMENT04
ELEMENT05 -- ELEMENT05
ELEMENT06 -- ELEMENT06
ELEMENT07 -- ELEMENT07

If I remove one element from the second EReference:

ELEMENT01 -- ELEMENT01
ELEMENT02 -- ELEMENT02
ELEMENT03 -- .........
ELEMENT04 -- ELEMENT04
ELEMENT05 -- ELEMENT05
ELEMENT06 -- ELEMENT06
ELEMENT07 -- ELEMENT07

The comparison will result in (its an example, but happens most of the
times):

ELEMENT01 -- ELEMENT01 <match>
ELEMENT02 -- ELEMENT02 <match>
ELEMENT03 -- ......... <deleted>
ELEMENT04 -- ELEMENT05 <modified>
ELEMENT05 -- ELEMENT06 <modified>
ELEMENT06 -- ELEMENT04 <modified>
ELEMENT07 -- ELEMENT07 <match>

This is just an example situation, but as you can see, the engine tries
to match elements in the same position, and gets a high similarity score
(since these elements are very similar, even in the name).

In my opinion, the engine should take a look in the neighborhood to
search for a perfect match. In case there is no perfect match, then it
could match those with the highest similarity score.

Cheers!

Víctor.

Re: [EMF Compare] Innacuracies while comparing lists of very similar elements [message #124040 is a reply to message #123712]

Fri, 30 May 2008 03:46

Eclipse User

This is a multi-part message in MIME format.
--------------080500040509030101030602
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

V

Re: [EMF Compare] Innacuracies while comparing lists of very similar elements [message #124053 is a reply to message #123712]

Fri, 30 May 2008 04:06

Eclipse User

Hi Víctor,

thanks for your feedback, you're not bothering us *at all* and the issues
you may encounter are likely to be encountered by other users not taking
the time to ask on the newsgroup, then thanks again :)

Cédric

Víctor Roldán Betancort wrote:

> Sorry to bother again about EMF Compare. I hope to help while reporting
> my findings.
>
> Try to imagine a multivalued referenced with lots of referenced
> children. These elements are simple named elements. Take a look at the
> following example (I'll put just 2 lists of names of these elements):
>
> ELEMENT01 -- ELEMENT01
> ELEMENT02 -- ELEMENT02
> ELEMENT03 -- ELEMENT03
> ELEMENT04 -- ELEMENT04
> ELEMENT05 -- ELEMENT05
> ELEMENT06 -- ELEMENT06
> ELEMENT07 -- ELEMENT07
>
> If I remove one element from the second EReference:
>
> ELEMENT01 -- ELEMENT01
> ELEMENT02 -- ELEMENT02
> ELEMENT03 -- .........
> ELEMENT04 -- ELEMENT04
> ELEMENT05 -- ELEMENT05
> ELEMENT06 -- ELEMENT06
> ELEMENT07 -- ELEMENT07
>
> The comparison will result in (its an example, but happens most of the
> times):
>
> ELEMENT01 -- ELEMENT01 <match>
> ELEMENT02 -- ELEMENT02 <match>
> ELEMENT03 -- ......... <deleted>
> ELEMENT04 -- ELEMENT05 <modified>
> ELEMENT05 -- ELEMENT06 <modified>
> ELEMENT06 -- ELEMENT04 <modified>
> ELEMENT07 -- ELEMENT07 <match>
>
> This is just an example situation, but as you can see, the engine tries
> to match elements in the same position, and gets a high similarity score
> (since these elements are very similar, even in the name).
>
> In my opinion, the engine should take a look in the neighborhood to
> search for a perfect match. In case there is no perfect match, then it
> could match those with the highest similarity score.
>
> Cheers!
>
> Víctor.

Re: [EMF Compare] Innacuracies while comparing lists of very similar elements [message #124800 is a reply to message #124053]

Mon, 02 June 2008 05:39

Eclipse User

This is a multi-part message in MIME format.
--------------070408040506040808080108
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi Víctor,

I took some time to tests this and couldn't reproduce your behavior with
the latest version of EMF Compare (0.8RC2 as I write this). My test case
was a simple ecore model with classes named ELEMENTx as you outlined in
your example, then deleting class ELEMENT3 was detected accurately by
EMF Compare. The same occured with EEnumLiterals named LITERALxx ... The
elements' name was the only thing I modified for this test.

Which version of Eclipse/EMF Compare are you using to reproduce this
bug? And can you provide us with the models you were comparing if they
do not contain any confidential information (preferred form is of course
a bug on Eclipse bugzilla ;)).

Laurent Goubet
Obeo

Cédric Brun a écrit :
> Hi Víctor,
>
> thanks for your feedback, you're not bothering us *at all* and the issues
> you may encounter are likely to be encountered by other users not taking
> the time to ask on the newsgroup, then thanks again :)
>
> Cédric
>
> Víctor Roldán Betancort wrote:
>
>> Sorry to bother again about EMF Compare. I hope to help while reporting
>> my findings.
>>
>> Try to imagine a multivalued referenced with lots of referenced
>> children. These elements are simple named elements. Take a look at the
>> following example (I'll put just 2 lists of names of these elements):
>>
>> ELEMENT01 -- ELEMENT01
>> ELEMENT02 -- ELEMENT02
>> ELEMENT03 -- ELEMENT03
>> ELEMENT04 -- ELEMENT04
>> ELEMENT05 -- ELEMENT05
>> ELEMENT06 -- ELEMENT06
>> ELEMENT07 -- ELEMENT07
>>
>> If I remove one element from the second EReference:
>>
>> ELEMENT01 -- ELEMENT01
>> ELEMENT02 -- ELEMENT02
>> ELEMENT03 -- .........
>> ELEMENT04 -- ELEMENT04
>> ELEMENT05 -- ELEMENT05
>> ELEMENT06 -- ELEMENT06
>> ELEMENT07 -- ELEMENT07
>>
>> The comparison will result in (its an example, but happens most of the
>> times):
>>
>> ELEMENT01 -- ELEMENT01 <match>
>> ELEMENT02 -- ELEMENT02 <match>
>> ELEMENT03 -- ......... <deleted>
>> ELEMENT04 -- ELEMENT05 <modified>
>> ELEMENT05 -- ELEMENT06 <modified>
>> ELEMENT06 -- ELEMENT04 <modified>
>> ELEMENT07 -- ELEMENT07 <match>
>>
>> This is just an example situation, but as you can see, the engine tries
>> to match elements in the same position, and gets a high similarity score
>> (since these elements are very similar, even in the name).
>>
>> In my opinion, the engine should take a look in the neighborhood to
>> search for a perfect match. In case there is no perfect match, then it
>> could match those with the highest similarity score.
>>
>> Cheers!
>>
>> Víctor.
>

--------------070408040506040808080108
Content-Type: text/x-vcard; charset=utf-8;
name="laurent_goubet.vcf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="laurent_goubet.vcf"

YmVnaW46dmNhcmQNCmZuOkxhdXJlbnQgR291YmV0DQpuOkdvdWJldDtMYXVy ZW50DQpvcmc6
PGEgaHJlZj0iaHR0cDovL3d3dy5vYmVvLmZyLyI+T2JlbzwvYT4NCmVtYWls O2ludGVybmV0
OmxhdXJlbnQuZ291YmV0QG9iZW8uZnINCnVybDpodHRwOi8vd3d3Lm9iZW8u ZnINCnZlcnNp
b246Mi4xDQplbmQ6dmNhcmQNCg0K
--------------070408040506040808080108--

Re: [EMF Compare] Innacuracies while comparing lists of very similar elements [message #124859 is a reply to message #124800]

Mon, 02 June 2008 07:15

Eclipse User

Laurent,

I think I must have correct one premise I posted in first instance:
these model elements aren't just plain elements, I mean, these element
weren't just classes with attributes, but rather classes with a mix of
attribs and references to other elements. Furthermore, another
characteristic I see is that these elements are part of a particular
hierarchy of EClasses. Using the original example, this would mean that
"ELEMENTx" is inherits from a somehow complex inheritance tree (lets
say, for instance, something like ELEMENTBASE -> ELEMENTABSTRACT -> ...
-> ELEMENT).

I'm using bleeding-edge stuff (All RC2 that's available). Using EMF
Compare 0.8RC2.

Unfortunately, as you say, the models I'm working on have confidential
information. I'll elaborate an "open source" clone of these
"confidential models" so I can provide it to you as test case ;) ;)

Regards,
Víctor.

laurent Goubet escribió:
> Hi Víctor,
>
> I took some time to tests this and couldn't reproduce your behavior with
> the latest version of EMF Compare (0.8RC2 as I write this). My test case
> was a simple ecore model with classes named ELEMENTx as you outlined in
> your example, then deleting class ELEMENT3 was detected accurately by
> EMF Compare. The same occured with EEnumLiterals named LITERALxx ... The
> elements' name was the only thing I modified for this test.
>
> Which version of Eclipse/EMF Compare are you using to reproduce this
> bug? And can you provide us with the models you were comparing if they
> do not contain any confidential information (preferred form is of course
> a bug on Eclipse bugzilla ;)).
>
> Laurent Goubet
> Obeo
>
> Cédric Brun a écrit :
>> Hi Víctor,
>>
>> thanks for your feedback, you're not bothering us *at all* and the issues
>> you may encounter are likely to be encountered by other users not taking
>> the time to ask on the newsgroup, then thanks again :)
>>
>> Cédric
>>
>> Víctor Roldán Betancort wrote:
>>
>>> Sorry to bother again about EMF Compare. I hope to help while reporting
>>> my findings.
>>>
>>> Try to imagine a multivalued referenced with lots of referenced
>>> children. These elements are simple named elements. Take a look at the
>>> following example (I'll put just 2 lists of names of these elements):
>>>
>>> ELEMENT01 -- ELEMENT01
>>> ELEMENT02 -- ELEMENT02
>>> ELEMENT03 -- ELEMENT03
>>> ELEMENT04 -- ELEMENT04
>>> ELEMENT05 -- ELEMENT05
>>> ELEMENT06 -- ELEMENT06
>>> ELEMENT07 -- ELEMENT07
>>>
>>> If I remove one element from the second EReference:
>>>
>>> ELEMENT01 -- ELEMENT01
>>> ELEMENT02 -- ELEMENT02
>>> ELEMENT03 -- .........
>>> ELEMENT04 -- ELEMENT04
>>> ELEMENT05 -- ELEMENT05
>>> ELEMENT06 -- ELEMENT06
>>> ELEMENT07 -- ELEMENT07
>>>
>>> The comparison will result in (its an example, but happens most of the
>>> times):
>>>
>>> ELEMENT01 -- ELEMENT01 <match>
>>> ELEMENT02 -- ELEMENT02 <match>
>>> ELEMENT03 -- ......... <deleted>
>>> ELEMENT04 -- ELEMENT05 <modified>
>>> ELEMENT05 -- ELEMENT06 <modified>
>>> ELEMENT06 -- ELEMENT04 <modified>
>>> ELEMENT07 -- ELEMENT07 <match>
>>>
>>> This is just an example situation, but as you can see, the engine tries
>>> to match elements in the same position, and gets a high similarity score
>>> (since these elements are very similar, even in the name).
>>>
>>> In my opinion, the engine should take a look in the neighborhood to
>>> search for a perfect match. In case there is no perfect match, then it
>>> could match those with the highest similarity score.
>>>
>>> Cheers!
>>>
>>> Víctor.
>>
>

Re: [EMF Compare] Innacuracies while comparing lists of very similar elements [message #124884 is a reply to message #124859]

Mon, 02 June 2008 07:39

Eclipse User

This is a multi-part message in MIME format.
--------------000109080502080507080501
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Thanks, will be waiting to try and fix these ;)

Laurent Goubet
Obeo

Víctor Roldán Betancort a écrit :
> Laurent,
>
> I think I must have correct one premise I posted in first instance:
> these model elements aren't just plain elements, I mean, these element
> weren't just classes with attributes, but rather classes with a mix of
> attribs and references to other elements. Furthermore, another
> characteristic I see is that these elements are part of a particular
> hierarchy of EClasses. Using the original example, this would mean that
> "ELEMENTx" is inherits from a somehow complex inheritance tree (lets
> say, for instance, something like ELEMENTBASE -> ELEMENTABSTRACT -> ...
> -> ELEMENT).
>
> I'm using bleeding-edge stuff (All RC2 that's available). Using EMF
> Compare 0.8RC2.
>
> Unfortunately, as you say, the models I'm working on have confidential
> information. I'll elaborate an "open source" clone of these
> "confidential models" so I can provide it to you as test case ;) ;)
>
> Regards,
> Víctor.
>
> laurent Goubet escribió:
>> Hi Víctor,
>>
>> I took some time to tests this and couldn't reproduce your behavior
>> with the latest version of EMF Compare (0.8RC2 as I write this). My
>> test case was a simple ecore model with classes named ELEMENTx as you
>> outlined in your example, then deleting class ELEMENT3 was detected
>> accurately by EMF Compare. The same occured with EEnumLiterals named
>> LITERALxx ... The elements' name was the only thing I modified for
>> this test.
>>
>> Which version of Eclipse/EMF Compare are you using to reproduce this
>> bug? And can you provide us with the models you were comparing if they
>> do not contain any confidential information (preferred form is of
>> course a bug on Eclipse bugzilla ;)).
>>
>> Laurent Goubet
>> Obeo
>>
>> Cédric Brun a écrit :
>>> Hi Víctor,
>>>
>>> thanks for your feedback, you're not bothering us *at all* and the
>>> issues
>>> you may encounter are likely to be encountered by other users not taking
>>> the time to ask on the newsgroup, then thanks again :)
>>>
>>> Cédric
>>>
>>> Víctor Roldán Betancort wrote:
>>>
>>>> Sorry to bother again about EMF Compare. I hope to help while reporting
>>>> my findings.
>>>>
>>>> Try to imagine a multivalued referenced with lots of referenced
>>>> children. These elements are simple named elements. Take a look at the
>>>> following example (I'll put just 2 lists of names of these elements):
>>>>
>>>> ELEMENT01 -- ELEMENT01
>>>> ELEMENT02 -- ELEMENT02
>>>> ELEMENT03 -- ELEMENT03
>>>> ELEMENT04 -- ELEMENT04
>>>> ELEMENT05 -- ELEMENT05
>>>> ELEMENT06 -- ELEMENT06
>>>> ELEMENT07 -- ELEMENT07
>>>>
>>>> If I remove one element from the second EReference:
>>>>
>>>> ELEMENT01 -- ELEMENT01
>>>> ELEMENT02 -- ELEMENT02
>>>> ELEMENT03 -- .........
>>>> ELEMENT04 -- ELEMENT04
>>>> ELEMENT05 -- ELEMENT05
>>>> ELEMENT06 -- ELEMENT06
>>>> ELEMENT07 -- ELEMENT07
>>>>
>>>> The comparison will result in (its an example, but happens most of the
>>>> times):
>>>>
>>>> ELEMENT01 -- ELEMENT01 <match>
>>>> ELEMENT02 -- ELEMENT02 <match>
>>>> ELEMENT03 -- ......... <deleted>
>>>> ELEMENT04 -- ELEMENT05 <modified>
>>>> ELEMENT05 -- ELEMENT06 <modified>
>>>> ELEMENT06 -- ELEMENT04 <modified>
>>>> ELEMENT07 -- ELEMENT07 <match>
>>>>
>>>> This is just an example situation, but as you can see, the engine tries
>>>> to match elements in the same position, and gets a high similarity
>>>> score
>>>> (since these elements are very similar, even in the name).
>>>>
>>>> In my opinion, the engine should take a look in the neighborhood to
>>>> search for a perfect match. In case there is no perfect match, then it
>>>> could match those with the highest similarity score.
>>>>
>>>> Cheers!
>>>>
>>>> Víctor.
>>>
>>

--------------000109080502080507080501
Content-Type: text/x-vcard; charset=utf-8;
name="laurent_goubet.vcf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="laurent_goubet.vcf"

YmVnaW46dmNhcmQNCmZuOkxhdXJlbnQgR291YmV0DQpuOkdvdWJldDtMYXVy ZW50DQpvcmc6
PGEgaHJlZj0iaHR0cDovL3d3dy5vYmVvLmZyLyI+T2JlbzwvYT4NCmVtYWls O2ludGVybmV0
OmxhdXJlbnQuZ291YmV0QG9iZW8uZnINCnVybDpodHRwOi8vd3d3Lm9iZW8u ZnINCnZlcnNp
b246Mi4xDQplbmQ6dmNhcmQNCg0K
--------------000109080502080507080501--

Re: [EMF Compare] Innacuracies while comparing lists of very similar elements [message #124924 is a reply to message #124884]

Mon, 02 June 2008 08:48

Eclipse User

Ok, got to reproduce it in a test metamodel. Should I open a bugzilla
and attach the files , or...?

laurent Goubet escribió:
> Thanks, will be waiting to try and fix these ;)
>
> Laurent Goubet
> Obeo
>
> Víctor Roldán Betancort a écrit :
>> Laurent,
>>
>> I think I must have correct one premise I posted in first instance:
>> these model elements aren't just plain elements, I mean, these element
>> weren't just classes with attributes, but rather classes with a mix of
>> attribs and references to other elements. Furthermore, another
>> characteristic I see is that these elements are part of a particular
>> hierarchy of EClasses. Using the original example, this would mean
>> that "ELEMENTx" is inherits from a somehow complex inheritance tree
>> (lets say, for instance, something like ELEMENTBASE -> ELEMENTABSTRACT
>> -> ... -> ELEMENT).
>>
>> I'm using bleeding-edge stuff (All RC2 that's available). Using EMF
>> Compare 0.8RC2.
>>
>> Unfortunately, as you say, the models I'm working on have confidential
>> information. I'll elaborate an "open source" clone of these
>> "confidential models" so I can provide it to you as test case ;) ;)
>>
>> Regards,
>> Víctor.
>>
>> laurent Goubet escribió:
>>> Hi Víctor,
>>>
>>> I took some time to tests this and couldn't reproduce your behavior
>>> with the latest version of EMF Compare (0.8RC2 as I write this). My
>>> test case was a simple ecore model with classes named ELEMENTx as you
>>> outlined in your example, then deleting class ELEMENT3 was detected
>>> accurately by EMF Compare. The same occured with EEnumLiterals named
>>> LITERALxx ... The elements' name was the only thing I modified for
>>> this test.
>>>
>>> Which version of Eclipse/EMF Compare are you using to reproduce this
>>> bug? And can you provide us with the models you were comparing if
>>> they do not contain any confidential information (preferred form is
>>> of course a bug on Eclipse bugzilla ;)).
>>>
>>> Laurent Goubet
>>> Obeo
>>>
>>> Cédric Brun a écrit :
>>>> Hi Víctor,
>>>>
>>>> thanks for your feedback, you're not bothering us *at all* and the
>>>> issues
>>>> you may encounter are likely to be encountered by other users not
>>>> taking
>>>> the time to ask on the newsgroup, then thanks again :)
>>>>
>>>> Cédric
>>>>
>>>> Víctor Roldán Betancort wrote:
>>>>
>>>>> Sorry to bother again about EMF Compare. I hope to help while
>>>>> reporting
>>>>> my findings.
>>>>>
>>>>> Try to imagine a multivalued referenced with lots of referenced
>>>>> children. These elements are simple named elements. Take a look at the
>>>>> following example (I'll put just 2 lists of names of these elements):
>>>>>
>>>>> ELEMENT01 -- ELEMENT01
>>>>> ELEMENT02 -- ELEMENT02
>>>>> ELEMENT03 -- ELEMENT03
>>>>> ELEMENT04 -- ELEMENT04
>>>>> ELEMENT05 -- ELEMENT05
>>>>> ELEMENT06 -- ELEMENT06
>>>>> ELEMENT07 -- ELEMENT07
>>>>>
>>>>> If I remove one element from the second EReference:
>>>>>
>>>>> ELEMENT01 -- ELEMENT01
>>>>> ELEMENT02 -- ELEMENT02
>>>>> ELEMENT03 -- .........
>>>>> ELEMENT04 -- ELEMENT04
>>>>> ELEMENT05 -- ELEMENT05
>>>>> ELEMENT06 -- ELEMENT06
>>>>> ELEMENT07 -- ELEMENT07
>>>>>
>>>>> The comparison will result in (its an example, but happens most of the
>>>>> times):
>>>>>
>>>>> ELEMENT01 -- ELEMENT01 <match>
>>>>> ELEMENT02 -- ELEMENT02 <match>
>>>>> ELEMENT03 -- ......... <deleted>
>>>>> ELEMENT04 -- ELEMENT05 <modified>
>>>>> ELEMENT05 -- ELEMENT06 <modified>
>>>>> ELEMENT06 -- ELEMENT04 <modified>
>>>>> ELEMENT07 -- ELEMENT07 <match>
>>>>>
>>>>> This is just an example situation, but as you can see, the engine
>>>>> tries
>>>>> to match elements in the same position, and gets a high similarity
>>>>> score
>>>>> (since these elements are very similar, even in the name).
>>>>>
>>>>> In my opinion, the engine should take a look in the neighborhood to
>>>>> search for a perfect match. In case there is no perfect match, then it
>>>>> could match those with the highest similarity score.
>>>>>
>>>>> Cheers!
>>>>>
>>>>> Víctor.
>>>>
>>>
>

Re: [EMF Compare] Innacuracies while comparing lists of very similar elements [message #124936 is a reply to message #124924]

Mon, 02 June 2008 08:50

Eclipse User

This is a multi-part message in MIME format.
--------------000100020104050708010102
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Yes, bugzilla will be easier to track evolutions of this.

Thanks!

Laurent Goubet
Obeo

Víctor Roldán Betancort a écrit :
> Ok, got to reproduce it in a test metamodel. Should I open a bugzilla
> and attach the files , or...?
>
> laurent Goubet escribió:
>> Thanks, will be waiting to try and fix these ;)
>>
>> Laurent Goubet
>> Obeo
>>
>> Víctor Roldán Betancort a écrit :
>>> Laurent,
>>>
>>> I think I must have correct one premise I posted in first instance:
>>> these model elements aren't just plain elements, I mean, these
>>> element weren't just classes with attributes, but rather classes with
>>> a mix of attribs and references to other elements. Furthermore,
>>> another characteristic I see is that these elements are part of a
>>> particular hierarchy of EClasses. Using the original example, this
>>> would mean that "ELEMENTx" is inherits from a somehow complex
>>> inheritance tree (lets say, for instance, something like ELEMENTBASE
>>> -> ELEMENTABSTRACT -> ... -> ELEMENT).
>>>
>>> I'm using bleeding-edge stuff (All RC2 that's available). Using EMF
>>> Compare 0.8RC2.
>>>
>>> Unfortunately, as you say, the models I'm working on have
>>> confidential information. I'll elaborate an "open source" clone of
>>> these "confidential models" so I can provide it to you as test case
>>> ;) ;)
>>>
>>> Regards,
>>> Víctor.
>>>
>>> laurent Goubet escribió:
>>>> Hi Víctor,
>>>>
>>>> I took some time to tests this and couldn't reproduce your behavior
>>>> with the latest version of EMF Compare (0.8RC2 as I write this). My
>>>> test case was a simple ecore model with classes named ELEMENTx as
>>>> you outlined in your example, then deleting class ELEMENT3 was
>>>> detected accurately by EMF Compare. The same occured with
>>>> EEnumLiterals named LITERALxx ... The elements' name was the only
>>>> thing I modified for this test.
>>>>
>>>> Which version of Eclipse/EMF Compare are you using to reproduce this
>>>> bug? And can you provide us with the models you were comparing if
>>>> they do not contain any confidential information (preferred form is
>>>> of course a bug on Eclipse bugzilla ;)).
>>>>
>>>> Laurent Goubet
>>>> Obeo
>>>>
>>>> Cédric Brun a écrit :
>>>>> Hi Víctor,
>>>>>
>>>>> thanks for your feedback, you're not bothering us *at all* and the
>>>>> issues
>>>>> you may encounter are likely to be encountered by other users not
>>>>> taking
>>>>> the time to ask on the newsgroup, then thanks again :)
>>>>>
>>>>> Cédric
>>>>>
>>>>> Víctor Roldán Betancort wrote:
>>>>>
>>>>>> Sorry to bother again about EMF Compare. I hope to help while
>>>>>> reporting
>>>>>> my findings.
>>>>>>
>>>>>> Try to imagine a multivalued referenced with lots of referenced
>>>>>> children. These elements are simple named elements. Take a look at
>>>>>> the
>>>>>> following example (I'll put just 2 lists of names of these elements):
>>>>>>
>>>>>> ELEMENT01 -- ELEMENT01
>>>>>> ELEMENT02 -- ELEMENT02
>>>>>> ELEMENT03 -- ELEMENT03
>>>>>> ELEMENT04 -- ELEMENT04
>>>>>> ELEMENT05 -- ELEMENT05
>>>>>> ELEMENT06 -- ELEMENT06
>>>>>> ELEMENT07 -- ELEMENT07
>>>>>>
>>>>>> If I remove one element from the second EReference:
>>>>>>
>>>>>> ELEMENT01 -- ELEMENT01
>>>>>> ELEMENT02 -- ELEMENT02
>>>>>> ELEMENT03 -- .........
>>>>>> ELEMENT04 -- ELEMENT04
>>>>>> ELEMENT05 -- ELEMENT05
>>>>>> ELEMENT06 -- ELEMENT06
>>>>>> ELEMENT07 -- ELEMENT07
>>>>>>
>>>>>> The comparison will result in (its an example, but happens most of
>>>>>> the
>>>>>> times):
>>>>>>
>>>>>> ELEMENT01 -- ELEMENT01 <match>
>>>>>> ELEMENT02 -- ELEMENT02 <match>
>>>>>> ELEMENT03 -- ......... <deleted>
>>>>>> ELEMENT04 -- ELEMENT05 <modified>
>>>>>> ELEMENT05 -- ELEMENT06 <modified>
>>>>>> ELEMENT06 -- ELEMENT04 <modified>
>>>>>> ELEMENT07 -- ELEMENT07 <match>
>>>>>>
>>>>>> This is just an example situation, but as you can see, the engine
>>>>>> tries
>>>>>> to match elements in the same position, and gets a high similarity
>>>>>> score
>>>>>> (since these elements are very similar, even in the name).
>>>>>>
>>>>>> In my opinion, the engine should take a look in the neighborhood to
>>>>>> search for a perfect match. In case there is no perfect match,
>>>>>> then it
>>>>>> could match those with the highest similarity score.
>>>>>>
>>>>>> Cheers!
>>>>>>
>>>>>> Víctor.
>>>>>
>>>>
>>

--------------000100020104050708010102
Content-Type: text/x-vcard; charset=utf-8;
name="laurent_goubet.vcf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="laurent_goubet.vcf"

YmVnaW46dmNhcmQNCmZuOkxhdXJlbnQgR291YmV0DQpuOkdvdWJldDtMYXVy ZW50DQpvcmc6
PGEgaHJlZj0iaHR0cDovL3d3dy5vYmVvLmZyLyI+T2JlbzwvYT4NCmVtYWls O2ludGVybmV0
OmxhdXJlbnQuZ291YmV0QG9iZW8uZnINCnVybDpodHRwOi8vd3d3Lm9iZW8u ZnINCnZlcnNp
b246Mi4xDQplbmQ6dmNhcmQNCg0K
--------------000100020104050708010102--

Re: [EMF Compare] Innacuracies while comparing lists of very similar elements [message #619095 is a reply to message #123712]

Fri, 30 May 2008 03:46

Eclipse User

This is a multi-part message in MIME format.
--------------080500040509030101030602
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

V

Re: [EMF Compare] Innacuracies while comparing lists of very similar elements [message #619096 is a reply to message #123712]

Fri, 30 May 2008 04:06

Eclipse User