Microphone. Yes. Good morning. My name is first new from Germany, but I think we've been through that already. I talked about the relationship with patients, which is part of the identity relationship management worker last. No, I think it was in may or June. We produced for finalized. That's a bad slide. We finalized the document. We find design principles management with the six design principles related to that. And what we have identified the six principles are you can see it here in the document world provable. So make sure that a relationship can be proved and the idea way around what happens if someone just declares a relationship to be there. How can I make sure that the unproved relationship can be removed?
Other part of the relationship, we have two, two entities related should be able to set a constraint of the users, usability. It might change, but we also might have a, a relationship which can change example what this is a was made by B that will never change revocable regarding the adding of relations of a relation to do that. What, what are very constraints that what needs to be taken into account? And delegatable the changing of the actors itself are the temporary, which is the data delegation or for which is really a move of the entity. So we exchange one of the, or maybe of the prediction that is all in the document. And we finalized that document, a section, the onboard journey. And would we have identified or, or plan for the next month years is to describe what needs to be done if you have, what, what, how could the relationship manager look like and how could a relationship rotation look like regarding the manager and what we have, if the entity theself and a relation needs to fully manage their relationship, you can't do that. You need some kind of instance, tote, the relations you have with other entities and the other scientist to, to enable a relationship manager to do this. You need something to describe the, the relation needed relationship notation.
When we started with that and the document itself, we have the phrase location language. When I started on this specific topic, I realized notation language is not correct because both notation and language describe the same since notation language is kind of ology. It's, it's the same with both still. We talk about notations only, not notation language. I hope I can get this and will not use notation language anymore. It's a little bit harder.
So one entity relations. First of all, the, the term entity we, the, the group, and we all talk about identities all the time. I would like to talk about entities, cause it's not always an identity, a person. It could be anything. It's an entity. It could be a machine, could be my phone. It could be a country. It could be an department, whatever. So entity we already know or talk about entity relations for quite a wide database design. So why do we need something new, the new point or the big difference on identity? No entity relationship management is we deal with disconnected entities here. So we do not have that all in one database with one table. We do have that linked and spread all over the world. That's a big difference to, to the database situation we have right now to, to point of you, help us to see what needs to be done for the patient. I think you have all seen something like this actually relationship models. It's great. It's a graphic rotation. It's great for humans moving power machines. We have different Haitians for integration models with this, from the EDIA gen ID EIC and so on.
So we already have something like that. But what we already see here is two entities connected by something for relation attention. We need to be sure or make sure of that. It first support the six design principles we have identified. We have that goal. It needs to be machine dependable and human understandable. Mark. You had earlier saying human understandable and human readable are two different things, as well as machine preferable and machine understandable. So I think it's, it's clear what this means. It needs to work for machines and it needs to work in some way for humans. We had that already and we need to support disconnected entities or remote entities who is familiar with the D I D discussion right now, going on this rooted identification. This part of it, we need this and it should be standard oriented or in the end, hopefully standard symbols, objects and concepts. We need to be able, and we need to, to find a way that the sender and the receiver of the notation description or notation is able to understand what is going on here. We have a good example here. Once on this line file is made by epic corporation, the sentence, human understandable.
Why do we understand this? Because we are all familiar with language and it has a form subject predicated object with subject Cate is, and we have an object, which is the technic operation to make a little bit more machine. I have choosing to say, okay, live bulb a is made by a that's fine. We still understand this as a human, the machine could interpret this as well, but what means live bulb? What means made up? Now we started something part of the graph theory. I'm not talking about graph databases. Now I will do in a few minutes. Okay. Right now, this is just about a relation between subject and object, subject. Ready? We have those in this view, we haves for lines and R and here you see the example from the light bulb light bulb, a and light B is made by operation. And happily enough, we have light bulb C as well, which is made by the CME, whatever entities, subject object, and a Frank Case between us
In a not, we could describe this. Like we see here, we have perfect definition. And within the perfect definition, we do have uniform resource identifier or international resource identifier, I, which gives into the direction with the stuff. And here we can describe that the previous lb, this describes using this, I E this is not, do not have to be really a website and address I can, I can check, but it's a unique identifier. That's the point with these descriptions? I can make the same statement we have seen before about our blood, a, B and C.
What we see here is already stem. This is resource description. It's a specification from 1999 within the area of the semantic web. And what we do with or can do with the RF is making statements in the form subject record object. And this is known as triple the I, or I bonds into the namespace. And we have for that a kind of concept domain. So the namespace can defined the concept of domain. I can describe things for NTA. Would it related to company a and describe, I can describe things related to the object, which might be country seeking, whatever. We just need to define that during the ire in the identifi, what we also have on top of RDF is something defined as well. Ontology language. This is now regarding ontology to the definition of the description. What is what? And O L it's not w O L because O L is easier to pronounce. It's not so O O L on top about IDF. And you see here, I have another three IDF IDSL and I can using this part. And this part here, I can clearly describe already now with link data information, what this is all about. We can grant that we have property. We have children, which is this, and can even go and say, Hey, time is made by this is property, which means I have a symmetry between another attribute and this, so this by, we can do that now.
And we can use that already with query language spark, we all, and is the same for graph database, but further more, we can dos here and have to do thiss here. Quite simple, everyone familiar with, will we about what's going on here? Spark utilize a few different things, especially for triple store. And I think this is the last slide. So we have a very language and we have notation and together, I think start is very language ation. We have standardized machine interpret rotation, which supports disconnections and remotes. And with the of theologies, we can do much more. You all use RDF on ontology. Whenever you go to Wikipedia and checking in language, checking your country, all the different information on the right side, that is link data. It's not a EDIA itself. It's link data automatically use using chronological informations and S oops. It was thanks.
Very, I just had a question you wanna say when the group meets and the schedules for the Porwal right now, we have to schedule every two weeks on Tuesday to check. Once again, the details are on the side, the, the group on details on this, we really, really, really, really need more help and more formal person people to, to, to allow us on this. What we have seen here is, is very early phase on the discussion. We do not even have really had a good route day by day, discuss all that. So if it might all help, might totally disappear the next month. What do we see yeah. To discussion. So those, you don't know it, that can
Initiative.org is the website. And then under the working groups can go and get involved in that. This is definitely an opportunity for us to get involved in starting to talk about how we deal with relationships. Right. It's it's, as I said, we definitely need help on it. And with what going do. Okay. That was my
Question.
Yeah. So are you looking at this in terms of perhaps how relationships sit in different models, like, like networks versus models where people, organizations and things like against Federation or blockchain network, or, yeah,
It's, it's this no other way. What we need is a way to struggle the relation between two entities of whatever kind it's not important, or it doesn't matter. That one thing is a person. The other one is an, or one is a person. The other one is, is a color, whatever it needs to, what we need to do for this is have a way to bring meaning into data and relations.
That's right. But that's the problem. Yeah. There's, there's no, there's no standardization in the relationship and what the ire group's trying to do. Having done the report and done the principles is dive into the, into the really fine grain detail of standardizing, what that relationship means in a different specific context, because that is that standardization thing that we, we try to dive into and it's bloody hard, but we think this is the way in which you, you can actually take, take something as a femoral, as a relationship and standardize it in a way that's, codeable, that's that's.
I mean, the there's some really interesting stuff there, right? I mean, one of the examples is, is simply if we start looking at things like, for example, ant use case, I buy a new, I don't know, ly widget people
Have life
Bulb, but something this magic black box, and I want to be able to access it on my network, but what are the things that it can connect to? What is it, what does it know about, right. What, what can I do? So either we have a big book about stuff that we have to manually type in, and each one has its own, but how can it tell the other devices on my network that it understands light bulbs or that it understands my nest thermostat, or it understands my Alexa, but these are all relationships that may be really useful. Even in a traditional retail use case. Imagine you've got a retail store and then you find different kinds of
Groups of customers.
How can it tell you this is a wedding party that is registered for gifts. That's a relationship, right? It's a relationship between different identities. And the problem is how do we propagate that without
Having
Some kind of notation by which we can define relationships? I just wanted to throw out some, some potential use cases where we could see being able to, to have a way of describing those relationships means we can utilize them across an ecosystem.
Got two more questions
Question. Good.
But beginning of your relations. Yeah, we do not have, describe what we, what we did is what we did so far is describing the language. Okay. We could say, if we agree on RDF, if we agree on, on triple stores, if we agree on apologies, then I would say, yes, we already have relationship managers on the market. They're just, just not specifically used for that. Right now,
The oncology definition means standardization seems like a very hard problem across the whole industry. That somewhere, like, is there progress being made on that process? How do two people agree on what the definition of a light bulb, like light bulb, you have features and things like that, like that whole process. And that stag seems so, so hard. Yeah. So of how do you make progress in
It is something that needs more effort. Okay. I want, we already have the efforts for that. And the linked data area and oncology, where we have a lot of stuff to find also the definitions. What is the brand? There's something like a Dublin core oncology where you have a lot of standard stuff in our daily world life defined. Okay. In the end, it needs to be an agreement between good. We have kind of that. Maybe we talked about that today, the, the in digital, single market, which hospitals in that direction to have that infrastructure.
Okay. Just say, if you a bunch of identity people in the room and the oxygen fighting definition, it's
Of the points that is, don't come up with a complete oncology. But what we do need to have is a grammar that we can talk about ontologies. Okay. Right. So each as we say, each user group, each group of interest is going to define an on that means something for them, but what we need to have with a standardized way to be able to say, these are the mountains. I understand these are the verbs. I understand. Let's, let's at least describe what Neo ontology looks like. And I think that's what the IM group is looking at is to say let's about how describe an, between entities.
