 and letting people get here. So thanks for being on time. I'm sure some more people will arrive soon. But we've just had a good talk this morning which has told us that we're in a war and that we have to make sure that all our information stays out there and stays free. I guess once you have all that free information, it wants to form its own social networks. We need ways of sorting it out, letting it join groups with other like-minded information. I think Paul's going to give us a way of trying to classify that information and sort it and store it and things like that. So I'd like to ask you all to welcome Paul Harvey. Hello. Yes, well, this talk is a little bit of exaggeration. It's just to get you here. Accidental wealth is really what I'm talking about accidental wealth. It's really trying to create workflows that are useful in everyday work. And we accidentally or at least without any extra effort by the user, they've come up with a workflow in a system that allows them to collate and store their information in reusable ways. So where I work at the Center for Plant Biodiversity Research, research is often geneticist, taxonomist, natural life science people. And although the young ones these days do have very good computing skills, there's been a long tradition of really overusing Microsoft Excel. I just have to say it that there are way too many Excel spreadsheets out there, a lot of copy paste madness, and a lot of time wasted trying to merge data, check data. So we've been trying to leverage FOSWIKI. Has anybody heard of FOSWIKI before? Before this talk? Oh, good, that's excellent. How about T-WIKI? Yep, a few more. Well, FOSWIKI is written in Perl, although Olo disagrees with that. It says it's written in JavaScript, but we check in a lot of jQuery libraries and things like that. It also said it's worth nearly $51 million, but that's a very interesting claim. At two years and three months old, we've come quite a long way. We've had over 10,000 check-ins, nearly 400 a month. There's anywhere between 10 and 22 contributors every month. And I managed to abuse Olo to make a very flattering graph here, where FOSWIKI's coming out on top of Drupal and Semitic MIDIWiki. Of course, that's a bit of a lie. That's just the core. So if we count contributions, yeah, FOSWIKI's down the bottom there. So it's not a huge project, but it is still significant, in my opinion. Drupal completely dwarfs everything, as you can see. So why didn't we go with Drupal? And in actual fact, I should mention that some of the work I'm about to describe today, there's been many, many attempts over the last decades to try and rationalize biodiversity systems. So biodiversity is a mess when it comes to computer science. Not that I'm doing anything really tricky here. That could be really called computer science. But just trying to structure and collect information in a rational manner, that is useful to scientists without getting in their way too much. So FOSWIKI has a very open community. It was important for us that we chose a platform that we could contribute to and keep our plug-ins alive. Like, is our project ends? Because most of these things are project-based. They have fixed lifetimes. And people are very terrified of putting their data into a system that's going to fail or end. So we don't want to create any data jails. So investing in an open-source platform helps us do that. FOSWIKI has many plug-ins. We have the old TV project. And FOSWIKI, of course, one of the common complaints is that it's hard to search for things. And we've funded somebody, or at least convinced them to open-source a plug-in that they had written, which was a solar integration. Anybody heard of solar? Yep, loosing, natural language searching, fuzzy matching, that sort of stuff. The interesting thing about solar is that the integration for FOSWIKI also does attachments and Word documents and Excel files of all things. So if you are plonking them and using the FOSWIKI as a glorified file system, then you'll still be able to find those things. FOSWIKI also has a superbly modular architecture. Now, I wouldn't say that the code is brilliant, but the APIs are generally pretty flexible. They've been well thought ahead. And being Perl in such an old Perl project, there's some ugly code, but there's some pretty good code in there, too. This is contrasting to TikiWiki, which is another platform that we considered, among other things. So apart from Drupal and TikiWiki and TWIKI and FOSWIKI, we also considered Google Wave. I actually wrote a couple of robots for Google Wave. That was a very interesting experiment that I couldn't get anyone to use. There was also XWIKI, which is a giant Java project. And as no one in my team is really strong in Java, we didn't go very far with that. So we kept coming back to FOSWIKI because it's very easy to hack being Perl. It's designed for hackers by hackers. That does show up a little bit in user interface, or I should say a lot, actually. But with proper training, and there are some plug-ins that make the default FOSWIKI a lot easier to use. One of them being that EditContrib plug-in, which allows users to interact or set preferences on their topics a lot more easily. And we do have WozzyWig. So actually, I personally use WozzyWig quite a bit, not when I'm writing FOSWIKI code, like macro expressions and building reports. But it's very useful to paste from rich text sources. It can filter a bit preserved formatting to a certain extent, so you can keep tables and then things from Word documents. And FOSWIKI has a tremendous, weird aptitude, which I haven't quite found in other platforms. So when I say, whip it up to Tude, I can put something together really, really quickly. Once you know the patterns, so just as an example, I'll show you something that a user asked me, I need to make a resource directory. They had a resource directory. It was in Excel. They emailed it about to each other all the time. They don't know what's changed. People accidentally paste over other people's cells. What sort of junk? I could have said, use Google Docs. But that wouldn't be using the Wiki, would it? No, actually, there is a great sense of wanting to preserve ownership of your information. So owning your data is a big deal in science and in other enterprises for a second. And this is just a very simple data forms app. And when we say data forms app in FOSWIKI, this is a sort of a data form as a schema in a sense. Well, a data form is actually, technically speaking, a special type of topic. And it just holds a Wiki markup table. And all it does is describes a set of fields in terms of a key value type schema. So I like to think of the pages on the Wiki. We call them topics in FOSWIKI, by the way, as objects. And if you attach a schema to an object, it suddenly has these fields that you can populate. So these are actually all pages. So we can filter these. I'm going to search for now, so I can filter these down. So instead of a whole bunch of articles, like on Wikipedia, you could make, or sorry, media Wiki. You could make a whole bunch of these articles, an article per row. That's what we're usually working to, is every row in a table that comes in, we turn that into a topic. But as they're all each individual pages, they have their own history. They can be separately tagged. We can add multimedia to them. And we can represent each topic in a view in different ways. So if I edit this now, the schema that's defined for these pages have types. So you can define the possible values. This is a multi-value field. And you can just keep adding to them and then save. I won't do that because it'll make people upset. But admittedly, it's kind of hard for users to take advantage of data forms. It requires a lot of reading the manual, as they say. So this is what we talk about when we mention structured data. So if I was to ask you, why do you think people find Excel hard to let go of? Can you involve? Sorry? Yep. Commonality familiarity. And they think they know how it works. Yeah. It is definitely ownership. Ownership is what we found was the number one thing. Because we have many database systems developed over the years where we're trying to take people away from using Excel. They need a collaborative environment. So we're trying to make them collaborate. We're trying to make the information that they create reusable so that it's not a throwaway thing. And it's frustrating watching people spend so much time fiddling and merging data and keeping things up to date by hand. It should be something that computers can do for them if only they would use the database that we give them. But the problem is they want to present the data in their own way. They want their columns, their headings. They want to create their own reports. They don't want to have to go through a database administrator. And if you don't have the resources to have the appropriate quantity of people or people with sufficient time and patience to sit down with users and work with them every day, they feel that they lose control of their data. If they keep it in their spreadsheet, yes, it wastes a lot of time. But at least it's their time. And it's up to them, really. So what are the risks? If we give them the perfect system, well, sometimes new systems are created. And they are technically better. But as with any project-based activity, people come and go. Money comes and goes. The systems can be left neglected for years and years before the next round of funding comes through or it breaks completely. So people have experience with this where they've used a system for a while and it becomes just another jail for their data and they find it very difficult to mobilize their data in and out. The other problem is it can be quite expensive to add flexibility and richness to the, and when I say richness, I typically mean multimedia. So things we take for granted on a wiki, like a commenting system or image galleries and that type of thing. And incidentally, we also have a web-dav interface, which makes that quite easy to work with. It can be that the new way doesn't actually meet their needs. So has anybody heard of Google data wiki? No, it was a Google lab thing. It fascinates me because I read the project description and it was basically describing FOSWIKI. Of course, they're describing their own product that they're making. But they actually do a better job of describing FOSWIKI than FOSWIKI does itself. Possibly because FOSWIKI is a thing that really has evolved. It never started off with all of these features and goals in mind. But as all the Pearlhackers slowly formulated this thing, this pattern has emerged where we can really make some really powerful stuff. So as I said, it's a key value-based schema. Unfortunately, there's only one schema at a time on a topic, although there are workarounds to that, but they're very geeky. Model view control separation, absolutely not. That would make things difficult for a user anyway. So there is a bit of tie in there with some of the peculiar ways that we mix up the view logic and the data storage. Plugins may extend the topic object with additional matter. And I've used this quite effectively at work. Some of the interesting things we're doing is we have these web services. So people are often copy-pasting fields from external data sources. And I really just want to link to them and really just pull in that information and cache it onto the page and make it so that they don't have to maintain that stuff that they've been copy-pasting. So we can build links in. So I've got some plugins that register some new metadata types that augment their pages with external information. So we can search, sort, and report on metadata on topics. There is a little bit of normalization possible. And I do this a little bit. But if you really go overboard and make third normal form structures, it becomes not only really, really slow, but because FOSPIC is really designed as more of a key value type query language, it has its own query language. It lends itself more to the denormalized sort of way of thinking. And so this is really a no SQL approach before it was called no SQL. So this has been, before that fad, sort of took off, you know, FOSPIC has been working with this kind of data model. And in doing so, it actually has a store API, which allows us to drop in. So at the moment, it's actually flat text files. There's no database. Even though we're trying to use FOSPIC Wiki as a database, FOSPIC itself out of the box does not use a database. It uses text files and grep. And that sounds terrifying and hopelessly unscalable. But if you do actually keep all your data in RAM, it works surprisingly well. We've found that on virtual machines, the limit is about, well, now virtual machines anyway. Once you get to over 4,000 topics in a web, it starts to get slow. And if you have lots of concurrent users using application in a web of that size, so when I say web, I mean like a namespace in other things, like workspaces in Confluence. So I don't know if you can see that. But so the anatomy of a topic is really what I wanted to show. When I say key value pairs and not necessarily key value as such, it's more of a, we have sort of root element metadata types. And each root element can have a collection of key value pairs, which probably makes no sense this time. But you just have to remember that we have different types of metadata. So we have user-defined metadata. We have plugin-defined metadata. And some metadata types, such as the authoring information, are native to FOSPIC Wiki itself. So they're always there out of the box. And this little diagram over here is talking about an instance of a topic that uses a data form. You can implement a view using a view template. And all of these things are pages. And that's really a fascinating thing about FOSPIC is that developing these applications and dashboards, you're just editing Wiki topics. You've got your version control. You can see who's done what on the application code as well. So I very rarely have to write much Perl when I'm augmenting the Wiki. And just it really is great, because I'm the only system administrator. Well, I share some responsibilities with some of my colleagues. But it's really liberating for me, as well as them, that they can actually write their own dashboards and reports without me having to be involved. So this is one report for a project we're working with, which I'll talk about a bit later. And I didn't have any hand in this at all. I did a little bit of debugging. So this is showing a report of some topics that we're calling terms. There's a hierarchy there. And these are all just built using standard macros, standard query expressions. It's certainly taken them probably after a year of usage. You can do this sort of stuff. But if it's something that they're using every day, their reporting aspect is quite powerful for them. And it means I don't have to do much. Well, I have to do less anyway. So the weaknesses are your typical data entry person or person authoring content doesn't really even know what a schema is or what a key value thing is. So they think in terms of headings and bullets, things that they've put into a Word document, obviously they're more advanced users, well, when I say more advanced. So I'm talking about we often have students contributing to data entry efforts as well as researchers. And volunteers, in fact. So we have community people coming in and trying to give us data about natural science stuff. So data forms are simple, but you still have to read the manual. A lot of reading manual, if you want to do fancy queries in macros, we can do more. So now you're just going to talk about where I work a little bit. That's the team. Sadly, most of these people have day jobs. So three of us work full time for hubris until very recent. We've got two extra. So we are the bioinformatics team within TRIN, something called the Taxonomic Research Information Network. And the goal of TRIN is to accelerate the capture and delivery of biodiversity data. And when it comes to taxonomists, they're sort of becoming less and less of them. And having them spend all day in front of spreadsheets is a waste of their time. So one of the things that we're trying to do with TRIN. So apart from FOSWIKI, we do use other platforms. We use Ruby on Rails project called MX. We use some proprietary software that makes building identification keys a lot easier. We could have done all these things in FOSWIKI, but really it's all about the right tool for the job. So it's not that we're obsessed with FOSWIKI. It is difficult to find another open source WIKI type system that has all this type of WIKI pattern stuff to it. The other thing we do at hubris is we're trying to build a sort of information best practice guide for marking up a particular type of data set. And this is taxon profiles. So these are like species pages, fact sheets. The type of information you might see in a field guide. If you don't know what a field guide is, that's something you take into the field with you too. So if you see a critter, you can look it up and see what it is. So the thing about standards are that there's just so many of them. And when it comes to biodiversity informatics, it's no exception. So it's very daunting for your average database administrator, for someone who's not even using a WIKI, so maybe they are using a corporate database at a museum or a specimen collection. If they want to expose the data and make it reusable, even to start with, they have to know how to export the data in a standards compliant way. Because there are so many standards, it's difficult to know the best way to do that. So part of our project is to come up with some guidelines for that. So we're trying to avoid creating any new vocabularies, too many new terms or any new schemers. It's been necessary in a few spots, but we've done a pretty good job of mashing some stuff up. I'll show you that in a second. So we have this problem where we're trying to integrate many, many systems. And because there's only been three of us for a while now, we've sort of tried to consolidate on just FOSWIKI as a sort of portal for doing that. There are, of course, lots of legacy systems. We have electronic lab book things. We have obscure specimen tracking systems. And we have tax on profiles. So we're trying to only build missing bits and otherwise work on links between systems. So rather than reinvent the world, even if we could do it in FOSWIKI, we're just trying to link stuff together. So this was what I was talking before about copy-paste madness. We have these people building species lists, checklists. And they're going to a database. They know the species name, but then they want all the other information associated with that name. It's classification, the authority who determined it, maybe some identification characters that comes with it. And they're sort of decorating that information with more information of their own. So that might be genetic sequences, GATC letters, that sort of stuff. And we don't want them to waste time having to keep that in sync. And it is a big problem because taxonomy changes. Sometimes, in this case here, I've got one highlighted right here. At the beginning of the year, they're looking at this species here, rhizophora, goniculator, and several months later, it was shifted entirely to a different order. And that's cool if you know about it. But when you've got a list of 1,000 species, you then, at the end of a data collection effort, have to go through one by one for each one of the 1,000 species and look up, is it still a current name? Is it still the current classification? Is the authority that I've used correct or even spelt correctly? So luckily for us, this isn't true of all disciplines, but luckily for us for plants and now for animals as well to a certain extent, plants are pretty robust. We have these web services that we can look up the name of the tax on and get all of that metadata about it, including its classification. Now, I'm using this word tax on profiles a lot, and it's occurred to me I haven't really explained what that is. So here's an example of one. Here's another example. So this is really just whenever you've got a species and any information about it. Some people have a more strict definition, but we've had to look at so many. It's sort of become all very blurry. So distribution maps, that sort of thing. There's one on the wiki. So we've come up with all these terms and there's really quite a lot of them. So you've got this sort of tag cloud soup of words. And people mean different things by the same word. People mean the same thing by different words. And it's really, really difficult when you've got these different tax on profile data sets and you want to present a unified view. So say you've got a collection of species that came from a project from somebody who was documenting the plants in northern Queensland and somebody is doing a mangrove's project over on the east coast of some island somewhere. They're talking about critters and species that are common between both sites, but they're talking about them with different terminology. They're using profiles that are structured slightly differently. And it's hard to present a unified view of this data. And to make it, it would be very, very valuable to present this data in a way that can be reused. So this is the problem. So this is just two different profiles. And as you can see, the mappings are not clear. There's no one-to-one mapping. The mappings are fuzzy where there are mappings. So our solution is to use something that we've called Wallace Core. This is named after, well, inspired by the Darwin Core standard. I don't suppose anybody here has heard of Darwin Core. Yep, one person. That's one more than I thought. So Wallace Core isn't necessarily inventing a whole bunch of new terminology or an ontology. We're using an evidence-based methodical procedure. So we've collected over 1,200 terms from about 60, I think, taxon profiles. And we've come up with a method where we're documenting the meaning and mapping of all of the elements in a taxon profile, trying to use an evidence-based approach to build a reasonably standard. There's no such thing as a standard, but we're just trying to aim for 80% to 90% coverage for the terms that you would expect to be able to find in a profile. And we're calling that Wallace Core. So this is what we're calling a term. This is all pretty boring stuff, but the term has a label and author. We have a basis term. So we try to never create a term out of thin air. It has to come from at least a profile that we've seen or an existing data standard that we've looked at. So we're really trying hard not to invent too much stuff from thin air. So the benefits of this approach is that, as I was saying, we can repurpose data a lot more easily. And I'll just show you in a second an example of that. It makes curating the data easily a lot more easier. So when we have tax on profiles encoded in the wiki using the Wallace Core format, we're hoping that we avoid the data jail problem to a certain extent, because if you can export the profile information that we've built up in the wiki and take that somewhere else, that's really been the whole goal of our project. So we've actually had users creating their own terms. We have a tax on profile builder toolkit, which I've worked very hard to try to have ready for release for this conference, but didn't quite get there. So hopefully in the next week or two, that'll be available on foswiki.org slash extensions. And this is a thing that allows users to create their own heading. So the thing is that they don't want to be told exactly the terminology that they have to use, because if we do that, they won't use it. This is going to be just like every other system that was inflexible that they had to use before, and they'd rather go back to Word. But in order to make that workable, when they create their own term for their own profiles, we have to be able to map it back to Wallace Core. So the idea is that we have all these mappings back to Wallace Core. So in Wallace Core, we have this thing called distribution. And in this profile over here, they've called it geographical range and dispersal. In this one here, they've called it distribution. And in Plinium Core, I believe that is, they've called it endemicity. I'm just a programmer. I'm not sure if I said that right. And in Weeds, they call it distribution. So this is an example of a Wallace Core term that has mappings to various other profiles. So this system basically forces the user to not only create a heading, but we like to present them as headings because that's just the easiest thing that they can cling on to. The easiest metaphor. But in actual fact, they are their own topic. So the heading in their namespace is their own topic. And the workflow forces them to set up a meaning. It's a semantic definition that allows our knowledge experts, or should I say Wallace Core mappers, our mapping team, to be able to go to a user heading that somebody has created without any intervention from the wiki team to go back and sort of tidy up after them and sort of determine what they mean when they say this heading here. Because the workflow forces them to define what they mean by that content holder. And here's an example of a term being entered. That's a very boring one. We have this thing called happiness index as well. Happiness index is how happy we are, basically, with the definition. There's also a happiness index for terms. So I can sort our terms here by happiness index. Let's see how happy we are in general. So there's a few 7s there. It's on a scale of 1 to 9. So our first 20 results out of 1,142 are all above 5. But it drops off after that, I can tell you. So we're still working through those. So have I convinced anyone that a wiki could be a database? Yeah? Maybe? Yes. And we're actually working on a... We're trying to adapt this system for a laboratory workflow that is doing Acacia DNA. So it's not been entirely smooth. We're funding a MongoDB backend to make that data more scalable. So we're still making the primary data the text file because we trust text files, and that's actually one of the selling points of PhosWiki is that if it doesn't matter how hard it crashes, you've still got the text files to resort back to. Whereas even a good SQL database can crash nastily. And when it comes to MongoDB, well, there was a talk the other day about how hard that can crash. I don't know if you saw that one. So it's really just a case. But it allows us to really index the data and the great thing about PhosWiki is with these store implementations, it's transparent to the user. So the user doesn't see any change. So if we swap out the regex search with the MongoDB one, nothing changes for them, it just becomes faster. And with the modularity of PhosWiki, it's sort of hard to describe. Like in other platforms, you don't have such a... If you're going to do hardcore queries, it just exposes you to the underlying SQL database. In PhosWiki, because there is no SQL database, it has its own query language. And a recent feature that was implemented was actually the ability to query all versions of all topics. So we can now search for finding all versions of a topic that ever had a field that contained this, or that ever had a state set to something or other, or ever had this list of contributors to a topic. So we're trying to improve the dashboards that we have so that a manager can look at the laboratory workflow and look at the things that a certain staff member has worked on in the last week, for example. And you would do that with a versions query. So the latest version might not have their authorship on it, but it will have at some point in the past. And the interesting thing about that feature was that I intended to implement it, but I made the proposal and somebody else did it for me. So that's the beauty of open source. I have to do less. Somebody else can fix the bugs sometimes. So are there any questions? MongoDB just released a new version like yesterday or something. That's supposed to make it a little bit more resilient if it crashes. They've implemented a write-ahead log. I don't know, just thought you might want to know. Oh, okay. I didn't follow that. Just yesterday. Cool. Sorry, just another question. One of the problems we've come into with trying to do data sharing issues in science is that people sort of get very, I don't want to share it with them. I'd like to see your data, but I don't really want to go the other way. Do you have a lot of problems with this or do you don't have that problem at all? Well, I have to admit that the projects I'm working with are funded across institutions. So there isn't such a secret obsession, although we do have some other stuff that is quite private. We also can implement hierarchical access controls. So you can pick and choose how you want to expose your data to a quite fine detail. A quick question on a slightly long question. With the data attributes, is there some form of the Wiki markup that lets you put them into each page so the page becomes a template for the metadata? So you want to pre-populate some of the metadata? No, no. I mean, just when you look at the Wiki page, rather than looking at it as a form, is it possible to have it as a HTML markup where there's particular Wiki tags that you use to display the specific fields? So it looks more like some kind of web page rather than form. So pre-formatted. Yes. So are you familiar with semantic media Wiki? Not really, no. Not really? So it sounds to me you're describing semantic media Wiki has these things called semantic links. So you can arbitrarily put any ad hoc information into the page that can create metadata in a way that's unstructured or is not bound to a schema. So is this sort of what you're talking about? No, what I'm asking is, you know when you clicked on a particular page's... So this is a row and a table here. Come on, Silstra. When you were showing a page's field value, as a form that you selected that one, some of the multi-select, some of the text fields, can you, like, yeah, in that, but then can you say you want to put, I don't know, say the acronym field inside the text, on the text tab? Is it a markup to say put the text, the acronym field here? Put the biome field here? Yes, well, yes. Do you want to make it editable as well? No, no, just displayed. Just displayed. There's a few different ways, sadly. There's always. This is the cool new way. So you just sort of do that. There's another one that's form field, and I can just... No, we're deprecating that one, yeah. Queer is the way to do it. The thing about the form types is that they can be rich fields, so not just holding text, but they can be interactive elements. So it might be a Google Maps field or a genome browser thing. So you can do... So a guy called Michael Dorn made FlexForm plugin, so I can do render for display, and I forget the exact parameter, but it's something like field equals... acronym, something like that. And if it's a special field type, how do the JavaScript and everything necessary to make that interactive element come up? Could you show us an example of how you could construct a slightly complex query, like maybe on a couple of fields? And I also wanted to ask about the licensing for it, because I see it's kind of copyright-respective contributors, which is not super useful, you know, wiki, but probably you have restrictions because of where the data's coming from, I'm guessing. Yes. So you're talking about the content of the actual page rather than the licensing of the wiki itself? Yeah, Trinwiki's copyright. Yes. A lot of it's user-created data and they haven't decided what license. So we're trying to push them to use Creative Commons, but they want to share it, but they don't ask them about a license. It's really too hard. I've got this guy who's made this Latin glossary. It's the most comprehensive botanical Latin glossary you could have and we're almost at the point where we can release it to the public. It's better than the Google Latin translator, by the way. I don't know if you've actually tried to use it for scientific Latin, but it's not very good. And the glossary isn't by any means as interactive as the Google Latin thing, but it's a very comprehensive list of 25,000 glossary terms. It covers some Greek as well. And the problem is he wants to share the data, but he doesn't, and he wants to have credit, but he doesn't want to be credited when somebody just changed it. And I haven't really found a CC license that sort of covers that scenario. If you can help me, I'd be glad to hear it. But I've nearly convinced him. So let's see if I can do a live demo. So FOSWIKI macros are interesting. In other platforms, you sort of have this outside-in expansion order. In FOSWIKI, it's inside-out, so you can actually build compositions of macros. So like you can build it in a macro that expands first, then an outer macro that takes the output of that one, and you can feed macros into other ones and build these monstrosities. So I go search, type, so I'm going to say, I want to get all my term forms. This is a query search. Running an experimental version of Mongo, so I don't, whoops, missing operator. That's because there's no operator. Now, this is running in debug mode on my laptop, so this might take a while. I think this is 1400. If you go to Web Search Advanced, when you hit return, get your results down the bottom, it even tells you what you'd put into the topic if you wanted to make a topic with that. So it's kind of a semi-useful prototyping tool that most people don't know about. I knew about it, but I haven't used it. You've changed your tech. Have you thought about the kinds of things that HTML5 will allow you to do with this sort of system? Hopefully, if we do HTML5, we'll be able to become WCAG compliant as well. Sorry, that's on the top of my list. HTML5, yes. At the moment, FOSWIC is not very AJAX-y, so every sort of screen is its own request. It's nice to have a sort of page that you don't leave, but it's going to reload those divs and do all those AJAX kind of things. And we've sponsored a REST plug-in, because the native REST API is a bit lacking. But the new REST plug-in allows us to send objects in JSON to and from the server over HTTP REST with content negotiations. That's the first step to really enabling AJAX-y type stuff. But in terms of specific HTML5 technologies, I haven't really thought that far ahead. Getting close to the end, so I'll just take one more question. I like the idea of sort of bottom-up. You can design a form out of nothing that your users can when they need to. Can you add how simple is it to add constraints validation? This one's got to be a number or anything like that. When that was your starting point, somebody just said, he's a box. Yes, validation is something that can be done but isn't part of the native data forms experience. Yeah, it's an intended feature yet to come. So really, it's hard to enforce constraints and things, because fundamentally, a topic is just a collection of metadata. So there's nothing that I know of. You could make a plug-in that prevents somebody saving illegal values into a metadata field if you so wish to do it that way, but you sort of then short-circuit a lot of the arbitrary Excel-like nature of this information. Yeah. Okay, well, I think Paul's going to be around for a few more minutes after the talk, but we have to get ready for the next one. So it's been good to hear how trying to deal with the unreasonable demands of all those users out there leads to this interesting bit of software. So would you all join with me in thanking Paul?