John Bonnett
Brock University
Background: The StructureMorph project rests on the premise that future publishing platforms will converge multiple applications, such as geographic information systems (GIS) and game engines, and multiple paradigms of computing, such as desktop computing and high-performance computing. Convergent platforms will also present design challenges for scholars.
Analysis: In this contribution, one response to these challenges is presented: the Complex Object. Complex Objects are 4D models that alter their shape and surface appearance in response to user interaction, and changes in world time. They also to mimic the behaviours of 2D polygons as configured in geographic information systems, graphically linking attribute data with spatial locales.
Conclusion and implications: This article discusses the concept of the Complex Object and describes the software and workflow devised to support its creation.
Keywords: 3D modelling; Complex Objects; Convergent platforms; Digital history
John Bonnett is Associate Professor of History at Brock University, 1812 Sir Isaac Brock Way, St. Catharines, ON, Canada L2S 3A1. Email: jbonnett@brocku.ca .
Mark Anderson is Professor of Computing at Edge Hill University, St. Helens Road, Ormskirk, United Kingdom L39 4QP. Email: Mark.Anderson@edgehill.ac.uk .
Wei Tang is Honorary Research Fellow in Computing at Edge Hill University, St. Helens Road, Ormskirk, United Kingdom L39 4QP. Email: wei.tang@go.edgehill.ac.uk .
Brian Farrimond is Research Assistant in Computing at Edge Hill University, St. Helens Road, Ormskirk, United Kingdom L39 4QP. Email: brianfarrimond@mailbolt.com .
Léon Robichaud is Associate Professor at the Université de Sherbrooke, 2500, Boulevarde de l’Université, Sherbrooke, QC, Canada J1K 2R1. Email : Leon.Robichaud@USherbrooke.ca .
There are many things that can and should keep digitally inclined scholars awake at night: things that promise opportunity and intellectual discovery, and other things that promise botheration and a mad scramble to keep up. In our work we have been preoccupied with two words that start with “C” that have presented both botheration and opportunity: computation and convergence. With respect to the first, scholars in the past decade have witnessed the shift of computing to what Ray Kurzweil (1999) has referred to as “the second half of the chessboard” (p. 37). Computers such as IBM’s Watson, through a combination of brute computational power and artificial intelligence (AI), now have the capacity to perform heretofore impossible tasks, such as driving cars, making medical diagnoses, and engaging in legal reasoning (Brynjolfsson & McAfee, 2014). In the next couple of decades, humanists will likely find themselves using similar devices to locate relevant data online. With respect to convergence, we refer to a trend with which most are familiar: the aggregation of multiple tools into a single device in order to enhance the capabilities of users (Peddie, 2001). A smart phone is a well-known example of this. It integrates applications and devices, such as the computer monitor, QWERTY keyboard, camera, and phone, into a single construct.
In this article, our purpose is to argue that convergence is a process that will impinge on the future of the digital humanities generally and constituent research domains such as digital history particularly. Indeed, this process is already beginning. We further suggest that this pathway of tool integration will have an important consequence. It will lead to the emergence of new online constructs that will constitute platforms for acquiring, generating, disseminating, curating, and storing content (Kondratova & Goldfarb, 2003). The rise of new platforms in turn will invite innovation: new formalisms and practices will be devised to support content expression and publication workflows.
Our rationale for making this argument stems from two trends that emerged at the turn of this century that we believe are driving convergence. The first trend was researcher adaptation to the opportunities and costs associated with the emergence of big data and high-performance computing (HPC). Scholars in disciplines ranging from physics to English literature began to recognize, sometimes slowly, sometimes quickly, that the Internet, Moore’s Law, and novel, distributed forms of HPC had endowed them with more data, and more ways to treat it, than any enjoyed by previous cohorts of scholars (Bonnett, 2009; Guldi & Armitage, 2014; Jockers, 2013; Manning, 2013). The outcome of that realization was the articulation in fora such as the National Center for Supercomputing Applications (NCSA) and Compute Canada of user requirements for platforms capable of visualizing space at any scale and resolution, and time at any duration and increment. Researchers want tools that enable them to represent space in any mode they please, be it cartographic, photo-realistic, or both. They further want tools that will enable them to simulate the behaviour of physical, geological, biological, and historical systems at temporal scales ranging from the nanosecond to the millennium and beyond.1
The second driver for our argument is the growing recognition in both business and the academy that extant applications for data treatment and spatio-temporal visualization, such as geographic information systems (GIS), impose limitations on research, expression, and analysis that need to be transcended. For this reason, one can identify calls in multiple literatures, ranging from GIScience and historical GIS to the digital humanities and history, for the integration of GIS with multiple other applications. These include:
One can also detect moves by vendors such as Esri to address these limitations. In recent versions of ArcGIS, for example, the company has incorporated a digital globe akin to Google Earth. It has also, via its CityEngine plug-in, provided users with the capacity to rapidly generate photo-realistic 3D models using procedural modelling techniques. Finally, one can identify current research initiatives in archaeology such as the CRANE Project Computational Research in the Ancient Near East, where scholars are moving now to integrate most of the above applications to support the integration, visualization, and analysis of the social, economic, and environmental data obtained from the Orontes Watershed of southeast Turkey (CRANE, n.d.).
While the move toward spatio-temporal visualization and tool integration is leading to the emergence of platforms that heighten the capacity of researchers, it is also presenting them with challenges that touch on the question of design. Scholars will need to consider such general questions as how narratives and analyses will be expressed in the platforms they construct. They will further need to consider narrower questions, such as how the functionalities of one application – such as GIS – might be appropriated in the context of another, such as the Unity Game Engine. These realizations emerged as a result of the authors’ participation in a Social Science and Humanities Research Council of Canada (SSHRC) Partnership Grant, Plaque Tournante, a project dedicated to exploring Montreal’s historic role as a hub for the circulation of people, goods, and knowledge (UQAM, n.d.). These deliberations in turn spurred a thought experiment in which we considered historians’ requirement for an HPC-supported virtual world, and the subsequent establishment of the StructureMorph project.
To gain purchase on our thought experiment, we recognized that we would need to narrow its terms considerably. We could not hope, for example, to specify user requirements for the discipline as a whole, nor could we hope to explore the implications resulting from integrating all the applications listed above. For that reason, we narrowed our focus to the user requirements of two domains: social history and architectural history. Such a focus was warranted, we believed, because within history both fields have been among the most active in appropriating computing and have done the most to specify their requirements for the same. We further narrowed our focus by considering one scale of space: the urban level of spatial organization. And we finally narrowed the scope of our scenario by exploring the implications of converging just two applications: the game engine and GIS.
With these terms settled, we soon realized as we proceeded with our thought experiment that social and architectural historians would be asking a great deal from 3D model buildings as expressive objects in the platform we conceived. More specifically, we would be asking a given model to express two fundamental relationships: the relationship between the historic structure and the social data associated with it; and the relationship between the model and the primary source data that gave rise to it. With respect to the first requirement, we foresaw that the 4D building would perform similar functions to those performed by 2D polygons in GIS today. It would, for example, be tied to a social ontology, such as those expressed in census data, and a colour ramp that would distinguish each category in a given ontology with a colour. Therefore, we required models with the capacity to change their surface appearance from photo-realistic to symbolic modes, to facilitate search queries from users (see Figure 1). If a given address was lived in or operated by someone who was English, for example, we needed its affiliated model to turn red. With respect to the second requirement, we believe, based on requirements emerging from the architectural history, theatre history, digital archaeology, and virtual heritage literatures, that scholars will require building models that reveal themselves to be mediated, temporal objects (Frischer & Stinson, 2007; London Charter Interest Group, 2009). They will need to show that the given 4D model is an imperfect construct, a construct that differentiates, again via colour ramp, building constituents that are based on data, and building sections that are hypotheses, derived from the scholar’s knowledge of architectural and building practices from the time (see Figure 2).
To meet these requirements, the StructureMorph project is contributing to the development of an expressive object that is gaining greater currency in the digital humanities: the Complex Object. There is no fixed definition of the characteristics associated with the Complex Object, but among other things it is conceived as a hierarchical construct of many parts, one well suited to represent the multiconstituent object we call the building. It is also a heterogeneous object. It is not based on one mode of representation, such as text. It is rather an amalgam of different expressive forms ranging from text to audio, 2D animations, and 3D objects (Delve, Anderson, Dobreva, Baker, Billenness, & Konstantelos, 2012). We are contributing to this literature by suggesting that the Complex Object should not only be heterogeneous and hierarchical, it should also be a 3D matrix. To meet our expressive needs, Complex Objects will need to be more than a single thing, one expressive object subject to the grammars of succession or juxtaposition normally operative in human and animal expressive systems. Instead, we thought it better to conceive them as a suite of things, one that would be subject to a grammar of interaction determined, in part, by the structure of the 3D matrix, and, in part, by the interface governing user interaction with the Complex Object and its surrounding virtual world (Bonnett, 2015).
So constituted, the Complex Object will be able to meet the expressive requirements we have set for it. It will be comprised of multiple three dimensional increments, or cells, and each cell will contain one of the potential versions of the model (see Figure 3). The characteristics of a given iteration of the model will be determined by the location – the address – of the cell in which it finds itself. That address will be specified by its position relative to the three axes in the matrix. Each axis in the matrix will specify one of three things about the model:
Model expression will be determined by changes in virtual world-time or user interaction, promptings that will lead to the expression of one of the potential versions available within the matrix. The cell or increment that is activated will depend on the characteristics – the parameters – that are specified. The viewer or chronometer in the virtual world will tell the matrix what he/she/it wants to see. For example, in Figure 7 we see a representation of a search query in which a user indicates a wish to determine the ethnicity of the business proprietor in 1905. Three drop-down menus are used to govern the search. Since model version is not an issue, the user leaves it at its default setting: Final Version. The user then selects “1905” and “Ethnicity” and then presses the “Go” button to initiate the search. In reaction, StructureMorph locates the “address,” the cell in the matrix that corresponds to the three parameters specified in the menu. It then expresses that selection in the virtual world, re-rendering the model red to show the proprietor was English.
To date, we have completed an alpha version of StructureMorph, our software for Complex Object construction. The software is based on a six-step workflow that starts with user specification of the number of cells that will constitute the temporal and interpretive axes of the Complex Object. Users will not specify the number of cells along the expressive axis, as this will be automatically determined. Here we are assuming – per our thought experiment – that the virtual world and supporting platform will function much like journals, and build on recent contributions to multimodal publishing practice by journals such as Vectors. They will be open to the display of multiple urban environments initiated by multiple teams in multiple locales, and thus will not constitute stand-alone projects. Each urban environment will constitute a domain of study to which, in principle, any scholar can contribute a 4D model. Editors and peer reviewers will oversee the operation and composition of the virtual world. Researchers will contribute Complex Objects as contributions to knowledge in the same way that researchers currently contribute articles to journals. The Complex Object will be more than a dataset that can be used in multiple research contexts and deposited in depositories such as Dataverse. Rather, it will be an interpretation of the datasets that constitute it, an interpretation expressed in the lines and points of 4D models, an interpretation expressed in the audio, text, and 2D objects that accompany the 4D model. In such a context of work, we are assuming that the given virtual world will be tied to one or more databases describing the multiple socioeconomic ontologies associated with the virtual city or settlement under view. The number of attributes associated with those databases will automatically determine the number of cells along the expressive axis of our new 3D matrix.
Once the extent and cell population of the 3D matrix have been specified, the workflow will then shift to the task of model deposition in each cell situated along the temporal and interpretive axes.2 Steps two through six in our workflow describe the tasks associated with depositing one model in one cell of the 3D matrix. They will need to be repeated to fill each cell and complete the construction of the Complex Object. Step two begins with the user uploading the model to their target virtual world. The model is aligned with its specified city address in the virtual world, but is placed in a floating position to permit final scaling and positioning by the depositor, as shown in Figure 8. Step three is dedicated to structuring the 3D model. Every model, at its base, is an assemblage of lines and points. These primitives are listed in a document that constitutes the model known as a scene graph. In scene graphs, primitives can be listed as a single list of coordinate points. More often, however, they are differentiated into multiple sub-lists, or nodes, in a manner analogous to the way authors group words in a given text into paragraphs. These nodes typically assemble sets of points and lines that are associated with a given building constituent, such as a door, a window, or a lower cornice. The rationale for so doing is that it enables users to transform or filter selected building constituents. An author of a narrative devoted to a specific structure, for example, might opt to highlight one feature of a given structure by removing all features save for the highlighted constituent, such as the pilasters shown in Figure 9.
To support that process, we assume that modellers will need to structure their scene graphs and name their building constituents using a template prescribed by the virtual world’s editors. Based on that assumption, and based on the assumption that something such as Complex Objects will become a norm in scholarly virtual environments, we foresee that such templates will employ structuring and naming schemes much in the manner of the following:
[SPATIAL LOCATION]_[TIME]_[VERSION]_[CLASS]_[LOCATION]_[INSTANCE]
Translating this abstract scheme into something specific, it would mean that a structure such as the one shown in Figure 10, located at 45 Sparks Street in Ottawa, would be named in the following way:
45SPARKS_1875_FINALVERSION
The remaining constituents of the model would be named first according to class. “Class” here refers to specific building objects, such as pilasters. “Location” refers to an identifiable section of the structure, such as a given wall, which for our purposes we will label Façade One. Instance refers to a particular pilaster located on Façade One. On the actual 45 Sparks there were four pilasters. We will assume here that we are in the process of naming the third one, resulting in a constituent and scene graph node named thus:
45SPARKS_1875_FINALVERSION_PILASTER_FACADEONE_PILASTERTHREE
The essential steps of step three, then, will be to use the provided tools to ensure all building constituents are named correctly, and that the entire scene graph is structured in conformance with our scheme. All constituents will be housed in a node titled
45SPARKS_1875_FINAL VERSION.
All pilasters will be housed under a sub-node titled
45SPARKS_1875_FINALVERSION_PILASTER.
And all pilasters situated at Façade One will be housed in a sub-sub-node titled
45SPARKS_1875_FINALVERSION_PILASTER_FACADEONE,
as indicated in Figure 11. Users will use established interface protocols to define nodes, akin to the methods a Windows user would use to define and create new folders. They will further use drag-and-drop methods to move nodes, and establish parent-child relationships between nodes and sub-nodes.
Step Four will be dedicated to inscribing confidence on each building constituent. “Inscribing confidence” in this context refers to the process of colour coding building constituents, to differentiate those that are based on data from those that are based on knowledge of extant building practices and other methods of surmise. Here, our tool will enable modellers to specify different categories of confidence. Those categories can be qualitative. A digital historian for example, might require only two categories – one showing sections based on data, the other showing sections based on inference. Other scholars, however, will want to impose quantitative categories of confidence on their structures. Digital archaeologists and other disciplines affiliated with the historical sciences often require a means to indicate that they are, say, 75 percent certain that a given pillar was of a certain design and morphology, while they are 95 percent certain a certain wall painting, despite its missing pieces, looked the way it is represented. Our tool will enable contributors to symbolically express those labels of confidence by:
Step Five oversees the scaling and final situation of a submitted model. While it is likely that modellers will submit models built to scales specified by their target environment’s editors, it is also likely that models will also require some final, small modifications to ensure the submitted structure does not intrude into the space occupied by neighbours. To facilitate placement and scaling, Step Five will provide a control panel that allows contributors to move the model downward to its final position, and to make minor changes in model size along the X, Y, or Z axes. Finally, Step Six supports the annotation of submitted Complex Objects. Using the tools and text entry fields provided in this step, contributors will be able to input publication and bibliographic data identifying who made the model, where it was made, its copyright status, and other relevant metadata, as shown in Figure 13. Contributors will also be able to provide a written account of the model’s paradata. Paradata is a term first coined by Drew Baker (2016) (Delve, Anderson, Dobreva, Baker, Billenness, & Konstantelos, 2012) to address a specific need of historic 3D model documentation. Typically, in written forms of history, documentation is generally understood to mean reference to the provenance of a monograph’s or an article’s sources. Citations are made in footnotes or endnotes and generally are deemed to be sufficient, in large measure because most authors include an account of their source use and interpretation in their narratives. In the case of 3D models, however, such written accounts cannot be integrated as constituents of the model. Instead, they must be annotated, and Baker and others have proposed the term paradata to describe all written, graphic, and 3D materials that describe how the submitted model was constructed.
It is common wisdom these days that iterative design is an optimal methodology for software development; it is a truism that we most decidedly affirm (Haughey, 2010; Kang, Park, & Ki, 2003; Salisbury, 2003). Indeed, we found it an essential method – in conjunction with detailed planning documents and storyboards – to address inefficiencies in team communication. It also proved to be an indispensable way to meet evolving user requirements and a deepening understanding of the architecture that will be required to support the software and platform we propose to build. To start, iterative design helped project participants separated by one ocean and two different disciplinary traditions (John Bonnett and Léon Robichaud in digital history; Mark Anderson, Brian Farrimond, and Wei Tang in computer science) to navigate the inevitable misunderstandings that emerge in group projects, particularly in teams that are new. Despite careful planning, we still ran into instances in which a user requirement relating to interface design or tool functionality was misunderstood or missed.
When problems of this nature arose, our default method was to do two things. The first was to consult a detailed set of user specifications produced by John Bonnett prior to the start of the project. They described the Complex Object, as well as the interface and functionality of StructureMorph. In television series, one often hears of script bibles that establish the setting and characters, their backstories, and provide guidance to script writers on the future trajectory of the series’ narrative. Bonnett’s writings functioned as our script bible. Our second action was to consult the detailed storyboards produced by Bonnett using PowerPoint, MS Paint, and Photoshop. These storyboards provided graphic and textual descriptions of the interface, StructureMorph tools, their functions, and the workflows they supported. They served as the point of departure for developing project tools, and as points of reference for locating and correcting omissions or mistakes. As is the case in film, our script bible and storyboard supported the iterative design and construction of StructureMorph’s interface and tools.
Aside from supporting team communication, an iterative approach proved essential for Mark Anderson, Brian Farrimond, and Wei Tang in working through problems associated with interface construction and software architecture design. Initially, our intentions with respect to StructureMorph were comparatively modest. We planned to construct a plug-in for the Unity Game Engine, one that would leverage its strength in delivering rich content, while using our plug-in to regulate the construction and expression of that content. Our initial purpose – since we were working on a proof of concept – was to produce a client application and leave server issues for another time or another team. However, for two reasons, we realized we would need to scale up the extent and complexity of our project. To start, we came to recognize that an adequate demonstration of the Complex Object would require displaying its features in the context of a virtual city, one that is present in whole or in part. We therefore required a server with architecture capable of efficiently rendering and processing our 3D data. A second impetus for incorporating server-side architecture was our recognition that we plan to deploy StructureMorph on multiple platforms and via different mediums, such as augmented reality. We needed to address server architecture if we were to create an application capable of creating and distributing responsive content.
The first indication that project participants needed to develop more than a plug-in emerged when Anderson, Farrimond, and Tang constructed StructureMorph’s interface using tools provided by Unity. It soon became clear that the game engine’s palates of tools dedicated to interface design were too limited to meet project specifications. We further realized that we needed interface design tools capable of supporting user interaction within Unity, and on platforms outside of Unity. Given that requirement, the three ultimately scrapped their initial versions of the StructureMorph interface, and selected Microsoft Visual Studio and Helix 3D to construct our interface. Our efforts to create a responsive interface and seamless user experience in turn brought a second issue to the fore: the need for a server architecture, and in the wake of first attempts, a re-engineering of the same server architecture. Our initial efforts in this area produced results that were, to put the matter charitably, inefficient. Individual files, not to mention larger scenes, took inordinately long times to load. The architecture further imposed unacceptable lags as the scene rendered and re-rendered to show movement through the virtual world.
To meet these challenges, Anderson and Tang made two significant changes respectively to the structure of project 3D models, and to the server’s architecture. With respect to the models, the two designed an algorithm to split submitted 3D models into smaller packets. It is a standard method to support efficient dissemination of 3D content, and subsequent user search queries and manipulation of the same 3D content (Brinkman, 2008; Millington, 2010). The second change was designed to enhance the operation of the Complex Object. As conceived, Complex Objects are required to change their shape or surface appearance more or less in real time. Unfortunately, early implementations of our server stored model data in XML formats, and assumed expression of the model data in the Unity game engine. These actions resulted in Complex Objects that were hampered by slow search, retrieval, and expression of model iterations, as each model’s data was stored in a separate file. To fix this problem, Anderson and Tang devised a new server architecture that relies on an MySQL relational database to store and access model data, and a web services architecture to allow client software, be it Unity or something else, to access the data. Further, to support the multidimensional expression of model data – the expression of our MySQL data as 3D/4D buildings – Anderson and Tang appropriated object relational modelling technologies to map the stored data to the web service architecture. More specifically, they have integrated a specific ORM toolkit, Hibernate, into StructureMorph. With it, users will be able to view dynamic, four-dimensional Complex Objects functioning in real time using client software that can be implemented on any platform: PC, Mac, or mobile device.
With these revisions complete, we are now ready to shift to the beta stage of software development. Our development methodology here will continue to be iterative. One reason we are disseminating our work now is that we are looking for colleagues in digital history, digital archaeology, and cognate fields, such urban history and theatre history, to help us test and refine StructureMorph. We anticipate the completion of our beta version by the end of 2016. In the summer of 2016, however, we will also initiate the second phase of HistorySpace, the larger project of which StructureMorph was the first part. The second phase will be devoted to creating Narrative Objects, objects dedicated to the rapid and intuitive creation of spatial narratives in virtual worlds. The tool will support author specification of a narrative pathway, and then will facilitate the rapid annotation of audio, text, and 2D graphic content to nodes situated along the pathway. The tool will also enable authors to specify the sequence and duration of each content object that is situated on the pathway. Our final objective, which we will begin in 2017, will be the creation of Documentation Objects. Here the objective will be to build on the documentation capabilities afforded by StructureMorph. We foresee that future scholarly platforms will require documentation that goes beyond the textual and graphic descriptions of paradata afforded by StructureMorph and similar applications. We are planning to produce documentation that will appropriate formalisms from construction, such as Petri-Nets, and integrate them into text, 2D, and 3D representations of the structure’s paradata. Documentation Objects, in sum, will support the expression of multimodal “footnotes,” the building’s paradata.
Armstrong, Marc. (1995). Is there a role for high performance computing in GIS? Journal of the Urban and Regional Information Systems Association, 7(1), 7-10.
Baker, Drew. (2016). Defining paradata in heritage visualizations. In Hugh Denard, Anna Bentkowska-Kafel, & Drew Baker (Eds.), Paradata and transparency in virtual heritage (pp. 163-176). Farnham, UK: Ashgate Publishing.
Bennett, David A., & Tang, Wenwu. (2008). Mobile, Aware, Intelligent Agents (MAIA). In Kathleen Stewart Hornsby & May Yuan (Eds.), Understanding dynamics of geographic domains (pp. 171-186). Boca Raton, Florida: CRC Press.
Bodenhamer, David. (2010). The potential of spatial humanities. In David Bodenhamer, John Corrigan, & Trevor M. Harris (Eds.), The spatial humanities: GIS and the future of humanities scholarship (pp. 14-30). Bloomington, IN: Indiana University Press.
Bonnett, John. (2009). High-performance computing:
An agenda for the social sciences and the humanities in Canada. Digital
Studies, 1(2). URL:
http://www.digitalstudies.org/ojs/index.php
/digital_studies/article/view/168/211 [May 17, 2016].
Bonnett, John. (2015). A plea for design: Historians, digital platforms, and the mindful dissemination of content and concepts. Journal of the Canadian Historical Association, 25(2), 189-231.
Brinkmann, Ron. (2008). The art and science of digital compositing: Techniques for visual effects, animation and motion graphics. The Morgan Kaufmann Series in Computer Graphics. London, UK: Morgan Kaufmann.
Brynjolfsson, Erik, & McAfee, Andrew. (2014). The second machine age: Work, progress, and prosperity in a time of brilliant technologies. New York, NY: W.W. Norton Press.
CRANE. (n.d.). Home. Toronto, ON: University of Toronto. URL: https://www.crane.utoronto.ca [May 17, 2016].
Delve, Janet, Anderson, David, Dobreva, Milena, Baker, Drew, Billenness, Clive, & Konstantelos, Leo (Eds). (2012). The preservation of Complex Objects: Volume 1, visualisations and simulations. Portsmouth, UK: Portsmouth University.
Frischer, B., & Stinson, P. (2007, September). The importance of scientific authentication and a formal visual language in virtual models of archaeological sites: The case of the House of Augustus and Villa of the Mysteries. In Interpreting the past: Heritage, new technologies and local development (pp. 11-13). Proceedings of the Conference on Authenticity, Intellectual Integrity and Sustainable Development of the Public Presentation of Archaeological and Historical Sites and Landscapes Ghent, East-Flanders.
Guldi, Jo, & Armitage, David. (2014). The history manifesto. Cambridge, UK: Cambridge University Press.
Harris, Trevor M., Corrigan, John, & Bodenhamer, David J. (2010). Challenges for the spatial humanities: Toward a research agenda. In David Bodenhamer, John Corrigan, & Trevor M. Harris (Eds.), The spatial humanities: GIS and the future of humanities scholarship (pp. 167-176). Bloomington, IN: Indiana University Press.
Harris, Trevor M., Rouse, L. Jesse, & Bergeron, Susan. (2010). The geospatial semantic web, pareto GIS, and the humanities. In David Bodenhamer, John Corrigan, & Trevor M. Harris (Eds.), The spatial humanities: GIS and the future of humanities scholarship (pp. 124-142). Bloomington, IN: Indiana University Press.
Haughey, D. (2010). Waterfall v agile: How should I approach my software development project? (Unilever). Project Smart. URL: http://projectsmart.co.uk/waterfall-v-agile-how-should-i-approach-my-software-development-project.html [May 20, 2016]
Jockers, Matthew L. (2013). Macroanalysis: Digital methods and literary history. Urbana, IL: University of Illinois Press.
Kang, I., Park, Y., & Ki, Y. (2003). A framework for designing a workflow based knowledge map. Business Process Management Journal, 9(3), 281–294.
Kondratova, Irina, & Goldfarb, Ilya. (2003). Design concepts for virtual research and collaborative environments. In Proceedings of the 10th ISPE International Conference on Concurrent Engineering: Research and Applications, 26-30 July 2003, Madeira Portugal (pp. 797–803). Lisse, Portugal: Swets and Zeitlinger.
Kurzweil, Ray. (1999). The age of spiritual machine. New York, NY: Penguin Press.
Lock, Gary. (2010). Representations of space and place in the humanities. In David Bodenhamer, John Corrigan, & Trevor M. Harris (Eds.), The spatial humanities: GIS and the future of humanities scholarship (pp. 89–109). Bloomington, IN: Indiana University Press.
London Charter Interest Group. (2009). London charter for the computer-based visualisation of cultural heritage. URL: http://www.londoncharter.org/ [May 18, 2016].
Manning, Patrick. (2013). Big data in history. New York, NY: Palgrave Macmillan.
Millington, Ian. (2010). Game physics engine development. Burlington, MA: Morgan Kaufmann.
Peddie, Jon. (2001). Digital media technology: Industry trends and developments. In IEEE Computer Graphics and Applications, 21(1), 27–31.
Salisbury, M.W. (2003). Putting theory into practice to build knowledge management systems. Journal of Knowledge Management, 7(2), 128–141.
Stojanovic, Natalija, & Stojanovic, Dragan. (2013). High-performance processing of geospatial data on networks of workstations. International Journal of Reasoning-based Intelligent Systems, 5(1), 42–49.
UQAM. (n.d.). Montréal: plaque tournante des échanges; histoire, patrimoine, devenir. Montreal, QC: Université du Québec à Montréal. URL: https://lhpm.uqam.ca/montreal-plaque-tournante.html [May 18, 2016].
Yuan, May, & Hornsby, Kathleen. (2008). Computation and visualization for understanding dynamics in geographic domains. Boca Raton, FL: CRC Press.
CISP Press
Scholarly and Research Communication
Volume 7, Issue 2, Article ID 0201253, 15 pages
Journal URL: www.src-online.ca
Received June 1, 2016, Accepted July 4, 2016, Published November 8, 2016
Bonnett, John, Anderson, Mark, Tang, Wei, Farrimond, Brian, & Robichaud, Léon. (2016). StructureMorph: Creating Scholarly 3D Models for a Convergent, Digital Publishing Environment. Scholarly and Research Communication, 7(2): 0201253, 15 pp.
© 2016 John Bonnett, Mark Anderson, Wei Tang, Brian Farrimond, & Léon Robichaud. This Open Access article is distributed under the terms of the Creative Commons Attribution Non-Commercial License (http://creativecommons.org/licenses/by-nc-nd/2.5/ca), which permits unrestricted non-commercial use, distribution, and reproduction in any medium, provided the original work is properly cited.