Traveling through time and place with Plone
CC Attribution 3.0 Germany:
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.
Elliott, Tom
Mitchell, Alec
Pleiades is a community-built gazetteer and graph of ancient places, built using the Plone content management system. It publishes authoritative information about ancient places and spaces, providing services for finding, displaying, and reusing that information under open license. Pleiades development started in 2006 and went to production status in 2010. The site continues to serve scholars, students, and enthusiasts around the world today. This case study will present the history and major milestones the project has seen. We will emphasize unique features like customizations for geospatial content, maps, and data serialization; modeling of uncertainty and unknown geometries; and bibliographic data management. Co-presented by Tom Elliott (New York University), the long-time project director, and Alec Mitchell (Jazkarta, Inc.), a long-time lead developer on the project, this talk will also address the reasons for choosing and sticking with Plone, as well as expectations for future work.
 I'll start right in. Pleiades is a community-built gazetteer and graph of ancient places. It was built using the Plone Content Management System, which is why we're here. It publishes authoritative information about ancient places and spaces, providing services for finding, displaying, and reusing that information under open license. And we publish not just for individual human users, but also for search engines and for the widening array of computational research and visualization tools that support humanities teaching and research. Pleiades was incubated during the early years of this century in reaction to two related developments. First, the year 2000 saw the completion of a 12-year, multi-million dollar project to compile and publish a comprehensive atlas of the Greek and Roman world. This thing right here. It's from that classical atlas project that Pleiades takes its name. In Greek mythology, the Pleiades are the daughters of the Titan Atlas. It's hard to believe, but this project, which was chartered by the North American Society for Classical Studies and funded through a combination of private and public funds, was the first project to successfully bring such an atlas to print since 1874. That time lag provides a critical insight into why academic classicists took on such a challenge. They not only had a century of literary and historical research gone by, but the entire modern discipline of archaeology had been born, had matured, and had brought massive change, both factual and theoretical. And this insight dovetails with the second reason we dreamed of Pleiades. The period of the atlas's creation coincided with, to a significant degree, with the maturation of desktop geographic information systems and the dawn of the geographic web. The project was really hybrid because it started before using full up digital tools was really in prospect. But as we went along the professional cartographic shop that supported the atlas project brought more and more GIS into the production project, but it was still in the end a cartographic art project that produced a print item. Bringing Pleiades to life so the next generation took a bit longer. We wanted to bring all the data that had been assembled for the atlas into the modern world, if you will. And our first attempt to obtain funds was not successful. We were calling the thing in Internet Archive for ancient geography. The major complaint we ran into with one of the proposal reviewers was that we had not pre selected whatever combination of workflow engine content management system, wiki system web framework or databases that we were going to use to build the prototype. Keep in mind this was 2004. So Wikipedia is a relatively recent development. I think Google Earth was about to hit but had not actually sprung on the scene yet. And that was kind of the lay of the land. We had been hoping to use grant funds to hire a developer to work with the project team and making our, you know, technical stack selection. But in light of getting shot down in the review process we decided to work in our spare time to do some initial evaluation before submitting a revised proposal in 2005. So it's then that we chose Zopinplone. Why you ask. I confess that one key reason was one zip file to download one click installs, you know one click install story, we were up and running with a toy environment in mere minutes. We didn't have to prove our Java wizard hood. We didn't have to present any credentials we're not in any kind of dependency management purgatory at least we weren't aware that we were. We didn't have you know operating system incompatibilities. Plone just worked. The agency had three unboxing boxes to in particular customizable workflow rules, customizable content items, a template framework with skin abstraction layers for the UI, all that's sort of stuff. I'd be remiss if I didn't mention here that we had some helpful advice string this period by a guy named Chris Cowley, who I think is attending a conference this year so shout out to him. we were launched. Our first grant provided by the US National Endowment for the Humanities allowed us to hire Sean Gillis as full-time project developer. Sean was to stay with Pleiades in the capacity of Chief Engineer until 2013, helping us with a series of project milestones, including two subsequent NEH grants, the transfer of Pleiades headquarters to New York University in 2008. It had been at the University of North Carolina at Chapel Hill before that. And crucially, our transition to full production status in 2010. So we're not only grateful to Sean for his role in these core project achievements, but we're proud that NEH and I saw funds were able to support his early work on the Python shapely package for manipulation and analysis of geometric objects in the Cartesian plane and on the GeoJSON format specification, which has subsequently matured into an internet RFC. In the seven years since Sean left NYU to work for Mapbox.com, we've come to rely on a development team of Jazz Carta, Incorporated for Plone Maintenance, Upgrade Customization, and cleaning up the messes that I make when I fiddle with code. Our most recent NEH grant, which began in 2016 and ended a little over a year ago, allowed us to address a number of growing pains that had built up over time and turned into major impediments. The biggest change came early in that process, early in 2016, when Jazz Carta helped us upgrade from Plone 3 to Plone 4 3 and to re-host to a more capable server managed by our longtime hosting provider, tummy.com. Jazz Carta took this opportunity to systematize our deployments using Ansible and to install New Relic Monitoring to identify and address performance bottlenecks. All this was a non-trivial exercise. I think Alec may be forced by my having mentioned it to explain that in a few minutes. And one of the main reasons I think he'll touch on is that we had such a large amount of customizations we're carrying in our software stack. That whole process was worth it, though, because we very quickly saw year-over-year improvement in average page load times of nearly 75%, which was down from a painfully long average of 12 seconds to about three seconds. Now, standard deviation on both of those is pretty wide, given our global user base and some of our folks being in places where they have metered connections and slow connect times, but still really big improvement, and most of our users see very fast performance. Subsequent work has improved things even further, such that we don't have, I don't think we've had a user complaint about performance in nearly three years, even though we've had some big increases in content complexity and so on. So what I'd like to do at this point is switch over and do a demo. So we're going to grab the browser. Whoops. So this is the Pleiades homepage. What's in Pleiades? Let's get some orientation here. Since we call ourselves a digital gazetteer of ancient places, I think the easiest thing to do is to pick a well-known place and start there. How about the city of Rome? Looks like Pleiades knows about four places that begin with that string R-O-M-E, and the first one is the one we're looking for. So here we're looking at the Pleiades entry for the ancient settlement of Rome. I'll scroll down so you can see the map and confirm that it's where it's supposed to be. This is an HTML view of an instance of a custom-plone content type that we call a place resource. Our content types are presently still built on archetypes, and you'll recognize at the top of this view some of the standard Dublin core fields like title, creators, contributors, a right statement, last modified date and summary. I'm going to blow this up just a little bit for folks with small devices. In Pleiades, our place resources are the primary organizational construct of the whole digital gazetteer. They're conceptual entities, so we apply the term place to any locus of human attention, material or intellectual, in a real-world geographic context. So a settlement that's mentioned in an ancient text is a place, whether or not it can be located now. An archaeological site is a place. A modern city located at top of an ancient settlement is a place. If you and I both had access to time machines and we could find a way to agree on somewhere to meet for lunch in antiquity, that would be a place for Pleiades purposes. So basically any spatial feature that's connected to the pre-modern past and that a human being has noticed and discussed as such, sometime between the past and the present, that's a place. If we look at what's here on our view, this canonical URI business, this simply repeats the stable uniform resource identifier that Pleiades automatically assigned when the content item is created. That's there in your browser location bar. We repeat it in the view and provide a handy JavaScript copy-to-clipboard affordance in the UI because the assignment, stability and reuse of these URIs constitute one of the most important functions of the gazetteer. Especially in the early days of the project, most humanity scholars were unaware of and suspicious of the web's long-term reliability for scholarly publication purposes. BITROT was, or, you know, LINCROT was a huge problem from an academic perspective because we want to cite everything. We want to be able to find out where assertions about the things we study came from. So we provide a unique stable identifier for places in the ancient world that other scholars and students want to discuss or reference in their own publications and datasets. And as a result, over the last 10 years, these URIs have come to be used in a variety of other web applications and research datasets. So that makes it easier for scholars and students to combine multiple datasets that they gather from different places, different repositories, and use them for research tasks without having to clean or align all the geography by hand. So that's one of the important things we do. This representative point here, this latitude-longitude value, is calculated automatically. It's usually a centroid of whatever spatial geometries are associated with the place. We'll talk about more of that in a minute. First, I want to look at a slide and talk a little more about our custom content. Not Sean and Scotty, but custom content types, in Pleiades. So the place resources, like the Rome entry we've been looking at, are our folder-ish, as the Plone folks say. That means they can contain other content. In Pleiades, we allow only three other custom content types inside places. We call these locations, names, and connections. There you get recent counts of each. I think if we move to another famous ancient city, we can have a good look at those. So let's go here. So welcome to the ancient city of Nineveh. I'll let you watch the map. It's located near the modern city of Mosul in Iraq. In this place resource, you'll see we've defined two location resources right here. We use locations to store the geospatial information about where an ancient place may have been located on the Earth's surface. Both of these are depicted on the map using the color blue. One of these is a simple point geometry imported from another database or data set called DAH-R-E, which stands for the Digital Atlas of the Roman Empire. It's the work of Johann Eiffelts at the University of Gutenberg in Sweden. The second location is a polygon. It's derived from an open street map from a way or a relation in open street map. It corresponds in this case to the boundaries of the modern archaeological site. So let's look at our location here. If you take a peek at it, you can see we store more than just the spatial geometry, although that's really obvious in the case of a polygon. We can subtype our locations. Here we call it a settlement because that's what we're outlining. We might have called this an archaeological site instead, but in any case, that's the current state of the data. We can indicate the nature and extent of archaeological remains associated with the location. This is a value to cultural heritage organizations and geos that respond to disasters, organizations that are engaged in the protection of cultural property during conflict, that sort of thing, knowing whether the thing is visible or not, and if there's something substantive on the surface is very important. We can also signal our confidence in associating this particular location with the place and any of the other information, like names and connections, that the place contains. Another crucial bit of information that we store is a citation. In this case, it's an annotated link to the OpenStreetMap way in question, the one that we imported to create this location. Keeping this information does two things for us. Firstly, it allows us to credit OpenStreetMap in compliance with their data license, and it also makes it possible for users to inspect the original data source in order to evaluate for themselves its quality and relevance. So the place resource for NINIVA also contains a number of name resources. In Pleiades name resources store information about toponyms, both ancient and modern, as they're associated with a given place. Pleiades names are more than labels, and therefore they are a more complex content type than a simple string or a series of language encoded strings. So if we look, for example, at the Pleiades resource for the ancient Greek name of NINIVA, Ninos, you can see that we record one or more romanization forms. Romanization forms are transcriptions in Roman characters of the ancient name. For some languages and writing systems like polytonic ancient Greek, which is what we have here, and modern or historical Arabic, multiple romanization forms can and probably should be used for the same original name. We want them to be used because we want our name-based search to be as easy and effective as possible, regardless of where you're coming from with a particular variant on a name, we want you to be able to find it. So we're encouraging our content contributors to provide as many romanization forms as are commonly in use or that one finds in earlier scholarly literature. When the original writing system is fully and accurately represented in Unicode, we fill out this attested name field, and then additional attributes are available to indicate the language and writing system of the original, to indicate the function of the name in the original context, and to characterize the accuracy and completeness of the text or texts that have communicated it to us. The next thing we encounter in the HTML Place view are two clickable lists of what we call connections. We use connection resources to express direct place-to-place relationships. They enable us to document geographic, political, and analytic hierarchies, networks, and linkages. Although the basic functionality for connections was introduced into Pleiades years ago by Sean Gillis, connections in their full current form are relatively recent implementations. So Alec Mitchell and his colleagues at Jaskarta bear the scars of turning these into full-fledged, awesome things that we have today. So connections as we have them now turn Pleiades into a directed graph. Our place resources are nodes in the graph, and the connections are the edges. Consequently, any place can participate in an ordered pair as either the origin, or you can call it the subject if you like RDF parlance. So it's either the origin or subject, or it's the target or predicate. And that's why you see two lists of connections in the Place view. Makes connections with list connections for which Nineveh is the origin. So Nineveh is a part of whatever. The receives connections from list shows connections in which Nineveh is the target or the predicate. So the Honduru gate is part of the topographic area of Nineveh. Let's look at one of these. When you examine a connection resource in Pleiades, like this one for the administrative relationship between Nineveh and the ancient kingdom of Assyria, it becomes immediately apparent that our graphs edges are not simple. They're attributed just like the nodes are, the places. Apart from the connection type, our contributors can also indicate scholarly confidence in making the connection, the time periods during which the connection is thought to have been active or functional, and any references to scholarly literature, databases, or websites that provide evidence of it or information about that connection. These three attributes, association, certainty, temporal attestation, and the references down here, their provision to not just for connections, but also for our names and locations. So you may have noticed them in the HTML views we looked at earlier, even though I didn't mention them. These two temporal constrained attributes, not before and not after, are a recent addition to the data model, and they apply to connections only. They were requested repeatedly and loudly by our users so that events and durations, and there's good historical data for them, can be more precisely delineated. So although these attributes are not extensively used on this particular connection, you can see them hard at work elsewhere in our data set. References are not limited to locations, names, and connections. We use them extensively at the place level as well. Nineveh boasts a substantial number of them, more than average in the data set. Our goal with references is to connect users as quickly as possible with additional information about the resource and question, you know, whether that is because the item was used in developing what we're showing you in the place resource, or if it provides additional information that might be useful to you or more data of some kind. So we link to things like photograph collections and museum sites and that sort of thing. We focus on getting users to the resource and question as fast as possible. So if the thing is available online, we're going to link right to it, in this case to a site called Topos Text that was created by a guy named Brady Kisling. It has cool stuff like lots of ancient source citations in which a particular place is mentioned. But if the item is not online, but it can be found separately cataloged in libraries, we link to the corresponding entry in something called WorldCat, which is an online union catalog of academic libraries around the world. It's maintained by the nonprofit online computer library center or OCLC for short. And by linking to WorldCat, we make it easier for users to identify the nearest library that holds a copy of the work that they're looking for that apparently is not a valid zip code in the US, but never mind. For journal articles and other works that are not cataloged by third parties, we're going to link to our own geographic database. We use the open source Citero citation management system for creating and managing all of the bibliographic data that we use in our references. But we only link directly to the Citero record when we've really got no place better to send people. Citero is run by the nonprofit corporation for digital scholarship that has a robust and reliable API that we use at author time. And we use it to relieve our contributors from tedious 20th century style bibliographic formatting tasks. And if I don't run out of time, I think I'm doing okay. We'll see it in action in a minute. You'll notice above the reference listing that we have a place type attribute. We've been looking at settlements so far, but Pleiades gives us the ability to describe many more types of ancient places and spaces. So let's see that in action real quick. All of the place types in our controlled vocabulary are listed in our advanced search on the categories tab. You can see we've got a bunch of them. Let's look at lighthouses. We can use that to quickly find things. And I want to limit our results to places. I don't think I'm logged in. We'll only get published items regardless of what we ask for. So here's eight lighthouses that are indicated as such. This one is the famous lighthouse of ancient Alexandria on the Egyptian coast. It's one of the original Seven Wonders of the ancient world. So this lighthouse was super famous in antiquity. In fact, it was simply known as the lighthouse, pharaohs in ancient Greek. So it's a return to the advanced search. I could demonstrate another key aspect of the data contained in Pleiades. Go back to the categorization tab. There's a lot of places in the ancient world that are mentioned in historical texts that we can't locate today with any kind of precision. Pleiades records these as well. And we normally add a place type value of unlocated to the corresponding resources. And that lets us hunt for them in the advanced search. You'll see we have just a few unlocated places. Let's narrow it down to unlocated places that have been added recently. Here's a few. The funerary grove of epicrates sounds interesting. Right. So typical of unlocated places in Pleiades, you'll see that no locations have been recorded. We do, however, have some connections that are used to provide associations with other geographic features known to be associated with this one on the basis of ancient sources. Nacroson is interesting because it's not precisely located either. But scholars have theories about where it was. In fact, you can find three competing identifications in the scholarly literature. So these are archaeological sites that are in the right general area. But there's no definitive evidence to say which one was this one named Nacroson that shows up in some ancient texts. So you'll see that we have three discrete locations associated with this place resource. And each of them makes use of the association, certainly the attribute to indicate the tentative nature of the association. And if you look at the map, you'll see each one of these is represented with one of our blue crosshair icons, which is the point location. So now I'm going to talk briefly about this representative point in more detail. It's indicated on the map with an orange circle icon. We've already noted its presence in the textual form and the attributes listing. In Pleiades, representative points are calculated as an approximate centroid of the locations associated with the place resource in question. Those of you who are familiar with Python Shapely library will recognize the terminology representative point. It's not always a centroid, but it often is. So in cases like this, the representative point will fall somewhere between the various location geometries. In similar cases like Rome, Nenove, and the forest, they'll fall near the center of the locations. We've also discovered that there are times when we know where a feature is, but we don't want to use a location for it. What do we do about the representative point then? And why would we want to leave locations out in the first place? Well, big, complex broad features are a good case. Study. Let's consider Hadrian's wall. There it is. So what's going on in the map here? We're visualizing two things for this huge complex fortification system. The spatial coordinates of each of the connected places that together constitute the fortification system. So these are the green bow tie icons that are all stuffed in here. And this time, the orange circle denoting the wall's representative point is calculated on the basis of those geometries, since we don't have any location objects defined on the wall place resource itself. We're starting to use this technique with kingdoms, provinces, and other administrative and regional divisions as well. So here, for example, is the island of Sicily. All right. It was also a Roman province. And it's here that the GIS folks are usually going to say, hey, why don't you just do a spatial containment or an intersection query instead of messing around with all these connections? It seems like a ridiculous amount of work. And I'll give you two interrelated reasons. We're not just making a map or constructing a geospatial data set for spatial analysis and graphic visualization. We're creating a data set that could be used for lots of tasks in addition to those. We want a data model in which every place known to be in a province, let's say, is properly associated with that province. A pure spatial query isn't going to find the unlocated places. Moreover, ancient regions and administrative divisions are and were sparse in spatial terms. We may know lots of settlements on a particular area of the Earth's surface, but we may only know about the belongingness of some of them to a particular historical region or administrative division. And moreover, we'd be making a huge error by assuming that ancient administrative regions were solid polygons in the first place. Borders could be fluid or ill-defined in real fact. And the internals could look like Swiss cheese if all the borders were, even if the borders were precisely defined and you could map them accurately, which we usually can't. Let's consider, for example, Delphi. This is a famous ancient sanctuary of Apollo in Greece. Delphi wasn't just a bunch of temples. It controlled a significant land area and therefore had an important economic role in the region above and beyond its religious and diplomatic functions. A naive observer would assume that during the Roman imperial period, this site would have fallen within the Roman province of Achaea. But legal documents demonstrate that Delphi, in fact, had a direct bilateral relationship with the emperors and it so bypassed the provincial administration completely. The Roman governor of Achaea could say nothing legal about what went on in Delphi or involving Delphi's neighbors, even though he had authority over the neighboring communities. Delphi gives us a chance to talk briefly about another important aspect of Pleiades' places. We call them alternate serializations or alternate representations. So far, I've been showing you the HTML versions of the content in the Pleiades' Zope database. Those of you familiar with how Plone 3 and Plone 4 work will recognize the term base view. When you look at Pleiades' places, names, locations, and connections in a web browser, you're looking at rendered versions of a customized Plone HTML base view template. Those of you who program Plone will know that it's possible to create alternative views for content items and that's what we've done. You'll see the links on every place page under the heading, alternate representations. Clicking on any of these links, I'm going to click on JSON, will get you the corresponding format. Complete with the appropriate MIME type and the response header so that your browser can try to figure out what to do with it. Here, for example, is the JavaScript object notation serialization of the Pleiades' place resource for Delphi. I'm not going to click on it now for time reasons, but you can click on the KML link to get a keyhole markup language serialization. And if you've got Google Earth installed and if your browser knows about it and if you don't have an old version of Adobe Photoshop that hijacks that particular MIME type, you can view your location data over Google Earth's spatial geometry. We've exposed these alternate representations in such a way that they constitute a read-only, open application programming interface that conforms to the web architectural style known as REST. That is, representational state transfer. We use a uniform method of constructing the corresponding URIs across the whole site and you see that summarized here. You can discover all of these resources. I mean Chrome, aren't I? Different set of keystrokes. So you can discover these things, whoops, in, in, on the web by parsing the link elements that have the alternate value in the rel attribute out of the HTML. You can also use HTTP content negotiation to get at them in Pleiades. And the whole idea here is to make Pleiades an easy resource to reuse from other web applications. We also publish RDF versions of the content and that makes Pleiades a linked open data application. We're proud of the fact that Pleiades was the first ancient history website or web application to meet the criteria for addition to the linked open data cloud diagram where you'll still find it today. But if you don't want to script a web app against Pleiades or, you know, set up a triple server and do all that sort of stuff, instead you'd like to download all our data to do things with on your own in your own applications or tools. We try to make that easy too. So we have a downloads page that you can get to and there we provide access to regularly refreshed bulk exports of the published data in several formats. Our JSON exports are the comprehensive ones. So they provide every attribute of every published place, name, location and connection. The other formats are bridged. So the comma separated values KML and so on. Every published object is represented. But only some of the commonly used attributes are provided in each. You can also get packaged copies of our data from various third party repositories. I've listed some of that here. And there are also a couple of really cool derivative data sets that are built and maintained by our partners. So how does all this information get created and updated? Well, we have a clone workflow for that. And I'm going to show you that very briefly. It looks like I've taken a little more time than expected and Alec is probably getting itchy to do some talking here. So let me just do a real quick demo. I'm not quite sure how the time got away from me. Oh, I see what's happening. It has to do. I actually got good time. I was looking at the zoom time instead of the clock time. I apologize for all the noise. All right. So authenticated users can add content. And we do that in a clone like way. I'm going to use a username that I have assigned that doesn't have any special privileges. And I can navigate to the places top folder. And I can add a new place in the way you'd expect to in clone four. And you get a form that lets you add stuff in. So let's say we were going to add Atlantis. Then you fill out the form. It's unlocated. We can have multiple types. So I can call it an island. A settlement. So on and so forth. I won't fill it all out. References. I'll show you how that works in a minute. We can add tags. I could credit or blame other people. And I even have a details and field rich text field in which I can write a long essay about how awesome Atlantis was. Once I save that, we're going to start in our default workflow state. And that's drafting. So it is visible only to me and to super users. And I can continue to edit this. In particular, I can add locations. We have a form that lets you put in an open street map ID and import the geometry from there, which is very handy for features that are extant and visible in the world today. We can also add names using the typical clone manner by entering stuff and using combo boxes for our various vocabularies as we encounter them. So for example, we're not going to let people randomly enter and type the name of the language. We're going to control that so that we don't get typos and that sort of stuff. So that's the basic process for adding something. Once you are ready to have it reviewed by our editorial college, you submit it for review using the typical clone workflow transition thing. We encourage people to write useful comments beyond initial revision. Although in this case, I think I'm not going to bother. I submit it for review. Once I've done that, if I'm a regular user, you'll notice the as I am logged in now, you'll notice that the edit option on this thing is gone. So we on moving depending, we lock the content item for additional changes by the user who submitted it. That keeps us from multiple edits involving the editors and the user at the same time. If I were to log in as an editor, I could look at this and revise it and in this particular case send it back to myself as deficient in terms of its content. But that's the basic way we work with new items. And so we allow people to come along and add whole new places for consideration or they can visit an existing place and add a name or a location using the same or connection adding the same kind of button affordances and then those get managed through the workflow process separately. Now modifications to existing resources are different animal. We make heavy use of clone iterate and I'm going to find a particular example and I'm going to go to another browser and log in as an editor. I was already logged in but I've logged out nifty me. Okay. So I scouted out this particular place in advance. This is a place called a gigli located on the North African coast. You'll see here under the names listing, we blow that up for small devices. We have a Latin form of the name and then picked out in orange here we have a Greek form of the name. That means this has been added. I'm showing you now the editor's experience of these that have just been added and I can go through this and approve it for publication. I promised you clone app iterate but in fact I got lost in my notes. Here's clone app iterate at work in Pleiades. At Asina is an entry in clone in Pleiades that I'm going to go back to my other user because I don't want you to be forced to see the editorial view of all this. It's still got some raw data in it from when it was imported from the original Barrington Atlas data. It's had some modifications made since then but we'd like to improve it. The way I do this as a user, I don't get to edit it live. This thing is locked for regular users to use. What I have to do is I have to use iterate to check out a working copy. I've checked out a working copy of the place. You'll notice it's copy of in the URL stub. Then I can edit this in draft to make the changes I want. I can modify any component of the presentation. I can iterate on that and then save it in my draft working copy. Once I've got that the way I want it, I can submit it for review just the way I would something entirely new. Back in the editor's view, suppose I'm doing my daily editing task and I want to see what's waiting. I hope this is not an embarrassingly large number of items. No, it's not. Here's that andesina entry that my alter ego submitted for review. I can look in the history to see what was said about it and then I can move it on through the workflow process. What I'd normally do if I think this is good to go is I would check it in. We bring forward the check-in message from whatever the workflow transition message was. Thanks to that editorial action, that summary is live in the database and it replaces the published version. The history will give you the ability to see back what was done previously to this particular entry all the way back to its original ingestion in the database in 2009. I think we are now at the point where I should turn things over to Alec and drive the slides for him and see how we go. I'm going to go really quickly here because we don't have a ton of time. Let's see if we can get the slides up again, Tom. I'm not seeing them. There we go. As you probably understand from Tom's demo, Pleiades is a pretty complex system. In fact, it comprises 25 custom Python packages. That complexity can make upgrades really tricky, especially for a development team that came in unfamiliar with the original code base. When we did the upgrade, we ran into various issues. We made some testing fixes, had to update a bunch of custom views and customizations of existing views, removed some dependencies on some old packages, removed various crufts from add-ons that had come and gone over time. Then we made a variety of performance improvements. If you saw Philip Bowers talk yesterday, you'll probably recognize a number of the sort of performance gotchas that we were dealing with, in particular things like lacking no-call statements on path expressions, which cause objects to be fully rendered while generating a template. There was a bunch of inline rendered JSON in head. Tom showed you those links to data in head, and a lot of those used to be full JSON. In some cases, it got very complex and was very hard to render. We moved that stuff to ASync, and that gave pretty large performance improvements. Then over time, we've also replaced AT Vocabular Manager with registry, Plenup Registry-based Vocabularies, which means fewer catalog queries, fewer object lookups, and some significant performance improvements. Then, as Tom mentioned, we implemented Ansible to ensure we had repeatable deployments and that the server wasn't a special snowflake, which is a term we might recognize from Calvin's AWS talk yesterday. Plone plays a big role in Pleiades, despite the fact that it's a very complex system that doesn't necessarily fit into traditional content management. You can see that it uses tons of features from Plone through Tom's demo. We've got content types with complex custom schemas, hierarchical content models, custom permissions and roles, custom workflows, and then a pretty heavy dependence on Plone app iterate for content staging. The fact that iterate is based on adapters makes it really easy to customize the data copying and merging logic, which Pleiades does extensively. Then on top of that, we use custom views for the various non-HTML representations for exports, and we depend on a variety of Python libraries for doing that, some of which, as Tom mentioned, came directly out of this project. In terms of recent work that Jazzgard has been doing on Pleiades, we've been preparing for a while for a Plone 5 upgrade. We've made improvements to the bulk import process. We've completely eliminated AT Vocabular Manager, improved the iterate customizations so that that checkout check-in process works pretty seamlessly. We've made completely comprehensive JSON representations, improved this concept of promoting locations to places, which is something that demo didn't quite get into, but it's another workflow-y action that allows you to actually convert subordinate content types into places. Then a bunch of other stuff, including better mapping systems and updated geographic information. Eventually we do plan to move to Plone 5.2 and Python 3, but the whole site's done in archetypes now, so we're going to have to move everything to dexterity, including all of the connections and relations, the various data. There's going to be a bunch of custom behaviors because there's a lot of shared functionality in terms of bibliographic references and things like that. All the custom views are going to need to be updated. Our plan is to basically do a new updated implementation of the site's dexterity, test everything out, leverage the fact that the site already has a comprehensive JSON export and a bulk import update feature to do the migration. For non-custom content, we would just use collective JSONify and transmodifier. I'm not sure that this site is a good fit for Volto at this point. As you saw from Tom's demo, it's really a data-driven research tool, so the need for customizable layouts and the other kind of nifty things you get with Volto is pretty minimal at this point, but who knows? That's the future. Anyway, that's it from me. Thank you, everybody, for coming to this talk, and thank you, Tom, for that wonderful demo. Yeah, thanks for me, too, to everybody and to you, too, Alex. Hey, great. Thanks, guys. That was fascinating. It's really cool to see how much work and all the cool stuff you can do with the Plone site and especially in the context of this. We have one slide-O question from Philip, and that's, what do you use to replace AT vocabulary manager as a collective taxonomy? No, it's essentially just a custom Plone app registry set of vocabulary, a couple of custom classes that pull vocabularies out. In the case of Pleiades, there's a view that makes those vocabularies appear as content-ish things to make it the same as ATVM. Yeah, it's custom code. There's an add-on. All of these add-ons are actually open source. I'm not sure how useful they are to anybody outside of Pleiades, but Pleiades' vocabulary add-on has all that code, and it used to all be ATVM in there. No, it's the new stuff.
 I'll start right in. Pleiades is a community-built gazetteer and graph of ancient places.  It was built using the Plone Content Management System, which is why we're here.  It publishes authoritative information about ancient places and spaces, providing services for finding, displaying, and reusing that information under open license.  And we publish not just for individual human users, but also for search engines and for the widening array of computational research and visualization tools that support humanities teaching and research.  Pleiades was incubated during the early years of this century in reaction to two related developments.  First, the year 2000 saw the completion of a 12-year, multi-million dollar project to compile and publish a comprehensive atlas of the Greek and Roman world.  This thing right here. It's from that classical atlas project that Pleiades takes its name.  In Greek mythology, the Pleiades are the daughters of the Titan Atlas.  It's hard to believe, but this project, which was chartered by the North American Society for Classical Studies and funded through a combination of private and public funds, was the first project to successfully bring such an atlas to print since 1874.  That time lag provides a critical insight into why academic classicists took on such a challenge.  They not only had a century of literary and historical research gone by, but the entire modern discipline of archaeology had been born, had matured, and had brought massive change, both factual and theoretical.  And this insight dovetails with the second reason we dreamed of Pleiades.  The period of the atlas's creation coincided with, to a significant degree, with the maturation of desktop geographic information systems and the dawn of the geographic web.  The project was really hybrid because it started before using full up digital tools was really in prospect.  But as we went along the professional cartographic shop that supported the atlas project brought more and more GIS into the production project, but it was still in the end a cartographic art project that produced a print item.  Bringing Pleiades to life so the next generation took a bit longer.  We wanted to bring all the data that had been assembled for the atlas into the modern world, if you will.  And our first attempt to obtain funds was not successful.  We were calling the thing in Internet Archive for ancient geography.  The major complaint we ran into with one of the proposal reviewers was that we had not pre selected whatever combination of workflow engine content management system, wiki system web framework or databases that we were going to use to build the prototype.  Keep in mind this was 2004. So Wikipedia is a relatively recent development.  I think Google Earth was about to hit but had not actually sprung on the scene yet.  And that was kind of the lay of the land.  We had been hoping to use grant funds to hire a developer to work with the project team and making our, you know, technical stack selection.  But in light of getting shot down in the review process we decided to work in our spare time to do some initial evaluation before submitting a revised proposal in 2005.  So it's then that we chose Zopinplone.  Why you ask.  I confess that one key reason was one zip file to download one click installs, you know one click install story, we were up and running with a toy environment in mere minutes.  We didn't have to prove our Java wizard hood. We didn't have to present any credentials we're not in any kind of dependency management purgatory at least we weren't aware that we were.  We didn't have you know operating system incompatibilities.  Plone just worked.  The agency had three unboxing boxes to in particular customizable workflow rules, customizable content items, a template framework with skin abstraction layers for the UI, all that's sort of stuff.  I'd be remiss if I didn't mention here that we had some helpful advice string this period by a guy named Chris Cowley, who I think is attending a conference this year so shout out to him.  we were launched. Our first grant provided by the US National Endowment for the Humanities  allowed us to hire Sean Gillis as full-time project developer. Sean was to stay with Pleiades  in the capacity of Chief Engineer until 2013, helping us with a series of project milestones,  including two subsequent NEH grants, the transfer of Pleiades headquarters to New York University  in 2008. It had been at the University of North Carolina at Chapel Hill before that.  And crucially, our transition to full production status in 2010. So we're not only grateful  to Sean for his role in these core project achievements, but we're proud that NEH and  I saw funds were able to support his early work on the Python shapely package for manipulation  and analysis of geometric objects in the Cartesian plane and on the GeoJSON format specification,  which has subsequently matured into an internet RFC. In the seven years since Sean left NYU  to work for Mapbox.com, we've come to rely on a development team of Jazz Carta, Incorporated  for Plone Maintenance, Upgrade Customization, and cleaning up the messes that I make when  I fiddle with code. Our most recent NEH grant, which began in 2016 and ended a little over  a year ago, allowed us to address a number of growing pains that had built up over time  and turned into major impediments. The biggest change came early in that process, early in  2016, when Jazz Carta helped us upgrade from Plone 3 to Plone 4 3 and to re-host to a more  capable server managed by our longtime hosting provider, tummy.com. Jazz Carta took this  opportunity to systematize our deployments using Ansible and to install New Relic Monitoring  to identify and address performance bottlenecks. All this was a non-trivial exercise. I think  Alec may be forced by my having mentioned it to explain that in a few minutes. And one  of the main reasons I think he'll touch on is that we had such a large amount of customizations  we're carrying in our software stack. That whole process was worth it, though, because  we very quickly saw year-over-year improvement in average page load times of nearly 75%,  which was down from a painfully long average of 12 seconds to about three seconds. Now,  standard deviation on both of those is pretty wide, given our global user base and some  of our folks being in places where they have metered connections and slow connect times,  but still really big improvement, and most of our users see very fast performance. Subsequent  work has improved things even further, such that we don't have, I don't think we've had  a user complaint about performance in nearly three years, even though we've had some big  increases in content complexity and so on. So what I'd like to do at this point is switch  over and do a demo. So we're going to grab the browser. Whoops. So this is the Pleiades  homepage. What's in Pleiades? Let's get some orientation here. Since we call ourselves a  digital gazetteer of ancient places, I think the easiest thing to do is to pick a well-known  place and start there. How about the city of Rome? Looks like Pleiades knows about four  places that begin with that string R-O-M-E, and the first one is the one we're looking  for. So here we're looking at the Pleiades entry for the ancient settlement of Rome.  I'll scroll down so you can see the map and confirm that it's where it's supposed to be.  This is an HTML view of an instance of a custom-plone content type that we call a place resource.  Our content types are presently still built on archetypes, and you'll recognize at the  top of this view some of the standard Dublin core fields like title, creators, contributors,  a right statement, last modified date and summary. I'm going to blow this up just a  little bit for folks with small devices. In Pleiades, our place resources are the primary  organizational construct of the whole digital gazetteer. They're conceptual entities, so  we apply the term place to any locus of human attention, material or intellectual, in a  real-world geographic context. So a settlement that's mentioned in an ancient text is a place,  whether or not it can be located now. An archaeological site is a place. A modern city located at  top of an ancient settlement is a place. If you and I both had access to time machines  and we could find a way to agree on somewhere to meet for lunch in antiquity, that would  be a place for Pleiades purposes. So basically any spatial feature that's connected to the  pre-modern past and that a human being has noticed and discussed as such, sometime between  the past and the present, that's a place. If we look at what's here on our view, this  canonical URI business, this simply repeats the stable uniform resource identifier that  Pleiades automatically assigned when the content item is created. That's there in your browser  location bar. We repeat it in the view and provide a handy JavaScript copy-to-clipboard  affordance in the UI because the assignment, stability and reuse of these URIs constitute  one of the most important functions of the gazetteer. Especially in the early days of  the project, most humanity scholars were unaware of and suspicious of the web's long-term reliability  for scholarly publication purposes. BITROT was, or, you know, LINCROT was a huge problem  from an academic perspective because we want to cite everything. We want to be able to  find out where assertions about the things we study came from. So we provide a unique  stable identifier for places in the ancient world that other scholars and students want  to discuss or reference in their own publications and datasets. And as a result, over the last  10 years, these URIs have come to be used in a variety of other web applications and  research datasets. So that makes it easier for scholars and students to combine multiple  datasets that they gather from different places, different repositories, and use them for research  tasks without having to clean or align all the geography by hand. So that's one of the  important things we do. This representative point here, this latitude-longitude value,  is calculated automatically. It's usually a centroid of whatever spatial geometries are  associated with the place. We'll talk about more of that in a minute. First, I want to  look at a slide and talk a little more about our custom content. Not Sean and Scotty,  but custom content types, in Pleiades. So the place resources, like the Rome entry we've  been looking at, are our folder-ish, as the Plone folks say. That means they can contain  other content. In Pleiades, we allow only three other custom content types inside places.  We call these locations, names, and connections. There you get recent counts of each. I think  if we move to another famous ancient city, we can have a good look at those. So let's  go here. So welcome to the ancient city of Nineveh. I'll let you watch the map. It's  located near the modern city of Mosul in Iraq. In this place resource, you'll see we've  defined two location resources right here. We use locations to store the geospatial  information about where an ancient place may have been located on the Earth's surface.  Both of these are depicted on the map using the color blue. One of these is a simple point  geometry imported from another database or data set called DAH-R-E, which stands for  the Digital Atlas of the Roman Empire. It's the work of Johann Eiffelts at the University  of Gutenberg in Sweden. The second location is a polygon. It's derived from an open street  map from a way or a relation in open street map. It corresponds in this case to the boundaries  of the modern archaeological site. So let's look at our location here. If you take a peek  at it, you can see we store more than just the spatial geometry, although that's really  obvious in the case of a polygon. We can subtype our locations. Here we call it a settlement  because that's what we're outlining. We might have called this an archaeological site instead,  but in any case, that's the current state of the data. We can indicate the nature and  extent of archaeological remains associated with the location. This is a value to cultural  heritage organizations and geos that respond to disasters, organizations that are engaged  in the protection of cultural property during conflict, that sort of thing, knowing whether  the thing is visible or not, and if there's something substantive on the surface is very  important. We can also signal our confidence in associating this particular location with  the place and any of the other information, like names and connections, that the place  contains. Another crucial bit of information that we store is a citation. In this case,  it's an annotated link to the OpenStreetMap way in question, the one that we imported  to create this location. Keeping this information does two things for us. Firstly, it allows  us to credit OpenStreetMap in compliance with their data license, and it also makes it possible  for users to inspect the original data source in order to evaluate for themselves its quality  and relevance. So the place resource for NINIVA also contains a number of name resources.  In Pleiades name resources store information about toponyms, both ancient and modern, as  they're associated with a given place. Pleiades names are more than labels, and therefore  they are a more complex content type than a simple string or a series of language encoded  strings. So if we look, for example, at the Pleiades resource for the ancient Greek name  of NINIVA, Ninos, you can see that we record one or more romanization forms. Romanization  forms are transcriptions in Roman characters of the ancient name. For some languages and  writing systems like polytonic ancient Greek, which is what we have here, and modern or  historical Arabic, multiple romanization forms can and probably should be used for the same  original name. We want them to be used because we want our name-based search to be as easy  and effective as possible, regardless of where you're coming from with a particular variant  on a name, we want you to be able to find it. So we're encouraging our content contributors  to provide as many romanization forms as are commonly in use or that one finds in earlier  scholarly literature. When the original writing system is fully and accurately represented  in Unicode, we fill out this attested name field, and then additional attributes are  available to indicate the language and writing system of the original, to indicate the function  of the name in the original context, and to characterize the accuracy and completeness  of the text or texts that have communicated it to us. The next thing we encounter in the  HTML Place view are two clickable lists of what we call connections. We use connection  resources to express direct place-to-place relationships. They enable us to document  geographic, political, and analytic hierarchies, networks, and linkages. Although the basic  functionality for connections was introduced into Pleiades years ago by Sean Gillis, connections  in their full current form are relatively recent implementations. So Alec Mitchell and  his colleagues at Jaskarta bear the scars of turning these into full-fledged, awesome  things that we have today. So connections as we have them now turn Pleiades into a directed  graph. Our place resources are nodes in the graph, and the connections are the edges.  Consequently, any place can participate in an ordered pair as either the origin, or you  can call it the subject if you like RDF parlance. So it's either the origin or subject, or it's  the target or predicate. And that's why you see two lists of connections in the Place  view. Makes connections with list connections for which Nineveh is the origin. So Nineveh  is a part of whatever. The receives connections from list shows connections in which Nineveh  is the target or the predicate. So the Honduru gate is part of the topographic area of Nineveh.  Let's look at one of these. When you examine a connection resource in Pleiades, like this  one for the administrative relationship between Nineveh and the ancient kingdom of Assyria,  it becomes immediately apparent that our graphs edges are not simple. They're attributed  just like the nodes are, the places. Apart from the connection type, our contributors  can also indicate scholarly confidence in making the connection, the time periods during  which the connection is thought to have been active or functional, and any references to  scholarly literature, databases, or websites that provide evidence of it or information  about that connection. These three attributes, association, certainty, temporal attestation,  and the references down here, their provision to not just for connections, but also for  our names and locations. So you may have noticed them in the HTML views we looked at earlier,  even though I didn't mention them. These two temporal constrained attributes, not before  and not after, are a recent addition to the data model, and they apply to connections  only. They were requested repeatedly and loudly by our users so that events and durations,  and there's good historical data for them, can be more precisely delineated. So although  these attributes are not extensively used on this particular connection, you can see  them hard at work elsewhere in our data set. References are not limited to locations, names,  and connections. We use them extensively at the place level as well. Nineveh boasts a  substantial number of them, more than average in the data set. Our goal with references  is to connect users as quickly as possible with additional information about the resource  and question, you know, whether that is because the item was used in developing what we're  showing you in the place resource, or if it provides additional information that might  be useful to you or more data of some kind. So we link to things like photograph collections  and museum sites and that sort of thing. We focus on getting users to the resource and  question as fast as possible. So if the thing is available online, we're going to link right  to it, in this case to a site called Topos Text that was created by a guy named Brady  Kisling. It has cool stuff like lots of ancient source citations in which a particular place  is mentioned. But if the item is not online, but it can be found separately cataloged in  libraries, we link to the corresponding entry in something called WorldCat, which is an  online union catalog of academic libraries around the world. It's maintained by the nonprofit  online computer library center or OCLC for short. And by linking to WorldCat, we make  it easier for users to identify the nearest library that holds a copy of the work that  they're looking for that apparently is not a valid zip code in the US, but never mind.  For journal articles and other works that are not cataloged by third parties, we're going  to link to our own geographic database. We use the open source Citero citation management  system for creating and managing all of the bibliographic data that we use in our references.  But we only link directly to the Citero record when we've really got no place better to send  people. Citero is run by the nonprofit corporation for digital scholarship that has a robust  and reliable API that we use at author time. And we use it to relieve our contributors  from tedious 20th century style bibliographic formatting tasks. And if I don't run out of  time, I think I'm doing okay. We'll see it in action in a minute. You'll notice above  the reference listing that we have a place type attribute. We've been looking at settlements  so far, but Pleiades gives us the ability to describe many more types of ancient places  and spaces. So let's see that in action real quick. All of the place types in our controlled  vocabulary are listed in our advanced search on the categories tab. You can see we've  got a bunch of them. Let's look at lighthouses. We can use that to quickly find things. And  I want to limit our results to places. I don't think I'm logged in. We'll only get published  items regardless of what we ask for. So here's eight lighthouses that are indicated as such.  This one is the famous lighthouse of ancient Alexandria on the Egyptian coast. It's one  of the original Seven Wonders of the ancient world. So this lighthouse was super famous  in antiquity. In fact, it was simply known as the lighthouse, pharaohs in ancient Greek.  So it's a return to the advanced search. I could demonstrate another key aspect of the  data contained in Pleiades. Go back to the categorization tab. There's a lot of places  in the ancient world that are mentioned in historical texts that we can't locate today  with any kind of precision. Pleiades records these as well. And we normally add a place  type value of unlocated to the corresponding resources. And that lets us hunt for them  in the advanced search. You'll see we have just a few unlocated places. Let's narrow  it down to unlocated places that have been added recently. Here's a few. The funerary  grove of epicrates sounds interesting. Right. So typical of unlocated places in Pleiades,  you'll see that no locations have been recorded. We do, however, have some connections that  are used to provide associations with other geographic features known to be associated  with this one on the basis of ancient sources. Nacroson is interesting because it's not precisely  located either. But scholars have theories about where it was. In fact, you can find  three competing identifications in the scholarly literature. So these are archaeological sites  that are in the right general area. But there's no definitive evidence to say which one was  this one named Nacroson that shows up in some ancient texts. So you'll see that we have  three discrete locations associated with this place resource. And each of them makes use  of the association, certainly the attribute to indicate the tentative nature of the association.  And if you look at the map, you'll see each one of these is represented with one of our  blue crosshair icons, which is the point location. So now I'm going to talk briefly about this  representative point in more detail. It's indicated on the map with an orange circle  icon. We've already noted its presence in the textual form and the attributes listing.  In Pleiades, representative points are calculated as an approximate centroid of the locations  associated with the place resource in question. Those of you who are familiar with Python  Shapely library will recognize the terminology representative point. It's not always a centroid,  but it often is. So in cases like this, the representative point will fall somewhere between  the various location geometries. In similar cases like Rome, Nenove, and the forest, they'll  fall near the center of the locations. We've also discovered that there are times when  we know where a feature is, but we don't want to use a location for it. What do we do about  the representative point then? And why would we want to leave locations out in the first  place? Well, big, complex broad features are a good case. Study. Let's consider Hadrian's  wall. There it is. So what's going on in the map here? We're visualizing two things for  this huge complex fortification system. The spatial coordinates of each of the connected  places that together constitute the fortification system. So these are the green bow tie icons  that are all stuffed in here. And this time, the orange circle denoting the wall's representative  point is calculated on the basis of those geometries, since we don't have any location  objects defined on the wall place resource itself. We're starting to use this technique  with kingdoms, provinces, and other administrative and regional divisions as well. So here, for  example, is the island of Sicily. All right. It was also a Roman province. And it's here  that the GIS folks are usually going to say, hey, why don't you just do a spatial containment  or an intersection query instead of messing around with all these connections? It seems  like a ridiculous amount of work. And I'll give you two interrelated reasons. We're not  just making a map or constructing a geospatial data set for spatial analysis and graphic  visualization. We're creating a data set that could be used for lots of tasks in addition  to those. We want a data model in which every place known to be in a province, let's say,  is properly associated with that province. A pure spatial query isn't going to find the  unlocated places. Moreover, ancient regions and administrative divisions are and were  sparse in spatial terms. We may know lots of settlements on a particular area of the  Earth's surface, but we may only know about the belongingness of some of them to a particular  historical region or administrative division. And moreover, we'd be making a huge error  by assuming that ancient administrative regions were solid polygons in the first place. Borders  could be fluid or ill-defined in real fact. And the internals could look like Swiss cheese  if all the borders were, even if the borders were precisely defined and you could map them  accurately, which we usually can't. Let's consider, for example, Delphi. This is a famous ancient  sanctuary of Apollo in Greece. Delphi wasn't just a bunch of temples. It controlled a significant  land area and therefore had an important economic role in the region above and beyond its religious  and diplomatic functions. A naive observer would assume that during the Roman imperial  period, this site would have fallen within the Roman province of Achaea. But legal documents  demonstrate that Delphi, in fact, had a direct bilateral relationship with the emperors and  it so bypassed the provincial administration completely. The Roman governor of Achaea  could say nothing legal about what went on in Delphi or involving Delphi's neighbors,  even though he had authority over the neighboring communities. Delphi gives us a chance to talk  briefly about another important aspect of Pleiades' places. We call them alternate serializations  or alternate representations. So far, I've been showing you the HTML versions of the  content in the Pleiades' Zope database. Those of you familiar with how Plone 3 and Plone  4 work will recognize the term base view. When you look at Pleiades' places, names, locations,  and connections in a web browser, you're looking at rendered versions of a customized Plone  HTML base view template. Those of you who program Plone will know that it's possible  to create alternative views for content items and that's what we've done. You'll see the  links on every place page under the heading, alternate representations. Clicking on any  of these links, I'm going to click on JSON, will get you the corresponding format. Complete  with the appropriate MIME type and the response header so that your browser can try to figure  out what to do with it. Here, for example, is the JavaScript object notation serialization  of the Pleiades' place resource for Delphi. I'm not going to click on it now for time  reasons, but you can click on the KML link to get a keyhole markup language serialization.  And if you've got Google Earth installed and if your browser knows about it and if you  don't have an old version of Adobe Photoshop that hijacks that particular MIME type, you  can view your location data over Google Earth's spatial geometry. We've exposed these alternate  representations in such a way that they constitute a read-only, open application programming interface  that conforms to the web architectural style known as REST. That is, representational state  transfer. We use a uniform method of constructing the corresponding URIs across the whole site  and you see that summarized here. You can discover all of these resources. I mean Chrome, aren't  I? Different set of keystrokes. So you can discover these things, whoops, in, in, on  the web by parsing the link elements that have the alternate value in the rel attribute  out of the HTML. You can also use HTTP content negotiation to get at them in Pleiades. And  the whole idea here is to make Pleiades an easy resource to reuse from other web applications.  We also publish RDF versions of the content and that makes Pleiades a linked open data  application. We're proud of the fact that Pleiades was the first ancient history website  or web application to meet the criteria for addition to the linked open data cloud diagram  where you'll still find it today. But if you don't want to script a web app against Pleiades  or, you know, set up a triple server and do all that sort of stuff, instead you'd like  to download all our data to do things with on your own in your own applications or tools.  We try to make that easy too. So we have a downloads page that you can get to and there  we provide access to regularly refreshed bulk exports of the published data in several formats.  Our JSON exports are the comprehensive ones. So they provide every attribute of every published  place, name, location and connection. The other formats are bridged. So the comma separated  values KML and so on. Every published object is represented. But only some of the commonly  used attributes are provided in each. You can also get packaged copies of our data  from various third party repositories. I've listed some of that here. And there are also  a couple of really cool derivative data sets that are built and maintained by our partners.  So how does all this information get created and updated? Well, we have a clone workflow  for that. And I'm going to show you that very briefly. It looks like I've taken a little  more time than expected and Alec is probably getting itchy to do some talking here. So let  me just do a real quick demo. I'm not quite sure how the time got away from me. Oh, I  see what's happening. It has to do. I actually got good time. I was looking at the zoom time  instead of the clock time. I apologize for all the noise. All right. So authenticated  users can add content. And we do that in a clone like way. I'm going to use a username  that I have assigned that doesn't have any special privileges. And I can navigate to  the places top folder. And I can add a new place in the way you'd expect to in clone  four. And you get a form that lets you add stuff in. So let's say we were going to add  Atlantis. Then you fill out the form. It's unlocated. We can have multiple types. So  I can call it an island. A settlement. So on and so forth. I won't fill it all out.  References. I'll show you how that works in a minute. We can add tags. I could credit  or blame other people. And I even have a details and field rich text field in which I can write  a long essay about how awesome Atlantis was. Once I save that, we're going to start in  our default workflow state. And that's drafting. So it is visible only to me and to super users.  And I can continue to edit this. In particular, I can add locations. We have a form that lets  you put in an open street map ID and import the geometry from there, which is very handy  for features that are extant and visible in the world today. We can also add names using  the typical clone manner by entering stuff and using combo boxes for our various vocabularies  as we encounter them. So for example, we're not going to let people randomly enter and  type the name of the language. We're going to control that so that we don't get typos  and that sort of stuff. So that's the basic process for adding something. Once you are  ready to have it reviewed by our editorial college, you submit it for review using the  typical clone workflow transition thing. We encourage people to write useful comments  beyond initial revision. Although in this case, I think I'm not going to bother. I submit  it for review. Once I've done that, if I'm a regular user, you'll notice the as I am  logged in now, you'll notice that the edit option on this thing is gone. So we on moving  depending, we lock the content item for additional changes by the user who submitted it. That  keeps us from multiple edits involving the editors and the user at the same time. If  I were to log in as an editor, I could look at this and revise it and in this particular  case send it back to myself as deficient in terms of its content. But that's the basic  way we work with new items. And so we allow people to come along and add whole new places  for consideration or they can visit an existing place and add a name or a location using the  same or connection adding the same kind of button affordances and then those get managed  through the workflow process separately. Now modifications to existing resources are different  animal. We make heavy use of clone iterate and I'm going to find a particular example  and I'm going to go to another browser and log in as an editor. I was already logged  in but I've logged out nifty me. Okay. So I scouted out this particular place in advance.  This is a place called a gigli located on the North African coast. You'll see here under  the names listing, we blow that up for small devices. We have a Latin form of the name  and then picked out in orange here we have a Greek form of the name. That means this  has been added. I'm showing you now the editor's experience of these that have just been added  and I can go through this and approve it for publication. I promised you clone app iterate  but in fact I got lost in my notes. Here's clone app iterate at work in Pleiades. At  Asina is an entry in clone in Pleiades that I'm going to go back to my other user because  I don't want you to be forced to see the editorial view of all this. It's still got some raw  data in it from when it was imported from the original Barrington Atlas data. It's had  some modifications made since then but we'd like to improve it. The way I do this as a  user, I don't get to edit it live. This thing is locked for regular users to use. What I  have to do is I have to use iterate to check out a working copy. I've checked out a working  copy of the place. You'll notice it's copy of in the URL stub. Then I can edit this  in draft to make the changes I want. I can modify any component of the presentation. I  can iterate on that and then save it in my draft working copy. Once I've got that the  way I want it, I can submit it for review just the way I would something entirely new.  Back in the editor's view, suppose I'm doing my daily editing task and I want to see what's  waiting. I hope this is not an embarrassingly large number of items. No, it's not. Here's  that andesina entry that my alter ego submitted for review. I can look in the history to see  what was said about it and then I can move it on through the workflow process. What I'd  normally do if I think this is good to go is I would check it in. We bring forward the  check-in message from whatever the workflow transition message was. Thanks to that editorial  action, that summary is live in the database and it replaces the published version. The  history will give you the ability to see back what was done previously to this particular  entry all the way back to its original ingestion in the database in 2009. I think we are now  at the point where I should turn things over to Alec and drive the slides for him and see  how we go.  I'm going to go really quickly here because we don't have a ton of time. Let's see if  we can get the slides up again, Tom. I'm not seeing them. There we go. As you probably  understand from Tom's demo, Pleiades is a pretty complex system. In fact, it comprises  25 custom Python packages. That complexity can make upgrades really tricky, especially  for a development team that came in unfamiliar with the original code base. When we did the  upgrade, we ran into various issues. We made some testing fixes, had to update a bunch  of custom views and customizations of existing views, removed some dependencies on some old  packages, removed various crufts from add-ons that had come and gone over time. Then we  made a variety of performance improvements. If you saw Philip Bowers talk yesterday, you'll  probably recognize a number of the sort of performance gotchas that we were dealing with,  in particular things like lacking no-call statements on path expressions, which cause  objects to be fully rendered while generating a template. There was a bunch of inline rendered  JSON in head. Tom showed you those links to data in head, and a lot of those used to  be full JSON. In some cases, it got very complex and was very hard to render. We moved that  stuff to ASync, and that gave pretty large performance improvements. Then over time,  we've also replaced AT Vocabular Manager with registry, Plenup Registry-based Vocabularies,  which means fewer catalog queries, fewer object lookups, and some significant performance  improvements. Then, as Tom mentioned, we implemented Ansible to ensure we had repeatable deployments  and that the server wasn't a special snowflake, which is a term we might recognize from Calvin's  AWS talk yesterday. Plone plays a big role in Pleiades, despite the fact that it's a  very complex system that doesn't necessarily fit into traditional content management. You  can see that it uses tons of features from Plone through Tom's demo. We've got content  types with complex custom schemas, hierarchical content models, custom permissions and roles,  custom workflows, and then a pretty heavy dependence on Plone app iterate for content  staging. The fact that iterate is based on adapters makes it really easy to customize  the data copying and merging logic, which Pleiades does extensively. Then on top of  that, we use custom views for the various non-HTML representations for exports, and  we depend on a variety of Python libraries for doing that, some of which, as Tom mentioned,  came directly out of this project. In terms of recent work that Jazzgard has been doing  on Pleiades, we've been preparing for a while for a Plone 5 upgrade. We've made improvements  to the bulk import process. We've completely eliminated AT Vocabular Manager, improved  the iterate customizations so that that checkout check-in process works pretty seamlessly.  We've made completely comprehensive JSON representations, improved this concept of promoting locations  to places, which is something that demo didn't quite get into, but it's another workflow-y  action that allows you to actually convert subordinate content types into places. Then  a bunch of other stuff, including better mapping systems and updated geographic information.  Eventually we do plan to move to Plone 5.2 and Python 3, but the whole site's done in  archetypes now, so we're going to have to move everything to dexterity, including all  of the connections and relations, the various data. There's going to be a bunch of custom  behaviors because there's a lot of shared functionality in terms of bibliographic references  and things like that. All the custom views are going to need to be updated. Our plan  is to basically do a new updated implementation of the site's dexterity, test everything out,  leverage the fact that the site already has a comprehensive JSON export and a bulk import  update feature to do the migration. For non-custom content, we would just use collective JSONify  and transmodifier. I'm not sure that this site is a good fit for Volto at this point.  As you saw from Tom's demo, it's really a data-driven research tool, so the need for  customizable layouts and the other kind of nifty things you get with Volto is pretty  minimal at this point, but who knows? That's the future.  Anyway, that's it from me. Thank you, everybody, for coming to this talk, and thank you, Tom,  for that wonderful demo.  Yeah, thanks for me, too, to everybody and to you, too, Alex.  Hey, great. Thanks, guys. That was fascinating. It's really cool to see how much work and  all the cool stuff you can do with the Plone site and especially in the context of this.  We have one slide-O question from Philip, and that's, what do you use to replace AT vocabulary  manager as a collective taxonomy?  No, it's essentially just a custom Plone app registry set of vocabulary, a couple of  custom classes that pull vocabularies out. In the case of Pleiades, there's a view that  makes those vocabularies appear as content-ish things to make it the same as ATVM.  Yeah, it's custom code. There's an add-on. All of these add-ons are actually open source.  I'm not sure how useful they are to anybody outside of Pleiades, but Pleiades' vocabulary  add-on has all that code, and it used to all be ATVM in there. No, it's the new stuff.
