Reltio Connect

If we update the physical configuration so that the not a match is reset for 'ANY_MATCHING_ATTRIBUTE' is there a way to prevent two entities from being matched even if one is updated? Basically we would want the default behavior to be that records would be re-evaluated if matching fields are updated (in case there isn't enough information for a definitive decision) , unless a steward already determined the two records were distinct and don't need to look at the records again.  Thank you!

------------------------------
Ed Mosier
Slalom
MO
------------------------------

Hello Ed,

Have you explored Negative match rules for this scenario? 

The negative rule has the same architecture as a rule but has the special behavior that if it evaluates to true, it will demote any directive of merge coming from another match group to queue for review. To be sure, most match groups across most configurations use a rule for most matching goals. But in some situations, it can be advantageous to additionally dedicate one or more match groups to supporting a negative rule to stop a merge based on usually a single condition. And when the condition is met, the negative rule prevents any other rule from merging the records. So in practice, you might have seven match groups each of which use a rule, while the eighth group uses a negative rule.

Note: A match group can have a rule or a negative rule. It cannot have both

You can find more information on this here

Thanks,

Shantanu

------------------------------
Shantanu Indra
------------------------------

Original Message:
Sent: 07-08-2021 18:09
From: Ed Mosier
Subject: Way to exclude entities from matching if not a match is set to ANY_MATCHING_ATTRIBUTE?

If we update the physical configuration so that the not a match is reset for 'ANY_MATCHING_ATTRIBUTE' is there a way to prevent two entities from being matched even if one is updated? Basically we would want the default behavior to be that records would be re-evaluated if matching fields are updated (in case there isn't enough information for a definitive decision) , unless a steward already determined the two records were distinct and don't need to look at the records again.  Thank you!

------------------------------
Ed Mosier
Slalom
MO
------------------------------

Hi Ed,

perhaps I am missing something, but isn't this the default behavior?  When records are updated, they are re-evaluated to see if they are a match.  If a record has been declared not a match by a data steward it remains not a match.  The only way that the records are usually marked as 'not a match' is if a data steward has declared that to be the case via the UI.

gino

------------------------------
Gino Fortunato
Senior Solution Engineer
Reltio
------------------------------

Original Message:
Sent: 07-08-2021 18:09
From: Ed Mosier
Subject: Way to exclude entities from matching if not a match is set to ANY_MATCHING_ATTRIBUTE?

If we update the physical configuration so that the not a match is reset for 'ANY_MATCHING_ATTRIBUTE' is there a way to prevent two entities from being matched even if one is updated? Basically we would want the default behavior to be that records would be re-evaluated if matching fields are updated (in case there isn't enough information for a definitive decision) , unless a steward already determined the two records were distinct and don't need to look at the records again.  Thank you!

------------------------------
Ed Mosier
Slalom
MO
------------------------------

Gino,  

I'll see if I can describe the scenario a little better.  If the configuration is set up to re-evaluate for matches as they are updated and two records are deemed to be suspect matches.  Is there a way to give stewards two options:

1.   Mark as 'not a match', which would prevent the two from being matched again.
2.   Close the task so that the records are not merged, but if either record is updated the two could potentially be matched again. 

Option 1 would used when there is enough information to determine the two entities are distinct. 
Option 2 would be used when there is not enough information to make a definitive determination.  

Hope this helps. 

Ed

------------------------------
Ed Mosier
Slalom
MO
------------------------------

Original Message:
Sent: 07-14-2021 10:10
From: Gino Fortunato
Subject: Way to exclude entities from matching if not a match is set to ANY_MATCHING_ATTRIBUTE?

Hi Ed,

perhaps I am missing something, but isn't this the default behavior?  When records are updated, they are re-evaluated to see if they are a match.  If a record has been declared not a match by a data steward it remains not a match.  The only way that the records are usually marked as 'not a match' is if a data steward has declared that to be the case via the UI.

gino

------------------------------
Gino Fortunato
Senior Solution Engineer
Reltio

Original Message:
Sent: 07-08-2021 18:09
From: Ed Mosier
Subject: Way to exclude entities from matching if not a match is set to ANY_MATCHING_ATTRIBUTE?

If we update the physical configuration so that the not a match is reset for 'ANY_MATCHING_ATTRIBUTE' is there a way to prevent two entities from being matched even if one is updated? Basically we would want the default behavior to be that records would be re-evaluated if matching fields are updated (in case there isn't enough information for a definitive decision) , unless a steward already determined the two records were distinct and don't need to look at the records again.  Thank you!

------------------------------
Ed Mosier
Slalom
MO
------------------------------

We are too abstract for my brain :-)

Let me see if an example helps.  ABC Co (entity A) is matched with ABC Company (entity B).  Due to other information, the data steward marks this as not a match.  Per the documentation at https://docs.reltio.com/matchmerge/resetmatch.html,  when ANY_MATCHING_ATTRIBUTE is used: To remove (from do not match pair list) if any matching attribute is changed. Here ANY_MATCHING_ATTRIBUTE means that for any attribute participating in a match rule update, the flag is reset.

Then an attribute used in matching is updated.  We want the match to be re-evaluated.  Lets say that this new evaluation comes back with a match.  The data steward is presented with the same choice as before.  If the data steward keeps marking the re-evaluation(s) as 'not a match' then we are in a loop.  But perhaps one of these changes actually makes it clear to the data steward that entities A and B are the same.  Then they are marked a match and the loop ends.  Are we looking for a different outcome?  If so, what would the expectation be?




------------------------------
Gino Fortunato
Senior Solution Engineer
Reltio
------------------------------

Original Message:
Sent: 07-14-2021 10:27
From: Ed Mosier
Subject: Way to exclude entities from matching if not a match is set to ANY_MATCHING_ATTRIBUTE?

Gino,  

I'll see if I can describe the scenario a little better.  If the configuration is set up to re-evaluate for matches as they are updated and two records are deemed to be suspect matches.  Is there a way to give stewards two options:

1.   Mark as 'not a match', which would prevent the two from being matched again.
2.   Close the task so that the records are not merged, but if either record is updated the two could potentially be matched again. 

Option 1 would used when there is enough information to determine the two entities are distinct. 
Option 2 would be used when there is not enough information to make a definitive determination.  

Hope this helps. 

Ed

------------------------------
Ed Mosier
Slalom
MO

Original Message:
Sent: 07-14-2021 10:10
From: Gino Fortunato
Subject: Way to exclude entities from matching if not a match is set to ANY_MATCHING_ATTRIBUTE?

Hi Ed,

perhaps I am missing something, but isn't this the default behavior?  When records are updated, they are re-evaluated to see if they are a match.  If a record has been declared not a match by a data steward it remains not a match.  The only way that the records are usually marked as 'not a match' is if a data steward has declared that to be the case via the UI.

gino

------------------------------
Gino Fortunato
Senior Solution Engineer
Reltio

Original Message:
Sent: 07-08-2021 18:09
From: Ed Mosier
Subject: Way to exclude entities from matching if not a match is set to ANY_MATCHING_ATTRIBUTE?

If we update the physical configuration so that the not a match is reset for 'ANY_MATCHING_ATTRIBUTE' is there a way to prevent two entities from being matched even if one is updated? Basically we would want the default behavior to be that records would be re-evaluated if matching fields are updated (in case there isn't enough information for a definitive decision) , unless a steward already determined the two records were distinct and don't need to look at the records again.  Thank you!

------------------------------
Ed Mosier
Slalom
MO
------------------------------

In your scenario, I'm looking for another possible outcome.  Given everything you stated,  I'd like to understand how you can  get out of the loop if the steward determines the two are actually different people and don't want to keep reviewing entities A and B as they are updated?






------------------------------
Ed Mosier
Slalom
MO
------------------------------

Original Message:
Sent: 07-15-2021 00:56
From: Gino Fortunato
Subject: Way to exclude entities from matching if not a match is set to ANY_MATCHING_ATTRIBUTE?

We are too abstract for my brain :-)

Let me see if an example helps.  ABC Co (entity A) is matched with ABC Company (entity B).  Due to other information, the data steward marks this as not a match.  Per the documentation at https://docs.reltio.com/matchmerge/resetmatch.html,  when ANY_MATCHING_ATTRIBUTE is used: To remove (from do not match pair list) if any matching attribute is changed. Here ANY_MATCHING_ATTRIBUTE means that for any attribute participating in a match rule update, the flag is reset.

Then an attribute used in matching is updated.  We want the match to be re-evaluated.  Lets say that this new evaluation comes back with a match.  The data steward is presented with the same choice as before.  If the data steward keeps marking the re-evaluation(s) as 'not a match' then we are in a loop.  But perhaps one of these changes actually makes it clear to the data steward that entities A and B are the same.  Then they are marked a match and the loop ends.  Are we looking for a different outcome?  If so, what would the expectation be?




------------------------------
Gino Fortunato
Senior Solution Engineer
Reltio

Original Message:
Sent: 07-14-2021 10:27
From: Ed Mosier
Subject: Way to exclude entities from matching if not a match is set to ANY_MATCHING_ATTRIBUTE?

Gino,  

I'll see if I can describe the scenario a little better.  If the configuration is set up to re-evaluate for matches as they are updated and two records are deemed to be suspect matches.  Is there a way to give stewards two options:

1.   Mark as 'not a match', which would prevent the two from being matched again.
2.   Close the task so that the records are not merged, but if either record is updated the two could potentially be matched again. 

Option 1 would used when there is enough information to determine the two entities are distinct. 
Option 2 would be used when there is not enough information to make a definitive determination.  

Hope this helps. 

Ed

------------------------------
Ed Mosier
Slalom
MO

Original Message:
Sent: 07-14-2021 10:10
From: Gino Fortunato
Subject: Way to exclude entities from matching if not a match is set to ANY_MATCHING_ATTRIBUTE?

Hi Ed,

perhaps I am missing something, but isn't this the default behavior?  When records are updated, they are re-evaluated to see if they are a match.  If a record has been declared not a match by a data steward it remains not a match.  The only way that the records are usually marked as 'not a match' is if a data steward has declared that to be the case via the UI.

gino

------------------------------
Gino Fortunato
Senior Solution Engineer
Reltio

Original Message:
Sent: 07-08-2021 18:09
From: Ed Mosier
Subject: Way to exclude entities from matching if not a match is set to ANY_MATCHING_ATTRIBUTE?

If we update the physical configuration so that the not a match is reset for 'ANY_MATCHING_ATTRIBUTE' is there a way to prevent two entities from being matched even if one is updated? Basically we would want the default behavior to be that records would be re-evaluated if matching fields are updated (in case there isn't enough information for a definitive decision) , unless a steward already determined the two records were distinct and don't need to look at the records again.  Thank you!

------------------------------
Ed Mosier
Slalom
MO
------------------------------

Original Message:
Sent: 7/15/2021 6:55:00 AM
From: Ed Mosier
Subject: RE: Way to exclude entities from matching if not a match is set to ANY_MATCHING_ATTRIBUTE?

In your scenario, I'm looking for another possible outcome.  Given everything you stated,  I'd like to understand how you can  get out of the loop if the steward determines the two are actually different people and don't want to keep reviewing entities A and B as they are updated?






------------------------------
Ed Mosier
Slalom
MO
------------------------------

Original Message:
Sent: 07-15-2021 00:56
From: Gino Fortunato
Subject: Way to exclude entities from matching if not a match is set to ANY_MATCHING_ATTRIBUTE?

We are too abstract for my brain :-)

Let me see if an example helps.  ABC Co (entity A) is matched with ABC Company (entity B).  Due to other information, the data steward marks this as not a match.  Per the documentation at https://docs.reltio.com/matchmerge/resetmatch.html,  when ANY_MATCHING_ATTRIBUTE is used: To remove (from do not match pair list) if any matching attribute is changed. Here ANY_MATCHING_ATTRIBUTE means that for any attribute participating in a match rule update, the flag is reset.

Then an attribute used in matching is updated.  We want the match to be re-evaluated.  Lets say that this new evaluation comes back with a match.  The data steward is presented with the same choice as before.  If the data steward keeps marking the re-evaluation(s) as 'not a match' then we are in a loop.  But perhaps one of these changes actually makes it clear to the data steward that entities A and B are the same.  Then they are marked a match and the loop ends.  Are we looking for a different outcome?  If so, what would the expectation be?




------------------------------
Gino Fortunato
Senior Solution Engineer
Reltio

Original Message:
Sent: 07-14-2021 10:27
From: Ed Mosier
Subject: Way to exclude entities from matching if not a match is set to ANY_MATCHING_ATTRIBUTE?

Gino,  

I'll see if I can describe the scenario a little better.  If the configuration is set up to re-evaluate for matches as they are updated and two records are deemed to be suspect matches.  Is there a way to give stewards two options:

1.   Mark as 'not a match', which would prevent the two from being matched again.
2.   Close the task so that the records are not merged, but if either record is updated the two could potentially be matched again. 

Option 1 would used when there is enough information to determine the two entities are distinct. 
Option 2 would be used when there is not enough information to make a definitive determination.  

Hope this helps. 

Ed

------------------------------
Ed Mosier
Slalom
MO

Original Message:
Sent: 07-14-2021 10:10
From: Gino Fortunato
Subject: Way to exclude entities from matching if not a match is set to ANY_MATCHING_ATTRIBUTE?

Hi Ed,

perhaps I am missing something, but isn't this the default behavior?  When records are updated, they are re-evaluated to see if they are a match.  If a record has been declared not a match by a data steward it remains not a match.  The only way that the records are usually marked as 'not a match' is if a data steward has declared that to be the case via the UI.

gino

------------------------------
Gino Fortunato
Senior Solution Engineer
Reltio

Original Message:
Sent: 07-08-2021 18:09
From: Ed Mosier
Subject: Way to exclude entities from matching if not a match is set to ANY_MATCHING_ATTRIBUTE?

If we update the physical configuration so that the not a match is reset for 'ANY_MATCHING_ATTRIBUTE' is there a way to prevent two entities from being matched even if one is updated? Basically we would want the default behavior to be that records would be re-evaluated if matching fields are updated (in case there isn't enough information for a definitive decision) , unless a steward already determined the two records were distinct and don't need to look at the records again.  Thank you!

------------------------------
Ed Mosier
Slalom
MO
------------------------------

Let's assume we make the configuration change so the records are reevaluated with data changes, which is probably what we would want in most cases. 

Is there a way out of the loop for entity A and entity B (without merging the records)? 

It sounds to me that the default behavior applies to all potential matches, meaning that if you say the two aren't a match, they won't be compared again.

------------------------------
Ed Mosier
Slalom
MO
------------------------------

Original Message:
Sent: 07-16-2021 00:49
From: Gino Fortunato
Subject: Way to exclude entities from matching if not a match is set to ANY_MATCHING_ATTRIBUTE?

Great question Ed.  As we discussed above, this is the default behavior: if no change is made in the environment then it will not be suggested again.

The 'limitation' of the default behavior is exactly that: how do you know the change to the record doesn't make it a duplicate?  Maybe it will, maybe it won't.  In my opinion, it seems like a situation where you can't have it both ways.  Either the data steward decision puts it to bed and a match is not suggested again (default behavior), or the record gets reevaluated after an update and again is potentially a match depending on that change(enabled by the new config settings).  Do you see a logical way to get both outcomes?

--

Gino Fortunato

Senior Solutions Engineer

e gino.fortunato@reltio.com

m 415.867.4195

   

w www.reltio.com | b blog.reltio.com

Original Message:
Sent: 7/15/2021 6:55:00 AM
From: Ed Mosier
Subject: RE: Way to exclude entities from matching if not a match is set to ANY_MATCHING_ATTRIBUTE?

In your scenario, I'm looking for another possible outcome.  Given everything you stated,  I'd like to understand how you can  get out of the loop if the steward determines the two are actually different people and don't want to keep reviewing entities A and B as they are updated?






------------------------------
Ed Mosier
Slalom
MO

Original Message:
Sent: 07-15-2021 00:56
From: Gino Fortunato
Subject: Way to exclude entities from matching if not a match is set to ANY_MATCHING_ATTRIBUTE?

We are too abstract for my brain :-)

Let me see if an example helps.  ABC Co (entity A) is matched with ABC Company (entity B).  Due to other information, the data steward marks this as not a match.  Per the documentation at https://docs.reltio.com/matchmerge/resetmatch.html,  when ANY_MATCHING_ATTRIBUTE is used: To remove (from do not match pair list) if any matching attribute is changed. Here ANY_MATCHING_ATTRIBUTE means that for any attribute participating in a match rule update, the flag is reset.

Then an attribute used in matching is updated.  We want the match to be re-evaluated.  Lets say that this new evaluation comes back with a match.  The data steward is presented with the same choice as before.  If the data steward keeps marking the re-evaluation(s) as 'not a match' then we are in a loop.  But perhaps one of these changes actually makes it clear to the data steward that entities A and B are the same.  Then they are marked a match and the loop ends.  Are we looking for a different outcome?  If so, what would the expectation be?




------------------------------
Gino Fortunato
Senior Solution Engineer
Reltio

Original Message:
Sent: 07-14-2021 10:27
From: Ed Mosier
Subject: Way to exclude entities from matching if not a match is set to ANY_MATCHING_ATTRIBUTE?

Gino,  

I'll see if I can describe the scenario a little better.  If the configuration is set up to re-evaluate for matches as they are updated and two records are deemed to be suspect matches.  Is there a way to give stewards two options:

1.   Mark as 'not a match', which would prevent the two from being matched again.
2.   Close the task so that the records are not merged, but if either record is updated the two could potentially be matched again. 

Option 1 would used when there is enough information to determine the two entities are distinct. 
Option 2 would be used when there is not enough information to make a definitive determination.  

Hope this helps. 

Ed

------------------------------
Ed Mosier
Slalom
MO

Original Message:
Sent: 07-14-2021 10:10
From: Gino Fortunato
Subject: Way to exclude entities from matching if not a match is set to ANY_MATCHING_ATTRIBUTE?

Hi Ed,

perhaps I am missing something, but isn't this the default behavior?  When records are updated, they are re-evaluated to see if they are a match.  If a record has been declared not a match by a data steward it remains not a match.  The only way that the records are usually marked as 'not a match' is if a data steward has declared that to be the case via the UI.

gino

------------------------------
Gino Fortunato
Senior Solution Engineer
Reltio

Original Message:
Sent: 07-08-2021 18:09
From: Ed Mosier
Subject: Way to exclude entities from matching if not a match is set to ANY_MATCHING_ATTRIBUTE?

If we update the physical configuration so that the not a match is reset for 'ANY_MATCHING_ATTRIBUTE' is there a way to prevent two entities from being matched even if one is updated? Basically we would want the default behavior to be that records would be re-evaluated if matching fields are updated (in case there isn't enough information for a definitive decision) , unless a steward already determined the two records were distinct and don't need to look at the records again.  Thank you!

------------------------------
Ed Mosier
Slalom
MO
------------------------------

Hi Ed,

That's what the configuration change does: It puts you in the loop and every time there is a change, you will potentially be rematched.  There are two ways out: 1) merge the data and 2) if the change makes the records no longer match.

Hope that helps.

------------------------------
Gino Fortunato
Senior Solution Engineer
Reltio
------------------------------

Original Message:
Sent: 07-20-2021 17:17
From: Ed Mosier
Subject: Way to exclude entities from matching if not a match is set to ANY_MATCHING_ATTRIBUTE?

Let's assume we make the configuration change so the records are reevaluated with data changes, which is probably what we would want in most cases. 

Is there a way out of the loop for entity A and entity B (without merging the records)? 

It sounds to me that the default behavior applies to all potential matches, meaning that if you say the two aren't a match, they won't be compared again.

------------------------------
Ed Mosier
Slalom
MO

Original Message:
Sent: 07-16-2021 00:49
From: Gino Fortunato
Subject: Way to exclude entities from matching if not a match is set to ANY_MATCHING_ATTRIBUTE?

Great question Ed.  As we discussed above, this is the default behavior: if no change is made in the environment then it will not be suggested again.

The 'limitation' of the default behavior is exactly that: how do you know the change to the record doesn't make it a duplicate?  Maybe it will, maybe it won't.  In my opinion, it seems like a situation where you can't have it both ways.  Either the data steward decision puts it to bed and a match is not suggested again (default behavior), or the record gets reevaluated after an update and again is potentially a match depending on that change(enabled by the new config settings).  Do you see a logical way to get both outcomes?

--

Gino Fortunato

Senior Solutions Engineer

e gino.fortunato@reltio.com

m 415.867.4195

   

w www.reltio.com | b blog.reltio.com

Original Message:
Sent: 7/15/2021 6:55:00 AM
From: Ed Mosier
Subject: RE: Way to exclude entities from matching if not a match is set to ANY_MATCHING_ATTRIBUTE?

In your scenario, I'm looking for another possible outcome.  Given everything you stated,  I'd like to understand how you can  get out of the loop if the steward determines the two are actually different people and don't want to keep reviewing entities A and B as they are updated?






------------------------------
Ed Mosier
Slalom
MO

Original Message:
Sent: 07-15-2021 00:56
From: Gino Fortunato
Subject: Way to exclude entities from matching if not a match is set to ANY_MATCHING_ATTRIBUTE?

We are too abstract for my brain :-)

Let me see if an example helps.  ABC Co (entity A) is matched with ABC Company (entity B).  Due to other information, the data steward marks this as not a match.  Per the documentation at https://docs.reltio.com/matchmerge/resetmatch.html,  when ANY_MATCHING_ATTRIBUTE is used: To remove (from do not match pair list) if any matching attribute is changed. Here ANY_MATCHING_ATTRIBUTE means that for any attribute participating in a match rule update, the flag is reset.

Then an attribute used in matching is updated.  We want the match to be re-evaluated.  Lets say that this new evaluation comes back with a match.  The data steward is presented with the same choice as before.  If the data steward keeps marking the re-evaluation(s) as 'not a match' then we are in a loop.  But perhaps one of these changes actually makes it clear to the data steward that entities A and B are the same.  Then they are marked a match and the loop ends.  Are we looking for a different outcome?  If so, what would the expectation be?




------------------------------
Gino Fortunato
Senior Solution Engineer
Reltio

Original Message:
Sent: 07-14-2021 10:27
From: Ed Mosier
Subject: Way to exclude entities from matching if not a match is set to ANY_MATCHING_ATTRIBUTE?

Gino,  

I'll see if I can describe the scenario a little better.  If the configuration is set up to re-evaluate for matches as they are updated and two records are deemed to be suspect matches.  Is there a way to give stewards two options:

1.   Mark as 'not a match', which would prevent the two from being matched again.
2.   Close the task so that the records are not merged, but if either record is updated the two could potentially be matched again. 

Option 1 would used when there is enough information to determine the two entities are distinct. 
Option 2 would be used when there is not enough information to make a definitive determination.  

Hope this helps. 

Ed

------------------------------
Ed Mosier
Slalom
MO

Original Message:
Sent: 07-14-2021 10:10
From: Gino Fortunato
Subject: Way to exclude entities from matching if not a match is set to ANY_MATCHING_ATTRIBUTE?

Hi Ed,

perhaps I am missing something, but isn't this the default behavior?  When records are updated, they are re-evaluated to see if they are a match.  If a record has been declared not a match by a data steward it remains not a match.  The only way that the records are usually marked as 'not a match' is if a data steward has declared that to be the case via the UI.

gino

------------------------------
Gino Fortunato
Senior Solution Engineer
Reltio

Original Message:
Sent: 07-08-2021 18:09
From: Ed Mosier
Subject: Way to exclude entities from matching if not a match is set to ANY_MATCHING_ATTRIBUTE?

If we update the physical configuration so that the not a match is reset for 'ANY_MATCHING_ATTRIBUTE' is there a way to prevent two entities from being matched even if one is updated? Basically we would want the default behavior to be that records would be re-evaluated if matching fields are updated (in case there isn't enough information for a definitive decision) , unless a steward already determined the two records were distinct and don't need to look at the records again.  Thank you!

------------------------------
Ed Mosier
Slalom
MO
------------------------------

Gino, I feel that there should be a 3rd option, which it doesn't sound like there is an easy way to accomplish it.

3) Stewards take an action so entity A and entity B are no longer compared to each other regardless of data changes.   

Other records would be re-compared as records are updated (based on the configuration change).

Thank you,



------------------------------
Ed Mosier
Slalom
MO
------------------------------

Original Message:
Sent: 07-20-2021 23:30
From: Gino Fortunato
Subject: Way to exclude entities from matching if not a match is set to ANY_MATCHING_ATTRIBUTE?

Hi Ed,

That's what the configuration change does: It puts you in the loop and every time there is a change, you will potentially be rematched.  There are two ways out: 1) merge the data and 2) if the change makes the records no longer match.

Hope that helps.

------------------------------
Gino Fortunato
Senior Solution Engineer
Reltio

Original Message:
Sent: 07-20-2021 17:17
From: Ed Mosier
Subject: Way to exclude entities from matching if not a match is set to ANY_MATCHING_ATTRIBUTE?

Let's assume we make the configuration change so the records are reevaluated with data changes, which is probably what we would want in most cases. 

Is there a way out of the loop for entity A and entity B (without merging the records)? 

It sounds to me that the default behavior applies to all potential matches, meaning that if you say the two aren't a match, they won't be compared again.

------------------------------
Ed Mosier
Slalom
MO

Original Message:
Sent: 07-16-2021 00:49
From: Gino Fortunato
Subject: Way to exclude entities from matching if not a match is set to ANY_MATCHING_ATTRIBUTE?

Great question Ed.  As we discussed above, this is the default behavior: if no change is made in the environment then it will not be suggested again.

The 'limitation' of the default behavior is exactly that: how do you know the change to the record doesn't make it a duplicate?  Maybe it will, maybe it won't.  In my opinion, it seems like a situation where you can't have it both ways.  Either the data steward decision puts it to bed and a match is not suggested again (default behavior), or the record gets reevaluated after an update and again is potentially a match depending on that change(enabled by the new config settings).  Do you see a logical way to get both outcomes?

--

Gino Fortunato

Senior Solutions Engineer

e gino.fortunato@reltio.com

m 415.867.4195

   

w www.reltio.com | b blog.reltio.com

Original Message:
Sent: 7/15/2021 6:55:00 AM
From: Ed Mosier
Subject: RE: Way to exclude entities from matching if not a match is set to ANY_MATCHING_ATTRIBUTE?

In your scenario, I'm looking for another possible outcome.  Given everything you stated,  I'd like to understand how you can  get out of the loop if the steward determines the two are actually different people and don't want to keep reviewing entities A and B as they are updated?






------------------------------
Ed Mosier
Slalom
MO

Original Message:
Sent: 07-15-2021 00:56
From: Gino Fortunato
Subject: Way to exclude entities from matching if not a match is set to ANY_MATCHING_ATTRIBUTE?

We are too abstract for my brain :-)

Let me see if an example helps.  ABC Co (entity A) is matched with ABC Company (entity B).  Due to other information, the data steward marks this as not a match.  Per the documentation at https://docs.reltio.com/matchmerge/resetmatch.html,  when ANY_MATCHING_ATTRIBUTE is used: To remove (from do not match pair list) if any matching attribute is changed. Here ANY_MATCHING_ATTRIBUTE means that for any attribute participating in a match rule update, the flag is reset.

Then an attribute used in matching is updated.  We want the match to be re-evaluated.  Lets say that this new evaluation comes back with a match.  The data steward is presented with the same choice as before.  If the data steward keeps marking the re-evaluation(s) as 'not a match' then we are in a loop.  But perhaps one of these changes actually makes it clear to the data steward that entities A and B are the same.  Then they are marked a match and the loop ends.  Are we looking for a different outcome?  If so, what would the expectation be?




------------------------------
Gino Fortunato
Senior Solution Engineer
Reltio

Original Message:
Sent: 07-14-2021 10:27
From: Ed Mosier
Subject: Way to exclude entities from matching if not a match is set to ANY_MATCHING_ATTRIBUTE?

Gino,  

I'll see if I can describe the scenario a little better.  If the configuration is set up to re-evaluate for matches as they are updated and two records are deemed to be suspect matches.  Is there a way to give stewards two options:

1.   Mark as 'not a match', which would prevent the two from being matched again.
2.   Close the task so that the records are not merged, but if either record is updated the two could potentially be matched again. 

Option 1 would used when there is enough information to determine the two entities are distinct. 
Option 2 would be used when there is not enough information to make a definitive determination.  

Hope this helps. 

Ed

------------------------------
Ed Mosier
Slalom
MO

Original Message:
Sent: 07-14-2021 10:10
From: Gino Fortunato
Subject: Way to exclude entities from matching if not a match is set to ANY_MATCHING_ATTRIBUTE?

Hi Ed,

perhaps I am missing something, but isn't this the default behavior?  When records are updated, they are re-evaluated to see if they are a match.  If a record has been declared not a match by a data steward it remains not a match.  The only way that the records are usually marked as 'not a match' is if a data steward has declared that to be the case via the UI.

gino

------------------------------
Gino Fortunato
Senior Solution Engineer
Reltio

Original Message:
Sent: 07-08-2021 18:09
From: Ed Mosier
Subject: Way to exclude entities from matching if not a match is set to ANY_MATCHING_ATTRIBUTE?

If we update the physical configuration so that the not a match is reset for 'ANY_MATCHING_ATTRIBUTE' is there a way to prevent two entities from being matched even if one is updated? Basically we would want the default behavior to be that records would be re-evaluated if matching fields are updated (in case there isn't enough information for a definitive decision) , unless a steward already determined the two records were distinct and don't need to look at the records again.  Thank you!

------------------------------
Ed Mosier
Slalom
MO
------------------------------

I see what you are saying.  I don't believe it is possible today.  You should have access to our ideas portal, reltio.aha.io, where you can add the idea and it will be evaluated for inclusion in the product.

The use case makes sense to me, so please add the idea!

------------------------------
Gino Fortunato
Senior Solution Engineer
Reltio
------------------------------

Original Message:
Sent: 07-21-2021 13:51
From: Ed Mosier
Subject: Way to exclude entities from matching if not a match is set to ANY_MATCHING_ATTRIBUTE?

Gino, I feel that there should be a 3rd option, which it doesn't sound like there is an easy way to accomplish it.

3) Stewards take an action so entity A and entity B are no longer compared to each other regardless of data changes.   

Other records would be re-compared as records are updated (based on the configuration change).

Thank you,



------------------------------
Ed Mosier
Slalom
MO

Original Message:
Sent: 07-20-2021 23:30
From: Gino Fortunato
Subject: Way to exclude entities from matching if not a match is set to ANY_MATCHING_ATTRIBUTE?

Hi Ed,

That's what the configuration change does: It puts you in the loop and every time there is a change, you will potentially be rematched.  There are two ways out: 1) merge the data and 2) if the change makes the records no longer match.

Hope that helps.

------------------------------
Gino Fortunato
Senior Solution Engineer
Reltio

Original Message:
Sent: 07-20-2021 17:17
From: Ed Mosier
Subject: Way to exclude entities from matching if not a match is set to ANY_MATCHING_ATTRIBUTE?

Let's assume we make the configuration change so the records are reevaluated with data changes, which is probably what we would want in most cases. 

Is there a way out of the loop for entity A and entity B (without merging the records)? 

It sounds to me that the default behavior applies to all potential matches, meaning that if you say the two aren't a match, they won't be compared again.

------------------------------
Ed Mosier
Slalom
MO

Original Message:
Sent: 07-16-2021 00:49
From: Gino Fortunato
Subject: Way to exclude entities from matching if not a match is set to ANY_MATCHING_ATTRIBUTE?

Great question Ed.  As we discussed above, this is the default behavior: if no change is made in the environment then it will not be suggested again.

The 'limitation' of the default behavior is exactly that: how do you know the change to the record doesn't make it a duplicate?  Maybe it will, maybe it won't.  In my opinion, it seems like a situation where you can't have it both ways.  Either the data steward decision puts it to bed and a match is not suggested again (default behavior), or the record gets reevaluated after an update and again is potentially a match depending on that change(enabled by the new config settings).  Do you see a logical way to get both outcomes?

--

Gino Fortunato

Senior Solutions Engineer

e gino.fortunato@reltio.com

m 415.867.4195

   

w www.reltio.com | b blog.reltio.com

Original Message:
Sent: 7/15/2021 6:55:00 AM
From: Ed Mosier
Subject: RE: Way to exclude entities from matching if not a match is set to ANY_MATCHING_ATTRIBUTE?

In your scenario, I'm looking for another possible outcome.  Given everything you stated,  I'd like to understand how you can  get out of the loop if the steward determines the two are actually different people and don't want to keep reviewing entities A and B as they are updated?






------------------------------
Ed Mosier
Slalom
MO

Original Message:
Sent: 07-15-2021 00:56
From: Gino Fortunato
Subject: Way to exclude entities from matching if not a match is set to ANY_MATCHING_ATTRIBUTE?

We are too abstract for my brain :-)

Let me see if an example helps.  ABC Co (entity A) is matched with ABC Company (entity B).  Due to other information, the data steward marks this as not a match.  Per the documentation at https://docs.reltio.com/matchmerge/resetmatch.html,  when ANY_MATCHING_ATTRIBUTE is used: To remove (from do not match pair list) if any matching attribute is changed. Here ANY_MATCHING_ATTRIBUTE means that for any attribute participating in a match rule update, the flag is reset.

Then an attribute used in matching is updated.  We want the match to be re-evaluated.  Lets say that this new evaluation comes back with a match.  The data steward is presented with the same choice as before.  If the data steward keeps marking the re-evaluation(s) as 'not a match' then we are in a loop.  But perhaps one of these changes actually makes it clear to the data steward that entities A and B are the same.  Then they are marked a match and the loop ends.  Are we looking for a different outcome?  If so, what would the expectation be?




------------------------------
Gino Fortunato
Senior Solution Engineer
Reltio

Original Message:
Sent: 07-14-2021 10:27
From: Ed Mosier
Subject: Way to exclude entities from matching if not a match is set to ANY_MATCHING_ATTRIBUTE?

Gino,  

I'll see if I can describe the scenario a little better.  If the configuration is set up to re-evaluate for matches as they are updated and two records are deemed to be suspect matches.  Is there a way to give stewards two options:

1.   Mark as 'not a match', which would prevent the two from being matched again.
2.   Close the task so that the records are not merged, but if either record is updated the two could potentially be matched again. 

Option 1 would used when there is enough information to determine the two entities are distinct. 
Option 2 would be used when there is not enough information to make a definitive determination.  

Hope this helps. 

Ed

------------------------------
Ed Mosier
Slalom
MO

Original Message:
Sent: 07-14-2021 10:10
From: Gino Fortunato
Subject: Way to exclude entities from matching if not a match is set to ANY_MATCHING_ATTRIBUTE?

Hi Ed,

perhaps I am missing something, but isn't this the default behavior?  When records are updated, they are re-evaluated to see if they are a match.  If a record has been declared not a match by a data steward it remains not a match.  The only way that the records are usually marked as 'not a match' is if a data steward has declared that to be the case via the UI.

gino

------------------------------
Gino Fortunato
Senior Solution Engineer
Reltio

Original Message:
Sent: 07-08-2021 18:09
From: Ed Mosier
Subject: Way to exclude entities from matching if not a match is set to ANY_MATCHING_ATTRIBUTE?

If we update the physical configuration so that the not a match is reset for 'ANY_MATCHING_ATTRIBUTE' is there a way to prevent two entities from being matched even if one is updated? Basically we would want the default behavior to be that records would be re-evaluated if matching fields are updated (in case there isn't enough information for a definitive decision) , unless a steward already determined the two records were distinct and don't need to look at the records again.  Thank you!

------------------------------
Ed Mosier
Slalom
MO
------------------------------

Hello Ed!

I think this use case can be handled using Reltio Workflow. This tool allows managing different business processes right in Reltio UI. One of the things it can do is a Potential Match Review process. You can create instances of this process for your potential matches, assign the review tasks to data stewards, leave comments for the tasks. By default, this process allows the same 2 actions (Merge or Set as Not-A-Match), but this process is customizable. For example, it's possible to add another step (like Deferred). So the process can look like this:

1. A data steward reviews a pair and decides that it needs to be deferred
2. He/she executes a "Defer" action. The task state changes from "Review" to "Deferred". It's also possible to leave a comment with additional details
3. Once the pair is ready to be re-evaluated by a data steward, you execute an action "Back to Review" and the task returns to the "Review" state

The potential match doesn't disappear, but it's marked so that a data steward can understand that this pair is waiting for further updates and doesn't need to be reviewed.

------------------------------
Maxim Karpov
Senior Software Engineer
Reltio
------------------------------

Original Message:
Sent: 07-14-2021 10:27
From: Ed Mosier
Subject: Way to exclude entities from matching if not a match is set to ANY_MATCHING_ATTRIBUTE?

Gino,  

I'll see if I can describe the scenario a little better.  If the configuration is set up to re-evaluate for matches as they are updated and two records are deemed to be suspect matches.  Is there a way to give stewards two options:

1.   Mark as 'not a match', which would prevent the two from being matched again.
2.   Close the task so that the records are not merged, but if either record is updated the two could potentially be matched again. 

Option 1 would used when there is enough information to determine the two entities are distinct. 
Option 2 would be used when there is not enough information to make a definitive determination.  

Hope this helps. 

Ed

------------------------------
Ed Mosier
Slalom
MO

Original Message:
Sent: 07-14-2021 10:10
From: Gino Fortunato
Subject: Way to exclude entities from matching if not a match is set to ANY_MATCHING_ATTRIBUTE?

Hi Ed,

perhaps I am missing something, but isn't this the default behavior?  When records are updated, they are re-evaluated to see if they are a match.  If a record has been declared not a match by a data steward it remains not a match.  The only way that the records are usually marked as 'not a match' is if a data steward has declared that to be the case via the UI.

gino

------------------------------
Gino Fortunato
Senior Solution Engineer
Reltio

Original Message:
Sent: 07-08-2021 18:09
From: Ed Mosier
Subject: Way to exclude entities from matching if not a match is set to ANY_MATCHING_ATTRIBUTE?

If we update the physical configuration so that the not a match is reset for 'ANY_MATCHING_ATTRIBUTE' is there a way to prevent two entities from being matched even if one is updated? Basically we would want the default behavior to be that records would be re-evaluated if matching fields are updated (in case there isn't enough information for a definitive decision) , unless a steward already determined the two records were distinct and don't need to look at the records again.  Thank you!

------------------------------
Ed Mosier
Slalom
MO
------------------------------