 So what are we going to do is talk about general semantic business domain modeling. What that means is when we sell a semantic media wiki that's supposed to manage corporate data, how do you convince people of that? I suggest you deliver them a wiki on a stick and start implementing their domain right away. We're going to look how we do that. And the second part is how do we implement an epostyle knowledge communication framework? That will include all aspects, forms, queries, templates and everything. So we're going to establish context for, sorry it's not, just very briefly. You have, our systems has to relay between the knowledge workers that have the information and are supposed to externalize it into some system so that the knowledge consumers can use it. On this side we have to make sure that we semanticize and structure our information in a way that the search engine that is actually serving the knowledge consumers can reach that information. That is just to establish the context. Right now we're going to talk about this side. My talk tomorrow would be about relevant search and how you do that across different resource silos in an organization. So here's my recommendation about how you start with a customer domain. First of all you start bottom up and inside out. You don't declare a class first. You start with any term. For example we start with SMCon Fall 2017. Now that at the outset is just a string. By the way this is all online on my web page. That starts as a string and you only know what it is because you've got cultural background. So now we have to explain to the computer what that is. The first thing we do is we do factorization. So SMCon Fall 2017 is a title. At the outset it's just a title. That was object oriented. Now you go to class oriented and say it's a title of what. And you say it's a title of a conference. And now just you have to accept that for the time being. We add the type not as a property but as a template name. You will see afterwards in my ontology how that works. So you include has title equals SMCon Fall 2017 as a field in a template called conference. Then you start to structure it. Structuring means you relate it to other entities within your domain. So for example MWStake is a group of users in the wiki world. And let's say they organized your conference. So you tell the conference that it was organized by MWStake. So that was the business domain structuring. And then you do facet oriented use casing. Now this is where the searcher comes into place. For example that guy wants to know which conferences were organized by MWStake. And it should return the title. That is just to show the value of SMW in a nutshell in 10 minutes to your end user. And this you should repeat until you have the minimum viable product for your potential customer. And by my experience this takes roughly and I'm not exaggerating half an hour. And after half an hour that person because the ontology I'm going to provide afterwards and you can actually download and install it on yours comes with everything included. The forms, the queries, the overviews, the faceting, the types, subject definities, regular, irregular, everything. So you will have a wiki on a stick running. And you can go through this loop and after let's say three, four iterations you have a value that the customer can perceive. And actually we started with this for Ben in Rotterdam in spring. So if you click on this link, this is the entire workflow. It takes you through the entire process of doing this with a customer. And the URL here is actually you'll find this down here. Semantic business domain modeling. Okay, now this is an epo page in my ontology. Now there's no design here. It doesn't look nice. I know that. But we're talking about the framework. We're talking about the scaffolding. It's only the scaffolding. So for example, you've got the title includes the type. I really recommend you to do that. We had a little quarreling with Sabine yesterday. She challenges me there. But imagine if I introduce a person to you. I could say this is Ben. But it's better to say this is my friend Ben. Or this is my colleague Ben. Or this is my brother Ben. There is more info you can immediately relate to that term much quicker. Because if it just says SMW con fall 2017, you're assuming that the reader already has the cultural knowledge to understand that SMW con is an acronym for a group of people working with us and so on. But here it's clear that it is a conference. Then we have this blurb as Sabine was explaining. So this is the typical introduction text that will explain to you about what's going on. This is a context and keywords. Actually I didn't include keywords yet. And you've got annotations. Now I'm sorry for introducing that term. You normally talk about properties in the SMW context. What's important is this concept can be applied to email accounts, file systems, CRM, ERP, GitHub repositories, whatever. Because we want to make sure, you'll see that in my talk tomorrow, the search engine has to cover all domains, all silos. That's another very important selling point. Because if you introduce SMW con as a great information management and editing tool, it is not so much appreciated if it carries its own search engine that doesn't tie in with complimentary resource silos. But this is something we're going to talk about tomorrow. So annotations, for example, here, we have included Rotterdam-Harbert-Tour-Yes. That's it. That's just an annotation that goes with that conference page. And for example, is organized by MWsake. Again, this is another annotation. Now very important, who knows about sub-objects here? Who is proficient with sub-objects? Okay, good. Because in my ontology, and you will see that afterwards, each annotation is double. It has a direct annotation, which is either loud or silent. By that I mean, you've got the two square brackets, property, colon, colon, value, which is what I call loud, because you also have the parser function set, which allows the silent annotation. On top of that, I'll do a sub-objected annotation. Now that means you have the subject is the conference page, the C122 and so on. Then you have the predicate, which is included Rotterdam-Harbert-Tour, and you've got the value. Yes. Now that's redundant, because we already have it silently or loud, and we're adding the sub-object. Why are we adding the sub-object? It's because of reification. Who knows what reification is? Okay, and please help me if you think I'm not explaining it correctly, but what we want is to make statements about a statement. For example, included Rotterdam-Harbert-Tour, yes, says who? Who says that? If it says, as stated by program chair, then you probably trust it in a different way than if it stated by Lex. You say, well, who's Lex? Who did you say anything? And by introducing a sub-object, you can re-find the entire statement. You can characterize that statement. And here, for example, we have that. So we have a context. Now that's a stupid example I have to admit, because it's the same page, but that's because I think I did it this morning. But you see, we're re-fying the relationship that that page has with that link by saying it's not confirmed by GM. Now, let's go to the source. Can you read this? Should I make it bigger, probably? Actually, I have a code-highlighted version of this, and if you don't mind, we're going to use that. Now, please focus on what I point at, okay? Otherwise, you're going to be a little confused, I think. Now I'm going to use my huge pointing stick. Sorry, that is not where we start. No, I prefer this, because lasers, you can see how I shake with this, you know. Okay, so this is the page we looked at before. It has a conference template, and it has these three fields. Now, some of those fields are domain agnostic. Whatever we talk about in the world, be it space travels, spaghetti, bus drivers, your sister, whatever, it always has a title and it always has a blurb, okay? Always, in order to confine to the EPO requirements. But here, we add a domain-specific property. It is organized by. Now, spaghetti carbonara is not organized by someone, okay? But here it is, and because it is a regular subject affinity, that means all conferences are organized by someone, it's included in this scope in the conference template. You see, the other two, included Rotterdam-Harbert-Tour, is not included in the conference template, because it is in irregular subject affinities. That means not all conferences in the world have a Rotterdam-Harbert-Tour included. And that's why it is going out into its own template, which is called annotation. And how this works, we'll look at it later. But just to let you know that the difference between something that is regular or valid for any conference in the world and something that is specific only for that particular conference. I'll show you quickly how that looks like. Please allow me some jumping here, maybe. This is not very... If we edit the page, is organized by, is a regular subject affinities for any conference, that is why it is so-called hard-coded in this form. It goes with the conference form. However, the others are not. So included Rotterdam-Harbert-Tour, and restrict that these are two values, are not characteristic for any conference. That's why it goes into annotations. And now you see what happens. Your information workers can add any new... So this is a tokens field, and you can add new annotations on the fly. Because your domain specialist is not necessarily the guy who administers the wiki, but the domain specialist is the field worker. And if you haven't set up the subject affinities for any conference correctly, he can add it here. Now, in the course of developing the entire wiki, of course, we could figure out that this company we're here dealing with is only doing conferences in Rotterdam. And if it is only doing conferences in Rotterdam, it is a valid point to say, let's move this annotation up to the conference template. But you have to understand that behind the scenes, it's the same implementation. It's just for the user... Well, actually, this is not something that the user will see. The user will only see the form, sorry. This. But technically, this and this is stored in the same way. Now, let's see how the template looks like. And again, please focus on where I am, otherwise you'll get slightly confused. So this is the conference template that is called. And you see that there is a hard-coded... So these are properties, right? Has title, has blurb, has subject type. These are predicates of annotations or property names. There is one which is hard-coded, has subject type. That is always conference, because, of course, this is the conference template. Now, some of you will probably say, you are not drying out your code, right? We're creating redundancy, because, of course, or let's say we duplicate code because if we add a different type, let's say event or spaghetti dish, then we have to repeat all of this. But I tell you, I've been developing this for six months with lots of trials and errors. I dumped days' worth of code, and I think, I just think, I found the right way, the right level of abstraction. So for the time being, you just have to trust me that this makes sense. However, if you, and just to give you a glimpse, this is where you can download the entire ontology. So this is my Dataspex DSKMF Core Ontology GitHub repository. And you can move this into your wiki and play around with it. And if you have drying out ideas, you know, make it more efficient, then I'm more than welcome to, or you are more than welcome to let me know. Okay, so what goes from the template call? Again, we've got the conference template with three fields, right? Now, those three fields are obviously, of course, used here. Has keyword, has title, has blurb. Now, since these three property values will be domain-independent, right? Any topic in the world has a title, a keyword and a blurb. We move it out into another template, yet we get to this afterwards. So this is nothing specific, right? So we just pass it on. We take it from the left and just pass it on to the next template. And I think media wiki allows cascading templates how far? Two, three? Do you know that? Okay, so two or three. Yeah, it's almost infinite, but you don't want to... Exactly. But don't worry. That's the only... This is one, okay? What do you mean, forms? When you use template form definitions or...? So you've got nested templates. Yeah, okay, yeah. Oh, well, then I'll be... Because this is how I did... You see? Okay, just... You flatten it out, it's fine. Yeah. So 40. Wow, okay. Now, you don't want to do that. Just because you can do it doesn't mean you want to do that, right? Okay, so these three template fields that are passed from the instance, from the instantiation, we move on to metadata. We get there afterwards. The others, for example, is organized by, goes into the annotation template. And that is just a... Okay, give me one minute to explain something important. I do not use categories. I only use categories on a meta level to organize the code, to organize the ontology, with two exceptions. I have a keyword category and I have a topic category. Of course, you could use categories, but it's probably... It's not as flexible as properties. But here, in order to gain an overview, because I want... I'll show you the list. No, I'll show you afterwards. So just forget all this no-include stuff. It's anyway... It's not important right now. So as we saw here, we have this annotation, right? So these two fields go into the annotation. You know what? This is wrong. Forget this, right? Just stay with that at the moment. Okay, so this is the... Let's go on to the conference form now. We have different topic types and we want to make sure that we keep the form definition code as coherent as possible. So what goes into the form definition page is only the info section. And of course, we've got duplication here, like conference, conference. You could do that more clearly, but this is not a big issue, okay? I mean, we will survive this. We'll not kill our weeks. But then, form header is a template call and we'll see what that means afterwards. And it only has one parameter and that is the name of the form. Why? Because you could theoretically use page name, the magic word page name. But the problem is that the magic word page name goes to the name of the instance and not the name of the form. So that's why that wouldn't work, at least with the current implementation of the magic word page name. So we pass this and then we have standard form sections and the form footer. Now let's quickly have a look how that looks. Where is it? Oh, sorry. It's up here. No? Okay, never mind. You know, the mouse is not working on this surface here. Ah, let me see. Sorry, I have to prepare this quickly. A what? No, just a cardboard would be great. No, I have a mouse. The problem is the surface is not a mouse pad would be great. Oh, that's a great idea. Thank you. Okay. So we're looking at the form header. Again, the form starts with the info section, which is trivial here. We only have the page name and it's got a unique random number of 10 digits. Now, the form header. Now, of course, I should have prepared it better because you have to escape the curly brackets and pipes. Otherwise, it gets confused. Do you know about this problem, all of you? Is that clear to everyone? What's going on here? Okay, it clutters up terribly, but I'll do my best to explain it anyway. And also, ignore the switch content lang. That's my very cheap multi-language solution. So in German, it's a title, and here it's a title, and it just goes to the magic word content lang. So forget that. Okay, so this is the first field. Field has title input text. Super simple. Then you've got the... What is that? Has keyword. Input type is tokens. And the values come from the category keyword. That means in the form, it suggests all the keywords it already knows. Okay? That makes sense, otherwise you will... But you can add new ones because that's input type tokens. And then you've got very trivially... Has blurb input type text area. And now that is super exciting. Text class form text area. Does someone know what that means? In order to reuse it. Because you see, for example... Let me show you what that means. No. Look, on my wiki... So this is my wiki, and I have... Oosh! Wait. That is not... Look, that's so funny. It hasn't happened in months. And it happens now. Is someone on my site like a law... Ben, are you hacking my site right now? So you see, I'm dealing with applications, commands, method, architecture, articles, and so on. And here I have the building blocks. There's always this template and this form I explained before. And I don't want to repeat... Has title, has blurb, because they all have that. So you should really dry out, and you know dry by dry we mean don't repeat yourself. Make sure that your code remains very clean. Where is it? Are we here? Where were we? Oh, here. Okay, so that was the form header. And again, no include is only a way to organize it. You can always forget the no include. Then we come to the standard form sections. Now this little guy is the end of the introductory table. You get that? We're beginning a table here. First row, second row, third row, another row delimiter, and there's no end to the table. Because that comes here. Why? Because as you can see here, we have the form header that goes until here. And we don't close the table. Why don't we close the table? In order to be able to add fields that are type specific. You understand that? Because whatever goes here should be anything that is totally specific to a conference. To the maximum, okay? So that form table here, title keywords blurb, is general to all topics. And only this is specific to conference. And the way to dry that out is to open a table in form header, add another. So this is the TH on the left, and that's the next table data on the right. You can add anything here if you want to add more regular subject affinities. So now this is closed here, and we end the template. So the conference template is now closed. Then we have the standard input, which is free text. And again, class form text area. Does someone know what that means? That is the most exciting thing since sliced bread, I tell you. Because it adds the Wikimedia visual editor to any text area in page forms. The thing is, this is not entirely working yet, but Yaron, in the back of the room, is coding right now to make that happen. So this is a French guy called Pierre Bonnet, and he coded an extension that allows to add visual editor functionality to any text area. So that's the form text area thing. Then rows, that's clear. Then we've got the... Okay, now we get there. So remember I said you have to give the user the capability to add any annotation at user time. He shouldn't call back to the Wiki administrator and say, I need another form element. I need another property. He should be able to do that on the fly. That means we need form functionality for that. And the form functionality is tied in by a template called for template annotation. Now, keep that in mind. We're going to finish the end of the form. For template context is identical to this, just with context, or forget that. It's just template annotation. And we're going to first close the form here with header tabs. Header tabs then allows you to have this little section on the top right to organize that. And then it's summary, minor edit, save, blah, blah, blah. This is all general stuff. But could you see how we dissected the form elements and made sure that when we add a new type, there's a minimum of things that are repeated. An absolute minimum. And even if we had to make it more or smarter, we could pass more fields or arguments to these template calls. But actually you don't want a lot of arguments in any method calls, in any programming. So this is the cleanest way I've come up with. Now, is there any question here? Good. Then let's go to the for annotation for template annotation. Now I know why I did this. I have a question. So just to make sure that I understand I'm following the overall hard coding entity or conference. But you're allowing users to develop annotated properties on the fly. Yes. And so that model, once you've done it for a conference, you can reimplement that for any other type of entity. Exactly. And you know why I do that? Because, OK, ontology-wise, there's two levels. Assertions and terminology. Assertion means the website, wiki-ahoy-anté, provides a certain website, sabines, spaghetti recipes, whatever. That's an assertion. But you have a terminological level that derives what your business is all about. So the cool thing is you provide a basic structure to your customer. They will work for it with it for, let's say, half a year. And then you derive the terminology from all the annotations that the end users added. That is super cool. It's fun because they say, whoa, our domain makes use of a building block? Never know that. So then you look up who actually declared. So this is on my system. I've got six domains, four repositories. And twice, somehow, some domain makes use of some repository. And these are actually, well, this is a screenshot. But these are links. So you can click on it. And then it shows you the facet, which relates these two. This is just to quickly explain to you why I do this annotation stuff so flexibly. Now, here. Now, this gets really interesting. And it's not really digestible. So we're talking about this guy now. This is an annotation template call. And it passes these two property, I mean, field values. Now, when it's called, first of all, it makes sure that it actually has a predicate. Otherwise, it will say error missing annotation predicate. That will show up on the page. Then, forget this for the moment. I told you that we have a silent annotation. So we are setting a property to that page using this annotation predicate, include Rotterdam-Harbertor and annotation objects. And this is here. And the separator is a semicolon. So the setParser function allows for multiple declarations of properties in one go by separating this. Now, when do you use this? Well, you should use it in order to make it nicer for result formats to be able to display these results in a more beautiful way. You should use that. However, if you want to reify, yes, differently from restricted, let's say Ben said it's included, but Lex said it's restricted, then you can't do it like that. Then you have to add a second annotation, which carries the same predicate with a different value. Good. So this is the set part. And then we have a manual sub-object. Do we have that here? Oh, yeah, to the right. Sorry. You know what array map means, right? It dissects the string and then... So by the way, this is online. No, it's not. No, that's local, but I'll put it online. So we turn all these object values, that is yes and restricted, into separate sub-objects. No, but that means it's... Okay, never mind. What's important for the time being, and we'll go into more details later, is that we create a sub-object with this annotation predicate and the annotation object. And here you see the ratification potential, because we can add any number of further properties to that sub-object. So here we could say, says who equals three, and three would actually be, says Ben, says legs. And then you've got it reified. And then you can ask the wiki, give me all statements that have been said by Ben and discard anything that was said by legs. Okay? So that becomes possible only with this approach. You don't need this approach to actually be able to just use the semantic media wiki in a classical way, of course. But it becomes very important when we look at search tomorrow, because it enables a lot of functionality there. So this is template annotation, and the manual sub-object is there. Now we were looking at, as you can remember, this. Four template annotation. And we are talking about this part. Okay? Now how is that done? Again, it's a terrible cluttering with this no wiki stuff. But you've got multiple annotations. And then you have a form table. And this was Sabine's suggestion in order to read nicely. Right? Now this here is the page title. It's actually completely unnecessary. But it reads nicer, right? Because if we read it like that, Conference SMWCon included Rotterdam arbitrary, yes. Because if we skip this, you have to mentally understand where you are and so on. So this makes it more comfortable. And since we are using display title, we're just using getDisplayTitleParser function on the full page name. Because, by the way, you should always use full page name and not page name. Why? Because if you are using user pages, then that will fall apart. If there's a user, I call on Lex, and you use page name, it will look for Lex instead of the user Lex. So just use always full page name. It will never be too much. Then you've got the annotation predicate, which is a combo box. Combo box allows you to select existing ones but add new ones. And that's exactly what you want to do, right? And the values are coming from the property annotation predicate. And now you understand what... No, actually that's the reason why we need sub-objects. Because otherwise, how do you know which properties are there? Of course, you could go to the property namespace. You could say, give me all properties from all namespace. But this allows you to further restrict what you're talking about. So let's say you've got properties that you use in a meta way to organize your content and not regarding the content. So this is part of the sub-object. You can really nicely set the granularity of how you load these or preload these values. And then, of course, you've got the annotation objects and that's it. So let's have a look how that works in practice. So here, I add... What should we add? Provides lunch. Okay. And then we put... Maybe. We store it. Maybe. It's loaded as provides lunch. Maybe. Now, I'm not... Premature optimization is the root of all evil. So what is not done yet is, of course, the wiki should turn this into a property page automatically. But that's not done yet. So let's do that quickly. So of course... Oh, no, I have a form for that. Sorry. Provides lunch and then you can add the type. Let's say it's just text. Constitution, forget it. That's something else. And then we save it. And this is our property dashboard view. Okay. So you see all statements for this property. Provides lunch. We've got conference SMCON fold 2017. And if we go back here... Now, of course, it provides lunch. And you can see how tremendously flexible this is. This is a general setup that can serve anyone. A cook, an astronaut, whatever. Right? Will always work. And now the typical use cases... Where do we have that? There are use cases by the user. The end user that provides information. First of all, we want to make sure it can use the visual editor for page form's free text. That's the first requirement. Then typically he wants to add a subject. And by the way, adding a subject is... Now this is my test wiki here. So here we've got the subject types. And so this is one of the main use cases, of course, is to add a new conference. And of course, we are again at this form. So that is one thing, one requirement. The other one would be to edit the subject. That's covered by the same means. And he wants to add... Okay, this is super complicated, but it's just this annotation. It's a subject type induced irregular subject affinity. That means a conference is typically organized by someone and that end user, not the administrator, wants to specify that. And we do this by form. And I have also a mechanic that can do that in line. That means anywhere in the text, by a template. Of course, you could always add a loud annotation, but then you don't have the subject functionality, which is not a big issue, but you forego a lot of functionality there. And then the use cases for the administrator typically is to add a subject type. And what he has to do, for example, he wants to add event, he has to add the event page, which is super trivial there. So we're talking about this page. And now this is, again, there's no design here. Any Italian would go crazy here, but just for the time being, it's just mechanics. So the conference page here, and as you can see, this is an explicit word. This is not a number. Why? Because it's fundamental. This will never change. It can be done differently. I had it differently, but it was cumbersome and not necessary. In about four months, I never came across a use case or situation where it made sense to have the topic type with a display title. So I just use this. There could be, and then we have to change it. But for the time being, we're fine with this. So you add this conference type page, and the content is extremely simple because it's just component type 2. That's actually on my wiki. That's trivial. It's just ask query and a couple of links. And this is something that I never used. I just put it once that you can put keywords to conferences because obviously you can reify the type now. You can annotate not only an instance, but a type. You can say conferences are inactive with our, let's say, postponed. All conferences are postponed. And then you add it here, which is then inherited down to all the instances. So that's the conference, sorry, that's the type page. And then you've got the template and the form, which are minimal as we saw before. And if you want to add a subject type induced regular subject affinity, you only have to edit the template and the form. The template is the annotation assignment and the form where we saw, as you can see. So we're just talking about these two files. Oh, we have to deal with metadata now. Okay, is it that's more or less clear? Okay, now let's have a look at this. Now that is a huge set of functionality. And by that I mean the biggest one I have, it's this. So what goes on here is we have, so sorry, what we're talking about is this part. This entire set of header tabs, right? How does that, how is that created? Well, it's a table. It's got a table of content. It actually includes the table of content, sorry. And now we're talking about it has the blurb, which is optional. So we have an empty default value. Then you've got the keywords, which array map the keywords field that is passed from here. Oh, sorry, I didn't use keywords here. Anyway, it would be one of those, right? That's easy to understand. Then you see here is where the annotation takes place and it's loud. And there's no sub-object. We could even turn keywords into sub-objects. And then you could say that keyword is only valid until next Monday. Or it will only be valid during Christmas or whatever. You could reify a keyword annotation. But again, we don't want to, you know, make it, we have to make sure our ontology is mutable. It should not cover the entire set of whatever could, someone could come up with doing, okay? That's why this is actually the only place where I do loud annotation. That's this, then we have, okay, now that's a little stupid because this is my, I did this highlighting myself and the regular expression is swallowing what's here. So we should look at it from this part. Okay, now we're here. You're asking for context. So we're talking about, show me the keywords and the context. So the keyword is this, the array map. And then we have an ask query that queries the sub-objects that has the property has context. And it is then passed into a context result item template. Let's see what that contains specifically afterwards. And here we have the annotations. Okay, again, this is more or less the same. It asks for the predicate object type. It sorts by predicate and it passes it into the annotation result item. Then it does a, that's actually not necessary. It asks for this page in which context are you appearing, right? So if we have colleague Lex is in context, mwsteak and smwcon. So this is just one of those travel, how did you call that? Travel along. Yeah, exactly. So that's one of the paths of transportation system functionality. Then we've got what links here. This is classical media wiki functionality. Nothing special here. And then we have three or four very important lines. You can see that we dried out the default form declaration to the metadata template. So the direct topic type template doesn't even contain this because we take it from the metadata template call, okay? And here you see category topic. That's the second, the only, that the second of the two only places where I use direct categories. And then we even have synthetic, oh yeah, this is a synthetic property. Look, you've got the display title that is composed from has subject type and has title. Then you have has title which is set directly, has subject type set directly and has type and title and it gets this display title again. And since this is called after this, it's already available. Now you could ask me why do we need this? This is what we need for the elastic search index that we're going to talk about tomorrow. It's just making relieving elastic search from work, okay? So this guy already does it. And that's it. So a lot of functionality is coded out into this single metadata template. And now just to show you, so this is the set of artifacts, forms, templates, properties, whatever, that make up the ontology. I highly recommend to you to manage that in a GitHub repository. Why? Because MediaWiki is not capable of grouped versioning, okay? You can imagine that all of these pieces need to work together. And if I start changing here and here and here, that means they depend on each other. So if you don't have that functionality, you're going to end up in a huge mess, right? So that's why we do this in a GitHub repository. And I can show you how it's deployed. Now that code is not yet here. This is a software tool I wrote. It's not yet ready for use other needs babysitting by me when it's used because it's not clean yet. But it allows you to specify either a GitHub repository or a local repository. And then declare, let's say this is now Sabine's wiki, declare a wiki where you want to inject it into. And then you just go through all the files of that GitHub repository and you store the object in this wiki. So I can, as I said, if a new customer calls me up, the wiki is ready in literally a minute. The basic, okay? I mean everything you need to go through this. And you can actually do that in front of the customer, which helps you qualify as a trusted information worker. Because they can see that you're doing it right away. Okay. Look, it's 11. It's great. So, yeah, that was the basic overview. I'm not sure. Do you have any shortcomings, questions that I should? Should I explain something in more details? Well, what's important to understand is that there's actually three roles. There's you, the wiki specialist, and you set up the entire system. With the code, for example, that I just showed now to inject the entire GitHub repository into a wiki. So that's your task. And then maybe behind you there's even the ontology developer, the ontology engineer. But what is seen with your customer, you typically have two roles, the end user and let's say the power user. And the power user is only covering two use cases. That is adding types or adding properties to types. So there I dare to say it's pretty easy. I can see where it gets complicated, but it gets only get complicated at the very back. And of course the end user just sees the form and nothing else. And even if you have visual editor enabled in all text areas, then it's literally a WYSIWYG experience. And I really hope that Yaron can finish this at this conference so we can show it to you. I had it hacked together, but it's such a hacky thing that I rather not show it here, how it's done. Because so Yaron should incorporate it into his. So actually the answer is no. This is the abstraction level that works. And you know, if you get too abstract, it's easier, but it's rigid. And if you get not enough abstract, then it's super flexible, but then you're down to coding every bit in pieces. But I really invite you to try out this and let me know whether you find ways to move functionality, you know, dig it down into the ground and hide everyone from it. But unfortunately right now this is the simplest way I've found yet. And the goal is to have a reusable domain agnostic highly flexible ontology. And that's how it is right now. You mean this? Actually, you mean, yeah, yeah, this is the exclamation mark for pipe escaping, right? Yes. That I use sometimes, but here I thought since because that won't be possible here. No, you know why? Because since this is a template, it will think this is a field. Okay, I understand what you mean. Yeah, I understand. Okay, okay. Oh, that's a good idea. You mean similarly to the exclamation mark for the pipe. That's a good, no, but let's try that out. That's interesting. However, you know, this instruction comes from page forms. I mean, Yaron explains if you want to have reusable form content, you have to escape these and the pipe. But that's a good point. Let's try that. Okay, let me see whether I understand you correctly. You have, since this is a template, you have to escape these three curly brackets because for a template, this announces a field name which will be replaced by the field value. But in the context of a form, this is not a field. Okay, now that's unfortunate because it's field. It's called field as well, but it's a form field. It's not a template field. And in order to do that, you have to put either no wiki or replace them with HTML entities, right? That would be possible as well. But then that's even worse. That's really ugly. Yes, yes, yes, because no, look what you're referring to is you see this could be written. Like this. Okay. And now I think what you are suggesting is to have something similar for this. That would be wonderful if you're right, but I trust, can you try that out? Okay. Sorry? Well, I would be very happy if that's, I don't know. What's your idea? Yeah, if that works, never tried it out. But you see, I don't really mind about this mess here because it's only seen by me anyway. It's not even seen by the customer's power user, right? It's only by the fundamental wiki engineer. So that's why I don't really, I'm not too worried about that. But it's still a good, it's a good point. We should. Okay. That's it. So far. And maybe if you just want to have a look. That is so funny. You see? Here, Yaron says you have to. And then you've got these two, either take the HTML entity or no wiki. No, no, no, that, that, that's horrible. I had that before, but it's really, that's even worse. But you know what I normally do is when I develop the wiki text, I take it out and I replace all the no wikis with nothing in VIM, then do everything and then when it works, I re-encode and then you have it. And since you're not, you're not doing this every day, you know? And if you're doing that once a year, no one cares about the extra five minutes you spend on this. The important is that you don't have to do that when you add types. Now that would be bad, okay? Okay. So that's, and that's the page from the first part, which actually still has been as an example. Have you seen that? There you go. It's a, you see? It walks you through the entire process. Okay. It's a category that you can establish, you know, the universal, every page properties, title. And then after that, when users are creating instances, they are creating, they are adding the properties beyond the core, you know? Exactly. Okay. Exactly. So you find that there are users, two questions come to mind. One is how would a given user find out what the most common properties added are? So like most conferences will have the social gave out or something, you know? And so that is always to be manually added. Is there a way that the system could suggest, you know, things with the things that most people add? That way, you know, you don't have discrepancies between what people type. Well, you wouldn't have that either because everything that is added is automatically suggested next time. So that's the combo box? Yes. Okay. Yes. The question is, is it possible that, and I'm thinking, I'm sort of stuck in this mentality of, you know, class kingdom, I don't know what the exact word is, the parent child. Yeah, yeah, yeah. Okay. And so for me, the ultimate application that I'm looking for is something like inventory management. And for a given piece of inventory, it may have a property that is actually its own entity. For example, some items we may track with an external database for asset management, you know, cost and, you know, how much it's worth to the organization. And other items, you know, are petty and don't qualify for that. So what I'm wondering is, is it possible, like what I've seen you describe here, sort of such everything is either a core property of the entity, or it's an on the fly user annotation. Is there a way that users could annotate a subcategory where maybe I would select something and it would pair it a whole set of fields that would need to be filled out because... Oh, yeah, yeah. Because of course you can have auxiliary templates, right? In a form, let's say, um, here, you could say anything that is shared, for example, across three entity of three topic types, but not all, you put in a template and then add it either before or after standard form sections. Okay. That's the modularization approach. Yeah. So to the extent that all of this is mostly ready for users to download and use, that would be something that would have to be crafted. Yeah. I mean, the moment you identify that you duplicated code across, let's say, four types, once you're bored on a, you know, given Saturday afternoon, I would code that out into a template and then call it in. There you, there's unlimited ways of organizing that. You just have to make sure you're not overdo it. You know, sometimes duplication denomalization is a good thing because it makes you understand it better, right? Well, I'm thinking in the Venn diagram, you know, that can't be changed. Yeah. Some items must be tracked with some kind of pedigree process and other items are sort of tracked ad hoc. And so if you guys will forgive me for introducing some concepts that are personal to me, a piece of inventory may be instrumentation. And that instrumentation, maybe that has to be calibrated. And so that calibration, all the attributes that would come with the calibration are part of a whole separate workflow tracking system. Yeah. So all calibrated inventory is inventory, but not all inventory is, requires calibration. Well, actually, what you're talking about, oh, where do I see it's still in its infancy here. That's, that's a concept I haven't implemented yet in that ontology because there is a difference between a type and a role. So this is a person. Yeah. And it's only a certain context that makes it a painter or a coach or a mother. Okay. So in here, we would add, let's say this was this lady we saw, it would say person, first name whatever, and then mother and then number of children. So instead of the participants. Forget this. This is, this is just, it would go in between. Okay. It would say mother painter coach with mother, it would have number of children. You know, a person doesn't have children per se. Okay. So the participants section has an annotation and a context. No, forget this. This is unfortunate. This is the, this is free. Yeah. Yeah. Forget that. I'm sorry. I have to, I have to change that. Okay. So you're saying it's really just the multiple. Exactly. Exactly. You get a template for each facet that you're talking about. Yes. Facet the right word. Facet, yes. A role. It's an aspect. Exactly. It's an entity role. Actually, what's interesting for you to read, but it's, where is it? There. This is complex to read, but you might understand it now pretty well. This is the whole story. So the concept, every page is page one that you have that this is online. Okay. What Sabine was introducing is based on topics or subjects or buys or whatever you call it, and they all have a single types, but can assume multiple roles. Yeah. But it's important that it is a single type. Okay. If you point at me, I'm not a presenter. I'm a person, but I assume the role of a presenter, but only until another 10 minutes. And after that, I'm not a presenter anymore. That's why it's not a type. Okay. And then it has regular affinities. Regular affinities are pertinent to the single type or multiple roles by a general cultural understanding, not by context, not by domain and not by whatever mood. Okay. And then they're tagged by keywords. This is just my sort of first line of attacks. And the keyword is by definition untyped. You cannot say conference SMW con is a keyword. No, it's not conference could be is a keyword in itself, but not in combination with an instance. And then irregular affinities. That's what we had, you know, when your coworkers add information or annotations that you were not forecasting, it's put into several contexts. Active and passive actions is something that is not yet implemented. That will come. The idea there is when you surf through, how did we call it the transportation? What was it? The transportation rules. So you surf through your domain. One important thing is what can something do and what can be done with something? Okay. So let's say a printer. So in an office context where the wiki manages equipment, you can say a printer has active actions. It can print. It can shut down. It can power up. It can fail. It can whatever. And it has got passive actions. It can be transport. It can be bought. It can be discarded. It can be sold. It can be cursed, whatever. Okay. So my idea is that there's a way to add an active action as a template call to an object which then serves as a very convenient faceting thing. So you could, for example, I guess in your domain, there's many things that say what can be cleaned or what cannot be cleaned and has to be thrown away and repurchased. Okay. So this wouldn't be, how would you encode that, right? So first of all, you would maybe say, okay, let's put a property called action as, or can be cleaned. That's one way of doing it. Or you add an action. Because the action as itself is then refiable. But, okay, that's just an idea that will come. And then, yeah, that's it. So this is the entire story of my, this is actually the pedigree of my, or the provenance of the entire. So in my world, we have a culturally talk about roles as if they're types. And so, you know, in the implementation of this ontology, right, I would act as the ontologist, I would have to learn to take all of the things that my organization talks about as types. This is safety equipment. This is calibration equipment. And I would have to start decomposing that and separating types for roles. Yeah, but I mean, you can skip the entire role concept. Well, just use types. Declare everything as types. Okay. And then once you come across a use case where you say, well, now it would be good to sort of move out a role. Then you just alter the entire terminological and assertional ontology. What I mean is the templates and the instances. Yeah. And if you do that programmatically, it's not an issue. If you have to do it manually, yes, but not programmatically. Okay. Imagine if you wanted to set up another type called presentations. And so, you know, you type, you know, you data collected all your conferences. And now you're data collected all your presentations. And you're trying to tie presentations to conferences. And so that would sort of create the parent-child relationship, right? Just any relationship. Okay. That's the thing I have to break my mind. You know, there's no hierarchy in a semantic web. It's only a relationship. But of course you could, you know, I imagine a semantic web is a couple of entities spread out on the floor with relationships. And if you want a facet, you grab two relations and pull. And what you see then is the facet. And of course it's hierarchical when you look at it. But the moment you drop it again, it becomes flat. So you just add a, this is what I was referring to by this structure. Sorry, a little lost with my, you see here. You either put it as a regular affinity into the conference template or you add it as an annotation. You're free here, you know, and you have to try out several, I mean, the way I developed this is not by thinking. I just put it and then I, you know, got a feeling is that comfortable. And after a weekend, you know, if I resume work on Monday morning, does it flow or do I have to reason out what I was doing? And this is, so yeah, you would just add it here if it's pertinent to conference. So there is some learning, right? I've come into this whole paradigm with this kingdom, family, genus, you know, with this Newtonian ontology myth, you know, idea. And letting go of that is a process of this. Yeah, but there's so much flexibility in the semantic web when you just don't think of parent-child. I mean, you could, you could, of course, you could put here has parent, but the system doesn't understand that the parent comes before the child. It's just, you would have to code that. And the one too many is an outdated concept. No, it's a human concept. It's how we think. But if you want to design a system that is flexible and resilient to, because if you start to think hierarchically, you will end up in dead end streets. Yeah. And then you will be really annoyed with yourself because you thought, hmm. complexity, roles that different people found is that by the time you come to the subject matter experts, they're not able to work in an ontology. They, they, they, they give it, they give it an ontology that can complain about it. They're not, they're not going to do this. So the, the question here is, what are the, the roles which I think is the right, right working, the roles of the participants in developing this? We've probably got somebody who's an ontology specialist who's, who's looking at the brain and doing model, if you want to call it that. You've got people who can, can add things, but not everybody can add because they don't know conceptually what they're going to do. There's a lot of people who give them the final structures and can enter the data. And that's why I think it's not there if they don't care about it. So I'm wondering about this separation of the skills in, in this process of, of getting this in stone because I'm thinking, what I found is that you've got to give people a form, pretty much, and they will kill the day. But you ask them what else is needed, and that's a very difficult question for, for a lot of people. Where, where is the, the different players in this implementation, and what skills do they have to have? Well, so, I mean this would be the editing view of the end user, the subject matter expert, right? Well, the default is this. And he, you know, if, if for example, we could put a notation, I mean, look, we could say instead of this, if we wanted to semanticize it, we would put has, has participants, and then it's you, me, and R2, D2, sorry, when, when I don't have my, so. That was a very difficult process. You just showed there, somebody actually did something that a concept was missing from a wall. Yeah. That very difficult for the most organization, for the organization. So you have to give them either the, the, the menu of a lot of, which I think is what we feel like, the menu of a lot of things. Or you're into some exception process that then has to go back to somebody that's, that's concerned about whether entropy is happening on the concept, on the concept map. The moment you allow somebody to add a new concept, back up, you, you've got chaos, but then you can regenerate it into a chaos system. Well, but this could be monitored. Yeah, you can monitor it. Right. And it could be a suggested topic. It gets added, and then it gets, it gets approved, or. Exactly. Because, you know, this will. Yeah, this will tell you. This will tell you who added an, an annotation. And since. I forget what you just said. The, the, the issue here is to do, is to do with how, how do you, something needed to be added. And does that one user make the decisions in semantics of what it was that's added? Or does it get referred back to somebody that's dealing with the whole ontology? Say, wait a minute. We've already got something that is equivalent to that. We should be using this. And so I'm concerned about the. Yeah. The nature of the, because I've seen wikis just destroyed. Absolutely destroyed by, by, it's up. It's up. You can add your stuff. I think, I see the complexity here in the way it's put in, the same type of everything. But if you, I'd be more worried about missing this first idea than, than, than the way it's putting it in. So if you, I don't know, imagine in a simpler way your product, whatever you said, I was missing color. We actually need a field. And in the field in my little database, I wanted a field that says color. I need a point of color for you. So if you have an option to somehow write it down and say, I need this here in work, or it's there. The idea is there. So I'd be more concerned about. Maybe it's in the chat. I mean, I'm thinking that it's in the chat that you do this. Not in the, in the actual form. So it's, it's the user's saying, I don't see where I can put color in here. So how, how does that, how does that get resolved? And, and I'm thinking it's more in the chat mechanism, which we've got. We've got all this wealth of, of, of collaboration mechanisms here. Who, who is it that, that would sort of direct this? And then I think it's the chat mechanism. I need color here. I need, you know. So I, I gave you some examples on how we do it on the NASA side. Going back to your comment about roles, I think that's a big part of what, what has worked a lot for us at the NASA Space Center NASA side here is that we have kind of in the user, so the probe user or advanced user where we have people actively in the enterprise community that folks can either in the discussion page or come after the ask age that you really ice it on the form pages for inventory to add a date for calibration. And since we don't need to go contact our one wiki administrator, this is something when it comes to adding things to forms and then that we can analyze because we don't understand how it would work. So that's how it's kind of grown organically. Now we don't catch everything. There are still times where we're using just dumps on our page. And we have to be okay with that happening and then just catching them as we go along. But the more users you can have that understand the concepts of how the forms are built and templates are built, I think the better chance that you have to just incorporate these additions and make it better. Because I think when you only have a few administrators, they can do very complex things and build a great starting structure with the base of the form but having kind of a mid-level user definitely helps on adding and making revisions. I agree. It's your mid-level users. It's when you start to fragment your mid-level users into different silos that the problem then starts. Now you're getting experts and they're going to make a decision in their silo. So how long does that work back in the collaboration across whatever the scope is to consume it to enterprise? Right, enterprise-wide. So a thought that I had is looking at the page in front of us, there's wanted red links. And so it seems to me that if you went to the special pages, you can click on the link of wanted properties. And so it's possible that if it were you, please, let us know. Is it possible that the average user does not have rights to a property's namespace? And so the system that you've implemented will only let them create properties that are wanted. But then a site, a super user, could then monitor the wanted properties list and disposition the wanted properties. You could disable this page for the average user. It's still left as a wanted property in a wanted property list. Yeah, that's actually nice. I was thinking in the chat that that's actually more specific. And if the middle-tier users actually are watching, I'm not sure how they watch to get the alert that this has happened. That's really important. Yeah, the layer, there is popcorns in the layer for you. So we do it just by occasionally going to the special pages. Just pulling it. But we all have the alert system currently. It would be nice to have something that sort of alerts on a wanted property or something like that that you can apply a watch list to that. And then you're starting to get notification. Exactly. So when I've talked to my management, one of the things that I've always told them, and I show them the W3C graph of the two axes of semantics of social connections and the semantics of knowledge connections, is that a plot that everyone here has seen? And so it charts the process from like the early 90s of the PC era through Web 1.0, 2.0, you know, the semantic databases. And ultimately where we're headed with all of this is intelligent personal agents. And so what I try to say is, you know, if you commit to migrating knowledge management to this kind of environment, then what you get in the future is the ability to automate all of these reports. And so every person, every user that has different questions that they want to ask of this semantic database, this fabric of semantic data, then there can be background processes that are constantly creating time reports. For example, the wanted properties, you know, you can imagine some backend thing that's mining the wanted properties and alerting the right people. And it does my work. I think that's a nice, I think you said the agent. I talk about it as a personal dashboard. Okay. In other words, when you're wondering, what do you have to do? You come in the morning and you've got your coffee, and you've got these four things. And you say, what am I going to do? And you want to go to the personal dashboard. It says, oh, I've got three things in under edit. I need to finish those because they're visible. If I don't finish them, I'm going to be embarrassed. And I've got these other things. I've got another that's coming from somewhere. You need to build those things for the management, which I think is your concept of a personal agent or a wizard to guide you into the focus. From my perspective, I think it's more and more creation. And I actually accept the risk. Everybody's got their own viewpoint on how it works. And they might be wrong. They might create something wrong. It's always something wrong. But you've got to be monitoring it to keep it. But I think really all the two of them are new systems where you just want to do anything. And it actually, you know, it prevents you from actually being involved here and you can come up with great ideas and actually get something out of you or never before. I think it's really important. There's supposed to be a fixed system. But the systems got to evolve. And the evolution comes from this. On the other hand, you don't want a penalty. And the penalty basically takes you to chaos. And then you sort of hand it off to value. So we need to cross that balance. Yeah. I think we're going to be able to handle it. That's right. It's a different style of wiki. It's a wiki burn of it. And then all you've got wiki for enterprise management and enterprise knowledge. You go to the wrong side of the balance. You sort of feel it. It's too controlled. You lose the innovation. And the system loses its ability to adapt to the situation. It's another way to get a project to come up with such an integrity. You see, what I recommend is go to the API and use that to control whatever facet you want to do. I mean, I make very little use of all the pre-programmed special pages. That's the quick solution, of course. And it's a good way if you need some quick insight. But otherwise, I code everything from the API and then you have the entire freedom to whatever you want, whatever you want to do. But coherence is a huge issue, of course. But this sort of supports coherence management better than nothing at all. This is huge. I would say. Exactly. If I wanted to test this today, how easy is that? Well, since this Ruby code that deals with back and forth is still under my babysitting, because it's not nicely coded yet, you would have to give me access to your API. And I can... I just do it from my computer as a workstation. No problem. You mentioned that you don't make use of the special pages, but I'm wondering, is it possible to go to the export pages? Of course. Look, this hasn't altered anything in the wiki. There's no extension involved. I mean, of course, semantic media wiki page 4. But I didn't code any extension to deal with this. The only thing I used, but I didn't explain it here, is some Lua, you know, Scribuntu? Who is using Scribuntu here? I use it for gadgets and things. Yeah. So... I was trying to load the string module, and it broke my wiki, trying to get the string to run. But just to make the point, I'm not altering any wiki functionality here. But one thing I'd like to point out to you is this. The semantic media wiki for Scribuntu is called... So, in any case, MW James has come up with an extension, or it's incorporated in the new SMW, I mean, semantic media wiki extension, that allows you... There's a Lua sub-object method that allows you to declare annotations in Lua. That is extremely useful. Because we sometimes come up with cascading, you know, sub-query, sub-annotation declare stuff, and it gets really complicated. And this is then an easier way. Is that a property chain? An object chain and then a method. This? Yeah. I'm not so familiar with Lua. So this is just something that sort of works. Is that a module? Yeah, that's a module. Okay. So does that have to be exported as well? Yeah, it is. So this is part of the ontology. What's probably more interesting is the motivations. The idea behind motivations is I'm using use cases, workflows, instructions, recipes, you know, in this Epo style, or information about how to do something. And you Americans have the perfect expression for that. Because when I say, should I get a ThinkPad or an Apple? The answer with this wonderful formulation saying, well, you want to make sure that, and you want to make sure that you get this, and you want to make sure you're not getting this. So what you're actually telling me is a motivation for something. So I started linking up stuff on the wiki based on motivations. And actually, that should, I hope, oh, actually, well, now this is about tomorrow. But here. So what you see here is implemented using that ontology. The basic is the same. So you see, this is a use case, and the use case is to blue spice performance. So blue spice is a enterprise media wiki distribution. And let's say we want to tune that. What I'm, and now, of course, this is empty. It's a stupid example. No, it's not actually not entirely. Anyway, so I want to register that this use case is motivating another use case. Okay, so if you want to tune blue spice performance, you also have to tune media wiki performance. And you also have to optimize the blue spice extended search. But actually there's a better, let me see. And then, yeah, here, that's better. You see the use case, tune media wiki performance, is motivating all of these, and it is motivated by use case, use case, tune blue spice performance. Now, the naming of these properties is probably not ideal. I had people telling me this is totally unclear, but the concept is important. I mean, you could also say, if you do this, you want to make sure, that's great, yeah, you want to make sure you set up a job queue. Or if you do this, you probably want to do that because you want to tune blue spice performance. And this can be then, I think it's the ontology. Like your conference type. Exactly. Okay. This is an epostyle topic. And you see how it's dissected. So tune blue spice performance is not the same as tune media wiki performance. And that's why it's not on the same page. It stays on one level. And it deals with one issue at a time. But let me see. Oh, I think it's here. So this is a keyword. And when I go to the keyword, it lists everything. And now let's, yeah, it's loading. Okay, works. What's cool then, is you cannot come up with a facet graph. And now the idea here is that if you hire a new employee and you have to explain to him, your job will be to tune media wiki performance. And you know we like motivating people by explaining to them why they want to do that. So you tell them, because you have to do that because they want to do tune blue spice performance. And by the way, you'll have a colleague that will do that. But you have to do this. And once you do that, you also have to make sure you do all of this. No, it's just a relationship. Forget hierarchies. Exactly. I'm trying to get the semantic... Yeah, of course. So this is motivating this. And it's, of course, this then is motivated by that. That's a mermaid. It's a JavaScript library. I showed you. Actually, I think Cindy's going to talk about that. Let me show you. Yeah, but it's... I used to do it in GraphVis. But GraphVis is server-based. And we don't want to do server-based stuff. I mean, it's more flexible if you do it in the browser. And what's really cool, and Jared knows that, remember when we did the... Where is it? The demos? Where did they put that? There's an online... an online editing... Anyway, I mean, you can see this is the... That's the source code. And that is then translated into this. And this is actually now an extension that I built that takes... Remember on the property pages, it said this property is included in the constitution of a facet. Remember that? Let's take this one. You see, all facets for which this property plays a constitutional role. And I told you the metaphor with the semantic web lying on the floor. And you take two properties, lift them up. Well, that is what you then have as a facet. And the facet is constituted by role... by properties. And here, on my... I'm not going to load that because it's too cumbersome. There. I just specified for is motivating and is motivated by... I think there's no... Anyway, that they play a constitutional role for this facet. And this facet would be called... motivations among use cases or whatever. And here you see this is the assertional graph, what people asserted. And it can be automatically... extracted into a terminology. So what we hear, what we learn about our business is that there is some stuff called feature that is somehow motivating something called use case. And apparently use cases can be motivated by other use cases. So this is the nature of your business. When people ask you, what are you doing? Well, this is the answer to it. And this is automatically derived from this. And these then are links. Actually, let's go... See if I click here, I get back to the page. The answer to the question, how do you produce that plot, is twofold. First is it's an extension and second is it uses mermaid. Yes, exactly, exactly. And here to show you the form. And by the way, if you go to this page and look at the ontology, that's a very old version. I haven't updated that yet. Yeah, that's it. Is it ready? Yeah. So you see this use case is motivating another use case or it is motivated by another use case. And as you can see here, it can be reified. That's very important. What's the reason that this use case should motivate that use case? So you can annotate the annotation and you can add others and choose whether they're motivated by something or whether they're motivating anything. So that would also help with keeping things tidy, right? This. And you know, there's a general issue with visualizing semantic data in this way. Usually it gets cluttered up. It's way too big. But if you declare only certain properties to make up a facet and you only look at little pieces of your information bowl at a time, then it can be very useful. Yeah, so that's another. Is that more or less helping? So the RIP guided in my head that was limited to who is asserting. But you're saying the RIP case is anything. It's a free text field? No, it's not a free text field. It's a way to annotate the annotation. You can add properties to property instantiations. Anything you can think of. So if you go back to the form where you had the verification data entry. That would be... You mean here? No, we had it. Where is it? Context. There. So is there a way to automate? I'll say that as an organization you wanted to only reify who is asserting. For whatever reason you wanted to constrain yourself to that. Whereas this is a field that lets you... You should know where you put that here. And you use the magic word username. And add... Actually here. We had a set, a further set call and say set has been annotated by equal user page. Or user. What is it? Username? User? Just user. So just user. And then you would have a way to query for all annotations that were made by a certain user. Actually that's... I should add that by default. So what I'm wondering... That's a very good point. Very good idea. Thank you. No, I'm seeing... I'm probably not like a... I would just appear in the history and still have a question about how you can have the history. I think there's two ways. One is you can manually go through the page history and look for where the text was changed where the property value was changed. But then I think what Lex is now talking about is a way that you could query the annotations. Yes. Yeah, yeah, yeah. So to me, right, that is now we have an organization that has roles and responsibilities and you may have someone whose responsibility and role it is is to simply do the raw data entry with no validation and so then you have someone come along and affirm that and then now you have it's not just what was said it's who said it and you can enable unqualified data capture and segregate that from qualified data capture. So is it like this? User? That's it? Oh, magic word? It's just user. What is it? Current users? Current user picks up the user that's actually doing that. Yeah, that's right. You see? No, it must be a stub. You have to replace it. It should be... How does that work? Stub? You know, the replace the magic word? I think it's... Doesn't it work like the stub like that? And then like this? Would that work? Because then it would take upon first save it would take the user name and store it as was annotated by and then it's not altered anymore because you're right. If we don't stub it it will always show the user that is actually looking at the page or no one if it's no longer in. I just looked it up in the list revision user as the only magic word revision user being the user name and the user who made the most recent edit to the page or the current user who created you in edit. Can you look up the stub thing? Like... I have a load of special extension for current users like in school Exactly, something like that. But it creates the magic word current. Exactly. Wouldn't that be a good idea to stub it? You know, it's replacing What was it? No, let me see. Oh, subst Is it stub? I'm sorry. That's stupid. Yeah, there you go. Yeah. Exactly. So many things open. There we go. Okay, so you said it's what was it? It's not a parser function. Like this? Or go on? Okay. So I think with this I think for all annotations that were made by a certain user. Sorry, I couldn't hear what... Oh, yeah. Yeah, it's... You create the conference that has the annotated properties one of which is has a tour and you as the initiator of the version of the page maybe don't know you give it a value expressing the intermittent state. Then so Cindy comes along updates the pages as yes and adds the field where to find the information. And then you refresh another user comes along and reads the page and sees that the fact that we're having a tour is asserted by Cindy, but the other facts are still asserted Yeah, you're right. by a previous user. In updating the attributes, he don't... If I want to update one value I don't validate all the other values with my name. At some point you have to code that outside and have a monitoring set of code that will because with wiki text there's only so much you can do. At some point you will have to go to a fully functional but you see this is something that I wouldn't dare to think through and discard. You have to just implement it try it out sometimes you're surprised it works sometimes it doesn't and then you dump it and go another another way. When is lunch? Because it's 12. We can look here Sure. Okay, good. So we have to break now. Good, perfect.