Traveling_through_time_and_place_with_Plone_-_Tom__VZXAYl2Qe4E_0_3299.png Traveling_through_time_and_place_with_Plone_-_Tom__VZXAYl2Qe4E_3300_11255.png Traveling_through_time_and_place_with_Plone_-_Tom__VZXAYl2Qe4E_11256_16811.png Traveling_through_time_and_place_with_Plone_-_Tom__VZXAYl2Qe4E_16812_17363.png Traveling_through_time_and_place_with_Plone_-_Tom__VZXAYl2Qe4E_17364_19067.png Traveling_through_time_and_place_with_Plone_-_Tom__VZXAYl2Qe4E_19068_21167.png Traveling_through_time_and_place_with_Plone_-_Tom__VZXAYl2Qe4E_21168_22067.png Traveling_through_time_and_place_with_Plone_-_Tom__VZXAYl2Qe4E_22068_23543.png Traveling_through_time_and_place_with_Plone_-_Tom__VZXAYl2Qe4E_23544_24047.png Traveling_through_time_and_place_with_Plone_-_Tom__VZXAYl2Qe4E_24048_26195.png Traveling_through_time_and_place_with_Plone_-_Tom__VZXAYl2Qe4E_26196_28439.png Traveling_through_time_and_place_with_Plone_-_Tom__VZXAYl2Qe4E_28440_29903.png Traveling_through_time_and_place_with_Plone_-_Tom__VZXAYl2Qe4E_29904_30971.png Traveling_through_time_and_place_with_Plone_-_Tom__VZXAYl2Qe4E_30972_31235.png Traveling_through_time_and_place_with_Plone_-_Tom__VZXAYl2Qe4E_31236_31487.png Traveling_through_time_and_place_with_Plone_-_Tom__VZXAYl2Qe4E_31488_35687.png Traveling_through_time_and_place_with_Plone_-_Tom__VZXAYl2Qe4E_35688_39191.png Traveling_through_time_and_place_with_Plone_-_Tom__VZXAYl2Qe4E_39192_40655.png Traveling_through_time_and_place_with_Plone_-_Tom__VZXAYl2Qe4E_40656_44123.png Traveling_through_time_and_place_with_Plone_-_Tom__VZXAYl2Qe4E_44124_44963.png Traveling_through_time_and_place_with_Plone_-_Tom__VZXAYl2Qe4E_44964_45983.png Traveling_through_time_and_place_with_Plone_-_Tom__VZXAYl2Qe4E_45984_46103.png Traveling_through_time_and_place_with_Plone_-_Tom__VZXAYl2Qe4E_46104_46151.png Traveling_through_time_and_place_with_Plone_-_Tom__VZXAYl2Qe4E_46152_46271.png Traveling_through_time_and_place_with_Plone_-_Tom__VZXAYl2Qe4E_46272_46619.png Traveling_through_time_and_place_with_Plone_-_Tom__VZXAYl2Qe4E_46620_46907.png Traveling_through_time_and_place_with_Plone_-_Tom__VZXAYl2Qe4E_46908_46955.png Traveling_through_time_and_place_with_Plone_-_Tom__VZXAYl2Qe4E_46956_47591.png Traveling_through_time_and_place_with_Plone_-_Tom__VZXAYl2Qe4E_47592_47723.png Traveling_through_time_and_place_with_Plone_-_Tom__VZXAYl2Qe4E_47724_47867.png Traveling_through_time_and_place_with_Plone_-_Tom__VZXAYl2Qe4E_47868_48119.png Traveling_through_time_and_place_with_Plone_-_Tom__VZXAYl2Qe4E_48120_48407.png Traveling_through_time_and_place_with_Plone_-_Tom__VZXAYl2Qe4E_48408_48671.png Traveling_through_time_and_place_with_Plone_-_Tom__VZXAYl2Qe4E_48672_49391.png Traveling_through_time_and_place_with_Plone_-_Tom__VZXAYl2Qe4E_49392_49571.png Traveling_through_time_and_place_with_Plone_-_Tom__VZXAYl2Qe4E_49572_50387.png Traveling_through_time_and_place_with_Plone_-_Tom__VZXAYl2Qe4E_50388_50531.png Traveling_through_time_and_place_with_Plone_-_Tom__VZXAYl2Qe4E_50532_51635.png Traveling_through_time_and_place_with_Plone_-_Tom__VZXAYl2Qe4E_51636_52763.png Traveling_through_time_and_place_with_Plone_-_Tom__VZXAYl2Qe4E_52764_52979.png Traveling_through_time_and_place_with_Plone_-_Tom__VZXAYl2Qe4E_52980_53051.png Traveling_through_time_and_place_with_Plone_-_Tom__VZXAYl2Qe4E_53052_53819.png Traveling_through_time_and_place_with_Plone_-_Tom__VZXAYl2Qe4E_53820_54671.png Traveling_through_time_and_place_with_Plone_-_Tom__VZXAYl2Qe4E_54672_54743.png Traveling_through_time_and_place_with_Plone_-_Tom__VZXAYl2Qe4E_54744_55595.png Traveling_through_time_and_place_with_Plone_-_Tom__VZXAYl2Qe4E_55596_55751.png Traveling_through_time_and_place_with_Plone_-_Tom__VZXAYl2Qe4E_55752_55871.png Traveling_through_time_and_place_with_Plone_-_Tom__VZXAYl2Qe4E_55872_56615.png Traveling_through_time_and_place_with_Plone_-_Tom__VZXAYl2Qe4E_56616_56675.png Traveling_through_time_and_place_with_Plone_-_Tom__VZXAYl2Qe4E_56676_56771.png Traveling_through_time_and_place_with_Plone_-_Tom__VZXAYl2Qe4E_56772_57599.png Traveling_through_time_and_place_with_Plone_-_Tom__VZXAYl2Qe4E_57600_58199.png Traveling_through_time_and_place_with_Plone_-_Tom__VZXAYl2Qe4E_58200_58247.png Traveling_through_time_and_place_with_Plone_-_Tom__VZXAYl2Qe4E_58248_59063.png Traveling_through_time_and_place_with_Plone_-_Tom__VZXAYl2Qe4E_59064_59939.png Traveling_through_time_and_place_with_Plone_-_Tom__VZXAYl2Qe4E_59940_60515.png Traveling_through_time_and_place_with_Plone_-_Tom__VZXAYl2Qe4E_60516_60623.png Traveling_through_time_and_place_with_Plone_-_Tom__VZXAYl2Qe4E_60624_60671.png Traveling_through_time_and_place_with_Plone_-_Tom__VZXAYl2Qe4E_60672_61043.png Traveling_through_time_and_place_with_Plone_-_Tom__VZXAYl2Qe4E_61044_61391.png Traveling_through_time_and_place_with_Plone_-_Tom__VZXAYl2Qe4E_61392_61523.png Traveling_through_time_and_place_with_Plone_-_Tom__VZXAYl2Qe4E_61524_61643.png Traveling_through_time_and_place_with_Plone_-_Tom__VZXAYl2Qe4E_61644_62447.png Traveling_through_time_and_place_with_Plone_-_Tom__VZXAYl2Qe4E_62448_62579.png Traveling_through_time_and_place_with_Plone_-_Tom__VZXAYl2Qe4E_62580_62639.png Traveling_through_time_and_place_with_Plone_-_Tom__VZXAYl2Qe4E_62640_62939.png Traveling_through_time_and_place_with_Plone_-_Tom__VZXAYl2Qe4E_62940_62999.png Traveling_through_time_and_place_with_Plone_-_Tom__VZXAYl2Qe4E_63000_63047.png Traveling_through_time_and_place_with_Plone_-_Tom__VZXAYl2Qe4E_63048_63203.png Traveling_through_time_and_place_with_Plone_-_Tom__VZXAYl2Qe4E_63204_69083.png Traveling_through_time_and_place_with_Plone_-_Tom__VZXAYl2Qe4E_69084_71279.png Traveling_through_time_and_place_with_Plone_-_Tom__VZXAYl2Qe4E_71280_73111.png