 Okay, hi everyone. My name is Yoram Koren. I, there's a lot to go through, so I'll give an introduction myself in my talk tomorrow. It's interesting that them talking after ad or odd who talked about making things easier, the interface easier for users. This is, this one, in this talk I'm focusing on making life easier for administrators. So I'll just do a brief history of what I'm talking about. In 2006, Semantic Media Wiki was introduced. At that point if you wanted to have a data structure, you needed to create templates, properties, categories, and query pages if you wanted to display all of that information. So life was good, you just had four types of pages. The next year, page forms was introduced. At that point it was called Semantic Forms. And so that added one more page type forms, and now you had five. Then later in that year, Semantic Drilldown was introduced for those who've heard of it. At that point you needed filters as well to create a data structure. And then in 2009, it was still called Semantic Forms. Page forms got this page special run query so that if you wanted to use that, you also had to create query forms, which is really just another kind of form, but it's sort of a separate part of the data structure. And this was really, this was the height of complexity with seven different page types. Then in 2014, Semantic Drilldown, the filters went away, now filters were defined in categories. Filter pages went away, so you're back down to six. And then Cargo came about in 2015. So for people who were using Semantic Media Wiki it was the same thing, but with Cargo there's no properties and you don't really need categories, although it might be a good idea to have anyway. So anyway, so four to six page types, even no matter which of those options you're using, that's complex and it's redundant. There's a lot of duplication of field names and so forth. So the question is, can we eliminate some or all of this redundancy? This is something a lot of people have looked into and I wouldn't be surprised if a lot of people here have looked into this. The usual solution is to create a data model which is defining that whole structure in one place and then you generate everything from that, templates, forms, et cetera. And then if you want to make changes you make changes to your data model and then regenerate everything. So there's a few different approaches to that. One is to define the structure right on the wiki. That's what the page schema's extension does. I think it's the only one that does it this way. And that's what the interface looks like where you're filling out this big form of forms or a meta form or something where you're defining all this stuff and then it generates forms and templates and stuff from that. The second approach is to define the structure somewhere outside the wiki and generate pages from that. There's one called MOBO that is proprietary. There's a European consulting company that uses it. I just mentioned it because they've talked about it at previous events in SMWCon. I think this is the most popular approach although as far as I know, all the solutions remain proprietary, local to that one organization unreleased. Just out of curiosity, who has at their organization something like this? Anyone? Okay, all right. Yeah. Oh, you have something like this. Yeah, I mean, with these structures how can we do it in UML? Okay, great. Well, I'll be... And that means you can do this UML. Sure, yeah. And you have something too, at NATO. Yeah, we're working on it and I hope to use a lightning speech to show a little bit what we have going on. Great. Then finally, the third approach is one that as far as I know is only used at MITRE, but it's quite interesting which is you define the structure in some sort of database and then have pages that query the structure so you're not really regenerating anything because the templates and forms are just little stubs. In MITRE's case, they use Scribunto slash Lua to add, if you don't know what that is, it's fine. I mean, the basic idea is you don't actually have all these separate components on the wiki, they're just pulling in the data from one place which is really neat, but for some reason, I don't think that many people are using that approach. So one weakness of all these approaches is that even in the best case, they're adding more complexity. In addition now to forms, templates, et cetera, you also have this other thing that you have to deal and maintain with. And it can be hard for users to figure out where to go or what to do if they wanna change something because it's not obvious looking at the wiki, what's going on, where the structure is actually defined. So this is just one thing I wanna talk about which is using the cargo extension specifically, maybe possible to truly simplify creation of the data structure down to just one thing which is templates and let the template define everything and let everything learn from that or read from that and get defined. So just briefly, I don't actually explain cargo here, it's an open source media wiki extension that's similar in its goals to semantic media wiki, but the key thing here is within cargo, all of a class is defined in a call to cargo declare which is a parser function within a template. So can we base everything around that? So here's an example, a very simple cargo declare call. So you wanna have pages about people. So in a template called person, you would say the name of this database table is people and then here are the three fields that I'm using and their types and the last one is a list which is that's something that the cargo has that SMW doesn't, there you just need to use a ray map to split up a list. And then yeah, so before we get into cargo, what about semantic media wiki? I think most people here use semantic media wiki. It could be done in semantic media wiki too, interestingly enough, part of why I call the cargo declare is because there is something in semantic media wiki called declare. I think no one uses it. Does anyone here use it? Yeah, oh, okay, I'll talk to you later. Often or, yeah, okay, yeah, I didn't think so. If you go to semanticmediawiki.org, I actually wasn't sure that it still existed. Use the search. Oh, I see, yeah, if you do a search within the wiki, that wiki, semanticmediawiki.org. Yeah, so what declare does is instead of a lot of set calls you say at the beginning, this template field gets set with this property and this other template field gets set with this property and so forth, yeah. Is that right? Yeah, I mean you can see clearly it's the same thing. Yeah, yeah, it's not that sophisticated. But it too could, in theory, it's the right mechanism to support additional statements about each field and property because you already have a parser function there. Will it happen to me to use the wiki? I don't know, no idea, not my jurisdiction. So, okay, so back to cargo. And I don't really have time to show examples of any of these, but filtering and cargo is all automated already, meaning unlike with semanticmediawiki, you don't need to define filters, it just looks at all the fields you have and their types and sets the drill down interface accordingly, so for instance, date fields will get drill down based on year first and then month, et cetera, and sorry if this is not making any sense, but the basic idea is that that's the easier part is filtering. Now forms is interesting, forms is interesting? Sure. Can you generate forms automatically based on only on the defined data structure meaning have form editing without form definitions? This could already be done, there's really no reason why it's not implemented already or no good reason, especially if you just have the simplest kind of form which is you just have one template at the top of your page, you already know all the fields in that template, so why not just have the code automatically generate a form to edit the page? So the basic idea is if there's no form specified for some page and that page calls a template and you know that the template calls a cargo table because in this case I'm talking about cargo, then you just create an on the fly form using those fields. Tied in with that, there's already quite a lot that forms do read from templates. And this is true for both cargo and semantic media wiki. I mean the input type, it tries to be smart about it and set the right input type based on the type of the property with SMW or field with cargo. Same thing with the lab values for both SMW and cargo that already happens. For cargo there's also the concept of hierarchy which I'll get to. Very new features in cargo and page forms is now you can set that a field is mandatory within cargo, and you don't have to do it within the form. So, and then so that within the form you just say this is the field and put the input for it right here. If it's specified already as mandatory, then it'll be made mandatory in the form too. The same is true for unique if you want something to be a unique value and reg X which is less important, but that's for stuff like phone numbers and so forth. For mandatory it's interesting and I wish I had some images because this is a lot to process but it's interesting because if you just set a field as mandatory in a form then if somebody goes and edits the page directly and edits the template called directly it won't be mandatory for them. I mean they can just set it to whatever they want. But if you do it within the data structure within the data storage in this case in cargo then you can have cargo itself throw up an error or something if you try to save a value that a blank value to that field. So it's sort of a more foolproof way of defining and the same is true for unique and reg X. This maybe illustrates it a little better if you have something like this in a cargo declare call if you have some field for color that can only be red blue or yellow for some reason and you set it to be mandatory then in the form automatically you'll have a dropdown input that is mandatory. You just need to specify for the field color and it'll take care of the rest. And then additionally if you go to edit the page without the form it'll still be mandatory and it'll have to be one of those values. Actually I'm not sure if it'll have to be one of those values but it will be mandatory from cargo's perspective. So that's a few things that most things can't yet be set within cargo that you can set within a form definition. These are sort of in decreasing order of importance the big two which are tied in are having more than one template in a form and having one or more of those templates be multiple instance templates if you know about those that's a way to define a whole table of data within one page. So I would get to all of those but there's not enough time to, oh actually no I am getting to multiple instance templates. Okay so let's take a specific example. Once again we're talking about pages about people and there's a form called person and it's going to have, you want each page about people to have not just information about them but about all the jobs they've had and jobs aren't something you can really fit into that person template because it's sort of a table of data it's not just a list of texts of strings it's more than that. So you need a multiple instance template for that. Can we define that within cargo declare and hopefully this will make more sense as we go through this. So what I suggest, what I'm thinking could work is have something called child tables, a new parameter to cargo declare where you specify for this main table this the jobs table is one child's table and you can have more than one and there's a reason why you'd want embed in field in there too but it's not that important. And then interestingly you can use that not just in forms but also in filtering and queries. But yeah, so the way this would work in forms I'm not even sure if I have a slide to explain how it works in forms. The basic idea is you don't have a form for people the code goes to try to create a form automatically it sees that this person table has a child table called jobs so it says okay I'll go ahead and create a multiple instance template for the job template because I know that the job template corresponds to the jobs table, it's very confusing. But in drill down that could work in that in that it would let you drill down based on not just the fields of the table called people but also additionally on job related fields which is quite useful. I mean that's something that people have asked about a lot in semantic drill down is how do I do filtering based on the data from more than one table, combine tables together or more than one category I guess in case of semantic drill down. And then this is more minor but for queries and here's an example of a query for cargo it's the parts of function called cargo query. The second line the one in red could be made optional if the child table relationship is defined but that's really not a big deal. It just sort of would indicate that this is a holistic approach that sees all of these things as related. Data storage, data entry, querying and drill down. Usually when people talk about data structure they're just talking about data storage. But what I'm saying is there should be a way to get some synergy and if you define things the right way to be able to really create all of these interfaces from that one structure. So interestingly speaking of UML this ties into UML. I mean maybe the old Holy Grail or maybe the current Holy Grail for some people with all of this data structure stuff in MediaWiki is to define all your classes in UML file because that's the usual way that people define structured data and then from that generate templates and forms we have an example of someone who's doing that here. So just briefly if you don't know about UML it stands for Unified Modeling Language and if you ever see a little chart like this that's UML or that's the graphical representation of UML. I'm not even sure if UML is, if it has to be visual or if this defines a UML file or something, I don't know. It's just the graphical representation. Okay, okay, okay, okay. Yeah, so an image like this would, that's an example of UML. I think this can't work because UML is just not good enough. Basically it's a wrapper around SQL or around the tables within a database within an SQL based database. And it really is a very closely wraps around that meaning if you can't do it in a database table then you can't do it in a, you can't structure it in UML class, I think. So let me give an example of something that can't be done in UML. Hierarchies. This is, there's, as far as I know, there's two, in my way of looking at it, there's two kinds of hierarchies, single field and multi field. Single field an example of that would be genre for a movie or a book or something where you have just the genre can have any level of granularity. You can say this is a drama film or this is a historical drama film which is a subset of that or biblical drama which is a subset of that. So it's going to be, every one of these nodes will be, are possible value for the genre field versus a multi field hierarchy. An example of that is continent, country and city. That's pretty typical one location based stuff where you'll have different fields in the table for these different things but each one can only be, you know, not really a subset but a child or whatever of that of the field above it. So yeah, so there's two kinds. I don't think UML can represent either one per se. I mean you can obviously, well not obviously, you can define all the tables that are needed to represent a hierarchy field and make something complex but you should be able to and you can't just say this is a field, this field genre in the table called movies holds a hierarchy of values and here's the full list of 50 values that it can hold. Yes? So if you say the country is within a continent and the city is within the country, you're just defining a relationship type which is a containment type. But what on the left is your category? It's your category hierarchy. In media, in media making. And in UML, it's exactly the same. It's exactly the same. It's exactly the same. And in UML, it's exactly the same. So you can define, okay. Yeah, I've screwed up. Yeah. You can define and hold anything. Never say that you don't want anything. You get no problem with anything about the cost of it. Because I don't think that's why it's universal. Okay, fine, thank you. No, it's unified. I list, okay. I feel better. I corrected one person at least. Okay, well, I'm both embarrassed and excited to hear that. That's weird. Okay, I should have asked someone when I was doing my research because I looked into all this stuff and I couldn't find anything for that. Okay, that'll be, that's good to know. Well, okay. Well, there goes, yeah, that sounds good. Yeah, okay. Well, it doesn't really detract from my main point which is simplifying things, but that actually is very good to know. So, okay, well, yeah. Yeah, to cover your sheets, yes. It's a very specialized don't need. Yeah, I mean, I read through a whole UNL cheat sheet and there wasn't anything, or a few of them actually, and there wasn't anything that looked like, like that category or enclosure or whatever it was. It's the same one you had with the declare statement. You didn't talk to anyone about this. I mean, if Ike was using declare, it seems like he would have been a good person to talk to. Maybe talk to people. No man is an island. Okay. Okay, so here is how hierarchy support is done within page forms, cargo and semantic media week at the moment. There is, again, there's the concept of single field and multi-field hierarchies and they have to be implemented in two different ways. Single field hierarchies are supported as of pretty recently, maybe six months ago, in page forms and cargo. They are sort of supported in semantic media week via categories. I mean, you can create a whole tree of categories and then if you query for something in the main tree, it will also find anything in the top level node. It'll also find anything in any of its subcategories. So if you're using categories, then you can do that with semantic media week. Sub properties. Okay, that's not, that's, yeah, it's, okay. Okay. Well, I, okay, that's, yeah. I don't know if we'll have time to go over that, but it would be interesting to talk about that too. Multi-field hierarchy is the thing with like, with, you know, country, city or whatever else, country, state, city. It's sort of supported in page forms with show on select and values dependent on, those are two different ways of doing, depending on exactly how your data is structured. It's not yet supported in cargo or semantic media wiki, but it certainly is something that I would like to see added to cargo declare in the cargo extension. Finally, this is not really something I'm getting into detail about, but it could be that the creation of the templates itself is simplifiable too. Maybe cargo declares all you need within a template and you don't even need for the template to, to, you know, display a whole, it's standard big chunk of wiki text that actually does all the displaying. So in a sense, the template could query itself, I guess, and find out what all the fields are and how they should all be displayed. And that would really, that I think is really something that could, that could, would be the apex of this whole thing is really just having a single declaration of a table within a template and then basing everything around that. Somebody else mentioned the Google Summer of Code. Actually there's a, there's a planned Google Summer of Code for the project for this summer that I'll hopefully be co-mentoring to improve the special drill down page in cargo, which is gonna cover some of these things that should, we'll start this summer hopefully. Has anyone tried to make a comprehensive? Well, I guess you've answered the question. I guess UML is it, I really, what? Sorry, yeah, go ahead. Okay, no, I'm very curious to hear what you think about this one actually. Well, we've had some discussion. Yeah, I'm gonna add a slide to my presentation tomorrow just to show an ontology done in UML. But it's relatively simple. It's pretty much aligned with Semantic Web. There are some subtle differences on inheritance. Inheritance doesn't work the same way in Semantic Web. But as an editing function to give you a roadmap before you start, it's excellent. And it's effectively free and vizio. UML, yeah. Yeah, okay, yeah, okay. Hi, so just one, I guess a clarification and a comment. So thank you for what you said about MITRE, but you sort of gave us a little bit, or my previous life, a little bit too much credit. We weren't doing anything quite that fancy. However, Toby Otterer gave a talk about using Scribonto last year at EMWCon, and he was doing some amazing things that really helped. We definitely do things, but it's a little bit more manual than you, yeah. Okay. I would aspire to do it as well as you described it. You had it though in at least one. Yeah, and I use a lot of Scribonto. That's absolutely true. Okay. Yeah, but it was in its infancy, and at some point I'd like to explore more the things that Toby was talking about last year. Yeah, yeah, sure. Well, that's my talk, yeah. If anybody has any more questions or comments, anything or corrections. Oh, yeah. Thank you. I was just wondering if you would be asked to suggest an extension, Sematic with a wiki versus cargo. Which one of these two extension would you suggest? Yeah, I'm not sure I'm the person to ask. I would. Last year. What? Last year. Yeah, I've given various talks on this kind of thing. I think cargo is preferable. I have a talk tomorrow where I'm going to go over it just very briefly. Okay, thank you. Okay, thank you.