How Well do you Know Your Data? Converting an Archive of Proprietary Markup Schemes to JATS: A Case Study
CC Attribution 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Faye Krawitz,
Jennifer McAndrews,
Richard O'Keeffe,
The presentation will describe the challenges, benefits, and opportunities resulting from converting an archival collection of approximately 750,000 files to JATS. The goal was to migrate the American Institute of Physics (AIP) and member society archival collection from multiple generations of proprietary markup to an industry standard to create a true archive, all managed within a new, more controlled content management system. Integral to the process was the adoption and application of the XML technologies XSLT, XPath, and Schematron to transform and check the content. Sounds straightforward doesn't it? Perform a thorough document analysis, map out the transformation rules, convert the data. But is it? Have you accounted for all historical variations, generated text, metadata, nomenclature variations on XML file assets? Beside your core, don't forget about reuse for other products, edge cases, online presentation, distribution channels and staff training!
 Hello, I'm Richard O'Keefe. I'm Faye Croetz. Hi, Jen McAnders. Hi, and we're here to talk about our journey as we might actually migrated to JAS. We've recently done that over the last year. We were participants at the last two conferences just as spectators, but now we have some real life experience that we wanted to share with you. And what we're going to do is present in three specific parts. Jennifer will be talking about the content transformations and the trouble spots, which matches up with the title of our presentation. And Faye will be talking about the validation and the QC piece that had to go on after we had done all these transformations. And what you'll find is that most of you, many of you have been working in NLM or have been working with any kind of convergence of your own. A lot of what you'll see is probably very familiar. You'll see many commonalities and many of it might even be self-evident to you as to what you come across in the papers and the data as you go to convert it. But one of the things that was pointed out by one of the peer reviewers, and I thank you, whoever you are, is that they indicated that everyone understands the trouble spots, how important they are. But a lot of times we underestimate how important they are. And it's really, really important to make sure that you know exactly what you need to do and how you go about doing it. So we don't want to take anything for granted. The fact is that our systems, tools, even the markup that you've used over years, sometimes decades, it changes all over the course of time. But of course the data itself, what you're trying to capture with all these tools, that's the most important asset. And that really doesn't change. You want to preserve its quality throughout its historical lifetime. So as we were doing this, what we learned is that it's not really just about the tags. It also has a ripple effect. It also affects your surrounding infrastructure and the support that you need to build and make the tags as useful as possible. So we'll be speaking about what AIP chose to do, and of course your circumstances may vary. The key thing is that, as we all know, the world doesn't stop when you have a project like this. You all have other obligations and responsibilities that you need to do, and you need to factor it all in as you go about doing this. So just a little bit about AIP. You can see the metrics and some of the factoids about AIP. We've been around for quite a while, and we support a wide portion of the physics community. But what I'd like to draw your attention to mostly is the mission statement at the bottom, because what it is, it's a premise that runs throughout the back. It's really formed the background and backbone of why we wanted to move to JATS and how JATS can help us achieve that particular mission. And also, in regard, allure's presentation was actually a great lead-in to this, only because a lot of the themes that she had mentioned and brought up, you'll see recurring throughout this. So what I wanted to also mention is that in JATS, we found a really great vehicle to achieve what our goal was. And as you can see in the mission statement, it's really applicable to anybody out there. If you just replace physical and applied scientists with any of your consumers, clients, or end users, and you replace AIP with your organization's name, you'll see this is what we're all really trying to achieve. So even though we work in the physics space, it really can apply and be helpful to just about anybody. This is where we had to start with. This was the scope of our challenge ahead of us. The AIP content collection was about 800,000 records, and it was divided up over three particular markup groups. They all derived at one point out of ISO 12083, which was a standard, but over years, actually two decades or at the time, it morphed into really an AIP type of format. And we primarily had everything in a header or a header reference XML, SGML format, and we had full text SGML, which was used on our online platform for quite a while, as well as an XML that was derived from our full text SGML and evolved mostly throughout the course of this particular time. How do we use it? Like most people had been using it. We used it to create the online PDFs, the print PDFs, and also as a source for our HTML, rendering it out on our own online platform. And quite frankly, it really did work well. But as Laura had noted, the evolution of how the NLM became into Jats and how more and more people were using it and new user groups are coming on all the time, AIP recognized the trend and knew that the times were changing and needed to do something. And that if we had any kind of affection for our own XML, the bottom line is it really wasn't that special. It's what it was tagging that was special. So what was the real problem? Why did we want to change? Well, it had morphed into something that was very AIP centric. It became a little overly specialized for our products and it was becoming a product-based markup as opposed to a content-based markup. And with that comes the necessary support and infrastructure and expenses that come with maintaining something proprietary and with many data transformations, so on and so forth. And it was becoming quite cumbersome to work with and as new standards come on and the community starts to embrace them, it makes it more difficult and costly to enhance and incorporate those into our products. And in the end, what we needed to do is recognize that it was at the end of its life cycle. It had matured to a point where we really couldn't take it anywhere further. So what AIP needed to do is focus on what we wanted to do next. So the key was the two areas of standardization. We wanted to join the community as Laura was mentioning. The community is a very important thing and the AIP XML community, well, you're looking at it. This was it. We go out and have a lunch break. That's how we discuss AIP XML tags. Right now, we have a whole wider community that we can take advantage of. We wanted to better position ourselves to adopt standards and obviously best practices that go along with using them, which would make the data interchange and the distribution of our data, which is our primary core mission, that much easier. And mostly, it was just great way to showcase the content at XML because believe it or not, the JETS as is was more than enough to tag what we wanted to tag at this point in time. But, it quickly became evident that not only was it a matter of changing tags, like we needed to do the trend, we needed to take our systems itself and transform that. And that would mean setting ourselves up for success. Converting to JETS is just not the answer in and of itself. It's really making sure you make the best use of it. And what that did is affected workflow, the content management aspects, staff roles, etc. You can go down the line of all the business rules and everything else that something like this would affect. So the first thing I wanted to talk about is the standards. And what happens that everybody is doing it? We succumbed to peer pressure. Yes, we were weak. But not only with the XML, it also mattered with the tools that support it because once you have a widely used XML tag suite or set just as this, is that you have XSLT, you have Schematron, all these other standards that could help. And it eliminates a lot of proprietary type of work that might be too costly for yourself. And it also widens the base on your own staff of who can operate and manipulate and work and make it the most efficient process you can. So and more importantly, as Laurel was chastising us about the listserv, it would enable us to evolve with the community and actually participate, join in, contribute, and hopefully innovate along with the community. And obviously our presence here is testament to that. So typically our XML, it fit nicely in with the traditional usage, so it wasn't so bad. And we had the benefit of dealing with standards to begin with. So we already knew that it would be of a benefit. When you work at AIP, this is what you see pages and pages and pages of. And you would think that extremely long mathematical equations, tables that can take up 400 pages in a journal would be the most devastatingly difficult part of your transform. But since we were using MathML already, and we were also using the Oasis XML exchange model, these ended up actually being the easiest part of the transformation, believe it or not. Now why all these long equations end up equaling zero? We don't know, but it's just the way it is. But believe it or not, all we needed to do in our transform was change the prefix from M to NML, and we were all set. So if we had to prove and change all this, we'd be in straight jackets by now probably. So obviously no surprise. We were using Jets, XSLT and Schematron. We're using the green. We're using the archive version because it's very important for us to have an open mind and also to be able to distribute our content, because that is a large part of what we really profess to do and want to do. So, and as well, even though all these were well and good and we get a lot of benefits from them, the other aspect was that using our old systems, the old management structures and everything else, it really wasn't sufficient to make maximum use of this. So I just wanted to speak a little bit about some of the foundational work we needed to do to get this started. So the first thing was obviously communicate. We needed to make the plan known. First, it's real easy to sit in a room and decide, oh, we should go and adopt this standard. Yeah, that's a great idea. We put the, we just put our foot down. We made the decision. We're decisive and decided to go for it. And that was half the time that's half the battle. So what we needed to do is communicate this out to everybody. Of course, there was a small group in the content technology group at AIP that was working on this particular project, but everyone was aware of it and they understood the importance of it and they understood that by converting to the Jets Tag Suite and maximizing the potential of that data, that it was really the cornerstone of where we wanted to go as an organization. So it was not done in a vacuum. The next aspect of it was that we needed to build for success was ownership. Is that AIP, the way it was originally set up, we had a couple different content groups that would work with the material. We had online groups. We had a production group. We had support groups for the production. And they were reporting to different managerial structures. Although everyone had AIP's best interest at heart, they had their own projects, occasionally their own agendas. And occasionally it would create silent unintentional conflicts where sometimes a decision would be made and it wasn't always officially communicated throughout. And then we would get some of the surprises that you'll hear about later in the content that we wouldn't have necessarily anticipated. So the first thing that we did is make sure everyone understood we have a unified message. We have a certain thing and how we want to approach and handle the data. And so we consolidated our content groups into a single group following that same principle and officially designated, which would be our group here as the official owners of the content and the gatekeepers to make sure that any changes to the markup or anything that's going to affect the product is handled properly. And even though I chose Monty Python's Black Knight, none shall pass. We don't really intend to have his fate, but we do intend to embody or disembodied his tenacity and make sure that everything is done properly. And believe it or not, there was surprisingly little resistance for this reorganization. Everybody realized it was the best thing to do. And in a lot of ways, it actually relieved quite a few departments because this way they didn't have to worry about making unilateral decisions. If you worked in online areas and supported our platform, you concentrated on online. If you were a project manager, you managed projects. If you worked in production, you worked in production, you could focus on your core skillsets and do the best you could at your job and leave the content technical details to the content technology group and pass muster on that. Everyone has a say into how we can change and what we need to do, but it does have to go through a more formal process. And as a result, we'll be able to better maintain our content. That leads to the next piece, which was for the infrastructure we did invest in a new content management system currently. We're working with R Suite to implement that. And what it will allow us to do is effectively manage the content, avoid the unneeded workflow duplication, as well as avoid those unwanted end-arounds to get content to look right or fit right even though it doesn't really have a really solid XML-based reason to do that. We'll have more extensibility, but most more importantly, we're going to have great versioning capabilities. And that's going to be very key to everything. So we can maintain and make sure we can document every change for documentation because in a way, we're almost starting at square one again. We had all our old content built over the years and now we go back to, here's Jax 1.0. This is where we're starting and we'll be able to manage our content and have a really firm grasp as to where it goes, where it needs to go and know exactly who, what, when and where. We need to manipulate something. And when you have authors submitting irradims and publisher notes and things like that, there's very important information to have. And the greatest data in the world, no matter how well you tag it, if you don't manage it properly, it's not going to be as effective for you. So what was the next step? So we know we have Jax, okay, check mark, we decided on that. We were going to use XSLTs instead of some of the custom transformation programs we had been using. We did need to decide what we were going to convert. I had mentioned 800,000 records, we really have more than that, but we decided to just translate the header of records with the references and we also decided to convert our full text XML since it went back rather far to 2005. We decided to put on hold for now the full text SGML that we had. So we made a business decision to do that. The next step was to test the XSLT transformations and adapt our findings and whatever the specifications based on the results. We needed to introduce a nice quality control system and this is where we started to implement the schema tron process. So we started to, again, while we were doing is take advantage of yet another standardization tool and then we need to document what we were doing. So for future generations of AIPers, they won't curse the day we were on the earth and they will be forever thankful that we took care of everything and they know exactly why something was done. And then obviously we'd have to train the staff and our production partners in the AIP usage because one of the key facts is yes, we're using the green archival DTD but it doesn't mean that we don't have our own way we would like to use it. For instance, how we might want to use the main content tag or we're going to use custom matter. What attributes are we going to allow and specific use? All those types of things or what we would be incorporating into our schema tron and taking firm details of so we can manage the data and have it still stay as predictable as possible for us. So with that, the next step would be with this foundation set. It was just time to go wrestle with all the angle brackets and find out what surprises were lurking for us. So with that, I'll pass it over to Jennifer McAndrews. Yes, when it comes to wrestling with angle brackets, that's how I spend my day. And then when someone says, hey, go get some clip art for your slides, that's like the lottery. So we're going to have some fun. So we had our prizes. Once we agreed on what the challenges were ahead of us, we had to get specific about how we were going to go about converting the data set, what needed to be done, what would be helpful to do, and what was going to have to wait for another time. The first and most critical piece in getting started was our document analysis. We needed to know what was out there, what we were dealing with, and how we were going to handle it. Keeping our data sets in mind, we needed to determine what the tagging rules were that we needed to follow. And once those decisions were made, at least enough to get started, we needed a means of keeping track of them. So the creation and maintenance of a document map, which we referred to internally as our spec or specification, became their first big working challenge. This was also really good time for us to create sample XML files and take copies of very specific data structures that may cause a problem later and we would need to be checking. So this is not a big surprise slide because you've seen it. The tagging principles that we decided upon. The first thing, one of the first things we did was define how AIP was going to use JATS. And that was our step off approach to all of these things. When the main facets of the document analysis and creation of the spec, sorry, in the main process, whatever, forget it. So since we had two data sets converting, the SGML sort records and the full text XML both converting to JATS, their tagging principles, our tagging principles were agreed upon early in the analysis. We made very strict distinctions between elements and attributes. We decided to hold customized content models and just not use them right away. We could use JATS out of the box as it were. And in the short term, we got a little bit tricksy with the X markup and we reserved that and in this instance, we used it to wrap problem areas in our data that we knew we would have to go back on later. For instance, for any occurrence we had of an ordered list in our source that abroniously failed to indicate what type of label was to be used, whether it was a bullet or a number, we actually output a label. But we wrapped that label in an X tag so later on we could do a data search and find those instances and go in on a case by case basis. Later on we can use the X but for now we were a little sneaky. In creating the document map, we came upon this very adorable formula. We had our tagging principles, number one, multiplied by our existing documentation, which are all the piles and piles of paperwork sitting in the back of people's desks and basements holding up chairs and the institutional memory. We're fortunate enough to have a lot of people at AIP who remembered or were there at the very inception of markup and online publications. So they were able to help us out with why certain decisions were made so that we could maintain that decision making process going forward and we didn't lose anything in what they meant us to keep. This is a sample of one of the pages from our resulting documentation. The first column is what the element was followed by a sample of what our proprietary tagging was and then it's target suggests. It's that fourth column there that was the most critical for us. These are the instructions to our programmer or the who was writing or XSLT that explained exactly what needed to be done. Frequently, there were instances of why this decision was made and then as you can see, any updates that came later on the process. The idea here is that we have this document that we can always go back to and see why we made this choice, what changed and how it was handled. Part of the benefits of the conversion process was our ability to polish up our archive. Stepping away from reviewing or completely tagged articles and instead just reading the DTD from top to bottom helped us identify any ambiguities in the existing tag set. Reading a tag outside of an article where inside an article you can get a sense of what the tag meant just by reading what the content was. If you're looking at just as a tag on its own, you start to see where it really just doesn't make any sense all by itself. In our example, extra one, extra two, extra three, that's pretty darn meaningless if you're just looking at the tag. We were able to take situations like that and use the more meaningful and intuitive tag set from the JATS that allows anyone to open up an XML file and say, oh, okay, I see, this is the guy's role, this is his professor, I see that all makes sense. The conversion to JATS was an ideal opportunity just for these cases. The only trick came in deciding whether the adjustment should be made using the XSLT or whether it was wider to use a pre-process in advance of the transform. In this instance, we did this via XSLT, it was fairly straightforward for us. Going in, we had some expected trouble spots, things we knew were going to be a problem. Of course, the very first one that so many people are going to be facing is generated text. That's our most pervasive known trouble spot. We found a solution by both accounting for instances of generated text in the specification. For instance, we would have a spec rule that says take, act, and output the text analysis. And also, it means of leveraging some of our existing conversions, our existing programs that in the past would populate data that had been generated text. We ran that as a pre-process to the first XML file, then transformed so that the final output file had all of the data within it. Style variations were another issue for us. Each of these scenarios is a possible method of presenting the title introduction, depending upon what journal you're in and what their styles were. Previously, we could do this through CSS or just page outlay, layouts. But now with Jats, we want to have everything in our file. So we had to locate and document every instance of every possible configuration of our titles. Text tags or tag reuse. We also call these our heavy list lifting tags. We had a number of tags that, while they were named the same, were handled very differently. One of the most problematic is shown here. It's a catch all of info, which for some reason we keep calling other info, even though the ERs aren't there. This position within the reference determined its handling. So it could indicate straight text to be carried forward. It could indicate punctuation or spacing that needed to be moved and then carried forward. Or it could be a mathematical formula within it and that had a whole separate thing. So again, each of these instances had to be located, documented, and accounted for in our specification. Of course, no listing of known problems is complete without the fabulous multimedia. And I was so tickled to see Laura mention it earlier because it really reflected what we saw. At the very beginning, at the dawn of time, we had treated multimedia as an external file. We had a link to it within our main XML and it linked over to our supplementary database. That's our first step. Then we started seeing them coming in. Well, I guess we're going to have to really find a way to tag this in our data because people want a live file within the file. So we came up with an embedding structure. And then we started to see a lot more of them. So we had to come up with a real solution. So we came up with our real solution and that wasn't enough because then we had to come up with a solution that accounted for different formats of the very same file. So now we have five separate, no, one, two, three, four, five, six separate possible tagging structures from multimedia that we have to locate, account for, write a transformation rule for, and beg the programmer to include. And this only is going to work if all of the tagging inside the file is correct. And all the tagging was done by hand so we weren't real competent. But we were hoping. Finally, probably our biggest hurdle was time. As Rich mentioned before, we are the whole content technology team. We look larger in real life. And we had to do all of this work that we're talking about on top of everything else we were doing. You know, you have regular workday, emails, meetings, more emails, more media support calls. This one needs help with that. That one needs help. And meetings, right. But the thing was we were able to do it. The biggest reason we were able to do it was we had the support of the rest of the staff and our management. Everybody understood the importance of this project to the company as a whole. So okay, yeah, there might have been a little grumbling. We said, you know, we can't do that today. You're going to have to wait for tomorrow. But for the most part, everybody was really on board and that was a big bonus. Our unexpected trouble spots, language. We had this group of people who speak in ankle brackets all day long writing a specification for someone who speaks in pearl code. We thought maybe English would be a good answer. You know what, that really turned out to not be a good answer. It wasn't even our common language. But what we decided to do was to use XPath, which in retrospect is a very obvious solution. In our example, what you could see is the PAX, which was a tag that we all know. We know where it goes. We know what it does. We know what its limitations are. So we thought, oh, you know, take PAX and put it here. But our programist says, well, where can I find the PAX? Where is it going to be? Is it always going to be in front of? Could it be in a reference? Could it be here? And these are things we kind of hadn't considered because our knowledge already, we have all that on our head. And using the XPathing in our specification allowed us to show our programmers and anyone else down the line who doesn't have this strange knowledge packed in their head for when they're can sleep. Anybody else will be able to follow it. Nasty surprises. You only think you know your data. You really don't. And the point of it is, again, as soon as a human being comes in and there's fingers on your data, you've lost the measure of positive control. These nasty surprises are out there, no matter how careful you are. And we were, I think, pretty darn careful throughout the years, or have our bus or quality checking unforeseen gaps snuck through. A lot of these gaps were identified on our first conversion run. And the example we're showing here is this attribute lead para. We perhaps foolishly assumed it was there because it's in our rules. It's in the directions, instructions we gave to our vendors. Make sure this gets included in your first paragraph in Chaos Journal. We need that there. It wasn't until we saw the online displays and our lead paragraphs, which need to appear as bold online, weren't there. We had no idea. So then this ended up being a whole go back, identify the problem areas. Rules were written for the transform again. And Fay will talk to you. Actually, you know what? Fay is going to talk to you right now about what was done going forward to make sure that doesn't happen again. Hi, I'm Fay. I'm going to speak to you about the quality control and testing piece. As discussed, we've had about 800,000 files that we've been producing markup for for over 20-plus years. And during that time, business rules changed, publishing styles changed, technology changes. And we separated this quality control and testing into four phases. Pre-requisite training, content tagging checks, incorporating Schematron and online displays. The first step to prerequisite training is that AIP chose to expand the knowledge of the entire QC team. We were already DTD experts, Jennifer and myself, but sending us out to learn the NLM Jats DTD was very valuable. Here we learned the industry tagging practices, and we understood the customization possibilities that the Jats does allow for. We also had a two-day class in XPath, XSLT, and Schematron. And with that two-day class, it taught us how to speak XSLT syntax. We learned to write much clearer and concise instructions for the programmer. And learning the Schematron actually enabled us to write our own Schematron, and we didn't have to rely on programmers. So it was really a great class. The next step was the content and tagging checks. The first part of that was it was actually performed while the XSLT was in progress. Here are the analyst check blocks of XSLT code, and they first confirmed that the programmer understood the instructions. We had daily meetings where held to discuss any new findings or clarifications with instructions. It was early on at this point where we did find one trouble spot, and that was with our specification, which Jennifer touched on. We realized that at that point our specification was way too simple. We would write something, for example, convert the AIP artwork tag to the Jats graphic tag. And to us, that made sense. However, it sounds simple, but it's actually much more complicated when you're writing the mapping, and you have to think about when you're converting, for example, the AIP artwork tag, it converts to the Jats graphic tag when it's a child of, for example, an entry or a de-formula. But in other cases, it's an inline graphic where it falls in other places, maybe a title or a formula. The next step during this phase was the batch processing, and this was performed when the whole XSLT was complete. The first goal we had was to see that the XSLT was working and that the files were valid. That was basically our goal at this point. And here we found, and basically decisions, we started to find some hidden problems. And when you get to these hidden problems, you have to decide, is it better to fix the source material? Is it better to fix the XSLT? Is it better to fix the Jats when the files are already completed? And you have to step back and ask yourself some questions. How many errors are there? How about fixing this impactor schedule? Is it easy to fix? And each problem was done on a case-by-case basis. I'll give you one example. In our AIP markup, if we had a reference item and we had two parts to it, we had a comma in between the two parts. And that was allowed in our AIP. However, when we converted to Jats and you had two parts, that comma had to be put inside, could not be floating PC data. So we had to, in this case, we decided to make an XSLT change. Of course, you're dealing with spaces and you're dealing, it wasn't so easy, but this was something we worked out with the XSLT. So you have to decide where is it best to fix your error and discuss that. The next step was group testing. And this was performed when all the files were, when the converted files were all valid. And we started by running approximately 200 files from various journals and different article types. The entire group checked the same files. Again, more hidden problems were found as you go on. And we looked, for example, in this case for Drop Text. We didn't actually proofread the files, but we knew if we had one tag in the source, we made sure that the tag was also in the target and all the text was inside. And this is where we started running the Schematron. We would get an error, for example, if we knew a table footnote had to be in the format of T1N1, let's say, and it came in a different format, here we would get an error. I'm going to explain the Schematron a little later in the slides, but we would start to check the Schematron errors also. The next step we referred to as bulk processing. And this was performed when these 200 files were approved in the group testing. At this point, we ran all the 800 files through the XSLT. And it was great. We had a 99% accuracy rate. Now you could think that's a great number, however, when you're dealing with 800,000 files, that's still left us with about 8,000 files with errors. So again, we had to decide where do we fix the errors. We fix it in the XSLT, or do we wait and fix it in the JAS when it was done. I'll give you an example here of what we found. We found that with our conference proceedings, we had multiple editors that were grouped together and didn't follow our intended specification. So here we decided to fix the source in this case. And we found a few other errors such as I mentioned. But here, then we re-ran the XSLT and all the files were run. So here, the final step was referred to as analyzed flag data. And this step was actually done on all, was done on the converted JAS files. And Jennifer touched on this. And what we set for analyzed flag data was basically hard to find known problems that we knew about in the beginning. As you see here, I'll give you an example. Here we have a 10 with a superscript minus 8, and that's how our PDF looked. We chose, or in our older data, we had a tag called at other. And this at other tag represented some unknown characters from our first generation of transforms done in the early 90s. And what we did is if we didn't know what the character was at that time, we tagged it as an at other and put in this case an at sign QL, which really had no meaning. It was just an unknown character. So because we didn't know what this tag, how to really convert this tag, we chose to tag it as an X strike tag, a strike wrapped in an X tag. And this way, it would go all the way through the conversion. It would be a valid file. And we knew at the end, we would get a list, a program would supply a list of all the X strike tags, and then we could analyze them at the end and modify all our JAS files. Again, a business decision was made to do this at the end, but it really made the most sense to us. There were a few leftovers at the time, but those we did manually. The next step in the quality control and testing was incorporating SchemaTron. I have to say this was my favorite piece. This is a central piece in our QC process, and it was derived from our preexisting proprietary QC programs. The SchemaTron is a list of checks or resurgence written in XPath syntax. It tracks errors and warnings specific to our data. Now, as mentioned by Rich, we decided early on to use, not make any modifications, not to customize the JAS DTD, and to rely on the SchemaTron as to have more control over our AIP styles. An example, we have one journal, one RKS journal, which has structured and a structured abstract. The rest don't. So here was a case where in the SchemaTron, we can make sure that every KS journal will always have a structured abstract. So this is the type of thing that we checked for. The XSLT was actually performed throughout the whole QC process since we started, because every time we found something specific in a journal, we would write a SchemaTron rule and to match our AIP styles. If the rule, let's say, only happened 80% of the time, we would put it in as a warning. But this way, we had every single rule as much as we could in that SchemaTron. So it's extremely helpful. Where you don't have to say, reviewing this journal, let me make sure that A, B, C, and D is correct. You don't have to do that. If you put it all in the SchemaTron, you could make sure that everything is correct. Right now, we have about 250 rules in place, and we're continuing writing more. Here's an example. If you look at the top of the screen, compound keywords. The top, the orange, the compound keyword has actually four parts inside, and that's valid in JETS. And actually, this was the problem that we found earlier. However, our style, we wanted to only allow for, if you look at the bottom, two parts inside the compound keyword. So on each one having code, one having value for this specific type. So what do we do? We create a SchemaTron rule to only allow two parts inside a compound keyword. So here, the file was valid, but the second check actually gave us an error. While you don't have to understand the actual SchemaTron rule, you'll see the orange is the error that actually comes out when you run the SchemaTron. The first one saying a compound keyword must have two parts, and the second one saying that the actual values of the attribute must be code and value. So again, we were able to put an error in there that shows our style, but yet the file was valid, and we didn't have to modify the JETS DTD. The final stage, again, which Jennifer touched on, is the online displays. And the icing on the cake, I don't know if you could see the icing, but to us, we called this the icing on the cake. And our assumptions at this point are that the file is valid, the SchemaTron is run, and everything is perfect. The testing here was expanded, not just to our small group, but to the online publishing group, and we selected random testers throughout the organization so they could also check the files. Of course, at this point, errors are found along every way, but errors are fewer and fewer along the way. And this was a case, again, as Jennifer found, when we were actually viewing the files, we saw that a paragraph in one of our journals wasn't bold, and sure enough, it was so much easier to find when you're viewing the files. So what did we do? We made a SchemaTron track, and this will never, ever happen again because we found this error. But it's just really a great way to confirm that all your business rules are being followed, this online displays. Okay. Rich. Oh, Jennifer. So just to sum it up, just go over some of the general lessons learned and conclusions. Excuse me. And the bottom line is, you know, don't go it alone. I mean, I think that was the key point that Laura was bringing out in the first presentation, is that you have this whole community out here, brilliant people, people who've gone through often what you're trying to do or solve, and when you're following industry best practices and standards, it just enables you to get that much more in the way of resources. I want to be beat. Set yourself up for success. Make sure that when you do all this work that you build a system and you build an environment in which you can constantly stay successful with it. And it's also impossible to overstate the importance of document analysis. But as we pointed out, no matter how much document analysis you do, there's always something that slips in because you figure 800,000 or more records. You figure how many characters could possibly be in there, how many hands have touched them over years. Doing somewhere is going to look good online or in a PDF, but it's not going to be right underneath the covers. And then what you could do is use the analysis as an opportunity to correct any known problems that you have that you always wanted to fix in your data, but never had the opportunity to do because once you want to take a project like this, how often will you ever get the resources and the attention of the organization to make sure that you can get it all done. So take advantage of it while you can. Do you want to finish up all of them? Okay. Hi. It's good to see you again. I'm kind of like a little bit crazy. Recognizing the difference between bad and incorrect data. I apologize. I didn't write my notes on that one. Can you speak to bad and incorrect? Well, what that was, the difference was is that you have data that is just all out bad. It just absolutely makes no sense. A user put in, there's an empty tag that makes no sense somewhere. It's just totally bad data. And then you have something that's just incorrect data where they chose a tag that's kind of what was you good. It might be valid, but it's not really what you wanted in that particular location. So as you go through your process of analysis, you try to identify which one is which because it makes a big difference as to how you want to go about and fix it. Okay. So incorrect data was a lot of my sneaky Pete solutions to get the math to display. I see. Create your details document map. We showed an example of it before. The more information you can put into this, the better it is going forward. It's a living document that hopefully you'll be able to pass off to any user who comes into the organization or is already in the organization who wants to understand what you've done and why you've done it. So, you know, is detailed as possible, keep it as current as possible. The XPath training, as Faye mentioned, was very valuable mostly because it gave us that common language to work on. But also, you know, I look at it and think, oh my God, how did I not know XPath cold having worked in Markup for so long? So it's become a tool that I didn't even realize how useful it was going to be until I started working with it. Now I can't imagine. It's kind of how I think and we talk about menus in XPath. It's terrible. Schematron is an essential piece of the QC process. We've always had a QC check that has been done for us by our programmers, proprietary, written in-house. But this Schematron has given Faye and I and Rich the opportunity to create our own rules, as Faye mentioned, not have to bother a programmer. We know the date of best. And I don't mean to say that to sound vain, but we work closely with it all day, every day. So we know what it has to have. We know who to ask to make sure that this particular paragraph is treated correctly or that heading is accurate. So it's much more expedient for us to be able to update and maintain this document than it is to have to put this all into some kind of request and pass it off to someone else and create another round of questions. And of course, the top and foremost issue is to work as a team. Hopefully by us being here, you kind of get the idea that, yeah, we do team stuff. And that spirit was really with us throughout the entire process with the organization. Everybody really enjoyed this project and that made it so much easier to have the support of the staff, your managers, your bosses, and just the whole production and programming crew. Okay, and that's just a little slide of the closing statement of the paper that we submitted. And in the end, we just really, we achieved what we wanted to do. And of course, there's always going to be room for improvement, and we will continue to improve that and hopefully be participants, active participants within the community and grow with all of you. Questions? Sorry to take too long. I know we're dreading to come up here, but we can't get us off the stage now. Okay, good. I'm live. Kevin Hawkins from M Publishing at the University of Michigan Library. I was really interested in the slide you had about the heading introduction. You were talking about how this is handled in different journals, that each journal has its own particular style. And what really surprised me was that you wanted to, and in your old tagging, these were tagged uniformly and yet handled by a style sheet in the output, correct? But then in your new tagging, you instead wanted to encode them differently. That is sort of move this information out of the style sheet and into the Jats markup. Why did you choose to do that? Rather than rewrite the CSS to continue to handle the styling for each journal? I'm going to step on Rich's toes on this. Part of that decision was made so that we had more control of the data because, I can't think of a better way to explain it, some of our work process can be fragmented. If we put that decision in CSS, then again, we're going to be writing requests to someone who can change the CSS going forward or who's going to make sure that, oh, this journal is italic, this journal is all cap. By taking it out of that structure and putting it in our XML, where I know, you know, it is almost a little overstepping to have that kind of instruction inside the XML, but that gives us the control. It lets us say, okay, in this scenario, this is, you know, it's bold, italic, it has a labeled number on it, so wherever we send this off, you know, whether we're displaying it or it's going to come up on, I don't know, too terribly much about CSS. I don't know if it's going to display the same on Firefox as it does on Explorer. You know, we've hit those situations before. This just gives us the ability to always make that change. Yes? Yes, I mean, and just to follow up with that is that the slide where we had generated text, I mean, AIP, to help out production systems and processes and smooth things through, we had an awful lot of generated text and all those labels were generated. And what we wanted to do is put that in the content then. For a lot of the reasons that Jennifer just spoke to, in that when we distribute it out, it's up to whoever wants to display this, if you do whatever they need to do to display it however they want. They don't have to guess, well, am I going to have to generate Arabic for this particular journal? Am I going to have to generate Roman numerals for this particular journal? And then, quite frankly, in this day and age, even with the AIP journals recently, there's a lot of, there's always, they're always reassessing their displays and requirements for what they want in the PDFs and all that. So by removing it out of the generated text environment and putting the labels specifically in there or not putting it in there, it would give the control that Jennifer was speaking about in the final products. There was another question. Hold that thought. In fact. Hi. My name is Chris Maloney. I work for PMC. Excuse me. You mentioned that you use R-suite and I was just curious about that. I know the infrastructure is probably very important to your success. What do you think of R-suite? R-suite and I think it's based on Mark Lodgett. Is that right? Well, I can't speak in great detail to that because I grew up, hasn't really focused on it. I don't know. I can't speak to that. I don't know. Evan, if you wanted to make a comment on that. Evan Owens, AIP. I have that conversation offline if you like. We're in the middle of a major R-suite implementation. The core facilities are to have a real archive with version control, a master archive. So we have a production archive and then the publication archive. So version control. Also we're in a world where we have a lot of external systems, external typesetters, external hosting provider, external content enrichment vendors and so on. So that particular project is to provide the plumbing that connects all of that together. And of course we have a large number of external data feed customers. Rich mentioned this in his slides, but one of the real benefits of Jats and one of the reasons we chose not to customize Jats at all is we can then hand our data to any external provider and say this is Jats according to the spec out of the box. Don't bother us. Go read the spec. Wendell? Yeah. Hi. Wendell Pease, Pease Consulting Services. Thanks for the plug. So in addressing the training, you should also be thinking Mulberry because of course the Jats training and a lot of the, you know, so everybody here knows about Mulberry so I don't need to stress that, but in fairness. The thing that interests me, I mean I sort of have a question which is kind of too prong but they're related. One is the question that has to do with the fact that you guys were implementing a migration from one tag set into another and therefore you had to control over both ends. And of course a lot of people are dealing with something rather different in terms of production, you know, pulling data in front that's being edited live and so forth. And so the question comes up as to what lessons that you might take from your experience which would apply also in this other kinds of applications of Jats. The second part of it has to do with the thing that you touched on with respect to the whole training issue and the expertise that you developed internally which I think is actually really interesting because that is one of the trends that we're seeing is that you're not seeing such a strong boundary line between the technical people and the editorial people as we used to. Instead, the editorial people are getting a lot of technical expertise and leveraging it and that improves communications as well as control, right? So can you just say whatever might come to mind with respect to the whole thing about what kind of lessons that you took which you think would help others who are also working with Jats as a team working together? Well, I would think from the training perspective is that even if your, you know, AIP was fortunate to have, we have very talented contact technology programmers who we could work with and so on. But even if you need to use a consulting firm or you don't have those resources in-house, having the training just to speak the language that they do because nobody is going who you hire, it's going to know the data as well as you do. But if you're able to communicate in a language that's common with them and explain what it is, then it just makes it that much easier. So even if you are not writing a schema trial and you're not writing an XSLT yourself, understanding how it works and knowing that those are more than likely the tools that someone is going to be using to do the work for you, it's just a great benefit because once you can communicate that and take advantage of every scenario, and I think that's what Faye and Jennifer had touched on quite a bit, is that we would think, well, we know this is the way we do it. And someone would come back, well, is it every single time you do that? What happens if it's not there? What happens if it's spelled differently? What if the attributes come up capital? What do I do? And it really makes you think that every single scenario that's there, you want to know if it's not written the right way. You could just have drop text and you may never know about it. You need to make sure that every instance is accounted for and only you know that and being able to communicate that in a way that's almost neutral, it's not your organization jargon, it's an industry standard kind of speech to say that is just so much more helpful. I know you had asked the first part question and honestly I don't recall exactly the details. Well it was about what lessons you might think apply to organizations who are not migrating an old data set into JADS but who are actually maybe working actively to publish new material that's coming from authors, a source from Word or whatever the case may be, something that which has sort of come back to the chaos question may be a little less stable. But yet, I mean in that kind of scenario, do you think that this general idea about the technical level of expertise within the editorial group is going to apply the same way? Yeah, I just wanted to comment and then you can answer, you know you have something too. The lessons learned for myself primarily because Fay and I were so involved in the data analysis and creation of the specification. I didn't know it was going to sound trite but documentation from any point whether you're going from migration or you're starting new. The JADS documentation online is wonderful, there are great examples there but like when we went to try and figure out some of the tags that were sitting in our data set and we just went I don't even know what this is, I don't know what it's trying to be, it's a string of numbers, I have no clue, nobody was there who really remembered and there's a lot of digging. So even from the very beginning, you might think it's minor, it makes perfect sense to you and everybody around you, it's still important to have it noted somewhere, have that information in the central repository that anybody can get hold of it and make sure they're going forward. There's a chain, there's a trail for people to follow to find out how you got from A to B. You had a comment? And I think what it is because we're in a situation just as you're describing, we have a production unit, an editorial unit that processes the information on a daily basis constantly and they had been familiar working with XML editors working in the XML and their role has changed and they're looking at the content itself and making sure that the author's information is being preserved properly and what it will come down to is that particular documentation and what's more important to me from our standpoint or anybody's standpoint is that you need to make sure you annotate it with your usage and all that included because just because you have the JAPS documentation saying A, B and C, well how are you interpreting A, B and C in your particular environment and making sure that they are aware of that and one of the things that we would be doing to help enhance that is when you were writing the Schematron, commenting out why we are doing this, it really, if you pull those comments out it becomes that external extra piece of documentation that helps people in production or why are we doing this, why is this happening, what business rule is trying to be met here in this particular case and we can break it down and translate it into a jargon that is more familiar with them and co-op wheels that they can use. And one thing I'd like to add, when it comes to XSLT, if you could say it in a pattern, if you could just say it, it could be written in the XSLT and that's basically the philosophy that we went with, that if you could find the pattern then just, it's really pretty simple to write so that's how we think. Evan. I'll add a little more context. Just so the audience understands, AIP no longer copy edits in house or typesets so the authors, the manuscripts all go to offshore vendors and come back to us right now in AIP XML. The documentation that was produced as part of this project will of course be the basis for them returning JATs to us but they can't do that until we switch our platform because we can't currently host JATs online until we launch our new platform. So it's never easy, changing all the parts all at the same time. But in the end, documentation is absolutely essential and the Schematron enforces that as well. Hi, Jeff Beck, National Library of Medicine. I want to thank you for this paper. I've already shared it in the preliminary proceedings with some organizations who are thinking about their data as an example of, hey look, here are some people that did it the right way. So I want to thank you for that. And then I wanted to kind of go on the back of Wendell's question and that is, when you were writing your transformation specification using XPath, did you realize how close you were to actually writing your own XSLT and were you excited about that? Yes, and you know what, Jennifer and I have now, we write small XSLTs for the company, writing the whole big one, you know, that's still yet to come. But whenever an XSLT needs to be written in the company, we are now the official XSLT writers and that was something that we gained from XPath. It's just, you know, learning that. I mean, that was really great. So I think, yeah, it was one of those things where, like I said, I didn't know XPath. We had a similar kind of format that we would communicate needs in. It wasn't strict XPath. And then of course we started writing our spec in kind of a plain English. And then XPath came in, so yeah, you know, by the time, by the end of it, you look at it and you go, hey, wait a second. You know, I had had this, but you know, like I said, yeah, we do write XSLTs. There's no way some of the things that were done for this, I would have been crying. So we really needed a lot of information. But we enjoy it very much, yes. Yeah, that's what I have. We're having fun, yes. That's what I have Laura for. The things that make me cry. But I mean, the key thing for an organization is these used to be done, these transformations in Lex or Pearl or something like that and that depended on when you had a technical resource, when they were available, when they could fit it in. Now it's more self-contained. Can I have one more question? Hi, Jenny Sherman, Nature Publishing Group. I'm just wondering how many people within your company are involved in this project and how long it took end to end? Well, primarily it was the three of us and we had one dedicated resource to handle the main XSLT that was really monstrous. And there were assorted other developers, maybe two or three, over a piece of their time where it brought in to run the list, do large amounts of data processing because we work on a UNIX platform so we needed their help to run the files and do all that. So I mean, it really boiled down to about four individuals spending most of their time doing it, even though we all had other responsibilities at the same time because we were responsible for sustaining the whole publishing operation with their questions and support simultaneously. And we started probably August, September, 2011 is when we had started to write the initial specs and all that. And it really, because of other responsibilities and resources, it was really about January of this particular year when we started to get full fledged into it and we spent most of the first and second quarter finishing up and running the tests on the files. So overall, about a nine to 10 month span. Another piece I'd like to add to that. At the same time, this team was converting the XML. We were also restructuring all the content, assets, the graphics, the packaging of the content as we moved from our old repository to our new repository and that has to tie in with the XML correctly, of course. So there was another set of projects going on as well. Thank you. Thank you. Okay. Thank you. Thank you. Thank you. Thank you.
 Hello, I'm Richard O'Keefe.  I'm Faye Croetz.  Hi, Jen McAnders.  Hi, and we're here to talk about our journey as we might actually migrated to JAS.  We've recently done that over the last year.  We were participants at the last two conferences just as spectators, but now we have some real  life experience that we wanted to share with you.  And what we're going to do is present in three specific parts.  Jennifer will be talking about the content transformations and the trouble spots, which  matches up with the title of our presentation.  And Faye will be talking about the validation and the QC piece that had to go on after we  had done all these transformations.  And what you'll find is that most of you, many of you have been working in NLM or have  been working with any kind of convergence of your own.  A lot of what you'll see is probably very familiar.  You'll see many commonalities and many of it might even be self-evident to you as to  what you come across in the papers and the data as you go to convert it.  But one of the things that was pointed out by one of the peer reviewers, and I thank  you, whoever you are, is that they indicated that everyone understands the trouble spots,  how important they are.  But a lot of times we underestimate how important they are.  And it's really, really important to make sure that you know exactly what you need to do  and how you go about doing it.  So we don't want to take anything for granted.  The fact is that our systems, tools, even the markup that you've used over years, sometimes  decades, it changes all over the course of time.  But of course the data itself, what you're trying to capture with all these tools, that's  the most important asset.  And that really doesn't change.  You want to preserve its quality throughout its historical lifetime.  So as we were doing this, what we learned is that it's not really just about the tags.  It also has a ripple effect.  It also affects your surrounding infrastructure and the support that you need to build and  make the tags as useful as possible.  So we'll be speaking about what AIP chose to do, and of course your circumstances may  vary.  The key thing is that, as we all know, the world doesn't stop when you have a project  like this.  You all have other obligations and responsibilities that you need to do, and you need to factor  it all in as you go about doing this.  So just a little bit about AIP.  You can see the metrics and some of the factoids about AIP.  We've been around for quite a while, and we support a wide portion of the physics community.  But what I'd like to draw your attention to mostly is the mission statement at the bottom,  because what it is, it's a premise that runs throughout the back.  It's really formed the background and backbone of why we wanted to move to JATS and how JATS  can help us achieve that particular mission.  And also, in regard, allure's presentation was actually a great lead-in to this, only  because a lot of the themes that she had mentioned and brought up, you'll see recurring throughout  this.  So what I wanted to also mention is that in JATS, we found a really great vehicle to achieve  what our goal was.  And as you can see in the mission statement, it's really applicable to anybody out there.  If you just replace physical and applied scientists with any of your consumers, clients, or end  users, and you replace AIP with your organization's name, you'll see this is what we're all really  trying to achieve.  So even though we work in the physics space, it really can apply and be helpful to just  about anybody.  This is where we had to start with.  This was the scope of our challenge ahead of us.  The AIP content collection was about 800,000 records, and it was divided up over three  particular markup groups.  They all derived at one point out of ISO 12083, which was a standard, but over years, actually  two decades or at the time, it morphed into really an AIP type of format.  And we primarily had everything in a header or a header reference XML, SGML format, and  we had full text SGML, which was used on our online platform for quite a while, as well  as an XML that was derived from our full text SGML and evolved mostly throughout the course  of this particular time.  How do we use it?  Like most people had been using it.  We used it to create the online PDFs, the print PDFs, and also as a source for our HTML,  rendering it out on our own online platform.  And quite frankly, it really did work well.  But as Laura had noted, the evolution of how the NLM became into Jats and how more and  more people were using it and new user groups are coming on all the time, AIP recognized  the trend and knew that the times were changing and needed to do something.  And that if we had any kind of affection for our own XML, the bottom line is it really  wasn't that special.  It's what it was tagging that was special.  So what was the real problem?  Why did we want to change?  Well, it had morphed into something that was very AIP centric.  It became a little overly specialized for our products and it was becoming a product-based  markup as opposed to a content-based markup.  And with that comes the necessary support and infrastructure and expenses that come with  maintaining something proprietary and with many data transformations, so on and so forth.  And it was becoming quite cumbersome to work with and as new standards come on and the  community starts to embrace them, it makes it more difficult and costly to enhance and  incorporate those into our products.  And in the end, what we needed to do is recognize that it was at the end of its life cycle.  It had matured to a point where we really couldn't take it anywhere further.  So what AIP needed to do is focus on what we wanted to do next.  So the key was the two areas of standardization.  We wanted to join the community as Laura was mentioning.  The community is a very important thing and the AIP XML community, well, you're looking  at it.  This was it.  We go out and have a lunch break.  That's how we discuss AIP XML tags.  Right now, we have a whole wider community that we can take advantage of.  We wanted to better position ourselves to adopt standards and obviously best practices that  go along with using them, which would make the data interchange and the distribution  of our data, which is our primary core mission, that much easier.  And mostly, it was just great way to showcase the content at XML because believe it or not,  the JETS as is was more than enough to tag what we wanted to tag at this point in time.  But, it quickly became evident that not only was it a matter of changing tags, like we  needed to do the trend, we needed to take our systems itself and transform that.  And that would mean setting ourselves up for success.  Converting to JETS is just not the answer in and of itself.  It's really making sure you make the best use of it.  And what that did is affected workflow, the content management aspects, staff roles, etc.  You can go down the line of all the business rules and everything else that something like  this would affect.  So the first thing I wanted to talk about is the standards.  And what happens that everybody is doing it?  We succumbed to peer pressure.  Yes, we were weak.  But not only with the XML, it also mattered with the tools that support it because once  you have a widely used XML tag suite or set just as this, is that you have XSLT, you have  Schematron, all these other standards that could help.  And it eliminates a lot of proprietary type of work that might be too costly for yourself.  And it also widens the base on your own staff of who can operate and manipulate and work  and make it the most efficient process you can.  So and more importantly, as Laurel was chastising us about the listserv, it would enable us  to evolve with the community and actually participate, join in, contribute, and hopefully  innovate along with the community.  And obviously our presence here is testament to that.  So typically our XML, it fit nicely in with the traditional usage, so it wasn't so bad.  And we had the benefit of dealing with standards to begin with.  So we already knew that it would be of a benefit.  When you work at AIP, this is what you see pages and pages and pages of.  And you would think that extremely long mathematical equations, tables that can take up 400 pages  in a journal would be the most devastatingly difficult part of your transform.  But since we were using MathML already, and we were also using the Oasis XML exchange  model, these ended up actually being the easiest part of the transformation, believe it or  not.  Now why all these long equations end up equaling zero?  We don't know, but it's just the way it is.  But believe it or not, all we needed to do in our transform was change the prefix from  M to NML, and we were all set.  So if we had to prove and change all this, we'd be in straight jackets by now probably.  So obviously no surprise.  We were using Jets, XSLT and Schematron.  We're using the green.  We're using the archive version because it's very important for us to have an open mind  and also to be able to distribute our content, because that is a large part of what we really  profess to do and want to do.  So, and as well, even though all these were well and good and we get a lot of benefits  from them, the other aspect was that using our old systems, the old management structures  and everything else, it really wasn't sufficient to make maximum use of this.  So I just wanted to speak a little bit about some of the foundational work we needed to  do to get this started.  So the first thing was obviously communicate.  We needed to make the plan known.  First, it's real easy to sit in a room and decide, oh, we should go and adopt this standard.  Yeah, that's a great idea.  We put the, we just put our foot down.  We made the decision.  We're decisive and decided to go for it.  And that was half the time that's half the battle.  So what we needed to do is communicate this out to everybody.  Of course, there was a small group in the content technology group at AIP that was working on  this particular project, but everyone was aware of it and they understood the importance  of it and they understood that by converting to the Jets Tag Suite and maximizing the potential  of that data, that it was really the cornerstone of where we wanted to go as an organization.  So it was not done in a vacuum.  The next aspect of it was that we needed to build for success was ownership.  Is that AIP, the way it was originally set up, we had a couple different content groups  that would work with the material.  We had online groups.  We had a production group.  We had support groups for the production.  And they were reporting to different managerial structures.  Although everyone had AIP's best interest at heart, they had their own projects, occasionally  their own agendas.  And occasionally it would create silent unintentional conflicts where sometimes a decision would  be made and it wasn't always officially communicated throughout.  And then we would get some of the surprises that you'll hear about later in the content  that we wouldn't have necessarily anticipated.  So the first thing that we did is make sure everyone understood we have a unified message.  We have a certain thing and how we want to approach and handle the data.  And so we consolidated our content groups into a single group following that same principle  and officially designated, which would be our group here as the official owners of the  content and the gatekeepers to make sure that any changes to the markup or anything that's  going to affect the product is handled properly.  And even though I chose Monty Python's Black Knight, none shall pass.  We don't really intend to have his fate, but we do intend to embody or disembodied his tenacity  and make sure that everything is done properly.  And believe it or not, there was surprisingly little resistance for this reorganization.  Everybody realized it was the best thing to do.  And in a lot of ways, it actually relieved quite a few departments because this way they  didn't have to worry about making unilateral decisions.  If you worked in online areas and supported our platform, you concentrated on online.  If you were a project manager, you managed projects.  If you worked in production, you worked in production, you could focus on your core skillsets  and do the best you could at your job and leave the content technical details to the  content technology group and pass muster on that.  Everyone has a say into how we can change and what we need to do, but it does have to  go through a more formal process.  And as a result, we'll be able to better maintain our content.  That leads to the next piece, which was for the infrastructure we did invest in a new  content management system currently.  We're working with R Suite to implement that.  And what it will allow us to do is effectively manage the content, avoid the unneeded workflow  duplication, as well as avoid those unwanted end-arounds to get content to look right or  fit right even though it doesn't really have a really solid XML-based reason to do that.  We'll have more extensibility, but most more importantly, we're going to have great versioning  capabilities.  And that's going to be very key to everything.  So we can maintain and make sure we can document every change for documentation because in  a way, we're almost starting at square one again.  We had all our old content built over the years and now we go back to, here's Jax 1.0.  This is where we're starting and we'll be able to manage our content and have a really  firm grasp as to where it goes, where it needs to go and know exactly who, what, when and  where.  We need to manipulate something.  And when you have authors submitting irradims and publisher notes and things like that,  there's very important information to have.  And the greatest data in the world, no matter how well you tag it, if you don't manage it  properly, it's not going to be as effective for you.  So what was the next step?  So we know we have Jax, okay, check mark, we decided on that.  We were going to use XSLTs instead of some of the custom transformation programs we had  been using.  We did need to decide what we were going to convert.  I had mentioned 800,000 records, we really have more than that, but we decided to just  translate the header of records with the references and we also decided to convert our full text  XML since it went back rather far to 2005.  We decided to put on hold for now the full text SGML that we had.  So we made a business decision to do that.  The next step was to test the XSLT transformations and adapt our findings and whatever the specifications  based on the results.  We needed to introduce a nice quality control system and this is where we started to implement  the schema tron process.  So we started to, again, while we were doing is take advantage of yet another standardization  tool and then we need to document what we were doing.  So for future generations of AIPers, they won't curse the day we were on the earth and  they will be forever thankful that we took care of everything and they know exactly why  something was done.  And then obviously we'd have to train the staff and our production partners in the AIP usage  because one of the key facts is yes, we're using the green archival DTD but it doesn't  mean that we don't have our own way we would like to use it.  For instance, how we might want to use the main content tag or we're going to use custom  matter.  What attributes are we going to allow and specific use?  All those types of things or what we would be incorporating into our schema tron and taking  firm details of so we can manage the data and have it still stay as predictable as possible  for us.  So with that, the next step would be with this foundation set.  It was just time to go wrestle with all the angle brackets and find out what surprises  were lurking for us.  So with that, I'll pass it over to Jennifer McAndrews.  Yes, when it comes to wrestling with angle brackets, that's how I spend my day.  And then when someone says, hey, go get some clip art for your slides, that's like the  lottery.  So we're going to have some fun.  So we had our prizes.  Once we agreed on what the challenges were ahead of us, we had to get specific about  how we were going to go about converting the data set, what needed to be done, what would  be helpful to do, and what was going to have to wait for another time.  The first and most critical piece in getting started was our document analysis.  We needed to know what was out there, what we were dealing with, and how we were going  to handle it.  Keeping our data sets in mind, we needed to determine what the tagging rules were that  we needed to follow.  And once those decisions were made, at least enough to get started, we needed a means of  keeping track of them.  So the creation and maintenance of a document map, which we referred to internally as our  spec or specification, became their first big working challenge.  This was also really good time for us to create sample XML files and take copies of very specific  data structures that may cause a problem later and we would need to be checking.  So this is not a big surprise slide because you've seen it.  The tagging principles that we decided upon.  The first thing, one of the first things we did was define how AIP was going to use JATS.  And that was our step off approach to all of these things.  When the main facets of the document analysis and creation of the spec, sorry, in the main  process, whatever, forget it.  So since we had two data sets converting, the SGML sort records and the full text XML  both converting to JATS, their tagging principles, our tagging principles were agreed upon early  in the analysis.  We made very strict distinctions between elements and attributes.  We decided to hold customized content models and just not use them right away.  We could use JATS out of the box as it were.  And in the short term, we got a little bit tricksy with the X markup and we reserved  that and in this instance, we used it to wrap problem areas in our data that we knew we  would have to go back on later.  For instance, for any occurrence we had of an ordered list in our source that abroniously  failed to indicate what type of label was to be used, whether it was a bullet or a number,  we actually output a label.  But we wrapped that label in an X tag so later on we could do a data search and find  those instances and go in on a case by case basis.  Later on we can use the X but for now we were a little sneaky.  In creating the document map, we came upon this very adorable formula.  We had our tagging principles, number one, multiplied by our existing documentation,  which are all the piles and piles of paperwork sitting in the back of people's desks and  basements holding up chairs and the institutional memory.  We're fortunate enough to have a lot of people at AIP who remembered or were there at the  very inception of markup and online publications.  So they were able to help us out with why certain decisions were made so that we could  maintain that decision making process going forward and we didn't lose anything in what  they meant us to keep.  This is a sample of one of the pages from our resulting documentation.  The first column is what the element was followed by a sample of what our proprietary tagging  was and then it's target suggests.  It's that fourth column there that was the most critical for us.  These are the instructions to our programmer or the who was writing or XSLT that explained  exactly what needed to be done.  Frequently, there were instances of why this decision was made and then as you can see,  any updates that came later on the process.  The idea here is that we have this document that we can always go back to and see why  we made this choice, what changed and how it was handled.  Part of the benefits of the conversion process was our ability to polish up our archive.  Stepping away from reviewing or completely tagged articles and instead just reading the  DTD from top to bottom helped us identify any ambiguities in the existing tag set.  Reading a tag outside of an article where inside an article you can get a sense of what  the tag meant just by reading what the content was.  If you're looking at just as a tag on its own, you start to see where it really just  doesn't make any sense all by itself.  In our example, extra one, extra two, extra three, that's pretty darn meaningless if you're  just looking at the tag.  We were able to take situations like that and use the more meaningful and intuitive tag  set from the JATS that allows anyone to open up an XML file and say, oh, okay, I see, this  is the guy's role, this is his professor, I see that all makes sense.  The conversion to JATS was an ideal opportunity just for these cases.  The only trick came in deciding whether the adjustment should be made using the XSLT or  whether it was wider to use a pre-process in advance of the transform.  In this instance, we did this via XSLT, it was fairly straightforward for us.  Going in, we had some expected trouble spots, things we knew were going to be a problem.  Of course, the very first one that so many people are going to be facing is generated  text.  That's our most pervasive known trouble spot.  We found a solution by both accounting for instances of generated text in the specification.  For instance, we would have a spec rule that says take, act, and output the text analysis.  And also, it means of leveraging some of our existing conversions, our existing programs  that in the past would populate data that had been generated text.  We ran that as a pre-process to the first XML file, then transformed so that the final  output file had all of the data within it.  Style variations were another issue for us.  Each of these scenarios is a possible method of presenting the title introduction, depending  upon what journal you're in and what their styles were.  Previously, we could do this through CSS or just page outlay, layouts.  But now with Jats, we want to have everything in our file.  So we had to locate and document every instance of every possible configuration of our titles.  Text tags or tag reuse.  We also call these our heavy list lifting tags.  We had a number of tags that, while they were named the same, were handled very differently.  One of the most problematic is shown here.  It's a catch all of info, which for some reason we keep calling other info, even though the  ERs aren't there.  This position within the reference determined its handling.  So it could indicate straight text to be carried forward.  It could indicate punctuation or spacing that needed to be moved and then carried forward.  Or it could be a mathematical formula within it and that had a whole separate thing.  So again, each of these instances had to be located, documented, and accounted for in  our specification.  Of course, no listing of known problems is complete without the fabulous multimedia.  And I was so tickled to see Laura mention it earlier because it really reflected what  we saw.  At the very beginning, at the dawn of time, we had treated multimedia as an external file.  We had a link to it within our main XML and it linked over to our supplementary database.  That's our first step.  Then we started seeing them coming in.  Well, I guess we're going to have to really find a way to tag this in our data because  people want a live file within the file.  So we came up with an embedding structure.  And then we started to see a lot more of them.  So we had to come up with a real solution.  So we came up with our real solution and that wasn't enough because then we had to come  up with a solution that accounted for different formats of the very same file.  So now we have five separate, no, one, two, three, four, five, six separate possible tagging  structures from multimedia that we have to locate, account for, write a transformation  rule for, and beg the programmer to include.  And this only is going to work if all of the tagging inside the file is correct.  And all the tagging was done by hand so we weren't real competent.  But we were hoping.  Finally, probably our biggest hurdle was time.  As Rich mentioned before, we are the whole content technology team.  We look larger in real life.  And we had to do all of this work that we're talking about on top of everything else we  were doing.  You know, you have regular workday, emails, meetings, more emails, more media support  calls.  This one needs help with that.  That one needs help.  And meetings, right.  But the thing was we were able to do it.  The biggest reason we were able to do it was we had the support of the rest of the staff  and our management.  Everybody understood the importance of this project to the company as a whole.  So okay, yeah, there might have been a little grumbling.  We said, you know, we can't do that today.  You're going to have to wait for tomorrow.  But for the most part, everybody was really on board and that was a big bonus.  Our unexpected trouble spots, language.  We had this group of people who speak in ankle brackets all day long writing a specification  for someone who speaks in pearl code.  We thought maybe English would be a good answer.  You know what, that really turned out to not be a good answer.  It wasn't even our common language.  But what we decided to do was to use XPath, which in retrospect is a very obvious solution.  In our example, what you could see is the PAX, which was a tag that we all know.  We know where it goes.  We know what it does.  We know what its limitations are.  So we thought, oh, you know, take PAX and put it here.  But our programist says, well, where can I find the PAX?  Where is it going to be?  Is it always going to be in front of?  Could it be in a reference?  Could it be here?  And these are things we kind of hadn't considered because our knowledge already, we have all  that on our head.  And using the XPathing in our specification allowed us to show our programmers and anyone  else down the line who doesn't have this strange knowledge packed in their head for when they're  can sleep.  Anybody else will be able to follow it.  Nasty surprises.  You only think you know your data.  You really don't.  And the point of it is, again, as soon as a human being comes in and there's fingers  on your data, you've lost the measure of positive control.  These nasty surprises are out there, no matter how careful you are.  And we were, I think, pretty darn careful throughout the years, or have our bus or quality  checking unforeseen gaps snuck through.  A lot of these gaps were identified on our first conversion run.  And the example we're showing here is this attribute lead para.  We perhaps foolishly assumed it was there because it's in our rules.  It's in the directions, instructions we gave to our vendors.  Make sure this gets included in your first paragraph in Chaos Journal.  We need that there.  It wasn't until we saw the online displays and our lead paragraphs, which need to appear  as bold online, weren't there.  We had no idea.  So then this ended up being a whole go back, identify the problem areas.  Rules were written for the transform again.  And Fay will talk to you.  Actually, you know what?  Fay is going to talk to you right now about what was done going forward to make sure that  doesn't happen again.  Hi, I'm Fay.  I'm going to speak to you about the quality control and testing piece.  As discussed, we've had about 800,000 files that we've been producing markup for for over  20-plus years.  And during that time, business rules changed, publishing styles changed, technology changes.  And we separated this quality control and testing into four phases.  Pre-requisite training, content tagging checks, incorporating Schematron and online displays.  The first step to prerequisite training is that AIP chose to expand the knowledge of  the entire QC team.  We were already DTD experts, Jennifer and myself, but sending us out to learn the NLM  Jats DTD was very valuable.  Here we learned the industry tagging practices, and we understood the customization possibilities  that the Jats does allow for.  We also had a two-day class in XPath, XSLT, and Schematron.  And with that two-day class, it taught us how to speak XSLT syntax.  We learned to write much clearer and concise instructions for the programmer.  And learning the Schematron actually enabled us to write our own Schematron, and we didn't  have to rely on programmers.  So it was really a great class.  The next step was the content and tagging checks.  The first part of that was it was actually performed while the XSLT was in progress.  Here are the analyst check blocks of XSLT code, and they first confirmed that the programmer  understood the instructions.  We had daily meetings where held to discuss any new findings or clarifications with instructions.  It was early on at this point where we did find one trouble spot, and that was with our  specification, which Jennifer touched on.  We realized that at that point our specification was way too simple.  We would write something, for example, convert the AIP artwork tag to the Jats graphic tag.  And to us, that made sense.  However, it sounds simple, but it's actually much more complicated when you're writing  the mapping, and you have to think about when you're converting, for example, the AIP artwork  tag, it converts to the Jats graphic tag when it's a child of, for example, an entry or  a de-formula.  But in other cases, it's an inline graphic where it falls in other places, maybe a title  or a formula.  The next step during this phase was the batch processing, and this was performed when the  whole XSLT was complete.  The first goal we had was to see that the XSLT was working and that the files were valid.  That was basically our goal at this point.  And here we found, and basically decisions, we started to find some hidden problems.  And when you get to these hidden problems, you have to decide, is it better to fix the  source material?  Is it better to fix the XSLT?  Is it better to fix the Jats when the files are already completed?  And you have to step back and ask yourself some questions.  How many errors are there?  How about fixing this impactor schedule?  Is it easy to fix?  And each problem was done on a case-by-case basis.  I'll give you one example.  In our AIP markup, if we had a reference item and we had two parts to it, we had a comma  in between the two parts.  And that was allowed in our AIP.  However, when we converted to Jats and you had two parts, that comma had to be put inside,  could not be floating PC data.  So we had to, in this case, we decided to make an XSLT change.  Of course, you're dealing with spaces and you're dealing, it wasn't so easy, but this  was something we worked out with the XSLT.  So you have to decide where is it best to fix your error and discuss that.  The next step was group testing.  And this was performed when all the files were, when the converted files were all valid.  And we started by running approximately 200 files from various journals and different article  types.  The entire group checked the same files.  Again, more hidden problems were found as you go on.  And we looked, for example, in this case for Drop Text.  We didn't actually proofread the files, but we knew if we had one tag in the source, we  made sure that the tag was also in the target and all the text was inside.  And this is where we started running the Schematron.  We would get an error, for example, if we knew a table footnote had to be in the format  of T1N1, let's say, and it came in a different format, here we would get an error.  I'm going to explain the Schematron a little later in the slides, but we would start to  check the Schematron errors also.  The next step we referred to as bulk processing.  And this was performed when these 200 files were approved in the group testing.  At this point, we ran all the 800 files through the XSLT.  And it was great.  We had a 99% accuracy rate.  Now you could think that's a great number, however, when you're dealing with 800,000  files, that's still left us with about 8,000 files with errors.  So again, we had to decide where do we fix the errors.  We fix it in the XSLT, or do we wait and fix it in the JAS when it was done.  I'll give you an example here of what we found.  We found that with our conference proceedings, we had multiple editors that were grouped together  and didn't follow our intended specification.  So here we decided to fix the source in this case.  And we found a few other errors such as I mentioned.  But here, then we re-ran the XSLT and all the files were run.  So here, the final step was referred to as analyzed flag data.  And this step was actually done on all, was done on the converted JAS files.  And Jennifer touched on this.  And what we set for analyzed flag data was basically hard to find known problems that  we knew about in the beginning.  As you see here, I'll give you an example.  Here we have a 10 with a superscript minus 8, and that's how our PDF looked.  We chose, or in our older data, we had a tag called at other.  And this at other tag represented some unknown characters from our first generation of transforms  done in the early 90s.  And what we did is if we didn't know what the character was at that time, we tagged  it as an at other and put in this case an at sign QL, which really had no meaning.  It was just an unknown character.  So because we didn't know what this tag, how to really convert this tag, we chose to  tag it as an X strike tag, a strike wrapped in an X tag.  And this way, it would go all the way through the conversion.  It would be a valid file.  And we knew at the end, we would get a list, a program would supply a list of all the X  strike tags, and then we could analyze them at the end and modify all our JAS files.  Again, a business decision was made to do this at the end, but it really made the most  sense to us.  There were a few leftovers at the time, but those we did manually.  The next step in the quality control and testing was incorporating SchemaTron.  I have to say this was my favorite piece.  This is a central piece in our QC process, and it was derived from our preexisting proprietary  QC programs.  The SchemaTron is a list of checks or resurgence written in XPath syntax.  It tracks errors and warnings specific to our data.  Now, as mentioned by Rich, we decided early on to use, not make any modifications, not  to customize the JAS DTD, and to rely on the SchemaTron as to have more control over our  AIP styles.  An example, we have one journal, one RKS journal, which has structured and a structured abstract.  The rest don't.  So here was a case where in the SchemaTron, we can make sure that every KS journal will  always have a structured abstract.  So this is the type of thing that we checked for.  The XSLT was actually performed throughout the whole QC process since we started, because  every time we found something specific in a journal, we would write a SchemaTron rule  and to match our AIP styles.  If the rule, let's say, only happened 80% of the time, we would put it in as a warning.  But this way, we had every single rule as much as we could in that SchemaTron.  So it's extremely helpful.  Where you don't have to say, reviewing this journal, let me make sure that A, B, C, and  D is correct.  You don't have to do that.  If you put it all in the SchemaTron, you could make sure that everything is correct.  Right now, we have about 250 rules in place, and we're continuing writing more.  Here's an example.  If you look at the top of the screen, compound keywords.  The top, the orange, the compound keyword has actually four parts inside, and that's  valid in JETS.  And actually, this was the problem that we found earlier.  However, our style, we wanted to only allow for, if you look at the bottom, two parts  inside the compound keyword.  So on each one having code, one having value for this specific type.  So what do we do?  We create a SchemaTron rule to only allow two parts inside a compound keyword.  So here, the file was valid, but the second check actually gave us an error.  While you don't have to understand the actual SchemaTron rule, you'll see the orange is  the error that actually comes out when you run the SchemaTron.  The first one saying a compound keyword must have two parts, and the second one saying  that the actual values of the attribute must be code and value.  So again, we were able to put an error in there that shows our style, but yet the file  was valid, and we didn't have to modify the JETS DTD.  The final stage, again, which Jennifer touched on, is the online displays.  And the icing on the cake, I don't know if you could see the icing, but to us, we called  this the icing on the cake.  And our assumptions at this point are that the file is valid, the SchemaTron is run,  and everything is perfect.  The testing here was expanded, not just to our small group, but to the online publishing  group, and we selected random testers throughout the organization so they could also check  the files.  Of course, at this point, errors are found along every way, but errors are fewer and  fewer along the way.  And this was a case, again, as Jennifer found, when we were actually viewing the files, we  saw that a paragraph in one of our journals wasn't bold, and sure enough, it was so much  easier to find when you're viewing the files.  So what did we do?  We made a SchemaTron track, and this will never, ever happen again because we found this error.  But it's just really a great way to confirm that all your business rules are being followed,  this online displays.  Okay.  Rich.  Oh, Jennifer.  So just to sum it up, just go over some of the general lessons learned and conclusions.  Excuse me.  And the bottom line is, you know, don't go it alone.  I mean, I think that was the key point that Laura was bringing out in the first presentation,  is that you have this whole community out here, brilliant people, people who've gone  through often what you're trying to do or solve, and when you're following industry  best practices and standards, it just enables you to get that much more in the way of resources.  I want to be beat.  Set yourself up for success.  Make sure that when you do all this work that you build a system and you build an environment  in which you can constantly stay successful with it.  And it's also impossible to overstate the importance of document analysis.  But as we pointed out, no matter how much document analysis you do, there's always something  that slips in because you figure 800,000 or more records.  You figure how many characters could possibly be in there, how many hands have touched them  over years.  Doing somewhere is going to look good online or in a PDF, but it's not going to be right  underneath the covers.  And then what you could do is use the analysis as an opportunity to correct any known problems  that you have that you always wanted to fix in your data, but never had the opportunity  to do because once you want to take a project like this, how often will you ever get the  resources and the attention of the organization to make sure that you can get it all done.  So take advantage of it while you can.  Do you want to finish up all of them?  Okay.  Hi.  It's good to see you again.  I'm kind of like a little bit crazy.  Recognizing the difference between bad and incorrect data.  I apologize.  I didn't write my notes on that one.  Can you speak to bad and incorrect?  Well, what that was, the difference was is that you have data that is just all out bad.  It just absolutely makes no sense.  A user put in, there's an empty tag that makes no sense somewhere.  It's just totally bad data.  And then you have something that's just incorrect data where they chose a tag that's kind of  what was you good.  It might be valid, but it's not really what you wanted in that particular location.  So as you go through your process of analysis, you try to identify which one is which because  it makes a big difference as to how you want to go about and fix it.  Okay.  So incorrect data was a lot of my sneaky Pete solutions to get the math to display.  I see.  Create your details document map.  We showed an example of it before.  The more information you can put into this, the better it is going forward.  It's a living document that hopefully you'll be able to pass off to any user who comes  into the organization or is already in the organization who wants to understand what  you've done and why you've done it.  So, you know, is detailed as possible, keep it as current as possible.  The XPath training, as Faye mentioned, was very valuable mostly because it gave us that  common language to work on.  But also, you know, I look at it and think, oh my God, how did I not know XPath cold having  worked in Markup for so long?  So it's become a tool that I didn't even realize how useful it was going to be until  I started working with it.  Now I can't imagine.  It's kind of how I think and we talk about menus in XPath.  It's terrible.  Schematron is an essential piece of the QC process.  We've always had a QC check that has been done for us by our programmers, proprietary,  written in-house.  But this Schematron has given Faye and I and Rich the opportunity to create our own rules,  as Faye mentioned, not have to bother a programmer.  We know the date of best.  And I don't mean to say that to sound vain, but we work closely with it all day, every  day.  So we know what it has to have.  We know who to ask to make sure that this particular paragraph is treated correctly or  that heading is accurate.  So it's much more expedient for us to be able to update and maintain this document than  it is to have to put this all into some kind of request and pass it off to someone else  and create another round of questions.  And of course, the top and foremost issue is to work as a team.  Hopefully by us being here, you kind of get the idea that, yeah, we do team stuff.  And that spirit was really with us throughout the entire process with the organization.  Everybody really enjoyed this project and that made it so much easier to have the support  of the staff, your managers, your bosses, and just the whole production and programming  crew.  Okay, and that's just a little slide of the closing statement of the paper that we submitted.  And in the end, we just really, we achieved what we wanted to do.  And of course, there's always going to be room for improvement, and we will continue  to improve that and hopefully be participants, active participants within the community and  grow with all of you.  Questions?  Sorry to take too long.  I know we're dreading to come up here, but we can't get us off the stage now.  Okay, good.  I'm live.  Kevin Hawkins from M Publishing at the University of Michigan Library.  I was really interested in the slide you had about the heading introduction.  You were talking about how this is handled in different journals, that each journal has  its own particular style.  And what really surprised me was that you wanted to, and in your old tagging, these  were tagged uniformly and yet handled by a style sheet in the output, correct?  But then in your new tagging, you instead wanted to encode them differently.  That is sort of move this information out of the style sheet and into the Jats markup.  Why did you choose to do that?  Rather than rewrite the CSS to continue to handle the styling for each journal?  I'm going to step on Rich's toes on this.  Part of that decision was made so that we had more control of the data because, I can't  think of a better way to explain it, some of our work process can be fragmented.  If we put that decision in CSS, then again, we're going to be writing requests to someone  who can change the CSS going forward or who's going to make sure that, oh, this journal  is italic, this journal is all cap.  By taking it out of that structure and putting it in our XML, where I know, you know, it  is almost a little overstepping to have that kind of instruction inside the XML, but that  gives us the control.  It lets us say, okay, in this scenario, this is, you know, it's bold, italic, it has a  labeled number on it, so wherever we send this off, you know, whether we're displaying  it or it's going to come up on, I don't know, too terribly much about CSS.  I don't know if it's going to display the same on Firefox as it does on Explorer.  You know, we've hit those situations before.  This just gives us the ability to always make that change.  Yes?  Yes, I mean, and just to follow up with that is that the slide where we had generated text,  I mean, AIP, to help out production systems and processes and smooth things through, we  had an awful lot of generated text and all those labels were generated.  And what we wanted to do is put that in the content then.  For a lot of the reasons that Jennifer just spoke to, in that when we distribute it out,  it's up to whoever wants to display this, if you do whatever they need to do to display  it however they want.  They don't have to guess, well, am I going to have to generate Arabic for this particular  journal?  Am I going to have to generate Roman numerals for this particular journal?  And then, quite frankly, in this day and age, even with the AIP journals recently, there's  a lot of, there's always, they're always reassessing their displays and requirements for what they  want in the PDFs and all that.  So by removing it out of the generated text environment and putting the labels specifically  in there or not putting it in there, it would give the control that Jennifer was speaking  about in the final products.  There was another question.  Hold that thought.  In fact.  Hi.  My name is Chris Maloney.  I work for PMC.  Excuse me.  You mentioned that you use R-suite and I was just curious about that.  I know the infrastructure is probably very important to your success.  What do you think of R-suite?  R-suite and I think it's based on Mark Lodgett.  Is that right?  Well, I can't speak in great detail to that because I grew up, hasn't really focused on  it.  I don't know.  I can't speak to that.  I don't know.  Evan, if you wanted to make a comment on that.  Evan Owens, AIP.  I have that conversation offline if you like.  We're in the middle of a major R-suite implementation.  The core facilities are to have a real archive with version control, a master archive.  So we have a production archive and then the publication archive.  So version control.  Also we're in a world where we have a lot of external systems, external typesetters,  external hosting provider, external content enrichment vendors and so on.  So that particular project is to provide the plumbing that connects all of that together.  And of course we have a large number of external data feed customers.  Rich mentioned this in his slides, but one of the real benefits of Jats and one of the  reasons we chose not to customize Jats at all is we can then hand our data to any external  provider and say this is Jats according to the spec out of the box.  Don't bother us.  Go read the spec.  Wendell?  Yeah.  Hi.  Wendell Pease, Pease Consulting Services.  Thanks for the plug.  So in addressing the training, you should also be thinking Mulberry because of course  the Jats training and a lot of the, you know, so everybody here knows about Mulberry so  I don't need to stress that, but in fairness.  The thing that interests me, I mean I sort of have a question which is kind of too prong  but they're related.  One is the question that has to do with the fact that you guys were implementing a migration  from one tag set into another and therefore you had to control over both ends.  And of course a lot of people are dealing with something rather different in terms of  production, you know, pulling data in front that's being edited live and so forth.  And so the question comes up as to what lessons that you might take from your experience which  would apply also in this other kinds of applications of Jats.  The second part of it has to do with the thing that you touched on with respect to the whole  training issue and the expertise that you developed internally which I think is actually  really interesting because that is one of the trends that we're seeing is that you're  not seeing such a strong boundary line between the technical people and the editorial people  as we used to.  Instead, the editorial people are getting a lot of technical expertise and leveraging  it and that improves communications as well as control, right?  So can you just say whatever might come to mind with respect to the whole thing about  what kind of lessons that you took which you think would help others who are also working  with Jats as a team working together?  Well, I would think from the training perspective is that even if your, you know, AIP was fortunate  to have, we have very talented contact technology programmers who we could work with and so on.  But even if you need to use a consulting firm or you don't have those resources in-house,  having the training just to speak the language that they do because nobody is going who you  hire, it's going to know the data as well as you do.  But if you're able to communicate in a language that's common with them and explain what it  is, then it just makes it that much easier.  So even if you are not writing a schema trial and you're not writing an XSLT yourself, understanding  how it works and knowing that those are more than likely the tools that someone is going  to be using to do the work for you, it's just a great benefit because once you can communicate  that and take advantage of every scenario, and I think that's what Faye and Jennifer  had touched on quite a bit, is that we would think, well, we know this is the way we do  it.  And someone would come back, well, is it every single time you do that?  What happens if it's not there?  What happens if it's spelled differently?  What if the attributes come up capital?  What do I do?  And it really makes you think that every single scenario that's there, you want to know if  it's not written the right way.  You could just have drop text and you may never know about it.  You need to make sure that every instance is accounted for and only you know that and  being able to communicate that in a way that's almost neutral, it's not your organization  jargon, it's an industry standard kind of speech to say that is just so much more helpful.  I know you had asked the first part question and honestly I don't recall exactly the details.  Well it was about what lessons you might think apply to organizations who are not migrating  an old data set into JADS but who are actually maybe working actively to publish new material  that's coming from authors, a source from Word or whatever the case may be, something  that which has sort of come back to the chaos question may be a little less stable.  But yet, I mean in that kind of scenario, do you think that this general idea about  the technical level of expertise within the editorial group is going to apply the same  way?  Yeah, I just wanted to comment and then you can answer, you know you have something too.  The lessons learned for myself primarily because Fay and I were so involved in the data analysis  and creation of the specification.  I didn't know it was going to sound trite but documentation from any point whether you're  going from migration or you're starting new.  The JADS documentation online is wonderful, there are great examples there but like when  we went to try and figure out some of the tags that were sitting in our data set and  we just went I don't even know what this is, I don't know what it's trying to be, it's  a string of numbers, I have no clue, nobody was there who really remembered and there's  a lot of digging.  So even from the very beginning, you might think it's minor, it makes perfect sense to  you and everybody around you, it's still important to have it noted somewhere, have that information  in the central repository that anybody can get hold of it and make sure they're going  forward.  There's a chain, there's a trail for people to follow to find out how you got from A to  B.  You had a comment?  And I think what it is because we're in a situation just as you're describing, we have  a production unit, an editorial unit that processes the information on a daily basis  constantly and they had been familiar working with XML editors working in the XML and their  role has changed and they're looking at the content itself and making sure that the author's  information is being preserved properly and what it will come down to is that particular  documentation and what's more important to me from our standpoint or anybody's standpoint  is that you need to make sure you annotate it with your usage and all that included because  just because you have the JAPS documentation saying A, B and C, well how are you interpreting  A, B and C in your particular environment and making sure that they are aware of that  and one of the things that we would be doing to help enhance that is when you were writing  the Schematron, commenting out why we are doing this, it really, if you pull those comments  out it becomes that external extra piece of documentation that helps people in production  or why are we doing this, why is this happening, what business rule is trying to be met here  in this particular case and we can break it down and translate it into a jargon that is  more familiar with them and co-op wheels that they can use.  And one thing I'd like to add, when it comes to XSLT, if you could say it in a pattern,  if you could just say it, it could be written in the XSLT and that's basically the philosophy  that we went with, that if you could find the pattern then just, it's really pretty  simple to write so that's how we think.  Evan.  I'll add a little more context.  Just so the audience understands, AIP no longer copy edits in house or typesets so the authors,  the manuscripts all go to offshore vendors and come back to us right now in AIP XML.  The documentation that was produced as part of this project will of course be the basis  for them returning JATs to us but they can't do that until we switch our platform because  we can't currently host JATs online until we launch our new platform.  So it's never easy, changing all the parts all at the same time.  But in the end, documentation is absolutely essential and the Schematron enforces that  as well.  Hi, Jeff Beck, National Library of Medicine.  I want to thank you for this paper.  I've already shared it in the preliminary proceedings with some organizations who are  thinking about their data as an example of, hey look, here are some people that did it  the right way.  So I want to thank you for that.  And then I wanted to kind of go on the back of Wendell's question and that is, when you  were writing your transformation specification using XPath, did you realize how close you  were to actually writing your own XSLT and were you excited about that?  Yes, and you know what, Jennifer and I have now, we write small XSLTs for the company,  writing the whole big one, you know, that's still yet to come.  But whenever an XSLT needs to be written in the company, we are now the official XSLT  writers and that was something that we gained from XPath.  It's just, you know, learning that.  I mean, that was really great.  So I think, yeah, it was one of those things where, like I said, I didn't know XPath.  We had a similar kind of format that we would communicate needs in.  It wasn't strict XPath.  And then of course we started writing our spec in kind of a plain English.  And then XPath came in, so yeah, you know, by the time, by the end of it, you look at  it and you go, hey, wait a second.  You know, I had had this, but you know, like I said, yeah, we do write XSLTs.  There's no way some of the things that were done for this, I would have been crying.  So we really needed a lot of information.  But we enjoy it very much, yes.  Yeah, that's what I have.  We're having fun, yes.  That's what I have Laura for.  The things that make me cry.  But I mean, the key thing for an organization is these used to be done, these transformations  in Lex or Pearl or something like that and that depended on when you had a technical  resource, when they were available, when they could fit it in.  Now it's more self-contained.  Can I have one more question?  Hi, Jenny Sherman, Nature Publishing Group.  I'm just wondering how many people within your company are involved in this project  and how long it took end to end?  Well, primarily it was the three of us and we had one dedicated resource to handle the  main XSLT that was really monstrous.  And there were assorted other developers, maybe two or three, over a piece of their time where  it brought in to run the list, do large amounts of data processing because we work on a UNIX  platform so we needed their help to run the files and do all that.  So I mean, it really boiled down to about four individuals spending most of their time  doing it, even though we all had other responsibilities at the same time because we were responsible  for sustaining the whole publishing operation with their questions and support simultaneously.  And we started probably August, September, 2011 is when we had started to write the initial  specs and all that.  And it really, because of other responsibilities and resources, it was really about January  of this particular year when we started to get full fledged into it and we spent most  of the first and second quarter finishing up and running the tests on the files.  So overall, about a nine to 10 month span.  Another piece I'd like to add to that.  At the same time, this team was converting the XML.  We were also restructuring all the content, assets, the graphics, the packaging of the  content as we moved from our old repository to our new repository and that has to tie in  with the XML correctly, of course.  So there was another set of projects going on as well.  Thank you.  Thank you.  Okay.  Thank you.  Thank you.  Thank you.  Thank you.
