Reltio Connect

 View Only

Introduction to Survivorship Strategies, Rules and Operational Value - Webinar

By Chris Detzel posted 01-23-2022 14:18

  



The first of a five part series of shows where we will do an overview and a technical deep dive into Reltio MDM attribute survivorship rules, groups and strategies, walk through types of strategies and their specifics and best practice with examples. For more information, head to the Reltio Community and get answers to the questions that matter to you: https://community.reltio.com/home

Find the PPT: Introduction to Survivorship strategies, rules and Operational Value (ov) calculation


Transcript below: 

Dmitry Blinov:

Thank you. Again, apologize to make you wait. It was a technical issue with Zoom that I personally had. Today we will talk about survivorship strategies and rules, and operational values and how they are calculated.

Dmitry Blinov:

So, they did behind this webinar ... This webinar starts a series of webinars where we would like to do a real deep dive into business use cases, technical use cases of the entity resolution. There are a lot of them and pretty techy ones we often times engineer and product management on the calls with the customers explaining complex cases of data modeling. But to do that, the first that we need to... There will be a series of webinars, as I already said, and we will start today with basics. We have to start with basics, outline the bedrock of entity resolution. What is operational value survivorship rules and strategies before we can really start doing a real deep dive into this topic.

Dmitry Blinov:

Today's webinar, we'll just go through this basics. For those of you who already familiar with that, will be a good refresh, but for those of you who are not maybe familiar with that, maybe not to the very details we prepared for you today, it'll be a good start for this theme. Why is it not... Okay. Switching up, well today's agenda real quick. I'll talk about entity resolution, then operational values and operationalized user interfaces, data structures, and operations like data cleans or profile matching. Then we'll talk specifically about OV calculator and then things that drives OV calculations. Survivorship rules and survivorship groups, their structures and types. And then we will go through specific types of survivorship strategies. The background of any operational value calculation and this way, entity resolution. How do I get this? Go back. Trying to do [inaudible], but probably disappear if I stop using my cursor.

Dmitry Blinov:

Yeah. Entity resolution and MGM happens on the attribute level. During the entity resolution process, an attribute either wins, which we call survive, or loses. Survive value, the attribute is called operational value, and it is calculated by the OV calculator, which is based, as I already said, on survivorship rules that are set for each attribute type. So quick example, let's say we have two crosswalks. Crosswalk A and crosswalk B, and two values of the first name attribute, and last name associated with them. Because two crosswalks participate in the entity resolution, they both part of a single entity and at the end we'll have resolved object which will have both crosswalks and the value of the first name attribute survived from the crosswalk B while the value of the last name attribute survived from the Crosswalk A. You'll have resolved object where operational value, which you will see in the profile view, for example, will be first name Mike, last name Frasca, and just a simple example.

Dmitry Blinov:

Then we talk about the operational ones. I have to find a way to this. OV or an operational value, is a boolean property. Every attribute has it. Is a mandatory part of the attribute. And simple, nested, sub-nested, reference and sub-reference, doesn't really matter. Any attribute will have it. An attribute can have multiple operational values, or one or zero. When we say that attribute doesn't have an operational value, that means that OV property, as you see in the simple structure here, it's a simple, simple attribute structure OV false. This specific attribute first name, it has one operational value, which is marked with OV true and other values here are OV false. They are not operational values. But all three are the values of the attribute. Let's switch.

Dmitry Blinov:

Sorry. Yeah. Currently slides are slow. Operational values is in the user interfaces. Same example in the profile view here, you can see in the left top corner, the first name attribute is shown this way. Basically operational value is shown as it is. And we do not show non operational values, as you know, in the profile view. We just show that there are some other values. This plus two means that there are two other values which are non operational in this case. In the source view, we chose all the crosswalks. We do show all values, operational, non operational. Here you can see that the value associated with this crosswalk is operational and these two associated with this crosswalk are non operational, but you can see all three of them in the source view.

Dmitry Blinov:

In the data structure, you will see again, I already showed how the attribute is structured, but let's look closer at the attribute itself. It has type, it has OV, it has value, and it has URI. This unique URI is associated with this specific value and it links this value to the crosswalk. We say that this attribute survived value came from this crosswalk. Be associated by URI, right? And this is just an example of [inaudible] addresses presenting specific profile, and each has operational value and we call golden record.

