 This is going to be very different from Lex's approach. My background is traditional data processing. And I came into this through the Semantic Web side. We've been doing some work in health care using AOL and Prodigy and understanding what Semantic Web could do in representing information, particularly health records and health terminologies. And we had been trying to get what I call an enterprise engineering practice off the ground. And we had not been able to find any tools to do what we wanted. And when we came across, as I went through Prodigy, I found that it wasn't doing what I wanted to and stumbled on Semantic Media Wiki. So it's about three years, I think, that we've been working on this. And what we're finding is that from a pure data processing approach, forget about documents, forget about office systems, forget about those. Just from a pure data processing, this is an incredible platform for developing tools. So I really want to give you an example of one of these through managed knowledge capture. And this is the process by which you gain the knowledge in the structure that you want, rather than getting all the documents and trying to retrofit the structure into it. We're a small company. We do mostly federal government contracting. A lot of that has been in the health care, in the security and privacy area as well. So as part of the sort of enterprise engineering, and this is a very informal definition, it's really enterprise architecture and the transformation process put together. So when you think about these two areas, you can't really separate them. There's the as is and the to be. But maybe your to be is following your to be is following your to be like week by week by week. So your transformation process and your target architectures are intricately connected. The two areas for this one's an operational area. And these are the things that you have in the enterprise, the actions that are taken, the processes. And you have operations management tools. So if you're manufacturing, you've got manufacturing systems that manage the state of all the things. You see what the thing and may take decisions as to what has to happen. The transformation process changes the process. And you have methodologies such as business re-engineering and the IT system development lifecycle. And you have transformation management tools. And they're slightly different. And in your methodology change, you're going to make a tooling decision. And the tooling decision is very interesting because it's got a lot of problems. So what is the problem? So the current transformation tools are aligned around with departments and teams pretty much. So you've got your project management tools. You've got architectural tools. You've got sharing tools like SharePoint and so forth, which are office systems. The cross department and team collaboration is left to office systems. So we're trying to do all this coordination with emails and meetings, many, many meetings. And as you see in the development lifecycle, in the scrum, the agile process, and you've got scrums, and then you've got scrum of scrums. I've actually seen a scrum of scrum of scrums. And you can just imagine what happens to your calendar in this process. If you've experienced this, it just fills up. And you're just going, oh, it's top of the R. I'm going into the next meeting. And so what's the need? We need oversight, visibility, and exception alerting. And we need it across this visibility as these systems that we're developing interconnect and are dependent on each other. So you're seeing these dependency chains are becoming pretty critical and you need to see them. This is not to stifle the innovation. We talked about that yesterday. You need the bottom up processes, but you need the oversight mechanisms that figures out, is something wrong? Is something totally missing? What's happening in the white space? The tool integration has not happened. So you can buy Best of Breed, and we've seen this Best of Breed paradox that says, OK, I'll go and buy the best project management tool and the best architectural tool. And of course, they all work together. Well, they don't. And so you get changes happening in one environment, not being reflected in another, another component added to the architecture doesn't feed into the project plan. And you can't see that it was missing from the project plan because there was no mechanism for detecting it. Most tools in this area really just support crud on complex data. You really look at it. You're feeding the stuff in. It's complex. And you get reports out and you get nice visibility of it. And the ontology is hard coded. Yeah, you can vary it. You can do extensions to it, but it's pretty much hard coded. And you can't go past the area that it's designed to work in. So what does SMW do? And I'm kind of focused on this because coming from the data processing side, this is the stuff that I can relate to. It allows an independent ontology model development. So we can define a model that covers the project plans, covers the architectural components that need to be built, the teams, the people in the teams, who is assigned to what. It supports tool building. I want to talk about this, that the platform isn't the tool really. Yes, you can do some basic things with the tool, but what you have to do is to build the tool on top of it. And so you're going to take an ontology or a model and you're going to build a tool that captures that knowledge and represents it back. The tool development is fast. I think that most people have understood this. And I want to talk about what this does in the market positioning for SMW. The language is feature rich. You go into the parser functions, look at some of these. It's very rich. The query, the ask function in SMW is incredible. So it's based on Sparkle, very, very powerful. The developers can almost be business analysts in this. I'm not a programmer. I've done programming. I don't do it anymore, but I can handle this. And this means that you can actually take the development above the platform into the SMW area and with some training. And there's a learn curve associated with this. But once you get over that, the language, the platform language, the Wikitext Plus is extremely powerful and very fast. What are the limitations? So we're struggling right now to find out what can't it do? And where do you end up with a brick wall? I came out of an area called model-driven architecture. Has anybody heard of model-driven architecture? Yeah. Championed by the object management group, I was part of the launch of model-driven architecture. We had actually developed some of these techniques in the banking industry at the beginning of the online banking, internet banking. Cindy, I thank you. We actually did the, I was with a previous company. We did the integration for Wells Fargo Bank for their online banking. And this was all model-driven. And it generated payload structures and so forth. Anyway, there was a tool that came out from Spain in about 2004 about model-driven architecture. It was called a lever nova because it was developed by a resort. It's now called Integra Nova. And Integra Nova, you developed a high-level model and you chose whether you wanted .NET or Java. You pushed the button and you got the app. And Gartner evaluated this. And they found that it was 23 times faster than a traditional Java or .NET development environment. SMW looks similar to this. The company, IZEARTH, we spent three days taking this product apart. And it worked. But we were in the contract programming business. And what this was going to do for us was to drop the pricing so dramatically that we could never actually recover the revenue. And we said, we're going to be real quiet about this because we don't want this to take off. And this is part of legacy, the reaction to a disruptive technology. This is a disruptive technology. SMW looks the same. I wish we could get a productivity benchmark. Maybe we could ask Gartner to do one. But I think that it's around anecdotally, some people know how fast this is. Yes, Mark? So I deal with one client that 10 years ago, they had hired a developer, a consultant, to build something for them, a library sort of thing, and to train other people with. And it didn't use, they were building on a Microsoft platform. So he took two years and still had nothing to develop, to deliver. Meanwhile, the head scientist, one of the senior scientists, said, oh, I can do this on a wiki. And he did it in a weekend. That's right. That is the anecdotal. I found this once I got over the learn curve. The learn curve, so figure out where the documentation is and all that sort of stuff. Yeah, you're able to get, I was able to do my prototypes. I'll talk about the prototypes in a minute, like two or three days to get a prototype working. And there are some people here that are more fluent than I am who could do it in an afternoon. So the productivity is absolutely incredible. And, but as we look at a cost reduction, you'll look at the market factors here of our cost reduction. If it was 10 times faster, what's this going to do and who benefits? The client certainly benefits. The vendors do not. So this basically starts to undermine the programming revenue and those sorts of things. So one part is cost reduction is another is revenue cut. And the market dynamics are interesting. I believe we're on the brink of a new computing generation with this. And I think it's a combination of fourth generation language. Yeah, it's still tech space, but that's all right. But you can put the front ends in front of it on top of semantic web. And this looks like it's very significant. The market forces need to be considered, particularly open source that doesn't have a lot of money. This is an issue. So competing against legacy products that have a lot of money to market. And we're in the early adoption stage, I think in the pre-CASM, if you look at the Jeffrey Moore model of adoption. Let's talk a little bit about the knowledge game. We really need this to manage knowledge. Two reasons. One is a learning and one is a factory core. And if you look at most way information is put together, whether it's in the book form, book forms typically are learning oriented to learning. They may have a strong index, which allows you to get at it for information recall. But these are the two things. The value of knowledge is eroded by chaos. So as we see that this knowledge being gathered in documents and so forth, so we get this chaos that then happens. And we're into what Lex is doing with the search engines to try and recover the order out of the chaos. So that's a recovery mechanism. But we can actually do this upfront by actually organizing the capture in the first place. There's a resistance to share. Competitive postures within organizations, job security. I've got all the knowledge therefore I'm an essential player. Therefore I'm not going to share this because then that dilutes my value. How do you get cooperation? Voluntary groups. I'm very interested to hear how NASA's dynamics is working. Voluntary groups and top-down mandate. And these are not exclusive of each other. Authors need privacy. We're starting discussion. I think we're going to have an ad hoc discussion this afternoon about confidentiality and what we need in the wiki area. But particularly authors need privacy while they're doing their drafting. If you're working on something and you haven't submitted it yet, you need some privacy on it. You need to be able to get the whole strength of supporting tools to help you so you're not offline. You want to be online, but you want to have that privacy. And the status of knowledge collection needs to be visible. How much are we actually collecting? Who's doing it and how far have they got? So I'm actually going to talk about a particular prototype. But these are the prototypes we've been investigating. Most of it's in the IT transformation tooling. You can call it IT for IT. But it's kind of interesting. There are reference models in this area. Security and confidentiality is one. We're going to be talking about that. Portfolio program and project oversight. This is a big one. This is a major area that large organizations, particularly federal agencies, are having a lot of difficulty with. Infrastructure configuration. So this is all the knowledge. Enterprise architecture, working, relating to systems. We've done work with the Department of Defense, with DODAF, using SMW, health informatics platform we've done. And for an operational tool, we actually built an electronic health record in SMW. It took three days. So this is the sort of thing that we're talking about. So here's the one to run you through an example. This is a US federal program called CUI. And CUI stands for anybody know CUI? Anybody know what you're sending? There's some NASA folks, I think, know about CUI. It's a federal program to manage controlled, unclassified information. And it came out, it was an executive directive to the executive branch. It has widespread implications. It's coming into compliance requirement now. Federal agencies have many systems. The systems need to be evaluated to see whether they contain CUI. And if it's present, then the security controls implementation needs to be assessed, remediated, and there's regulatory reporting that they need to make up. So what we did was to work a tool prototype for capturing the knowledge about each system in an organization, like an enterprise. Some of these federal agencies have 1,000 systems. This is quite easy to see those sorts of volumes. So the logistics of managing the capture of this is a challenge. I put this in last night because we had this discussion about UML and an ontology. Who was a great pointer somewhere? No? Lex. Lex? You didn't lose your honor. Oh, sorry, I didn't realize it was yours. Thank you. So this is an ontology. It's a low-level ontology. It's lower levels and upper-level ontologies around. So this is talking about, really, the categories that you're going to see. Here is the system. The system has applied controls. Here are the controls. The controls come out of SRM is the security reference model of the federal enterprise architectural framework. So these concepts come from existing documentation. So the system can have sensitivities. And the sensitivities have links to handling practices. And one of the interesting piece of the handling practice is that it has an authority. That authority points to a US code or a code of federal regulation. And so these structures are all knowledge that's actually built into this program. So you don't need to invent this. It's all there. So we imported all this stuff into semantic media wiki so that in the data capture process, you can see exactly if you apply this sensitivity, then it will give you this handling practice. And this handling practice applies to certain government organizations that the system has a point of contact. There's an applied control. The control goes up here. And here is a little interesting thing. You probably can't see it from the back. But the applied control is actually a sub-object of the system. So as you actually make the connection between the system and the control, there's more detail that's applied here. It's like the recipe model. It says, OK, what are the things? Well, it's got a planned. It could have a control plan date. It's been implemented. And there's some description associated with how that control was implemented on that system. So that's all sub-object. And it says, here's has sub-object. So it's taking me to the properties. And these are the names of the properties. And this is the roadmap for building it. And I put this diagram. And I import the diagram. And I put it in the model. And I bring it up on a screen. And it's there in front of me. So here's the knowledge and capture cycle for this program. This is mermaid too. And I'm very interested in mermaid, particularly the sequence diagram. But the sequence diagram isn't complete enough yet to take into production. There's an online site called websequencediagrams.com that has a commercial service of mermaid sequence diagrams, which has got the full implementation in it. It is free. There's some extra bits that you have to pay for. But pretty much it's a full UML sequence diagram implementation. So what we've got here are assessors and points of contact. The point of the assessor basically issues the questionnaire for the system. So we've identified a system. They issue it. And it goes, they create a page for the system. And they assign the scope to points of contact. So it says, who would be the people? And they can choose. Who are the people who are going to actually fill this in? And so they apply it to the point of contact. Then the point of contact up here selects the questionnaire that's in scope and changes it to draft. From being issued, changes it to draft. The moment they change it to draft, they now own that page. That page can't be seen by anybody else until they've actually submitted it. So they then do this. They enter the sensitivity. They can enter the plan controls. The moment they enter the sensitivity will come up with a whole lot of supporting information. And when they submitted it goes now into the assessor's side, the assessor can see the submitted questionnaires. Is it accepted or not? If it's yes, it's accepted and it may expire and may have to be refreshed. If it's not accepted, it needs completion goes back in the cycle. So this is a very simple cycle for collection. Here's the scope focus. Talked about here where the submission states issue draft submitted accepted needs refresh. The user scope privileges. This is not a hard security mechanism. This is a focus mechanism. We don't yet have a full implementation for access control that will give us what we want. We'll talk about that this afternoon. They, but it gives them privileges to questionnaires they can edit. Questionnaires they can see with the grouping. We'll talk about the grouping in a minute. The user has a role. They're either an assessor or not an assessor. All this can be changed. This is all above the platform. This is all implemented in the SMW artifacts. The rules control what the user can see or edit. They can only see questionnaires content within scope privileges. We intercept the queries. So when you do an ask, there's an intercept filter on that. Does the user have scope for this? And that means it will only produce the list of the things that they have scope. Now, I had a terrible problem with this originally. I thought this would be great for putting concepts, putting it into concepts. Oh, I can just say, here's a concept. Does the user have scope privilege? And then I found that the concept cached the decision. And when you changed users, the new user got the privileges of the previous user because it was not updating and refreshing current user. And so it was like the worst nightmare for privacy. So I expanded it out. So they can see the questionnaire status within scope and so forth. These are the kind of rules that are programmed in it. It's a soft security. It's not, we know that if you transition across because you've got some dependency from one program to another, we're gonna let you do that and go across, and you're in a program that you might not have privileges for. It's better for you to see that than to sort of stop you and say, there was some dependency, but you can't see where that goes. And so there's some decisions that have to be made on these rules. Here's screenshots now, because this is implemented. Here's our property has submission state. And here are the allowed values for it. And I've got some sample dummy systems in here. Department of Agriculture System One, the Fish and Wildlife Service, which was my favorite, has got a system. And National Park Services got some. And here you can see, this is generated, this is SMW generated, just looking at the property page. And here's the issue draft accepted, draft and submitted type of pieces. Here's our user. Guess where we're going with this. Okay. So here's Fox Mulder. Here's the user page and we've put a template into the user page. So here are the scope privileges. So template with everything is managed with page forms. Don't do anything except with page forms and there is no free text anywhere in any of these pages. All fielded, 100% fielded. So you can define when we're questioning, does the user get to choose this or does somebody else get to choose this? Don't know yet. But the first approach was to say, it's a scoping focus for the user that they could choose what to do this but we may put it under another level of control a little bit later. So they might have an agency scope which means they can see the whole of the agency. That means they can see the progress that's going on with all the questionnaires in the agency or the segment which is the administration or department or a system scope. And they need a system scope to actually edit the questionnaire. So that's how you give somebody permission to edit the Fish and Wildlife Service System one. And here's the role assessor. Fox Mulder's not an assessor. And here's the intro page. So when you go into the system, the first thing it does is to say, it's your dashboard. Nobody else says it's your dashboard. And who are you? You're a user and you might be a point of contact. So there are point of contacts that might not be users in the system. Here's your total sort of view of the metrics. It's got one questionnaire which is in draft. And here's the link, the questionnaire. It's, of course, the X file, so we know where we were going with this. And it has a security marking, INSL, which is an intelligence national, I'll see it in a minute. And here are the revision users. Here was the last edited. So you can see this information. This is really a duplicate of the same. So as you go further on, here's the questionnaire. Here's what it is. It's in draft. Here's the intelligence national security letter, which is the security marking that's been assigned for this. There's no implemented or planned controls yet. So it's in partial development. But the moment you put this in here, it's come up with the knowledge of saying, wait a minute, this sensitivity is a handling practice and it described the US code that is the handling practice for this. You click on this, I'm not gonna take you, you click on this, it'll then take you a link and you'll take it to all the wording that's in the US code, covering this particular section. And there's the marking level on the right. So... That it gives you the link to the tool. So in order to edit something, you need to get to the form page and that link is controlled with the access control. So if you're able to edit it, you get here. If you don't, it'll say you can't. So here's the point of contact. Here's the control, and this is standard page form. And then when we go to the controls, we go to another level of the form. And I'm gonna show you, and here's the submission state. It's in draft when you want to submit it. It's a dropdown, you put submit in there, you save the page, you just submitted the form. Here's the more interesting piece to this. I put myself in here. I've got actually agency scope in here. And I can see some things that I was actually doing, but I can also see the status of the questionnaires in scope. And you'll notice here that I can't open these. I can't open these to see them, but I can see who the revision contract is, where they are, and when they were last edited. So this is giving you visibility of the progress. You know, there could be a thousand of these. So it's giving you visibility of the progress as to where the forms are. So kind of in looking at this, there's some positioning that needs to be done for SMW. It's not a tool out of the box. We think that it's a really good candidate for enterprise engineering tool development. You saw some of the prototypes that we've done, and actually these prototypes start to merge together. That's why the ontology is so important. Once you describe a system, the systems in the knowledge base, you want that system to be reused in all the other aspects associated with it. And so the ontologies will start to merge together so you can actually see development on systems which are going to remediate a CUE situation. In other words, you have to implement the controls. That means there's a project going to be spawned up on that system to put the controls in place. I'm very interested in this adoption question of where we are. I believe this is disruptive. It tips the balance of make-by in this tool area. So you can go and buy a tool and then you try and integrate it with something else or you could make it. And you were never able to think about even building one of these before. But with this productivity change, and when you were able to get a prototype in place in three days or five days or whatever it is, this is a whole new game. And it basically changes that balance. We talked about a threat to existing tool vendors. You're gonna get a lot of resistance here. This is not, you know, this is understandable. There's a potential large expenditure displacement. Potentially can happen here. There's a lot of money at stake. But the money that's gonna be saved, I think, is on the customer side. And I think that this combined with the productivity analysis of where this is could actually drive some of the adoption. It needs a strong marketing message. The marketing message has to come from the tooling solution, not from the platform, I think. The platform can be an umbrella, but the real thing is you're going to build something, a tool, and it's gonna be branded and it's gonna merchandise that way. And the message is a low cost to development customize. It provides a holistic ecosystem cross-organization. This is a different thinking from putting different systems in, different parts of the organization or for different functions. And I think even the multi-wiki situation is one. And I've heard that discussion here about, wait a minute, you should sort of try and get one wiki. And so this is, how do you get this cross-organization when you have these dependencies that go on? Flexible ontology. There's almost nothing you can't do with this. And the customization potential, you can go into a customer and look at their methodology and build the tool to their methodology. And that's very exciting, that's different. So, trying to catch up with our timing here. In conclusion, there's a large number of tools that exist which are CRUD. And they're against complex information structures. That's really what ERPs are about to some extent. So CRMs are exactly the same thing. All they're doing is storing the information, the complex information about the relationships. So CRM is a potential tool. The modeling tools are there. The project management tools are there. And I think we've been talking about the comparison with some of these tools. The cross-tool integration, we've talked about that. There's an opportunity for a homogenous platform but the marketing position needs to be established. And the scale is from text. We talked about a questionnaire that was heavily fielded but the questionnaire might not be that way. It might have a whole lot of text. So it's not limited to that but the management process, you've seen how that can actually happen and how you can administer and keep track of where your completions are. So if you have a thousand systems and a thousand questionnaires out there with a thousand people to contact, how do you keep control of that? And that is my story. Does anybody have any questions or? Yes, Rich. You said this could be implemented today with existing technology. What I showed you I've implemented. Okay. Yeah. So then my next question is, so many organizations sort of have or there's a fractal relationship between the model that you've described and then that pattern repeats within the organization. So at an agency level, you could apply this model and then within an agency, you might have branches. Yes. The branches would have their own granularity to this. Yes. So do you think that this could, this security model could replicate as it goes from, you know, as it scales from the top level entity to the micro entity? Yeah. I think some of the governance mechanisms could do that. It could be hierarchical. In other words, as you, we talked a little bit about the approvals for the individual to get access. And those approvals certainly can be, we didn't really talk about how to do that. That could be done centrally or it could be done granularly at the level of down through the organization. The ontology is going to change. If a different part of the organization's dealing with a different part of the ontology, then they're going to have different, that's a different piece. But the security model is probably, it's flexible. I think you could implement it with a central control. You could distribute the control down through the organization. Was that answer your question? Yes. Yes. Yeah. Hang on, hello. There you go. Yeah, I mean, you talked about tools and Media Week is a tool builder where presumably the Wiki with all the forms, et cetera, is the tool. Yeah, I mean, I'm just wondering, at what point does a Wiki become a tool in itself as opposed to, sorry, does it stop being a tool and become a tool builder? Well, I... Oh, and actually, I tied in with that. What are the, you said the competitors are other tool builders and so forth. You know, what kind of software were you talking about? Well, we've talked about SharePoint and SharePoint is a file sharing environment. But you could be talking about the best of breed project management, Primavera, Oracle P6 Primavera, for example. You'll be talking about the IBM rational suite of tools. Some of them just, you know, diagram draws, but the underlying information that they carry is something that can be projected. And we've done this, used this instead of system architect, for example, in the DODAF architectural area. So, but you can't just say here's the platform and here's Wikitext, go for it. You can't do that with the users. You've got to present something that the average user with a page form can actually build. So it's taking the platform with Wikitext Plus and building it into a tool that the users can use. That's the difference. So it's in the eyes of the user. Is this a tool or is it a technology that somebody else has to build into a tool? And that's the difference. No more, and I'm standing between you and lunch. So, thank you.