How_Well_Do_You_Know_Your_Data_Converting_an_Archive_of_Proprietary_Markup_Schemes_0_167.png How_Well_Do_You_Know_Your_Data_Converting_an_Archive_of_Proprietary_Markup_Schemes_168_371.png How_Well_Do_You_Know_Your_Data_Converting_an_Archive_of_Proprietary_Markup_Schemes_372_1007.png How_Well_Do_You_Know_Your_Data_Converting_an_Archive_of_Proprietary_Markup_Schemes_1008_3227.png How_Well_Do_You_Know_Your_Data_Converting_an_Archive_of_Proprietary_Markup_Schemes_3228_3491.png How_Well_Do_You_Know_Your_Data_Converting_an_Archive_of_Proprietary_Markup_Schemes_3492_5279.png How_Well_Do_You_Know_Your_Data_Converting_an_Archive_of_Proprietary_Markup_Schemes_5280_7247.png How_Well_Do_You_Know_Your_Data_Converting_an_Archive_of_Proprietary_Markup_Schemes_7248_7379.png How_Well_Do_You_Know_Your_Data_Converting_an_Archive_of_Proprietary_Markup_Schemes_7380_8555.png How_Well_Do_You_Know_Your_Data_Converting_an_Archive_of_Proprietary_Markup_Schemes_8556_13655.png How_Well_Do_You_Know_Your_Data_Converting_an_Archive_of_Proprietary_Markup_Schemes_13656_14591.png How_Well_Do_You_Know_Your_Data_Converting_an_Archive_of_Proprietary_Markup_Schemes_14592_17867.png How_Well_Do_You_Know_Your_Data_Converting_an_Archive_of_Proprietary_Markup_Schemes_17868_18107.png How_Well_Do_You_Know_Your_Data_Converting_an_Archive_of_Proprietary_Markup_Schemes_18108_18563.png How_Well_Do_You_Know_Your_Data_Converting_an_Archive_of_Proprietary_Markup_Schemes_18564_18719.png How_Well_Do_You_Know_Your_Data_Converting_an_Archive_of_Proprietary_Markup_Schemes_18720_18803.png How_Well_Do_You_Know_Your_Data_Converting_an_Archive_of_Proprietary_Markup_Schemes_18804_18947.png How_Well_Do_You_Know_Your_Data_Converting_an_Archive_of_Proprietary_Markup_Schemes_18948_22547.png How_Well_Do_You_Know_Your_Data_Converting_an_Archive_of_Proprietary_Markup_Schemes_22548_23207.png How_Well_Do_You_Know_Your_Data_Converting_an_Archive_of_Proprietary_Markup_Schemes_23208_23423.png How_Well_Do_You_Know_Your_Data_Converting_an_Archive_of_Proprietary_Markup_Schemes_23424_23507.png How_Well_Do_You_Know_Your_Data_Converting_an_Archive_of_Proprietary_Markup_Schemes_23508_25859.png How_Well_Do_You_Know_Your_Data_Converting_an_Archive_of_Proprietary_Markup_Schemes_25860_27131.png How_Well_Do_You_Know_Your_Data_Converting_an_Archive_of_Proprietary_Markup_Schemes_27132_29687.png How_Well_Do_You_Know_Your_Data_Converting_an_Archive_of_Proprietary_Markup_Schemes_29688_31607.png How_Well_Do_You_Know_Your_Data_Converting_an_Archive_of_Proprietary_Markup_Schemes_31608_32411.png How_Well_Do_You_Know_Your_Data_Converting_an_Archive_of_Proprietary_Markup_Schemes_32412_33407.png How_Well_Do_You_Know_Your_Data_Converting_an_Archive_of_Proprietary_Markup_Schemes_33408_35723.png How_Well_Do_You_Know_Your_Data_Converting_an_Archive_of_Proprietary_Markup_Schemes_35724_36683.png How_Well_Do_You_Know_Your_Data_Converting_an_Archive_of_Proprietary_Markup_Schemes_36684_37583.png How_Well_Do_You_Know_Your_Data_Converting_an_Archive_of_Proprietary_Markup_Schemes_37584_41123.png How_Well_Do_You_Know_Your_Data_Converting_an_Archive_of_Proprietary_Markup_Schemes_41124_41651.png How_Well_Do_You_Know_Your_Data_Converting_an_Archive_of_Proprietary_Markup_Schemes_41652_43259.png How_Well_Do_You_Know_Your_Data_Converting_an_Archive_of_Proprietary_Markup_Schemes_43260_45551.png How_Well_Do_You_Know_Your_Data_Converting_an_Archive_of_Proprietary_Markup_Schemes_45552_45647.png How_Well_Do_You_Know_Your_Data_Converting_an_Archive_of_Proprietary_Markup_Schemes_45648_45839.png How_Well_Do_You_Know_Your_Data_Converting_an_Archive_of_Proprietary_Markup_Schemes_45840_45959.png How_Well_Do_You_Know_Your_Data_Converting_an_Archive_of_Proprietary_Markup_Schemes_45960_46271.png How_Well_Do_You_Know_Your_Data_Converting_an_Archive_of_Proprietary_Markup_Schemes_46272_46463.png How_Well_Do_You_Know_Your_Data_Converting_an_Archive_of_Proprietary_Markup_Schemes_46464_46727.png How_Well_Do_You_Know_Your_Data_Converting_an_Archive_of_Proprietary_Markup_Schemes_46728_46943.png How_Well_Do_You_Know_Your_Data_Converting_an_Archive_of_Proprietary_Markup_Schemes_46944_52163.png How_Well_Do_You_Know_Your_Data_Converting_an_Archive_of_Proprietary_Markup_Schemes_52164_56855.png How_Well_Do_You_Know_Your_Data_Converting_an_Archive_of_Proprietary_Markup_Schemes_56856_58355.png How_Well_Do_You_Know_Your_Data_Converting_an_Archive_of_Proprietary_Markup_Schemes_58356_58511.png How_Well_Do_You_Know_Your_Data_Converting_an_Archive_of_Proprietary_Markup_Schemes_58512_58991.png How_Well_Do_You_Know_Your_Data_Converting_an_Archive_of_Proprietary_Markup_Schemes_58992_59819.png How_Well_Do_You_Know_Your_Data_Converting_an_Archive_of_Proprietary_Markup_Schemes_59820_60359.png How_Well_Do_You_Know_Your_Data_Converting_an_Archive_of_Proprietary_Markup_Schemes_60360_61127.png How_Well_Do_You_Know_Your_Data_Converting_an_Archive_of_Proprietary_Markup_Schemes_61128_63647.png How_Well_Do_You_Know_Your_Data_Converting_an_Archive_of_Proprietary_Markup_Schemes_63648_77723.png How_Well_Do_You_Know_Your_Data_Converting_an_Archive_of_Proprietary_Markup_Schemes_77724_78071.png How_Well_Do_You_Know_Your_Data_Converting_an_Archive_of_Proprietary_Markup_Schemes_78072_78395.png How_Well_Do_You_Know_Your_Data_Converting_an_Archive_of_Proprietary_Markup_Schemes_78396_78671.png How_Well_Do_You_Know_Your_Data_Converting_an_Archive_of_Proprietary_Markup_Schemes_78672_78743.png How_Well_Do_You_Know_Your_Data_Converting_an_Archive_of_Proprietary_Markup_Schemes_78744_80195.png How_Well_Do_You_Know_Your_Data_Converting_an_Archive_of_Proprietary_Markup_Schemes_80196_80243.png How_Well_Do_You_Know_Your_Data_Converting_an_Archive_of_Proprietary_Markup_Schemes_80244_80303.png How_Well_Do_You_Know_Your_Data_Converting_an_Archive_of_Proprietary_Markup_Schemes_80304_80471.png How_Well_Do_You_Know_Your_Data_Converting_an_Archive_of_Proprietary_Markup_Schemes_80472_80555.png How_Well_Do_You_Know_Your_Data_Converting_an_Archive_of_Proprietary_Markup_Schemes_80556_80603.png How_Well_Do_You_Know_Your_Data_Converting_an_Archive_of_Proprietary_Markup_Schemes_80604_80975.png How_Well_Do_You_Know_Your_Data_Converting_an_Archive_of_Proprietary_Markup_Schemes_80976_87227.png How_Well_Do_You_Know_Your_Data_Converting_an_Archive_of_Proprietary_Markup_Schemes_87228_89279.png How_Well_Do_You_Know_Your_Data_Converting_an_Archive_of_Proprietary_Markup_Schemes_89280_89357.png