Dmitry Blinov:

Operational values are defined by OV calculator based on survivorship rules, which are based in turn on survivorship strategies. Survivorship rules and survivorship strategies are two different concepts. At the same time they are interrelated. And survivorship rules are based on survivorship strategies. Strategies are part of the predefined logic. Basically they are embedded into the platform. You can use them, but you just get whatever you have the list of strategies from the platform. You put it in your data model still and later I'll show how. Roles described which strategy from which specific list will be applied to a specific attribute of a specific entity type and whether extended settings also applied, but we'll not be talking about extended settings today.

Chris Detzel:

Hey, Dmitry.

Dmitry Blinov:

Yep.

Chris Detzel:

I almost want to call you Chris. Quick question for you. Is there Reltio APIs that allow us to extract all or select attributes from each crosswalk within like a given profile as we seen them in the UI? We have some use cases to analyze this outside of the UI.

Dmitry Blinov:

Well, since in UI, in the profile view or in the source view? So basically the question is... Let me go back to this one. This has shown exactly based on this structure. So when you extract this structure, this UI is built on based on this structure. Now you can extract everything like shown here, operational, non operational. I think you can, well, you can at least parse operational values because you have them here. So I'd like this question to be clarified. It's not clear to me what exactly.

Chris Detzel:

Yeah. Sandro, I don't know if you want to take yourself off mute or if you just want to push that in the chat and we can.

Yakov Goyhman:

I can some details. There is option for getting entity and the option is get OV values only, or non OV values only. And if you want to get some particular cross related where it's not possible.

Sandro:

This is Sandro. So I can see that I can get the non OV values, but I wouldn't be able to necessarily associate that with a given crosswalk if I'm exporting it from the time.

Dmitry Blinov:

You can. You always can do this by this URI. So once-

Sandro:

All right. Okay, I got you.

Dmitry Blinov:

Yeah. So you see, this is exactly the URI that associates. This is how UI understand that these... We mark them by color in UI. This is how UI actually associate that these values came from this crosswalk exactly using these URI, which is uniquely identifies each value of the attribute. So if you would have, let's go back little bit. Yeah. You see, we have three different values here and each has its own unique URI. And this URIs may be in three different crosswalks. So this is how we understand which value came from which crosswalk.

Sandro:

Okay. Gotcha. Thank you. So we just wanted to... Sometimes what happens on our side is, business processes update a given crosswalk with completely different party profile. And it starts to impact the integrity of the golden because of it. So we just want to do that analysis right.

Dmitry Blinov:

You want to find the-

Sandro:

Yeah. Perfect. Thank you for that.

Dmitry Blinov:

Got it. Important piece here to know about OV calculator. Operational value is not stored. We do not persist it. It is always calculated on the fly based on the natural. So basically, anytime you apply an operation on the entity, surviving attribute value always been recalculated. So that gives us a lot of flexibility because anything change in the profile, we just recalculate everything by default and a different value may survive as a result of this calculation. Obviously, if you change the proof for a specific attribute, you need to take care about index and much information because they start going to separate secondary storage's. So you need to re-index already build matches if you change the rule. But change the rule is you change the data model. So you have to do that in this case. Additional calculation rules.

Dmitry Blinov:

You can pin values, as you know. You can do it even in UI. So if you pin the value, they not participating in the OV calculations, they just always survive or always win. At the same time, you can ignore values or you can end date crosswalks. So values that I ignored was that came from the end-dated crosswalks. They also do not participate in the OV collections. They always lose, they never win. And OV operations. Using operational value, you can tune some operations like cleanse or short to expert to apply OV operations or processes only to operational values of the attributes of the entities. At this cleansing, for example, you can apply this configuration with OV-only equals two parameter. And it'll tell the cleanse separation to only work with the values of the address attributes that are operational for OV equals two.

Dmitry Blinov:

You can do the same research. And obviously then you can do the same with export because exports is just an extension of the search. You can do the same with matching. When you apply matching, you try to match two profiles. You can say match OV only equals two, you can set this parameter. And setting this parameter margin will only be calculated or applied to operational values of the attributes. We also introduced a new OV only to the bulk date function, but it'll be available only starting to the 20 release that is coming in the middle of February. And it is configured in the LT. So you apply this record on the metadata or business model level. You say for specific attribute, this attribute when bulk update is applied to it on taking account on operational values.

Chris Detzel:

So quick question, Dmitry. So when ignoring an attribute, if a change to the cross updates, the ignored attribute with the new value, does it keep it ignored forever or will it remove ignore?

Dmitry Blinov:

It keeps ignored until you remove. So you need to unpin the ignore check from this.

Chris Detzel:

Okay. And then one more question. So we pin a certain attribute, or we pin certain attributes values of record. When a update later on comes in for the same attribute and does it not override the pinned value? Is that right?

Dmitry Blinov:

I think it's right. Yakov, if you can on this because I think there may be use case where I can reset the pinned-

Yakov Goyhman:

Yeah. There's a very complex behavior and we have even many rules, I know at least two of them, which allows to very smartly behave with pin ignored, all neutral status of the value. So the answer of the entry is correct. So in many cases, it's correct that pined or ignored value stay forever and never unignored when you put some changes in crosswalk. But there is some specific cases or some specific KPI which allows to change this behavior.

Dmitry Blinov:

And we'll talk about this specific or advanced behavior in the future webinars. So default-

Yakov Goyhman:

It's even not advanced behavior of strategies. It's something about pinned or ignorant. And I don't think that we are going to-

Dmitry Blinov:

Maybe let's look at including this into future webinars. What I'm trying to say is, yeah again, we have series webinars for that. And it's a good question. So you want to produce this in more details. But default behavior, you need to specifically unpin the value. Otherwise, doesn't matter if you do a data audit, it'll remain pin, and so basically always survive. This is the reason we put this pin values in the first place on the platform. If you want to exclude specific value, you just want to pin it and say, you always win, this value always wins. You just pin it and it never participates in calculation, just always stays survivor or OV. So let's talk about survivorship rules and groups, because this is what drives the operational value calculation. And today will show specifically how it happens. But for now, what are survivorship rules? This are specified in a business configuration.

Dmitry Blinov:

So in your data model where you have all your entity types, attribute types and things like that. You specify simple groups there, survivorship rules there. And this is how you do that. So you define a group, inside the group, you define what's called the mapping. This mapping is a rule. You can have multiple, many of them. Rule basically says, it's a basic definition of the rule, which strategies should be applied to which attribute? So strategies are listed, I'll show in a different slide. They are listed in parallel on the same business model. And you can use the same strategy in multiple rules, but you cannot apply multiple rules to the same attribute because it'll be conflict. So you should specifically say for this attribute apply this strategy, and this is what's called pero. And this is how operational value calculator, calculates the surviving value. And all this is said in the group, in the survivorship group, which is defined for a specific, we can define multiple groups.

Dmitry Blinov:

Did I miss anything here? I think no. Let's been very quick time checking, doing good. Structure of survivorship group then. Let's deep dive a little bit into the structure of survivorship group. As you saw, it has a URI which defines the group uniquely. It's a unique identifier for the group. It has a default flag. We can have any number of survivorship groups, as I said, but only one must be marked as default. If you specify several groups as default, you'll get a validation error when you'll try make an attempt to save this business configuration and metadata configuration.

Dmitry Blinov:

We also call it L3 configuration just so you know. It's all the same thing, or sometimes L2, L3 because there is inherently there. And then survivorship group would have a mapping section. This is the main section, as we already said. We also call it survivorship rule, this mapping section. It describes which strategy must be applied to each attribute. Use last update date survivorship strategy for the first name attribute. And basically this is a link to this strategy, which is just a static strategy, the list on the platform. Yeah. I don't think I need to go any deeper on that.

Chris Detzel:

So I do have a question for you, Dmitry. So if we're going to go to the next... So can we have custom survivorship rules say we have an amount column. I need to sum all the values coming from the different sources and only the summed value should be on my OV equals true. Any comment on that?

Dmitry Blinov:

The overall question is yes. Sorry answer is yes. Yakov, do you want to comment on this more?

Yakov Goyhman:

Yeah. Currently search function is not available.

Dmitry Blinov:

Okay. So the rules you mean, right? We can only do custom strategy, but not custom rule.

Yakov Goyhman:

Yes correct. Current strategy is possible, but not a current rule yeah.

Dmitry Blinov:

Got it. I got it. Sorry, my mistake. So you can do custom strategy, but not the custom rule yeah.

Chris Detzel:

Oh, thank you.

Dmitry Blinov:

Okay. Thank you Yakov. Structure of survivorship strategy. Well, it's simple. It's just, you can see the list of strategies here. You would put it in your data model or metadata configuration, the same level where you place your sources, entity types, relation types, and such.

Dmitry Blinov:

Well, they cover next functions. They defined which strategists can be used. So if you're going to use specific strategy as part of your rule, you have to put it in your configuration and also to see it in the UI. I think I have it. Yeah, like this, to have it in the dropdown list, you also need to put it in your business configuration or metadata configuration. So just have this list of strategies and whatever you have here you have in UI and you can use in your rules, and has URI and label. So basically, label is a name which you'll be referencing. You'll be referencing strategy by name in your rule. URI is again, because every object in the business models should be identified to you. So you have this unit identify as a URI. Basic types of survivorship strategies. We'll only cover basic types today. Last update date, source system, frequency, aggregation, oldest value, minimal value, and maximum value.

Dmitry Blinov:

Other attribute between our crosswalk and winner entity crosswalk. You can switch between the... You can select the strategy pair attribute right in the MDM UI, it's available. We can try different strategies applied. You change your model. So let's talk about each individual strategy specifically and see how it works in the entity resolution. First last update date. Basically it says, make all values with the most recent update date to be winners for this attribute. I have a configuration where I have my attribute first name mapped to the survivorship strategy last update date LUD. I have a crosswalk A with update date first day of this year, and crosswalk B with update date December 12th of last year. So the value from crosswalk A will survive because last update date is applied, and this is the last update date basically. It's very simple. I used a lot. It's a very popular strategy.

Dmitry Blinov:

So last update date. Next one is source system. I can define a prioritized list of source systems. It can be a model, two items. I can have 12, 20 whatever items here, all of my sources. And I can say that, well, if the value came from this source, it'll survive. If there is no value from this source. So next value that survives that came from this source and so forth. So basically this has a highest priority, and this is the next one. And this is the next one. So if I have a first name attribute again, this source system and source crosswalk listed in this order, and I have to Crosswalk A and B, obviously A will win, value from Crosswalk A will win here because it has higher purity.

Dmitry Blinov:

Frequency. Frequency says, make values that came from the most number of different sources to be winners. Very simple. I have three crosswalks and the most popular value of the attribute will survive. In this case, I have first name Ann, and then I have first name Anna and Anna Yang. That one will survive just because it's the most frequent from all the crosswalks that participate in the operational value calculation for this attribute.

Dmitry Blinov:

Aggregation says, make all values to be winners. And I have again, three crosswalks and all three will be in this case. So basically my value will be a combination of all three values that came from all three crosswalks. Oldest value. Oldest value is different from the last update date, because it works not with the last update date timestamp, but instead it works with create date type timestamp. And create date doesn't change when you update the profile. It stays the same since you created this specific crosswalk. So if you'd like to stick with the oldest value that was ever, that ever get into this entity was ever created came from the oldest source, whatever sounds like this, you use this strategy, and well, that's very simple. And again, same example, just create date. Oldest is December the 12th, so that one crosswalk B value won or survived in this case.

Chris Detzel:

Hey, Dmitry sorry. Regarding LUD. What if the two records have the exact same LUD? So this causes survivorship conflicts.

Dmitry Blinov:

Yes. This is why we introduced this new behavior for the bulk update. Exactly for this reason. When you do a bulk update and you have LUD, multiple attributes can survive. So in this case, since to the one, operational value will get the priority. For other cases, Yakov, if you have any specific examples of how the platform will behave.

Yakov Goyhman:

Yeah, sure. So if for example, we have two different values which came from two different crosswalks and each of them, each different crosswalk, has same update date. In such case, bot will use gate winners and most crosswalks are also winners.

Dmitry Blinov:

So it'll be like aggregation, right?

Yakov Goyhman:

No. If you have showed value, which-

Dmitry Blinov:

Yeah, I got it.

Yakov Goyhman:

Not so recent, it won't win.

Dmitry Blinov:

So, it's not the same exactly as aggregation. But the two winners will be aggregated and you'll have two values. Well, similar to how aggregation works, but just for these two last update date, which exact match in this case.

Chris Detzel:

Great. So another kind of question. So does Reltio rely on fallback strategy if two records have the exact LUD?

Dmitry Blinov:

Yakov if you want to take this one, fallback strategies are out scope of today's scope. But let's answer this one.

Yakov Goyhman:

Okay yeah, sure. There is possible to define fallback section in each survivorship mapping in each survivorship rule. So you can unlimited number of fallback sections. And in case if you have zero or many values, which are survive it, you can create some additional rules inside fallback section, which allows you to differentiate between them and select exactly only one survive it value.

Chris Detzel:

Thank you.

Dmitry Blinov:

Cool. Next strategy. Well, actually we combine the two here, minimum value and maximum value. Very simple again. The minimum of the maximum value of the two will be select. It's a made up example here license, but we just need to have any number as an example. So if you for some weird logic, you want to be lower number for a license ID to survive, you just apply minimum value. Again, if you want the bigger number to survive, you just apply maximum value. It's as simple as that at the same time, there are a lot of real examples with various types of IDs where you need the earliest identify, especially when they're generated sequentially to survive or the latest or earliest. And yeah.

Chris Detzel:

So quick question Dmitry. Sorry couple... What crosswalk, sorry. What crosswalk dates are used to calculate, I'm just going to call it LUD, LUD survivors.

Dmitry Blinov:

Okay. So what is the question? Which crosswalk-

Chris Detzel:

Yeah, what crosswalk dates are used to calculate lead survivorship?

Dmitry Blinov:

Last update date.

Chris Detzel:

Okay. And is Reltio-

Dmitry Blinov:

Its updated. Sorry, it's just update date. Last update date is the field called update date. Yes.

Chris Detzel:

Okay. And so some more stuff's coming in. But is Real LT date included in the calculation?

Yakov Goyhman:

No.

Speaker 5:

No, it shouldn't be. But if I could add something, Dmitry. There are crosswalk level single attribute up update dates. So if those are populated, I believe they are factored in before the crosswalk level update date.

Dmitry Blinov:

Yes. You're right.

Speaker 5:

So for example, if your single attribute update date has a more recent date than just the crosswalk level update date overall, then that gets considered for that particular attribute. In that case, the maximum is taken of that versus the crosswalk level update date to my knowledge.

Dmitry Blinov:

Good. No, it's a good point. And we'll need to the specific slide with that example as well. Because you're right. There is additional parameter on the attribute level. It is optional, so it can be missed. But if it's there and if it is later... So basically it gets priority over the crosswalk in this case.

Yakov Goyhman:

Actually, it's inside crosswalk and this single attributable update date, it belong to crosswalk [crosstalk] So, our current session is only overview session and it's not possible to speak about everything inside survivorship. Therefore, exactly. Single attribute, the date specifics will be discuss it in next sessions.

Dmitry Blinov:

Yeah. We'll include it into next sessions. It's a little bit... It's one step deeper than-

Chris Detzel:

And guys, I figured most we'll probably go a little bit deeper because there'll have to be a lot of questions and I'm loving the questions, so there's a few more. What happens if we have given minimum slash maximum rule for string attributes? So example like first name.

Dmitry Blinov:

Yakov, do you want to take this one? Because I think I know what'll happen.

Yakov Goyhman:

Yeah, it would be sorted alphabetically and the most attribute which is most closer to A, which be minimal and the attribute is which more closer to Z will be treated as maximum.

Chris Detzel:

Great, thank you. And then so far, SRC underscore says, can I put only one source of highest priority compared to all the others? So all other sources will have same priority and fallback strategy will apply if the highest priority source is not present between the contributors.

Yakov Goyhman:

The answer is yes. It's possible to provide only one source system inside priority book.

Chris Detzel:

And guys, as you going to think about some of the episodes that you're going to do, you might think about incorporating some of these maybe within your demo on how to do some of this stuff just to FY, I think it'll be good. Couple other questions. As far as I understand, LUD considers most recent of crosswalk, last update date, single attribute update date, and then source publish date. Is that still hold?

Dmitry Blinov:

Source publish date.

Yakov Goyhman:

I think source publish date is not included here.

Chris Detzel:

Okay. And then Sapara, if there's additional insights or questions there let me know. So for whatever reason, the last update date is not being updated in our tenant. How would this affect a survivorship rule?

Dmitry Blinov:

Well, basically if there are other values for which last update was updated, they may became later and then basically survive. So operational value may change because of that for a specific attribute. And then if you have operations that include only... Well, everything type to operational value view change behavior wise. So for example, if you do search vibration while only you, you're not having different operation value. So things like that.

Chris Detzel:

Okay. Now last question, but maybe not from last-

Santana:

Dmitry... Sorry to cut you. Santana here. I was asking about this source publish date. If I would tell you, I don't see this source of this data usually. Is this kind of specifically a date or how do we get it? And like whenever I do get entity, I don't see it in crosstalk somewhere else.

Dmitry Blinov:

But source published data is not participating in some part anyways. It's just not part of the LUD calculation.

Santana:

Okay. But I had read it somewhere in Viki. So I asked this question.

Dmitry Blinov:

Let's link up after this call, maybe there is some internal documentation that is outdated, something. Let's check on that.

Santana:

Okay. Okay sure.

Speaker 5:

I think I've seen the same notes, but I think just to answer your question. Source published date is optional at the crosswalk level. And I don't see it used too frequently, but it's supposed to represent the date at which an extract was taken from a source, because it might not be equal then to the Reltio load date. It might also not be equal to the actual record create date in the source, nor the update date. So it's just meant to represent the time at which data was extracted from a source. So you might have never seen it because it might not actually be part of the dataset. It's optional.

Santana:

Yeah. Okay. Got it, yeah.

Chris Detzel:

Yeah. Last question. Is it possible to have multiple sources with the same priority?

Yakov Goyhman:

I would answer. So yes, it's possible, but not with source URI order. When in L3, some source types, I define it. It's possible to provide source priority. There's optional field for source type definition. And in this source type definition for every source is possible to provide a priority with some integer number. So sources with same priority would have same integer numbers. In such case, you don't have to provide sources URI order inside SRCC strategy, because sources order provided in SRCC since would take precedence over L3 sources definition. If there is no sources URI order provided inside rule, it would be treated as priority from L3.

Dmitry Blinov:

And definitely, another case where demo will be great, because I'm just not sure on how... You need to visualize what Yakov says to understand. So if you ever did this, you would understand, but if you don't, it's quite complex use case. We'll definitely in the future webinars, we'll touch on this topic and demonstrate. So Chris, are you okay if I'll cover two last slides?

Chris Detzel:

Yeah, go ahead. Thank you.

Dmitry Blinov:

So other attribute winner crosswalk strategy. Make attributes from the source that wins in the other attribute winners for this attribute. So the way you define this one is, and let me see how can I show it here this way. So, you have two roles here in the market, two different modules or two different roles. For the last name attribute you, you have a simple last update date LUD right? And for the first name attribute, you have this other attribute between our crosswalk, which points there is an additional parameter to this strategy, which points to the last name attribute. Which basically says, whatever crosswalk, this value should survive from the same crosswalk. So I have a crosswalk A and a crosswalk B, and last name here will survive from the last update date. So this one, so this one will survive. And because of that, first name will survive from this same crosswalk A. So that'll be an operational value here.

Dmitry Blinov:

This one is used locations and the attributes values as far as I saw them, at least in the past. Last one, I think. Winner entity crosswalk. Make all values of the attribute from the winner entity to be winners. So the difference here is, I'm not operating on the crosswalk level, I'm operating on the level. There was a merge event for two entities and entity one won in this merge event. So if I apply winner entity crosswalk to my first name attribute, the operational value for this attribute will always be taken from the winner entity. So entity one in this case.

Dmitry Blinov:

That's all for the basic strategies. A lot of good questions. That's great. So we just wanted to walk you through, as we started again, I'll just real quick repeat. We started with what entity resolution is on the crosswalk and entity level, not going into the merge level, but just on the entity level, and how you know it is based on the OV calculation and how OV calculation is based on survivorship rules and how survivorship rules are based on survivorship strategies. And then we discussed existing survivorship strategies and you know, used examples of how operational value will be calculated in each example. Entity solution can be much more complicated than that. But to understand this complexity you first need to get to this basic. So we covered it today. Thank you all for your participation. Chris, I'll stop sharing and give it back to you.

Chris Detzel:

We have lots of questions. So why don't we just start with the questions or a few. Is it based on old URI only? Is that the case or no? URL. Sorry.

Yakov Goyhman:

Okay. So as I understand, you want to know technical deals, what is under the hood of this strategy, correct? Yeah. I think the explanation of this how it works would be done in next sessions. Again, there's two complex and it relies on some terms like initial source. There's hidden property of each cross walls. It says, what was the initial URI of entity when it was created firstly in our system?.

Chris Detzel:

Okay. So what I'll do at the end of today is, I'll send you all these questions, so you guys can kind of push them in to your new demos. A couple more questions. How do you select a winner entity?

Dmitry Blinov:

I think it's the same question actually. It is the same question.

Chris Detzel:

Sorry. So for the other entity winners, what if the value of FN was pinned? Will it still overwrite?

Monalisa:

Sorry. Sorry. So FN is first name, so the example that Dmitry pulled up on his screen was if last name is winning, since other entity winner is selected, then first name has to win. And my question is, what if the first name was pinned?

Dmitry Blinov:

In this case, it'll win before calculation even starts. So calculation will not even be applied. It'll just win, not because last name won for the same cross world, but because it's pinned

Chris Detzel:

Great.

Monalisa:

Okay. Got it.

Chris Detzel:

And Haresh says, it sure would be nice to have a live practice session.

Dmitry Blinov:

I agree. But we needed to go through this basics. I understand for a lot of people, yeah. Many folks know all that maybe.

Chris Detzel:

I think we're on it Haresh. And then when we ignore an attribute value, does it apply to the entire entity class, or can we do this for specific records?

Dmitry Blinov:

We can do it for specific records. You actually do it on a SP. So you can end date the crosswalk and everything that comes from this crosswalk will be ignored. But when you ignore, you ignore a specific value, I think not even attribute. Yakov, keep me honest, please. Do we ignore value?

Yakov Goyhman:

There's two different ways. One of them is end day crosswalk and each value which assigned to this crosswalk contributed by this crosswalk would also be treated as end-dated. And other way is apply some status like pinned or ignored to value. [crosstalk] On value basis yes. It's per value, per attribute, per entity. Not per class. You mean type maybe. There is no such thing as class, but I think you mean type.

Dmitry Blinov:

Yeah. So three levels. Entity, crosswalk, and individual value. You can configure on all of these three levels. But the question was specifically about ignore value. Ignore attributes apply to value. You can even within the single attribute, you can ignore a couple of values and then leave others as they are. So they will continue participating in OV calculation.

Chris Detzel:

I think that... I love the back and forth Yakov is keeping Dmitri very honest today, so that's good stuff. So Chatan says that and if you're from Reltio, can we have a session on cleansers as well? So I don't know who might would cover that, but please get with me directly. If you are very smart in the cleanser piece of it and we'll put a webinar together. And you don't have to be an employee, you could be one of our customers or partners that are really smart about it and we'd love to get you on as well. So I think that's it for today. No other questions that I can see. And again, apologies for the technical difficulties, but we still got the content in. So very excited about that.

Chris Detzel:

Thank you everyone for attending. The last thing I'll say is, if you haven't been to community.realtio.com today, we do have some swag to give away by either posting questions, answering questions and inviting some of your colleagues to be part of the Reltio community. Go check it out. So everyone, thank you so much for attending today. This will be recorded and posted maybe by the end of today, but for sure by early next week. Dmitry, Yakov, this was great. Really appreciate it. So good session.

Dmitry Blinov:

Thank you, Chris. Bye.

Chris Detzel:

Thank you. And I'll stay on for a minute or so if you want to put some feedback in there, hopefully this is helpful. We'll get some good demo stuff out there here in the next few weeks, and I'll get all these questions over to the team. So, all right. Thank you everyone.

 


#Survivorship
#rules
#communitywebinar
#CommunityWebinar
0 comments
6775 views

Permalink