Science, Irving K. Barber Faculty of (Okanagan)
Computer Science, Mathematics, Physics and Statistics, Department of (Okanagan)
DSpace
UBCO
Fritter, Matthew Stanley
Master of Science - MSc
University of British Columbia
The field of Life Cycle Assessment (LCA) models the resource flows and emissions characteristic of real-world industrial, agricultural, and economic activities through the use of Life Cycle Inventory (LCI) datasets. As the amount of data available to LCA practitioners through national and commercial database initiatives increases, there have been growing concerns within the LCA community regarding the interoperability of LCI data. Choice of data format and nomenclature poses problems for re-usability, as a dataset may not cleanly integrate into an LCA model due to differences in nomenclature, or a practitioner’s LCA software may simply not recognize the format type. This interoperability has been identified as one of the largest problems, along with data availability, in the LCA field. The focus of this research was the development of a new national Life Cycle Inventory database: The Canadian Agri-food Life Cycle Data Center (CALDC), which will serve as a central repository for Canadian agri-food data. During the course of the research, information was solicited from existing LCA database providers to inform development, and potential solutions for the interoperability issues were researched and implemented within the CALDC. The development included a searchable public database repository, as well as a web application that allows users to create, modify, and publish new LCI datasets, known as SimpLCIty. A set of recommendations were drafted for new LCI database initiatives, with the goal of increasing the interoperability between databases and datasets and increasing the availability of data. These recommendations were used in the development of the CALDC, and also present potential future avenues for expansion and development, such as the implementation of Application Programming Interfaces (APIs) or the re-distribution of datasets through third-party data providers and initiatives. The Canadian Agri-food Life Cycle Data Centre is now live, and is currently being used by researchers at both UBC and external stakeholder partners such as the Canadian Roundtable for Sustainable Beef (CRSB) to create and publish new publicly available agri-food data for LCA research.
Development of the CanadianAgri-food Lifecycle Data Centre withData Format InteroperabilityRequirementsbyMatthew Stanley FritterB.A., The University of British Columbia, 2017A THESIS SUBMITTED IN PARTIAL FULFILLMENT OFTHE REQUIREMENTS FOR THE DEGREE OFMASTER OF SCIENCEinTHE COLLEGE OF GRADUATE STUDIES(Computer Science)THE UNIVERSITY OF BRITISH COLUMBIA(Okanagan)August 2020© Matthew Stanley Fritter, 2020The following individuals certify that they have read, and recommendto the College of Graduate Studies for acceptance, a thesis/dissertation en-titled:Development of the Canadian Agri-food Lifecycle DataCentre with Data Format Interoperability Requirementssubmitted by Matthew Stanley Fritter in partial fulfilment of the re-quirements of the degree of Master of ScienceDr. Nathan Pelletier, I. K. Barber School of Arts & Sciences, Faculty of ManagementSupervisorDr. Ramon Lawrence, I. K. Barber School of Arts & SciencesCo-SupervisorDr. Yves Lucet, I. K. Barber School of Arts & SciencesSupervisory Committee MemberDr. Barb Marcolin, Faculty of ManagementSupervisory Committee MemberDr. Ying Zhu, Faculty of ManagementUniversity ExamineriiAbstractThe field of Life Cycle Assessment (LCA) models the resource flowsand emissions characteristic of real-world industrial, agricultural, and eco-nomic activities through the use of Life Cycle Inventory (LCI) datasets.As the amount of data available to LCA practitioners through nationaland commercial database initiatives increases, there have been growing con-cerns within the LCA community regarding the interoperability of LCI data.Choice of data format and nomenclature poses problems for re-usability, asa dataset may not cleanly integrate into an LCA model due to differencesin nomenclature, or a practitioner’s LCA software may simply not recog-nize the format type. This interoperability has been identified as one of thelargest problems, along with data availability, in the LCA field.The focus of this research was the development of a new national LifeCycle Inventory database: The Canadian Agri-food Life Cycle Data Center(CALDC), which will serve as a central repository for Canadian agri-fooddata. During the course of the research, information was solicited from exist-ing LCA database providers to inform development, and potential solutionsfor the interoperability issues were researched and implemented within theCALDC. The development included a searchable public database repository,as well as a web application that allows users to create, modify, and publishnew LCI datasets, known as SimpLCIty.A set of recommendations were drafted for new LCI database initia-tives, with the goal of increasing the interoperability between databases anddatasets and increasing the availability of data. These recommendationswere used in the development of the CALDC, and also present potentialfuture avenues for expansion and development, such as the implementa-tion of Application Programming Interfaces (APIs) or the re-distribution ofdatasets through third-party data providers and initiatives.The Canadian Agri-food Life Cycle Data Centre is now live, and is cur-rently being used by researchers at both UBC and external stakeholderpartners such as the Canadian Roundtable for Sustainable Beef (CRSB) tocreate and publish new publicly available agri-food data for LCA research.iiiLay SummaryThis research proposes and implements a new central database, knownas the Canadian Agri-Food Life Cycle Data Centre (CALDC), which allowsusers to both contribute and access publicly available life cycle inventorydatasets. These datasets describe the inputs and outputs of agricultural andindustrial processes. Often, such datasets variously utilize one of several dif-ferent, incompatible formats and naming systems. The datasets producedby the CALDC are designed to support multiple formats, be easily interop-erable with different kinds of LCA software, and can be published publiclyon the database, allowing data needed to model agricultural emissions to beeasily created, shared, accessed, and used by researchers free of charge.ivPrefaceThis thesis, including all diagrams, tables, research, and resultant soft-ware is the original work of the author, M.S. Fritter. The initial thesisproposition and objectives were developed by Dr. Nathan Pelletier as notedin Chapter 3.1.Chapters 2, 3, 4, and 6 have been summarized and published in the June2020 article ”A survey of Life Cycle Inventory database implementationsand architectures, and recommendations for new database initiatives” in theInternational Journal of Life Cycle Assessment (Springer), based on originalresearch and analysis work by M.S. Fritter, with editorial and proofreadingcontributions by Dr. Ramon Lawrence, Dr. Barbara Marcolin, and Dr.Nathan Pelletier.This work was supported with funds from the Natural Sciences and En-gineering Research Council of Canada (NSERC)/Egg Farmers of Canada(EFC) Industrial Research Chair in Sustainability.vTable of ContentsAbstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iiiLay Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ivPreface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vTable of Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . viList of Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ixList of Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xAcknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . . xiiDedication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiiiChapter 1: Introduction . . . . . . . . . . . . . . . . . . . . . . . 1Chapter 2: Background . . . . . . . . . . . . . . . . . . . . . . . 32.1 LCA Methodologies . . . . . . . . . . . . . . . . . . . . . . . 32.2 The Life Cycle Inventory . . . . . . . . . . . . . . . . . . . . . 52.3 Interoperability in LCI . . . . . . . . . . . . . . . . . . . . . . 82.3.1 Existing LCI Data Formats . . . . . . . . . . . . . . . 82.3.2 Other Interoperability Issues . . . . . . . . . . . . . . 92.4 Third Party Database Initiatives and Programs . . . . . . . . 102.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13Chapter 3: Methodology . . . . . . . . . . . . . . . . . . . . . . 153.1 Initial Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 153.2 Technical Considerations . . . . . . . . . . . . . . . . . . . . . 163.3 Interoperability Requirements . . . . . . . . . . . . . . . . . . 183.4 Third Party Providers & Initiatives . . . . . . . . . . . . . . . 19viTABLE OF CONTENTS3.5 Development & Testing . . . . . . . . . . . . . . . . . . . . . 193.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22Chapter 4: Implementation . . . . . . . . . . . . . . . . . . . . . 234.1 Technical Findings . . . . . . . . . . . . . . . . . . . . . . . . 234.1.1 Existing LCI Databases . . . . . . . . . . . . . . . . . 234.1.2 Formats & Nomenclatures . . . . . . . . . . . . . . . . 254.2 Software & Architecture Choice . . . . . . . . . . . . . . . . . 284.2.1 Web Application . . . . . . . . . . . . . . . . . . . . . 284.2.2 Database . . . . . . . . . . . . . . . . . . . . . . . . . 294.2.3 Stack Architecture . . . . . . . . . . . . . . . . . . . . 304.2.4 Database Design . . . . . . . . . . . . . . . . . . . . . 314.3 Security & Maintenance Considerations . . . . . . . . . . . . 344.4 Development Timeline . . . . . . . . . . . . . . . . . . . . . . 37Chapter 5: Features . . . . . . . . . . . . . . . . . . . . . . . . . 395.1 Application Workflow . . . . . . . . . . . . . . . . . . . . . . 395.2 Feature Walkthrough . . . . . . . . . . . . . . . . . . . . . . . 415.2.1 Logging In . . . . . . . . . . . . . . . . . . . . . . . . 425.2.2 User Home Page . . . . . . . . . . . . . . . . . . . . . 425.2.3 Additional User Options . . . . . . . . . . . . . . . . . 435.2.4 Browsing Datasets . . . . . . . . . . . . . . . . . . . . 435.2.5 Viewing Datasets . . . . . . . . . . . . . . . . . . . . . 445.2.6 Managing Datasets . . . . . . . . . . . . . . . . . . . . 455.2.7 Creating a New Dataset . . . . . . . . . . . . . . . . . 465.2.8 Editing a Dataset . . . . . . . . . . . . . . . . . . . . 475.2.9 Exporting a Dataset . . . . . . . . . . . . . . . . . . . 495.2.10 Importing a Dataset . . . . . . . . . . . . . . . . . . . 515.2.11 Support Page . . . . . . . . . . . . . . . . . . . . . . . 525.2.12 Managing User Settings . . . . . . . . . . . . . . . . . 525.2.13 Submitting User Feedback . . . . . . . . . . . . . . . . 535.2.14 Using the Admin Console . . . . . . . . . . . . . . . . 545.2.15 Public CALDC Homepage . . . . . . . . . . . . . . . . 565.2.16 Navigating the Public CALDC . . . . . . . . . . . . . 585.2.17 Viewing and Downloading Public Datasets . . . . . . 59Chapter 6: Discussion and Recommendations . . . . . . . . . . 636.1 Interoperability Recommendations . . . . . . . . . . . . . . . 646.2 Technical Recommendations . . . . . . . . . . . . . . . . . . . 676.3 Third Party Data Providers and Initiatives Recommendations 68viiTABLE OF CONTENTSChapter 7: Conclusion . . . . . . . . . . . . . . . . . . . . . . . . 69Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78Appendix A: Risk Assessment . . . . . . . . . . . . . . . . . . . . . 78A.1 Injection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78A.2 Broken Authentication . . . . . . . . . . . . . . . . . . . . . . 79A.3 Sensitive Data Exposure . . . . . . . . . . . . . . . . . . . . . 79A.4 XML External Entities . . . . . . . . . . . . . . . . . . . . . . 80A.5 Broken Access Control . . . . . . . . . . . . . . . . . . . . . . 80A.6 Security Misconfiguration . . . . . . . . . . . . . . . . . . . . 81A.7 Cross-Site Scripting . . . . . . . . . . . . . . . . . . . . . . . 81A.8 Insecure Deserialization . . . . . . . . . . . . . . . . . . . . . 82A.9 Using Components with Known Vulnerabilities . . . . . . . . 82A.10 Insufficient Logging & Monitoring . . . . . . . . . . . . . . . 83viiiList of TablesTable 4.1 Three major LCI databases compared. . . . . . . . . . 25Table 4.2 Average and Maximum Sizes of Datasets by Type. . . 33Table 5.1 Summary of Features and Permissions. . . . . . . . . . 41Table 6.1 Total Counts as of July 2020. . . . . . . . . . . . . . . 64Table 6.2 Recommendations for LCI Database Initiatives. . . . . 65Table A.1 Injection Risks. . . . . . . . . . . . . . . . . . . . . . . 78Table A.2 Broken Authentication Risks. . . . . . . . . . . . . . . 79Table A.3 Sensitive Data Exposuren Risks. . . . . . . . . . . . . 79Table A.4 XML External Entities. . . . . . . . . . . . . . . . . . 80Table A.5 Broken Access Control. . . . . . . . . . . . . . . . . . . 80Table A.6 Security Misconfiguration. . . . . . . . . . . . . . . . . 81Table A.7 Cross-Site Scripting. . . . . . . . . . . . . . . . . . . . 81Table A.8 Insecure Deserialization. . . . . . . . . . . . . . . . . . 82Table A.9 Using Components with Known Vulnerabilities. . . . . 82Table A.10 Insufficient Logging & Monitoring. . . . . . . . . . . . 83ixList of FiguresFigure 3.1 Typical Web Software Stack . . . . . . . . . . . . . . 17Figure 4.1 CALDC Software Stack . . . . . . . . . . . . . . . . . 31Figure 4.2 CALDC Database Tables . . . . . . . . . . . . . . . . 32Figure 5.1 Public-facing Web User Flow . . . . . . . . . . . . . . 40Figure 5.2 Private-facing Web User Flow . . . . . . . . . . . . . 42Figure 5.3 CALDC Splash Page . . . . . . . . . . . . . . . . . . 43Figure 5.4 SimpLCIty Home Page . . . . . . . . . . . . . . . . . 44Figure 5.5 User Menu . . . . . . . . . . . . . . . . . . . . . . . . 44Figure 5.6 Dataset Browser . . . . . . . . . . . . . . . . . . . . . 45Figure 5.7 Viewing a Dataset . . . . . . . . . . . . . . . . . . . . 46Figure 5.8 Dataset Completion Message . . . . . . . . . . . . . . 46Figure 5.9 Empty Dataset Value Warnings . . . . . . . . . . . . 47Figure 5.10 Viewing ILCD Reference Flows . . . . . . . . . . . . . 47Figure 5.11 Dataset Actions . . . . . . . . . . . . . . . . . . . . . 48Figure 5.12 Dataset Dependencies . . . . . . . . . . . . . . . . . . 48Figure 5.13 Dataset Creation Selection . . . . . . . . . . . . . . . 49Figure 5.14 Dependency Warning . . . . . . . . . . . . . . . . . . 49Figure 5.15 Editing Interface . . . . . . . . . . . . . . . . . . . . . 50Figure 5.16 Placeholders and Tooltips . . . . . . . . . . . . . . . . 51Figure 5.17 Input Validation . . . . . . . . . . . . . . . . . . . . . 51Figure 5.18 Exchange Interface . . . . . . . . . . . . . . . . . . . 52Figure 5.19 Confirmation Page . . . . . . . . . . . . . . . . . . . . 52Figure 5.20 Export Dialog . . . . . . . . . . . . . . . . . . . . . . 53Figure 5.21 Exported Files . . . . . . . . . . . . . . . . . . . . . . 54Figure 5.22 Import Interface . . . . . . . . . . . . . . . . . . . . . 55Figure 5.23 Support Page . . . . . . . . . . . . . . . . . . . . . . 56Figure 5.24 User Settings . . . . . . . . . . . . . . . . . . . . . . . 56Figure 5.25 Feedback Form . . . . . . . . . . . . . . . . . . . . . . 57Figure 5.26 Feedback Submission Message . . . . . . . . . . . . . 57xLIST OF FIGURESFigure 5.27 Submissions Table . . . . . . . . . . . . . . . . . . . . 58Figure 5.28 Administrator Actions . . . . . . . . . . . . . . . . . 58Figure 5.29 Approved Datasets . . . . . . . . . . . . . . . . . . . 59Figure 5.30 Adding Administrators . . . . . . . . . . . . . . . . . 59Figure 5.31 Public Datasets Access . . . . . . . . . . . . . . . . . 60Figure 5.32 CALDC Public Homepage . . . . . . . . . . . . . . . 60Figure 5.33 Viewing Public Datasets . . . . . . . . . . . . . . . . 61Figure 5.34 Exploring a Public Dataset . . . . . . . . . . . . . . . 61Figure 5.35 Downloading Public Datasets . . . . . . . . . . . . . . 62Figure 5.36 ILCD Reference Flow in Public Viewer . . . . . . . . 62xiAcknowledgementsI would like to acknowledge the help and guidance provided to me byProf. Lawrence and Prof. Pelletier, without whom this thesis would not havebeen possible. I would also like to thank Prof. Lucet and Prof. Marcolin fortheir role on my graduate committee, and Prof. Fazackerley, Prof. Nastos,and Prof. Ould-Khessal for their continuing camaraderie.Thank you also to Davoud Heidari, Ian Turner, and Vivek Arulnathan,my fellow PRISM lab researchers who contributed much to the developmentand testing of our software and whose feedback and insight was invaluable.I would also like to thank all those who offered me insight into the worldof Life Cycle Assessment, in particular Peter Arbuckle of the US Departmentof Agriculture, who has been an invaluable resource in this research.xiiDedicationTo my friends, my family, my coworkers, and my students who haveaccompanied me on this academic journey and have wished me luck.xiiiChapter 1IntroductionLife Cycle Assessment (LCA) is a heavily data-reliant approach to mod-elling resource flows and emissions associated with the production and useof products and/or services, primarily for industrial and agricultural pro-duction. This technique allows entire supply chains to be modelled andthe resulting emissions to be measured and aggregated into useful metrics.The development and distribution of datasets used in these models are con-tributed to by both public researchers and commercial businesses; most LCApractitioners choose to make use of a dedicated Life Cycle Inventory (LCI)database to support their modelling [CF06] – in particular with respect toinputs to the product system of interest. Such databases have been devel-oped at both national and international levels, both as publicly availableresources and commercially licensed products.Although Life Cycle Assessment was conceived as a field in the 1960’s,and developed throughout the 1980’s and 1990’s [HBOM17], there has beenrelatively little standardization in terms of data exchange formats, nomen-clature, and technical implementation of LCI databases. Those standardsthat do exist such as ISO 14048, are broad enough that interoperabilitybetween two claimed ISO 14048-compliant LCI data sources may be poor.The lack of shared best practices in the production and formatting of LCIdata is believed to have negatively impacted both the interoperability of thedatasets, and their reusability [RBF+15]. As LCI datasets can potentiallycontain a large amount of data that is usually manually entered, the cost toproduce these datasets, in terms of time and effort, is not trivial. Therefore,by promoting interoperability with different dataset formats and nomencla-tures, the overall cost in time can be reduced and the sharing of LCI datais encouraged.To date, there have been few LCI databases developed specifically forCanadian data. A provincial LCI database was developed for Quebec as partof the much larger ecoinvent commercial LCI database [LS16]; at a nationallevel the Canadian Raw Materials Database (CRMD) provides LCI data forthe aluminum, glass, plastics, steel, and lumber commodity industries, withdata collection up to 1998 [oW]. This means that much of the Canadian1Chapter 1. Introductionagri-food sector outside of Quebec does not have a data repository to ac-cess or to contribute to, even as new LCI datasets are being created. TheFood Systems Priority Research for Integrated Sustainability Management(PRISM) Lab at the University of British Columbia Okanagan campus hasproposed to fill this gap through the development of a new LCI database,the Canadian Agri-food Life Cycle Data Centre (CALDC). The proposeddatabase would provide a public repository for Canadian agri-food LCI data,allowing for the development of accurate life cycle models to support sustain-ability measurement and management initiatives in the Canadian agri-foodindustry [Pel].This thesis describes the goals, methods, and implementation of the newCALDC database, as well as general observations of the current state of LCIdatabases and recommendations for the development of new, interoperableLCI data sources. It also suggests some features, now common in certain as-pects of commercial web data applications and analysis, that may be imple-mented in future LCI databases to further promote good data managementand sharing practices. The contributions of this thesis include a study ofthe major interoperability issues existent between major data formats; thedevelopment, testing, and initial release of the new CALDC database; andthe development of a set of recommendations for further interoperability inLCI data sources. Chapter two provides a background on the field of LifeCycle Assessment and its data sources, the interoperability and usabilityconcerns that the LCI field currently faces, and the objectives of CALDCdevelopment. Chapter three discusses the methodology used for the devel-opment of the CALDC and LCI database recommendations. Chapters fourand five cover the technical findings and chosen technical implementation forthe CALDC, in addition to a walkthrough of workflow and features imple-mented. Chapter six discusses current trends in LCI database development,and further recommendations for LCI databases.2Chapter 2BackgroundIn developing a new LCI database, it is necessary to consider that themethodology and standards used in LCA practice can vary widely. It is alsonecessary to understand the different datasets that make up a typical LCAmodel, as this affects which necessary data and metadata must be accom-modated within the LCI database. This chapter covers the background ofLCA methodology and LCI datasets, as well as covering the interoperabil-ity challenges that have been identified in the LCI field, and existing LCIdatabase implementations.2.1 LCA MethodologiesAlthough the concept of performing a holistic analysis of inputs, out-puts, emissions, and wastes for industrial processes that is now known asLCA was developed almost five decades ago, the framework, methodologies,and standards for this analysis remain in development to the present day.The Midwest Research Institute was a primary source of initial LCA studiesduring the late 1960’s and early 1970’s, known at the time as Resource andEnvironmental Profile Analysis (REPA) [GHH+11]. However, it has beensuggested that these were generally unpublished internal corporate studiesof narrow scope, done during a time when LCA/REPA was primarily com-pany driven. By the latter half of the 1970’s this corporate drive was beingsuperseded by regulatory and compliance goals for LCA research [MT15].However, no common methodology, terminology, or framework was devel-oped for LCA until the 1990’s, creating a chaotic period between 1970 and1990 that Guine´e et al. suggest prevented the more widespread adoption ofLCA, due to unreliable or irreproducible results produced by studies duringthis period [GHH+11].By the early 1990’s, a movement towards the development and adop-tion of a common set of standards and methodologies was underway. Thiswas led in part by the creation of the Society of Environmental Toxicologyand Chemistry (SETAC) in 1989, whose early standards for retrospectiveanalysis formed part of both regulatory policy and the original 1997 ISO32.1. LCA Methodologies14040 standards for LCA frameworks [MT15]. Concurrently, the Nether-lands sponsored a study on LCA standardization through the National Reuseof Waste Research Programme. This culminated in the 1992 publishing ofthe Environmental LCA of Products guide by the Centre of EnvironmentalScience at Leiden University [dBG02]. Following further research by SETACand subsequent revisions of ISO 14040 in 1997, the Handbook on LCA waspublished in 2002 as a successor to the original 1992 guide [dBG02]. A setof guidelines for LCA methodology were similarly developed in Denmarkbetween 1997 and 2003; these were developed for the Danish EnvironmentalProtection Agency, and were designed to provide greater detail than exist-ing standards [Wei03]. Additional effort was made to improve the existingstandards, resulting in the release of a 2006 revision for ISO 14040, and theintroduction of the new and more popular ISO 14044 standard. The 14044standard encompassed all the requirements of previous ISO LCA standards,while improving readability and consistency to create a set of requirementsand guidelines for LCA study [FIT+06].While there has been a proliferation of LCA standards, guidelines, andmethodologies since the 1990’s, there remain unresolved issues that have pre-vented adoption of a single LCA framework or methodology. Contentiousissues include the acceptability of market mechanisms within LCA models,and the value of attributional versus consequential methodologies in LCA.Consequential modeling methodology is aimed at determining the environ-mental consequences of a given decision, including indirect economic effectsand market pressures. This necessitates the use of system expansion andsubstitution to avoid multi-functionality problems [PAB+15]. Although ISO14044 provides a hierarchy for allocation, the lack of consensus on alloca-tion procedure has been recognized as a problem in LCA, particularly inindustries where multi-functional systems are common [KL14]. Similarly,the Dutch and Danish guidelines for LCA are split over the issue of in-cluding market data. The use of monetary value of outputs as a functionalunit or as a means of allocating emissions based on product values has beencontentious; with Guine´e et al. arguing that market mechanisms are out-side the scope of LCA [dBG02], while Weidema supports the use of marketmechanisms in LCA [Wei03].Beyond the development of LCA frameworks and methodologies, an areaof particular interest is the development of LCI databases. Data availabilityand quality has been classified as one of the most severe problems facingLCA, a problem compounded by a lack of established data quality analysisstandards for LCI data [RRDB08a]. Current LCI databases either tend tobe generic databases such as ecoinvent or GaBi, or are limited to a specific42.2. The Life Cycle Inventorysector or product; variances between generic and sector-specific databasevalues such as data localization and aggregation can result in drasticallydeviating results for the same model [LHPC15]. Agri-food LCA also posesunique challenges, commonly involving multi-functional systems that de-mand expansion or allocation, as well as requiring geospatially accurate datato account for different agriculture situations within a region [NSA+17].2.2 The Life Cycle InventoryIn terms of time and monetary expense, the development of the LCI isusually the most involved phase within a LCA study. Following the defini-tion of the project goal and scope, the LCI phase includes enumerating anddiagramming all unit processes within the system boundaries, the collectionand validation of process data, as well as the identification and justifica-tion of modelling decisions such as cut-off criteria or allocation methods[dBG02]. However, modelling decisions and data must be approached withcaution during this phase, as uncertainties in the data, choice of arbitrarycut-off criteria, or issues with allocation methodology can result in signif-icant errors in final analysis [RRDB08b] [RRDB08a]. ISO 14044 includesrequirements for data validation, sensitivity analysis when refining systemboundaries, and documentation of anomalies in the data or special caseswithin the system [ISO06], potentially avoiding errors or clearly and trans-parently documenting where modelling decisions have been made that couldinfluence the results of the assessment.The initial step in the LCI phase is the identification of unit processeswithin the product system(s), including all input, output, waste, and en-ergy flows associated with them, in terms of the functional unit, which isused as the metric for analysis; for example, an output volume in units orweight of the final product. A single unit process may contain several activ-ities, and is linked to other unit processes via intermediate flows [REF+04].A flow diagram is created showing the unit processes that fall within thesystem boundary and the intermediate flow relationships between them, aswell as inputs and outputs that cross the system boundary; this can be donewith aggregate processes for simplified LCA, or iteratively developed intoa more detailed model [dBG02]. Branching and looping in the flow chartthat represents multifunctional or recycling processes should be accountedfor either through system expansion or allocation [KG14]. Processes can bedefined as either foreground processes that are specific to the system beingstudied, over which the producer or operator has influence, and background52.2. The Life Cycle Inventoryprocesses that are not specific to the system and which are not influenced bythe producer or operator [JI10]. Foreground and background classificationof processes can help determine the appropriate type of data to use. Al-though the Handbook on LCA suggests avoiding generic datasets, they areoften appropriate for background processes involving homogenous marketcommodities where specific data for a given producer may be unavailable[KG14].Following the development of a satisfactory flow diagram, the processof data collection can begin. ISO standards require that the data collec-tion process be documented, including referencing any public datasets, datacollection times and techniques, and data quality markers [ISO06]. Whilethe standard specifies that metadata such as geographic location, temporalcoverage, and sources should be included in data quality requirements, itprovides no specific format or nomenclature with which to address these re-quirements. As a result, several standards for metadata documentation anddata transfer have been developed within LCA practice, such as the SPOLDformat and the database-oriented SPINE format; ISO 14048 has furtheritemized appropriate metadata for LCA datasets [REF+04]. The data it-self (known as computable data) quantifies the process or elementary flows,whether they be in materials, energy, transport, or economic value, while themetadata describes the actual object of the flow and how the computabledata was collected or generated [CTSL98]. The data may be classified intotypes of inputs, such as energy, raw material, or ancillary inputs, outputssuch as products and waste, or emissions to environmental compartments[dBG02]. Environmental compartments serve as categorizations for inputs,outputs, and emissions of the product system, although there may be com-plicated relationships between compartments as emissions travel from one tothe other through evaporation, condensation, or leaching; the typical threecompartments of air, water, and soil may also be split into more specificsub-compartments such as surface soil or root-zone soil [vZLLR14]. Bound-aries may also be drawn between system inputs and emissions between theecosphere and the technosphere, although these boundaries may be difficultto determine in an agricultural context [vZLLR14]. Data availability andthe need for spatially specific data remain among the most severe problemsin LCA [RRDB08b].The data collected during the LCI phase must be validated and assessedfor quality and uncertainty. The data should meet the data quality require-ments set out during the Goal and Scope Definition phase of the study,and missing data or obvious anomalies should be substituted with justifi-able values or alternative data [ISO06]. The Handbook on LCA suggests62.2. The Life Cycle Inventoryboth quantitative measures of data quality, such as precision and complete-ness, alongside qualitative metrics such as consistency, reproducibility, andrepresentativeness [dBG02]. Uncertainties or dispersions in the data setsshould be known, and may be quantified through additional metrics suchas the NUSAP pedigree approach; these can be propagated in analysis us-ing the Monte Carlo method, Latin Hypercube, fuzzy logic, or other means[HGH+14]. However, uncertainty remains a problem, particularly in com-parative analysis where some uncertainty may be shared; the use of relativecertainties for untraceable commodities and dependent sampling have beensuggested to help reduce the uncertainty associated with averaged or pointdata [HHD+15].Having validated the collected data, the LCI phase can conclude with theactual calculation of the inventory. This is usually done using LCA-specificsoftware for matrix calculations, and scales all processes in the system suchthat their output is in terms of the functional unit [dBG02]. Software canalso be used to determine stable values for infinite process loops that mightexist within the system [JI10]. At this point, the study may proceed ontoLife Cycle Impact Assessment (LCIA), or it may iterate back into datacollection, should the system boundaries be refined or it is determined thatmore data is required [ISO06]. The scope of the study may require refiningfrom the initial definition; this includes the system boundary and cut-offcriteria, which may be iteratively re-determined until a satisfactory resultis produced [JI10]. However, it is also pointed out that if data has alreadybeen collected that causes the cut-off to be re-evaluated, it may simplybe best to keep the data anyways [RRDB08a]. A compromise would beusing estimated data for less-relevant processes that might fall outside cut-off boundaries, and saving the time and expense of finding data for morerelevant, foreground processes [JI10].LCI databases play a key role in performing LCA research, providingthe base datasets used to model common inputs to more complex productsystems. However, the diverse ecosystem of LCI databases, including com-mercial, national, and regional databases, has led to the adoption of a varietyof non-interchangeable data formats and implementations. This has provedto be a major problem in the LCA field [KDRJ16]. Initiatives such as theUNEP Global LCA Data Access Network aim to improve LCI database in-teroperability and access, allowing greater access and compatibility betweenLCI data sources [UNE17]. As previously mentioned, data gaps also pose asevere problem in the LCA field [RRDB08b].72.3. Interoperability in LCI2.3 Interoperability in LCIDue to the lack of cohesive standards for both LCI methodology andLCI formatting, there can be issues of interoperability between datasetsproduced using different modelling criteria, or produced by different LCAsoftware suites. In developing a new public LCI database resource, it be-comes necessary to consider how to maximize the interoperability of thedatasets provided so that they can be of maximum utility to the LCA com-munity.Interoperability between the various LCI databases and LCA softwarecurrently in use presents a major field of study in LCA. Interoperabilityissues in LCI data have been tied to the general problem of data avail-ability, specifically that relevant datasets may exist, but cannot be useddue to interoperability issues [IHT+15]. The issue of data availability hasbeen considered the most pressing concern facing the LCA field [RRDB08b].This issue has been identified since at least 1998, when SETAC noted thatthe technical systems for LCI data exchange required further development[Bre99]. Since then numerous new databases and exchange formats havebeen introduced, but interoperability remains a problem.2.3.1 Existing LCI Data FormatsCurrently, there are two major data exchange formats that are usedby most life cycle inventory databases: the EcoSpold format, further splitinto two revisions; and the International Reference Life Cycle Data System(ILCD) format. Other older formats exist, such as SPINE, but uptake ofthese formats has been minimal hence they have not been further considered.Similarly, ISO/TS 14048 provides guidelines for LCI format compliance, butreal-world use is limited. Some mappings for less common exchange formats,such as SPINE to ISO 14048 have been published [CEF+03].The EcoSpold format is the successor to the older SPOLD97 and SPOLD99data exchange formats developed by the Society for the Promotion of Life-cycle Development as a means of standardizing data exchange betweendatabases [Cur04], in compliance with the ISO/TS 14048 specifications forLCI data documentation format [Kel07]. A revised version of the format,EcoSpold2, was developed and introduced, replacing EcoSpold1 as the for-mat for the ecoinvent database in May 2013 [MMBV16].Development of the ILCD began in 2005 under the European Commis-sion Joint Research Center (JRC), and comprises a collection of technicalguidance documents that cover the whole of the LCA process. The ILCD82.3. Interoperability in LCIsimilarly claims to be ISO 14048 compliant [WPC+12]. Development of theILCD was driven by the need for greater consistency and quality in LCIdata and the lack of a suitable format conducive to achieving these goals[WDK11]. Wolf et al. (2011) note that data formats such as SPINE andISO/TS 14048 did not achieve widespread uptake. They also argue thatEcoSpold, while popular, lacks unique identifiers, full multi-language sup-port, and has limited documentation abilities for some LCI methods (2011).The project includes documentation for the naming and classification offlows [JI10], in addition to development, formatting, and validation toolsprovided through the JRC Life Cycle Data Network (LCDN) [JI18].The EcoSpold and ILCD data exchange formats are both based on theExtensible Markup Language (XML) data encoding, and both have theirown editors for creating datasets, the EcoEditor and ILCD Editor respec-tively. However, it has been noted that these editors can be difficult to use,increasing the time and expense of generating compliant datasets. Whilemoving to a single dataset editing system would help alleviate the prob-lems of interoperability between datasets and reduce the expense of creatingdatasets using exiting editors, this would again require a consensus amongthe LCA community on using a singular data model and editing workflow;whether this is feasible remains to be seen. The underlying XML encodingwas developed to support a wide array of data exchange tasks while beinghuman-readable and easy to process [BPSM+08]. This shared data encodinghas allowed for conversion between EcoSpold 1, EcoSpold 2, and ILCD dataformats [Ope15]. However it has been noted that while much of the rele-vant data can be mapped between the EcoSpold and ILCD formats, somefields have no equivalent, and metadata may be lost between conversions.For example, the ILCD format has no equivalent fields for the EcoSpold2mandatory ‘Type’ and ‘Special Type’ fields, so an ILCD-to-EcoSpold2 con-version would result in those fields being lost. This has been improved withEcoSpold 2 but remains a problem [MMBV16], presenting a persistent bar-rier to interoperability.2.3.2 Other Interoperability IssuesEven if a singular LCI data exchange format could be adopted, or datasetscould be seamlessly converted between formats, other interoperability con-cerns may prevent datasets from working correctly. In this context, nomen-clature provides the references required to use the dataset effectively: namesof flows, units of measurement, directionality of flow, impacted environ-mental compartments, and other key properties of the dataset [EIR+17].92.4. Third Party Database Initiatives and ProgramsDifferences in nomenclature can cause interoperability issues, even betweendatasets with the same syntax. A simplified example of this would be twoflows of identical format but differing nomenclature, one requiring an in-put of acetone, the other producing an output of propan-2-one, the IUPACnomenclature for acetone. LCA software could not be relied upon to de-termine that acetone and propan-2-one are semantically identical, and as aresult it would fail to link the two flows together.2.4 Third Party Database Initiatives andProgramsBeyond individual LCI databases, there has been a trend towards thedevelopment of distributed LCI data networks and third-party LCI dataproviders. The consolidation of LCI data into networks and third-partyrepositories has the effect of ensuring some level of compatibility in for-mat, while also addressing the problem of data availability that has beenidentified in the LCA field [RRDB08a]. This is being done both at the in-stitutional level, through initiatives such as the Life Cycle Data Network(LCDN) developed by the JRC-EPLCA, and through private and commer-cial organizations such as OpenLCA and ecoinvent.The LCDN service uses a node-based approach, with individual databasesand providers maintaining their own locally hosted nodes using a J2EEservlet environment and MySQL database, coupled with the Soda4LCApackage [FKL16]. Individual nodes form a network, with each node sharingan identical interface for searching and browsing the datasets within thenode, and the LCDN maintaining a list of all published datasets and theirrespective nodes [FKL16]. At present, nodes have been registered for theAgri-footprint and GaBi commercial databases, in addition to the ELCD,Italian National LCI Database, and others. Minimum requirements for entryinto the LCDN are ILCD syntax and nomenclature compliance, with plans tointroduce data quality, documentation, and review validation requirementsin the future [JI12]. While this cleanly solves the interoperability problemin terms of nomenclature and format, it moves the burden of ensuring inter-operability from the LCA practitioner to the data provider. This shift couldpotentially limit the data uptake of the LCDN, as even with automatedtools, extensive manual intervention, and thus expense, would be requiredto convert non-compliant datasets. If the expense is not justifiable, the datamay simply be omitted from the database altogether [SLTC16]. However,this impact would be lessened on new LCI databases which have not yet102.4. Third Party Database Initiatives and Programsselected a format or nomenclature, and the availability of automated utili-ties for the hosting and validation of LCI data in the LCDN make it easilyaccessible for new databases.A similar approach has been used in the development of the USDA LCACommons. While previously the LCA Commons had operated as a cen-tralized database, it has switched to a curated collaborative approach, withindividual data providers maintaining their own dataset repositories that arethen reviewed and released by the National Agriculture Laboratory (NAL)[LBG18]. This has been implemented using the LCA Collaboration Serverdeveloped by GreenDelta, which provides a repository system with accessand version control features; access to this repository system is integratedinto the OpenLCA software suite, allowing datasets to be committed to therepository directly from OpenLCA [BGC19]. This system has the benefit ofenabling collaborative development of datasets by multiple LCA practition-ers while maintaining a history of dataset changes and minimizing the riskof conflicting edits or accidental overwrites when working collaboratively[BGC19]. Minimum requirements for mandatory data and interoperabilityare maintained by NAL, which reviews datasets prior to publication throughthe LCA Commons website or via the LCA Commons Global LCA Data Net-work (GLAD) node. Datasets are distributed in both ILCD and JSON-LDformats.Another approach to data consolidation has been the OpenLCA Nexus,a web application that allows the user to search a variety of both institu-tional and commercial databases and download databases in the proprietaryZOLCA file format for use in the OpenLCA software suite. Dataset format-ting and interoperability is handled by GreenDelta, the consultancy behindthe OpenLCA and OpenLCA Nexus projects, with a share of the licens-ing fees and maintenance fees covering the cost of file conversion [Ope18].Datasets provided through the OpenLCA Nexus are mapped to OpenLCAreference flows, allowing for interoperability between different databases pro-vided through OpenLCA Nexus [Ope18]. This includes a number of agri-food relevant databases such as ecoinvent, GaBi, Agri-footprint, and ESUWorld Food commercial databases, in addition to the free USDA, ELCD,and Agribalyse databases. The OpenLCA Nexus has the benefit of notburdening the data provider to ensure interoperability. It was noted dur-ing consultation with ecoinvent that they send EcoSpold2 files directly toOpenLCA, who handled the conversion to ZOLCA format and mapping ofreference flows. However, the proprietary file format means that the datasetsare only useful for users of the OpenLCA software suite, and interoperabilitymay not carry over if datasets are exported and re-imported into another112.4. Third Party Database Initiatives and Programssoftware suite.A third option for national and regional LCI databases is inclusion intoexisting databases, such as ecoinvent. This option was chosen for the Que-bec LCI Database Project, which used ecoinvent to host regional data as aNational Database Initiative. National database initiatives are responsiblefor data collection, while ecoinvent provides the infrastructure for validationand publishing of the data in the ecoinvent database. Certain advantagesto using an existing database make this option ideal for smaller regionaland national databases; it eliminates the costs associated with developingand implementing the technical infrastructure of a new database, and al-lows immediate interoperability with a large dataset through the rest of theecoinvent database [LS16]. In addition, copyright and license remains withthe original data provider, allowing for publishing publicly or through an-other third-party vendor [WBH+13]. Editing and submission of datasetsin EcoSpold2 format is done through the aforementioned ecoEditor inter-face. While publishing data through the ecoinvent NDI initiative restrictsusage to those practitioners who hold an ecoinvent license, the ability toself-publish data or publish through other third parties makes it possible toprovide data to non-license holders. This is an important consideration fordatabases that have a mandate to make datasets freely and publicly avail-able. Inclusion in the ecoinvent database also means propagation of the datathrough third party data providers such as OpenLCA Nexus, allowing formore widespread distribution and interoperability.It is abundantly clear that third party data providers and networks playa major role in both the distribution of datasets, as well as the validationand standardization thereof. Many of the major LCA databases, includingagri-food databases such as Agri-footprint, ESU World Food, and the USDALCA Commons, are available through networks such as the LCDN and thirdparty providers such as OpenLCA Nexus. In turn, major databases thathave taken on regional LCI initiatives have also become parts of these net-works, leading to a cascading consolidation of LCI data into centralizedrepositories. While this does not entirely solve the issue of data interop-erability, particularly between different providers and networks, this doesprovide the opportunity for wider distribution of data and immediate accessto interoperable datasets. This immediate access to additional data has beencited as a motivation for working with third party providers [LS16]. Depend-ing on the format(s) chosen for an LCI database, third party data providerscould offer a low-barrier means of solving the issue of data availability thatis endemic to the LCA field.In addition to currently available databases, networks, and third party122.5. Summarydata providers, there are several global initiatives seeking to increase theinteroperability and quality of LCI data, both through the introductionof new standards for metadata and new repositories for LCI data. Theseinclude the recently launched Global LCA Data Access Network (GLAD)developed through the United Nations Environmental Program, and theGlobal Guidance Principles for LCA Databases, also known as the ShonanGuidance Principles. Both were developed under the auspices of the UnitedNations Environmental Program (UNEP).The GLAD initiative is a new network of LCI data providers that seeksnot just to aggregate data, but also to easily convert between LCI data for-mats through the use of new metadata descriptors and a global mapping ofelementary flow nomenclature [UNE17]. Much like the LCDN, the GLADnetwork consists of independently operated nodes and a central user in-terface; nodes are required to meet minimum interoperability requirementsthrough the planned use of newly defined metadata descriptors [UNE17].These specifications include required metadata fields, such as process name,type, time, and geography, as well as a new metadata descriptor structure;this new structure includes representation goals, actual representation, anda calculated conformance based on the distance between goal and represen-tation [CAC+17]. Both ILCD and EcoSpold2 datasets can be used withGLAD once the necessary descriptors are identified; GLAD can also in-tegrate with the LCA Collaboration Server and the Soda4LCA software,allowing datasets to be pushed directly from these applications [UNE17]. Inaddition, the GLAD network provides a documented RESTful API servicefor searching and indexing LCI data in the GLAD network [US17], increasingthe utility of the GLAD network and facilitating the development of exter-nal management tools. The GLAD network is still currently in development,and only a subset of the proposed metadata descriptors are available in thepublic beta version of the network.2.5 SummaryWhile the field of Life Cycle Assessment has grown considerably along-side ecological and economic concerns, differences in practice and betweendifferent data formats has resulted in the creation of several competing for-mats and nomenclatures among the LCA community. This poses a challengefor new LCI databases, as the choice of format and nomenclature can haveserious impacts on the ability of users to successfully implement a datasetinto their LCA model. While the two most common LCI data formats share132.5. Summaryan underlying data exchange language (XML), they feature very differentorganization, hierarchy, and metadata fields. This results in potential dataloss during conversion between formats, and necessitates the use of mappingsboth between formats, and between nomenclatures.14Chapter 3MethodologyThis research primarily focuses on the development of a national publicdatabase for agri-food LCI data, with the aim of allowing LCA practition-ers to more accurately assess the ecological impacts and outcomes of theCanadian agri-food industry. Regional variation in agricultural techniques,technologies, and regulations must be accounted for. This makes globallyaggregated data less useful while emphasizing the importance of nationaland regional data sources. The CALDC is the intended solution, providingprimary source gate-to-gate datasets for Canadian agri-food processes, in-dependent of, but compatible with, existing commercial and internationalLCI database solutions and LCA software.With these objectives in mind, research was done to determine the bestapproach in developing the CALDC, the results of which have been summa-rized in Chapter 4. From this research, recommendations were developedfor both the technical implementation and the interoperability componentsof the database, the results of which have been included in Chapter 6.3.1 Initial ObjectivesThe CALDC was proposed as a publicly accessible database for Canadianagri-food life cycle assessment data. Prior to the beginning of research, somekey objectives for the CALDC were determined, based on the needs of thePRISM lab as well as stakeholders such as the Canadian Roundtable forSustainable Beef and the Department of Agriculture and Agri-Food Canada,who were consulted to ensure the success of the database:− The database must have provisions to allow public access to publisheddatasets− There must be a system to allow datasets to be reviewed before pub-lishing to ensure that datasets meet required standards of quality anddata reporting153.2. Technical Considerations− The database must take interoperability into consideration and providesome means of producing datasets in both major formats and ideallyhandle nomenclature as well− The database should follow industry standards within the LCI databasecommunity in terms of technical implementationBased on these initial objectives, areas of study were determined based ona preliminary literature review undertaken in the development of the thesismethods proposal. During this review, more than 60 articles, technicalreports, and guidelines were studied, dating from 2002 up until 2018. Inaddition, LCA professionals and existing databases were engaged for furtherinformation on the current state of LCI databases. Areas of inquiry includedtechnical considerations in implementing an LCI database, and an emphasison producing interoperable datasets that could be readily shared through theCALDC platform with other practitioners and reused with minimal effort.Further discussion of the methodology used to examine each of these areasof study is outlined in the subsequent subchapters.3.2 Technical ConsiderationsFrom the outset, it was considered that in order for the database to ful-fill the requirement of being open to the public, it would be necessary tointegrate some form of public-facing web interface for the database. Thiswas seen commonly across other LCI database implementations such as theELCD, ecoInvent and GaBi. Due to the sparsity of information describingthe system architectures behind these common LCI database implemen-tations, it was decided that existing database owners and documentationwould be solicited for information. The findings of this research would thenbe used to determine the appropriate approach to developing the CALDC.In order to determine common technical implementations of LCI databases,several major LCI database providers and providers specific to the agri-foodsector were contacted, including the USDA LCA Commons, ecoinvent, GaBi,and Agri-footprint databases. Both commercial and institutional databaseproviders were consulted. The European Life Cycle Database (ELCD) wasalso solicited for information, however the ELCD project was officially dis-continued in June, 2019. The WFLDB and the Global Feed LCA Institute(GFLI) were also contacted, but did not provide a response for this research.Responses to requests included documentation, diagrams, and conferencecalls with developers and technical staff to discuss their implementations.163.2. Technical ConsiderationsData requested, if available, included the chosen database software(s)in use, choice of web server and backend scripting language or framework,the formats used to store LCI datasets within the database, and generalinformation on the workflow of information from contributors through tothe underlying database. A typical web application stack is shown in Figure1, demonstrating the major components that database providers were askedabout. Queries also included both the management of front-end portalsand search engines for databases, such as the ecoinvent ecoQuery system, inaddition to back-end management and storage of data. Where possible, ad-ditional documentation and discussion with technical staff was requested, al-though both commercial concerns and varying degrees of familiarity with theunderlying technical systems prohibited data collection from some sources.Figure 3.1: A traditional web application software stack.In order to ensure that the developed database would follow current goodpractices in web application development, existing literature on database-driven web application development was also consulted. This included devel-oper surveys on popular technologies, as well as documentation on currentmajor software components such as Apache, PHP frameworks, and Flask.This information was used in conjunction with the data solicited from ex-isting LCI databases to help determine the appropriate software, and archi-tecture choices and ensure that the CALDC was developed using up-to-dateand appropriate software choices.173.3. Interoperability Requirements3.3 Interoperability RequirementsIn terms of developing the CALDC, interoperability was defined as theability to seamlessly integrate datasets from multiple sources in order todevelop cohesive system models while minimizing the need for manual edit-ing. Interoperability further promotes the sharing and re-use of LCI datawhile potentially reducing the expenditure of time and resources on convert-ing datasets or producing new background process LCI data sets. One ofthe primary goals of the CALDC is to provide Canadian LCI datasets atthe process level that can be seamlessly integrated with background datasetsfrom existing major databases and database providers with minimal effort inorder to produce spatially and temporally relevant models for the Canadianagri-food industry.Considerations for ensuring interoperability between LCI databases werefirst identified based on a preliminary review of available literature, includ-ing peer-reviewed journal articles, conference proceedings, technical reportsproduced by major institutions, and end-user documentation for existingdatabases and utilities. On this basis, dataset exchange formats, and nomen-clature were identified as core concerns for creating and maintaining inter-operability between LCI data sources. An in-depth review was subsequentlyperformed of currently utilized LCI data exchange formats, including bothpublished literature and technical documentation provided by format devel-opers. Data exchange formats represent the primary means by which LCIdata is recorded, represented and exchanged. Format origins, major usersof each format, and the underlying data encodings were identified, as werethe challenges in converting data between formats. The shared encodingsystems that underlie each format were also evaluated, providing additionaltechnical information and identifying priority areas for further developmentof data exchange formats.In order to facilitate interoperability in format, a direct comparison ofEcoSpold2 and ILCD data formats was performed, based on the technicaldocumentation available for each format. This comparison was done toallow for the development of a cross-compatible data entry or conversiontool. Individual data fields in each format were examined and comparedwith similar fields to determine potential mappings between similar fields.In addition, all mandatory and optional data fields were enumerated fromeach format to facilitate identifying the baseline requirements needed toproduce a valid dataset.In addition to format, reviews of previous studies on LCI database in-teroperability highlighted the importance of nomenclature. Nomenclature183.4. Third Party Providers & Initiativesrefers to the actual naming of reference flows and units within LCI data sets,as well as classification schemas used to categorize and organize datasets.Even following a strict formatting rule, format conversion only allows forsyntactic interoperability – the guarantee that the syntax of the formatteddataset will match the syntax of other datasets of the same format. How-ever, it provides no such guarantee of semantic interoperability. The lack of astandardized nomenclature for LCA presents a greater challenge to interop-erability than the lack of a standard data exchange format [Tiv15]. Failure toappropriately translate disparate nomenclatures between datasets can resultin linkage failures between processes and flows. Major current nomenclaturesystems employed in LCI databases were identified, and potential solutionsto the problem of disparate nomenclatures reviewed. This included a reviewof existing tools and mappings available between nomenclatures, such as theOpenLCA/GreenDelta Format Converter tool, as well as proposals for newmethods of mapping and aggregating existing nomenclatures. The use ofunified nomenclatures by existing LCI databases, such as OpenLCA, wasalso examined.3.4 Third Party Providers & InitiativesIn considering interoperability and the technical aspects of implementinga new LCI database, the roles of third-party data providers, networks, andinitiatives in distributing and standardizing LCI data were also considered.The emergence of international LCI database initiatives and distributorsprovides a new avenue for greater distribution and standardization of LCIdata, although the benefits and costs of compliance with new standards mustbe considered. Information regarding third party providers, networks, andinitiatives was sourced from published literature, technical reports, end-userdata guidelines, and developer documentation. The requirements, reasoning,and impact of these systems and initiatives on the LCI field at the presenttime was evaluated.3.5 Development & TestingThe development cycle of the project was managed using a Scrum soft-ware development process. Scrum is an agile development process suitedto small development teams that uses very short, iterative developmentcycles known as sprints [RJ00]. The process focuses on producing usablesoftware with each sprint, building the project incrementally towards com-193.5. Development & Testingpletion [RJ00]. The advantages of this process are that prototypes can bequickly produced and feedback elicited at regular intervals, in addition tobeing able to more easily adapt to changes in requirements than a traditionalwaterfall model of software development.The initial features required were identified from both background re-search, including features available in other major LCI databases, as wellas the requirements for the project set out in the initial thesis descriptionprovided by Dr. Nathan Pelletier. Some features were considered too largeto implement in a single iteration, such as the ability to export both ILCDand EcoSpold2 formatted datasets; these features were subsequently splitup to allow for iterative testing of the tool with some implemented featureswhile others remained under development.As the actual software development was undertaken as a solo effort,not all aspects of agile Scrum process could be used. Traditionally, featuredevelopment in each iteration would be split across multiple developers, andeach Scrum would be quite short – typically 2-4 weeks between iterations– allowing for new features to be rapidly implemented and then tested,before potentially adding new features or revisions to the queue for the nextScrum iteration. In addition, use of a project/feature management utilitysuch as JIRA or Trello was determined to be unnecessary, as those toolsare primarily designed to provide coordination when working with multipledevelopers. This led to a development approach similar to that seen in thecode-and-fix software development model. Prototypes were commonly sentout to the PRISM lab and changes or bug reports solicited, with changelistsnoted in email announcements. The code-and-fix model is a commonlyiterative development process used when project specifications are minimaland allows for rapid development by foregoing the need for documentationand testing, but this exposes projects to additional risk and makes assessingprogress difficult [Kne18].In order to minimize the risk associated with a code-and-fix softwaredevelopment model as well as elicit additional features for the project, em-phasis was placed on the iterative testing and feedback cycle used in agileScrum. Software testing is usually considered a major component of riskmanagement in the development of new software. Three major potentialtesting groups were identified: internal testing among researchers within theFood Systems Priority Research for Integrated Sustainability Managementlab; stakeholder testing, primarily amongst stakeholders who expressed in-terest in using and releasing data through the CALDC; and public testing,among a global group of life cycle assessment practitioners. Feedback wasprimarily obtained through email on an individual basis, with internal and203.5. Development & Testingexternal testers submitting bug reports and suggestions. While major fea-tures such as the ability to create datasets in both formats had already beendetermined, user feedback helped identify ambiguities in the user interface inaddition to new features. The testing process included both functional andnon-functional testing, such as the use of per-function/method unit testing,verification of output data format and content, and usability testing.It was determined that initial iterations of the software would be dis-tributed and tested internally, with feedback and features to be solicitedfrom researchers familiar with both other LCI databases and with the in-tended purpose and feature set of the CALDC. Researchers at the PRISMlab were expected to be among the end-users of the software, making theirfeedback particularly valuable. In addition, internal testing would allowfor tighter turnaround times on feedback, as well as the ability to directlydemonstrate issues found in the testing. It was decided that initial develop-ment would focus on implementation of primary features, such as the abilityto create and export a basic dataset, with functionality taking precedenceover usability at this stage of development. Once a minimum set of neces-sary features was developed through internal iteration, a functional softwareproduct could then be distributed for stakeholder testing.Improving usability was a primary focus of the subsequent stakeholdertesting process. The external Expert Stakeholder Advisory Committee forthe CALDC project included government, academic, and commercial stake-holders, including the department of Agriculture and Agri-Food Canada, theCanadian Roundtable for Sustainable Beef, Group Age´co, and Egg Farmersof Canada. Prior to the beginning of stakeholder testing, materials wereshared with the stakeholders to keep them abreast of development, includ-ing the thesis methods proposal initially developed at the beginning of theproject, and the subsequent journal article that outlined recommendationsfor the development of the CALDC. While internal testing was done withresearchers intimately familiar with both the life cycle analysis process andsimilar software, the project stakeholders represented a range of familiar-ity and understanding of LCA practices and terminology. Because of this,testing with external stakeholders focused on improvements to the user in-terface, and ensuring that users less familiar with LCA processes would becapable of comfortably using the software when complete.Once the software was thoroughly tested both internally and by thestakeholders, and all necessary features had been identified, implemented,and tested, the software would then be ready for a public announcementand release. It was determined that the ability to give feedback should bebuilt directly into the application, something which has been identified as a213.6. Summaryviable means of collecting user feedback [Kne18]. In particular, it has beenshown that it must be easy for users to provide feedback, as otherwise manyusers will simply decline to provide any feedback [Kne18]. This was notconsidered a problem for earlier stages of testing, as communication via in-person meetings, conference calls, or email could be easily maintained withinboth the PRISM lab and among the external stakeholders committee, bothof whom had a direct interest in providing feedback for the developmentof the software. In terms of actual release, it was decided that the globallife cycle assessment listserve mailing list would be used to announce anddisseminate the completed CALDC project.3.6 SummaryIn summary, a thorough review of published literature, technical docu-mentation, and existing LCI data formats and nomenclatures was performed,both to guide the development of the CALDC as well as to provide recom-mendations for LCI databases moving forward. This included analysis of thetechnical implementations of LCI databases, identifying major interoperabil-ity challenges and analysis of existing data formats and nomenclatures, andconsideration of the role of third party initiatives and databases in terms ofoperability and implementation, and considerations for future maintenance.Besides existing literature, LCI databases were solicited directly for infor-mation regarding their own systems to help better inform the research onthe current state of LCI database development.An agile, iterative development cycle was used to continuously implementand test features as they were identified. This testing would be performedinternally to identify major features necessary for the success of the project,before moving into testing with external stakeholders to further improve theusability of the tool while continuing to add secondary features. The itera-tive development cycle and regular testing placed an emphasis on producingworking software prototypes that could then be incrementally refined withfurther feedback. Once all major features were identified, implemented, andrefined through the testing process, public release would then be possible,with the ability to further collect feedback during the public release phaseand thus continue incremental improvements to the CALDC software.22Chapter 4ImplementationBased on the requirements and the results of the background research,development of the CALDC web application began, in collaboration withother team members from the PRISM lab who provided testing feedback,as well as external stakeholders. The finished application includes a fully-fledged user login and account system. It further provides the ability tocreate, view, edit, import, and export LCI datasets, and submit these LCIdatasets for acceptance into the CALDC, at which point they may be pub-lished for public use.4.1 Technical Findings4.1.1 Existing LCI DatabasesBased on the responses solicited from existing LCI database providers,it was determined that a number of popular enterprise web software prod-ucts were in use among them, and that the software and architecture chosendiffered greatly between different databases. In terms of processing andserving of data, a variety of languages, frameworks, and content manage-ment systems are employed. Choice of database management software issimilarly varied, although all are using relational databases based on Struc-tured Query Language (SQL). Agri-footprint makes use of the PostgreSQLopen-source DBMS software, while ecoinvent uses the commercially licensedMicrosoft SQL Server software. In surveys of both professional and non-professional software developers, MySQL, MSSQL, and PostgreSQL rep-resent the top three most popular DBMS packages in use; in the case ofMySQL and MSSQL, this popularity spans multiple years [Exc18]. Thepopularity of these systems ensures long-term support will exist, and theirchoice suggests that LCI database providers are following the prevailingtrends in database and web application development.In terms of how LCI datasets were actually stored within the database,a more varied approach was seen among existing databases. Datasets arestored primarily as JSON-LD formatted files in the LCA Commons database,234.1. Technical Findingswith datasets available in both ILCD and JSON-LD formats. In the ecoin-vent database, XML data are stored in the relational tables as Binary LargeObjects and then converted back into EcoSpold2 format by the web-serviceslayer for use in the ecoEditor. A copy of the database is prepared after eachrelease of the ecoinvent database with additional EcoSpold2 data; this isthen translated into readable HTML and served to users via the ecoQuerysystem.It is also important to note the maturity and management of LCI databases,and how this has impacted the choice of architecture and software. Theecoinvent database represents a mature LCI database, beginning in 2000 asa joint effort between Swiss research offices and the Swiss federal government[FR05]. Maintenance of the database and web services is not handled byecoinvent internally, but rather by IFU Hamburg GmbH, a German softwareconsultancy firm that specializes in sustainability software. This could ex-plain the use of IIS and MSSQL in the ecoinvent technology stack; both arepopular in enterprise-level web development. In contrast, some databaseshave moved away from traditional web and database technologies, and in-stead have adopted LCI-specific systems for the management of datasets.An example of this is the USDA LCA Commons, which has moved awayfrom a custom-built Drupal, Apache, and DKAN software stack to a systembased on the GreenDelta LCA Collaboration Server.Given the variety of different software stacks in use in existing databases,it was determined that there was only minimal consensus on technical im-plementation. While all the databases who responded used some form ofSQL-based database, choice varied between databases in terms of particularDBMS software choice, web server software, and scripting languages. Theuse of common web application technologies such as Apache and Drupalwere also noted, in addition to backend scripting languages such as Python(in use for data management at ecoinvent) and Grails (formerly in use at theUSDA LCA prior to the move to LCA Collaboration server). The results ofthese exchanges suggest that LCI database providers are using traditionalenterprise server and database technologies, with some changes in softwarechoice and architecture coming with increased maturity and growth of thedatabase, in addition to the development of specialized LCI applications.The lack of consensus among LCI database technical implementations, andthe variety of enterprise web technologies in use, suggested that a standardweb application software stack would be an appropriate choice for the de-velopment of the CALDC.A summary of the formats, nomenclatures, and underlying technicalimplementations of three major LCI databases has been provided below in244.1. Technical FindingsTable 4.1. It is also worth noting that most of the databases are relatedto one or more third-party providers, such as via OpenLCA Nexus or viaSimaPro.Table 4.1: Three major LCI databases compared.ecoInvent Agri-Footprint USDA LCA Com-monsOutput For-matecoSpold2 XML OpenLCAZOLCA format,SimaProILCD XML,JSON-LDInput Format ecoSpold2 viaecoEditorVariable Variable, viaOpenLCA soft-ware suiteNomenclature ecoInvent, vari-able versionsavailable throughthird partiesecoInvent 2.2 Combinationof ILCD andOpenLCAnomenclaturesUnderlyingTechnical Im-plementationCentralizedMSSQL databasehandling eco-Query anddatasets, main-tained by thirdpartyProvided viathird-partyproviders(SimaPro,OpenLCA Nexus)Central databasehosting multiplerepositories usingthe OpenLCACollaborationServer4.1.2 Formats & NomenclaturesFrom the initial background research, it became clear that the most com-mon and recognized formats in use among major LCI databases presentlyare the EcoSpold2 format, and the ILCD format. EcoSpold is in use withthe eponymous ecoinvent database [FR05], the National Renewable EnergyLaboratory (NREL) US LCI Database [LILS04], and the French Agribalysedatabase [CAM+15], among others. ILCD in comparison is in use with theLife Cycle Data Network (LCDN), which has consolidated data in the ILCDformat from both Italian and Brazilian national databases, in addition to thecommercial Agri-footprint and Thinkstep AG GaBi databases. The ILCDformat has also been adopted by the World Food LCA Database (WFLDB),using the ecoinvent 3.0 naming conventions [NRL+14].254.1. Technical FindingsBased on the popularity of these two formats, it was considered manda-tory that the CALDC should support both, such that LCA practitionerscould freely use CALDC-distributed datasets in their models regardless ofwhich software and other LCI data sources were in use. A study of the for-mat documentation for each format revealed that although they both use thesame underlying XML format, the data field formats for both are different.As some data fields only exist in one format or the other, it was determinedthat a conversion between the two formats could lead to data loss, or resultin empty data fields where the necessary data simply did not exist in theorigin format. As a result, a study was conducted by researchers of thePRISM Lab at the University of British Columbia, Okanagan Campus todevelop a suitable data reporting template capable of producing both ILCDand EcoSpold2-compliant datasets [TSAP20].Turner et al. identified 65 distinct fields that would be required to createa dataset that would be compatible with both the ILCD Process format, andEcoSpold2 Activities. They further found that a number of fields unique toeach format could be appropriately mapped to fields in the other format,reducing the duplication of effort by having the software perform those map-pings automatically [TSAP20]. This eliminates the need to keep duplicatefields from each format, reducing the total amount of data the user is re-quired to enter to produce a compatible dataset.In addition to the fields identified in the ILCD Processes, the ILCDformat documentation identified another nine mandatory fields for Con-tact datasets, seven mandatory fields for Flow Property datasets, thirteenmandatory fields for Flow datasets, and seven mandatory fields for Sourcedatasets [TSAP20]. It was decided to use only the mandatory fields acrossILCD and EcoSpold2, ensuring that datasets are compliant with both for-mats while requiring only the minimum amount of data entry. An excep-tion was made for eight non-mandatory ILCD fields, including the synonym,Chemical Abstracts Service (CAS) number, and formula fields. These fieldsprovide alternative identification for their datasets, i.e. the CAS numberof a chemical flow, or common synonyms for a particular process. Thesefields are optional, but may contain additional useful data for identifying adataset that may otherwise use an unconventional naming schema.Beyond providing datasets in both formats, the literature referencednoted that nomenclature also plays a major role in interoperability betweendatasets. To this end, the decision was made to use an established nomen-clature as the basis for the CALDC, to prevent further fragmentation ofLCI data standards and ensure compatibility with existing datasets. Theelementary reference flows and units provided by the ELCD were chosen as264.1. Technical Findingsthe basis for nomenclature within the web application, as the datasets arefreely available and can be redistributed without concern for licensing or in-fringement of intellectual property. However, this does not directly resolvethe issue of incompatibility between EcoSpold2 and ILCD nomenclatures.Although a mapping could be used to identify similar data fields withinthe ILCD and EcoSpold2 formats, this did not necessarily mean that bothfields used similar formats or values for their inputs. In this respect, sec-ondary mappings were required to convert between ILCD nomenclature,which was used by default, and EcoSpold2. For example, it was determinedthat the geographical location categories used by ILCD differed slightlyfrom those used in EcoSpold2; this required a secondary mapping to bedeveloped to convert ILCD location values and UUIDs into EcoSpold2 com-patible location values and UUIDs. A similar process is required for themapping of units between ILCD and EcoSpold2. The mapping produced byOpenLCA/GreenDelta as part of their Format Converter tool [Ope15] wasfound to be the most complete ILCD-EcoSpold2 mapping available, includ-ing complete or near-complete maps of locations and units across the twoformats. However, the elementary reference flow mappings included withthe tool were found to be incomplete, encompassing only 2,802 of the 41,675ILCD elementary reference flows. This allows the use of a subset of ILCD-standardized elementary flows, which can then be converted to appropriatereferences for EcoSpold2-formatted elementary flows.Ultimately, no clear solution to this problem was found. Use of theFormat Converter mappings necessarily limits the user’s selection of flowsto those that have been properly mapped if fully compatible EcoSpold2datasets are desired. At this time, no other compatible flow mappings be-tween ILCD and EcoSpold2 were found to be available. Several potentialapproaches to this problem have been set forth. New structured ontologiesfor LCA nomenclature have been suggested [IHT+15], however the adop-tion of a single standard nomenclature model is considered a long-termgoal [Tiv15]. Alternative approaches such as semantically-linked nomen-clature catalogues or dictionaries have been proposed; Kuczenski et al. havedeveloped a semantic catalogue based on major LCI databases, includingthe ELCD, ecoinvent, the US LCI database, and the GaBi 2016 database[KDRJ16]. While a new ontology may eventually develop, or a semanticcatalogue may be completed in the future, it was determined that the ex-isting partial mapping of ILCD to EcoInvent2 reference flows was the mostfeasible to implement at this time.274.2. Software & Architecture Choice4.2 Software & Architecture Choice4.2.1 Web ApplicationThe primary means of interacting with and using the CALDC is througha public secure web application. The CALDC application allows users tosearch and browse currently available datasets, view their associated meta-data, and download them for use in a manner similar to the system currentlyused for the European Life Cycle Database (ELCD) [JE17]. In addition, theapplication also allows users to submit new datasets for addition in theCALDC, pending a curation process that will verify the completeness of thesubmitted data. This is a manual task and subject of a concurrent study aspart of the broader research project.Initially, the web application was also going to be the user interface fora conversion utility, allowing the user to select a preferred data exchangeformat and potentially nomenclature when downloading a dataset. Whenit was determined that this conversion would potentially be very difficult toperform without data loss, it was determined that the web application wouldinstead provide the ability to create new datasets directly in both EcoSpold2and ILCD formats. Emphasis was placed on creating easily navigable web-pages that clearly display relevant metadata and background informationfor datasets, allowing users to quickly find and identify appropriate data.The requirements for the UX design (derived from Human-Computer Inter-action principles) also take into account the W3C Web Content AccessibilityGuidelines, insofar as the CALDC is a public web service and should provideat least some support for screen readers and similar systems [W3C08].The decision to integrate a new dataset creation tool into the CALDCwas made both to avoid the aforementioned data loss during the conversionprocess, as well as to provide a more user-friendly interface than was avail-able through existing LCI data creation tools. This was of concern becausemany stakeholders in the agri-food industry may not necessarily be familiarwith LCI formats and nomenclature, and LCA practitioners may not be fa-miliar with all of the required metadata fields in an LCI dataset. Thus, itwas considered important that the tool be easy to use; not necessarily forthe layman, but for LCA practitioners and those at least familiar with LCAterminology and practices who were considered our user group.Based on the software currently in use in the LCI database field, itwas determined that many LCI databases were using a variety of conven-tional enterprise web application technologies. This suggests that the de-tails of technical implementation were not necessarily important in terms284.2. Software & Architecture Choiceof interoperability, allowing the use of a typical web application stack suchas PHP/Laravel or Python/Flask over a standard Apache or NGINX webserver. Subsequently, the decision was made to use a conventional web ap-plication architecture. The initial choice of language was PHP, using theLaravel framework, which had previously been used in the development ofthe Digital Archives Database Project (DADP), a similarly database-drivenweb application developed under Dr. Ramon Lawrence at the University ofBritish Columbia, Okanagan Campus [MSO17]. However, the decision wasultimately made to go with a Python environment using the Flask frame-work. Flask was initially released in 2010 and has gained popularity as alightweight and easily portable framework. Flask development techniqueshave been well documented in published literature [GM18].In terms of advantages, Flask required fewer dependencies and provideda clearer organizational structure than the Laravel framework, while alsoproviding a built-in webserver that facilitated testing prior to the actuallaunch of the web application. Flask also provides the benefit of beingPython-based, making the code base more maintainable through the use ofa common, high-level programming language with long-term support. Inaddition, Flask provides a number of built-in security functions, such as theability to store user-specific session data using encrypted client-side cookies.In developing the web application, functionality was split across multiplePython modules imported into the Flask web routing application, allowingfor greater organization and maintainability of the code base through mod-ularization. In addition, documentation of function methods and purposeswas included within the code, and the code itself makes use of descriptivevariable and function names throughout to make familiarization by futuremaintainers easier.The Flask application was hosted using the Apache web server, a pop-ular freeware web server that has the highest market share (>25%) amongmodern web servers [Ref20]. The web server itself is run on CentOS, acommunity-maintained variant of the popular RedHat enterprise Linux dis-tribution. These software choices are typical of modern web applicationsoftware stacks and are based primarily on the reliability and longevity ofthe software, as both Apache and CentOS offer long-term support for theirsoftware.4.2.2 DatabaseSimilar to the choice of web server and backend software, existing LCIdatabases were found to use a variety of different SQL-oriented databases. In294.2. Software & Architecture Choiceaddition, there was no consensus on how data was stored within the databaseitself. As a result, the choice of the database was only limited by the decisionto use an SQL-oriented database, and was primarily informed by enterprisechoices and cost. As Python supports database drivers for many differentdatabases, it did not impose any limitations on the database choice. The useof parameterized queries within Python’s SQLite/MySQL drivers preventsSQL injection into the database by automatically escaping parameter inputs.The initial client-side implementation of the CALDC used a combination ofstoring data in complete XML-encoded files, while maintaining a listing ofthese completed datasets in a SQLite database. SQLite is a lightweight,serverless database with native support in Python, designed for embeddedclient-side usage in web and mobile applications [Owe06]. While this allowedfor quick development of the software, limitations of the SQLite engine suchas lack of concurrent operations and slow read/write times when handlinglarge tables required that an alternative database be used.MariaDB, a community-developed fork of the popular MySQL databasewas chosen as a replacement. It enjoys broad commercial support amongdatabase providers while also being a free and open-source database, remov-ing the need for a licensing fee. To further speed up the application, datasetswere moved from standalone XML files to dedicated tables, removing theneed to parse XML files to retrieve metadata attributes when displaying thisinformation through the web application.4.2.3 Stack ArchitectureThe CALDC uses a traditional web application stack architecture, basedon an Apache web server running on the CentOS operating system. On topof this, the web application, known as SimpLCIty, runs as a service, con-nected to the underlying Apache server using a Web Server Gateway Inter-face (WSGI), which facilitates the passing of information between Apacheand the Python application. It is served via Secure Hyper-Text TransferProtocol (HTTPS) using a TLS certificate. For storing of datasets and userdata, the MariaDB SQL database is used. MariaDB can be interfaced di-rectly using a standard mysql-connector module in Python, allowing theapplication to communicate directly with the database. A diagram repre-senting this architecture is provided in Figure 4.1 below.The application is run on a Digital Ocean “droplet” virtual machine,which provides four virtual CPUs, 8GB of RAM, and 160GB of solid-statestorage. Initial deployment was done on a smaller virtual machine, butwas resized due to issues with poor database performance on lower-powered304.2. Software & Architecture ChoiceFigure 4.1: Software stack used in the development of the CALDC.machines. The caldc.ca domain name was acquired and serves as the primarydomain for the application.4.2.4 Database DesignAlthough initial versions of the SimpLCIty application used an SQLitedatabase and stored datasets as files, performance was found to decreaseheavily when the application required loading of a large number of datasets.An example of this can be seen when selecting a flow for a Process in-put/output exchange; when using ILCD elementary reference flows, such aquery may return several thousand potential flow datasets for a given en-vironmental compartment. This was found to be too much load for theapplication, due to the requirement that it parse data out of the XML-formatted files for each possible flow. The decision was hence made toswitch to MariaDB, a community-developed fork of the MySQL database,and move towards the storage of data directly in the database. The databaseitself consists of twenty-two tables, organized around six major purposes.Figure 4.2 shows the major organization of the subsequent database:User-created datasets are stored directly in the database in the appropri-ate table, organized by ILCD dataset type. Each table dedicated to a typeof user-created dataset includes as a column each of the previously discussedmandatory data fields, as well as any additional optional data fields suchas synonyms. Each row within these tables represents a dataset that hasbeen created of that type, which is owned by a specific user. These tables314.2. Software & Architecture ChoiceFigure 4.2: Classification of tables in the CALDC database by purpose.are pulled when rendering a user-created dataset in both SimpLCIty andthe public-facing CALDC service, as well as for final dataset export. Eachdataset also contains a reference to the specific user in the ‘users’ table thatcreated the dataset; this is internally referenced when an attempt to read,edit, or export a dataset is made to ensure that a logged-in user can onlyperform such actions on their own datasets.The internal column names used to denote each field in a given user-created dataset table are stored in the form fields table, which is used to han-dle dynamic data entry form generation. This table maps internal columnnames to the proper external names used in the ILCD and EcoSpold2 for-mat documentation, while also applying a step, type, and maximum size toeach attribute. The absolute maximum storage size of each type of dataset,as well as the average size as of July 2020 is provided in Table 4.2 below, asreported by the MariaDB database.Maximum lengths greatly exceed average lengths for all dataset types,in particular as a 65,535B text-type column is used to store the flow prop-erty and flow exchange tables. As there is no prescribed maximum lengthwithin the specifications for the number of flows or flow properties that canbe listed in these fields, they were provided additional length to accommo-date large exchange/property tables if necessary. This allows forms to be324.2. Software & Architecture ChoiceTable 4.2: Average and Maximum Sizes of Datasets by Type.Type Average Size (B) Absolute Maximum Size (B)Contact 372 6380Source 682 7740Flow property 1092 5660Flow 1195 73945Process 8366 126495built on a step-by-step basis, with each “step” constituting a number ofrelated data fields that will be prompted from the user on the same page.Specifying a type for each attribute allows for automatic generation in thebackend (Flask) of appropriate HTML form fields; for example, a numericfield will be rendered as an HTML5 number-type input, while a dropdownselection will be rendered with the appropriate options for that dropdown.Additional fields denote whether a field is required (and apply an HTMLrequired keyword to the generated form input), as well as allowing maxi-mum lengths and default options to be specified. The form headers tablesimply provides appropriate titles for each generated data entry step page(i.e. Step 1: Modelling and Validation, Step 2: Exchanges, etc).The static data and reference flow data tables act as repositories for pre-defined data. This includes data for the ILCD elementary reference flows,and the standard ILCD reference flow properties. The ilcd flows table rep-resents the largest table within the database, consisting of 41675 rows, eachrepresenting one of the standard ILCD elementary reference flows. Thisdata was previously stored in file format on the web server and referencedin the database, but was transitioned into the database due to performanceconcerns. Additional ILCD reference datasets, such as default contacts andsources are stored outside the database in XML file format, as they do notrequire regular parsing and are merely included with exported datasets as anecessary dependency. Similarly, the static data tables store the classifica-tion and categorization groups for flows and classes, as well as the defaultILCD unit groups. Additional static data and/or reference flows may beadded as necessary to these tables should the underlying ILCD standardschange.The nomenclature mapping tables, location, unitmap, and flowmap, con-tain mappings between ILCD and EcoSpold2 nomenclature. They representthe in-database version of the mappings laid out in the Excel files that comewith the OpenLCA Format Converter [Ope15]. These tables are primarily334.3. Security & Maintenance Considerationsused during the export process, during which the original ILCD units, loca-tion, and flow(s) are converted to their equivalent EcoSpold2 mapping forexport as a .spold file. One exception to this is the flowmap table, whichis used during dataset creation to selectively show only the mapped subsetof ILCD flows. This feature can be turned off in the user settings, at whichpoint the flowmap table is only referenced during export.Finally, a group of application-specific tables handle web applicationdata unrelated to LCI datasets. This includes user and admin login infor-mation and site settings, as well as feedback provided through the built-infeedback system. The submissions table is responsible for the managementof datasets submitted for public release to the CALDC. It does not directlyinclude the submitted data set, but instead a reference to the dataset’sunique UUID and the type of dataset it represents (Contact, Process, etc).While most of these tables are used primarily to handle user logins andpermissions, the submissions table is also used in the admin console for theapplication, as well the public-facing CALDC.4.3 Security & Maintenance ConsiderationsAs the CALDC was designed as a long-term web application, securityand maintenance also needed to be considered. Since a full-stack soft-ware architecture was used, security has been implemented across multi-ple levels of the software stack. In addition, a basic risk assessment hasbeen provided in Appendix A, based on the Open Web Application Secu-rity Project (OWASP) Top Ten web application security risks awarenessdocument[OWA17].The underlying CentOS 8 server uses the iptables Linux packet filter fire-wall by default. This provides only basic filtering ability, but allows all un-necessary ports to be closed on the server machine, leaving only Secure Shell(SSH), Secure File Transfer Protocol (SFTP), HTTP, and HTTPS protocolsenabled on their respective ports. In addition, CentOS comes preconfiguredwith the Security-Enhanced Linux module (SELinux), which provides accesscontrol policy and audit logging for processes[MMC06]. SELinux access con-trol prevents the underlying Apache web server process from accessing ormodifying files outside the scope of the web application folder, and existson top of the existing Linux user/group ownership and permissions system.Communication with the web server is done via Hypertext Transfer ProtocolSecure (HTTPS), which uses a third-party issued TLS certificate to verifyownership of the web server and encrypt user traffic to and from the server.344.3. Security & Maintenance ConsiderationsAll standard non-secured HTTP traffic is redirected to use HTTPS.The MariaDB database is run internally on the CentOS server, andhas no external ports. An application-specific user role was created in thedatabase that allows access to read and modify data where necessary, whileremoving unneeded permissions such as the ability to modify static tables,modify the overall database architecture, or perform administrative func-tions. All database connections made by the web application use this role,reducing potential for abuse through SQL injection. As the primary purposeof the CALDC is to provide publicly-available datasets it was considered un-necessary to encrypt the contents of the database. However, passwords arestored in the form of a salted SHA-256 hash. This prevents the use of com-mon precomputed lookup or “rainbow” tables to reverse the hashes shouldthe database ever be compromised, requiring the attacker to generate newlookup tables specific to this application. While the system prevents pass-words from being stored in plaintext, the SHA-256 standard is now consid-ered deprecated, and should be replaced with an appropriate key-stretchingfunction such as PBKDF2 or bcrypt to provide additional protection againstattacks as recommended by the IETF [Mor17].The Flask and Python back-end of the application includes a numberof built-in security features to protect against such attacks, in addition tocommon attacks such as Cross-Site Scripting (XSS). The Jinja templatingengine provides automatic escaping of data passed between the web appli-cation and HTML templates, preventing cross-site scripting (XSS) attacksbased on malicious user input. In addition, prepared SQL statements areused throughout the application to prevent SQL injection attacks when userinput is handled.In terms of data validation, requirements are low. All fields except forauto-increment identifiers are cast to strings and stored as text, and mostfields allow for free-form text entry with minimal formatting requirements.Where an input must follow a specific format or data type, client-side vali-dation is performed using the built-in form validation in HTML5. If client-side validation is disabled or fails, internal try-except catches will return theuser to the previous editing page with an error message and prompt themto retry data entry. This system only provides basic syntactic validation ofinput data. Validation of datasets for completeness, quality, and suitabil-ity for the CALDC is a manual task performed by CALDC administrators(see section 5.1). The requirements for manual validation are the subjectof additional study within the PRISM lab and fall outside the scope of thisthesis.In terms of maintenance, the application was designed to require minimal354.3. Security & Maintenance Considerationsday-to-day maintenance beyond CALDC administrators needing to approveor reject datasets in the CALDC submission queue. A systems administratorwith shell access is required for periodic updating of software packages, andalso if manual access to the database is necessary, such as for a passwordreset. The application was designed to allow changes to the underlyingdata templates and input fields without requiring additional changes to theapplication code. New fields may be added directly via the form fields tableand subsequently added to the output XML template file. Currently shellaccess is only available to the developer; however moving forward additionalshell access will be passed off to the PRISM lab should maintenance oraccess be required in the future. While requiring minimal maintenance, theapplication still requires an ongoing systems administrator.One major security feature not yet implemented in the CALDC is theability for users to recover their password without requiring manual inter-vention by the system administrator. This is due to the underlying servernot being configured for the sending of secure email. Mail would be sentvia unencrypted Simple Mail Transfer Protocol (SMTP) in plaintext, po-tentially allowing an eavesdropper to see the email in-flight and steal logindetails or reset links. This could be remedied through the use of a secureexternal mail provider, or by configuring the server for Simple Mail Trans-fer Protocol Secure (SMTPS), using the existing TLS certificate used forHTTPS.To protect against catastrophic failure or intrusion, a basic backup sys-tem is in place. Complete images of the virtual server, including the op-erating system configuration, database, and web application software, aretaken on a daily basis. These images are stored by DigitalOcean and areperformed externally to the machine. Access to the backups requires ac-cess to the DigitalOcean account responsible for hosting the CALDC webapplication. Should the virtual machine be unrecoverable due to failure orcompromise, the backup images can also be used to create a new virtual ma-chine, although some post-configuration of DNS records and TLS certificatewould be required. Images are kept for a period of thirty days after theyare taken, allowing the server to be restored to any day in the past month.A weakness in this backup system is the reliance on DigitalOcean; shouldthey suffer catastrophic data loss it is possible backup images would becomeunavailable. Offline storage of a cold backup on a weekly or monthly basisfor longer periods would provide additional recoverability in such an eventand could be achieved with a simple automated script if necessary. OWASPstates that average time to discover a breach in a web server was 191 days,suggesting that the current 30-day backup window is too short to adequately364.4. Development Timelineprotect against a malicious attack of a clandestine nature[OWA17].4.4 Development TimelineAfter the major requirements of the CALDC were established and back-ground research was completed, development of the CALDC application be-gan in 2018, culminating in the initial prototype release in December 2018.This prototype used the Flask framework’s built-in web server to locally hostthe web interface for the software on the user’s machine, while using SQLiteas a local database. This version of the software was distributed internallywithin the PRISM lab for testing and feedback, although at this stage manyfeatures had not yet been implemented, including ecospold support. Severaldrawbacks to the client-side approach were found: it necessitated an updat-ing service of some sort to keep the software updated as changes rolled out,took up large amounts of space due to the packaged WinPython installation,and would still require a separate web interface to facilitate sharing and pub-lishing of LCI data. The client-side version of the software continued withdevelopment until the release of version 1.5, with version 1.6 switching to atraditional web application without the need for a separate application onthe user’s machine.Initial feedback on the user interface and the ease-of-use of the softwarewas taken from internal testing in the PRISM lab, with subsequent versionsof the client-side software provided to select stakeholders for further testing.In addition, version 1.3 of the client-side only software was presented atthe 2019 HOLOS Conference on Sustainability of Canadian Agriculture andfeedback was solicited from those in attendance, which included users withvarying levels of familiarity with Life Cycle Assessment data. Feedback fromthese sessions was then implemented in subsequent client-only versions (1.4and 1.5), in addition to the web-only version of the application, which wasreleased in September of 2019 as the 1.0 beta version.The beta 1.0 version included additional features requested in the feed-back, including the ability to import datasets, the ability to export ecoSpold2formatted datasets, a revamping of the support documentation, and adjust-ments to the user interface to make it more user-friendly. The online versionof the software was subsequently released for public testing in October of2019, and included an online feedback form to solicit additional feedback.This version was provided to stakeholders for the creation of new datasets,as well as advertised on Life Cycle Assessment listserves to get additionalexposure for the software, in addition to feedback. Throughout this pe-374.4. Development Timelineriod additional features and modifications were added, and bug testing wasperformed in conjunction with internal testing in the lab and by externalstakeholders. The final major patch was released in March of 2020, includinga number of small fixes and features, in preparation for a training presenta-tion at the 2020 Conference on Sustainability of Canadian Agriculture thatmonth [Aru20].38Chapter 5Features5.1 Application WorkflowThe CALDC website is primarily split into two major interfaces: Thepublic-facing CALDC database, and the private SimpLCIty application.Datasets may be developed privately within the SimpLCIty application,and then submitted to the CALDC for public release. Once approved, thesedatasets then become available to all users on the public-facing database,allowing datasets to be browsed, downloaded, and used in life cycle assess-ments by the general public. While the two interfaces are linked to allowcreated datasets to be submitted, they serve separate purposes within theCALDC.When a user visits the CALDC website (https://caldc.ca), they firstencounter a splash page that provides portals to both the public and privateinterfaces. The user may choose to log in or register a new account toaccess the SimpLCIty application, or may choose to navigate to the publicCALDC database. Access to the public database does not require that theuser log in or have an account. The public database shares the same basicuser interface as the SimpLCIty application, and allows the user to browse,search, preview, and download public datasets. This interface is discussedin subsections 5.2.15 through 5.2.17.If the user intends to create or edit an LCI dataset, they can instead login or register a new account on the splash page. Account registration is freeof charge and requires only a unique user email address, and a user-providedpassword. Logging in will redirect the user to the SimpLCIty applicationhome page. Within the SimpLCIty application, entered datasets are keptprivately; users only have access to those datasets that they themselveshave created, or are part of the standard reference datasets i.e. the ILCDelementary reference flows. Within the SimpLCIty application, users maycreate new datasets, edit or import existing datasets, browse or view existingdatasets, and export completed datasets. This is done primarily through aunified, step-wise editing system that provides the same interface for creat-ing datasets as well as for editing an existing or imported dataset. Use of395.1. Application WorkflowFigure 5.1: Public-facing CALDC website user flow.the editing system is described in subsection 5.2.8. Once the editing or cre-ation process has been completed the user receives confirmation that theirchange(s) have been made, and may then return to the home page to beginthe workflow process again. A summary of the major features and theirpermission requirements is provided in Table 5.1 below.It should be noted that the Administrator role within the CALDC isnot analogous to a system or software administrator. The Administratorrole is identical to that of a normal user, but an Administrator may also ap-prove or reject datasets (see subsection 5.2.14), and grant the Administratorpermission to other users.The user’s logged-in status is maintained even if the user chooses to leavethe SimpLCIty application. The user may switch from SimpLCIty to thepublic-facing database and then return to SimpLCIty without requiring theuser to log in again. However, if a user has not yet logged in, or has manuallylogged out, they will be required to log in again before they can move fromthe public database into SimpLCIty.The “User intent” decision allows users to pick their flow: Users cancreate, edit, or import datasets, export their datasets, or submit them tothe CALDC for public release. Users are under no obligation to releasedatasets publicly, and datasets that have not been submitted remain pri-vate and viewable only by the logged-in user who created them. The exportoption, detailed in subsection 5.2.9, allows users to privately download acopy of their dataset in the ILCD/EcoSpold2 format(s) without submittingthe dataset for public release. Datasets may only be exported or submittedto the CALDC if they are considered ‘complete’, meaning that all required405.2. Feature WalkthroughTable 5.1: Summary of Features and Permissions.Feature Section Required PermissionLogin 5.2.1 PublicUser Home Page 5.2.2 Logged-in UserUser Options 5.2.3 Logged-in UserBrowsing Datasets 5.2.4 Logged-in UserViewing Datasets 5.2.5 Logged-in UserManaging Datasets 5.2.6 Logged-in UserCreating a New Dataset 5.2.7 Logged-in UserEditing a Dataset 5.2.8 Logged-in UserExporting a Dataset 5.2.9 Logged-in UserImporting a Dataset 5.2.10 Logged-in UserSupport Page 5.2.11 Logged-in UserUser Settings 5.2.12 Logged-in UserSubmitting User Feedback 5.2.13 Logged-in UserUsing the Admin Console 5.2.14 AdministratorPublic CALDC Homepage 5.2.15 PublicNavigating the Public CALDC 5.2.16 PublicViewing and Downloading PublicDatasets5.2.17 Publicfields in the dataset have been filled. Once submitted, the dataset requiresthe approval of an administrator, after which it becomes immediately avail-able in exported form on the public-facing database. Administrators arePRISM lab members or stakeholders tasked with ensuring that submitteddatasets meet the necessary completeness requirements to be publicly re-leased through the CALDC.5.2 Feature WalkthroughThe CALDC provides a number of features, both for creating, editing,and exporting datasets, as well as managing and viewing existing datasets.Features can be broadly classified as being public features, accessible toany user; user-specific features, which require the user be logged in; andadmin-specific features, which are only available to a logged-in user withadministrator permissions.415.2. Feature WalkthroughFigure 5.2: Private-facing SimpLCIty application dataset user flow.5.2.1 Logging InWhen first visiting the web application, the user is provided with a splashpage that includes a login/registration form. From this page, the user maylog in using their chosen email address and password, or register a newaccount with the email and password of their choice. In addition, the splashpage includes some information about the SimpLCIty application, and linksto both the public-facing CALDC interface (“View Public Datasets”), aswell as an external link to the PRISM lab web page. If at any point anunlogged-in user tries to access a page that requires the user to be loggedin, they are automatically redirected to the splash page. Attempting tovisit the splash page while logged in will redirect the user immediately tothe user’s home page.5.2.2 User Home PageWhen a user first logs into the SimpLCIty application, they are di-rected to a home page (/home). This home page includes recent SimpL-CIty/CALDC news, as well as a table of the most recent datasets the userhas created or edited. Clicking on a recent dataset will take the user directlyto the viewing page for that dataset, facilitating quickly accessing recentlyworked-on datasets.425.2. Feature WalkthroughFigure 5.3: CALDC Splash page.On the left-hand side of the page, a vertical navigation menu allows theuser to navigate through the SimpLCIty application, or to move over to thepublic-facing CALDC to download public datasets.5.2.3 Additional User OptionsWhen logged in, the user’s email is displayed in the top navigation barof the page. Clicking on the user’s email will open a drop down menu,providing the option to log out. If selected, the user will be immediatelylogged out and redirected to the CALDC splash page. In addition, if thelogged-in user has administrator privileges, a second link in the drop-downmenu will be available, labelled “Admin Console”, which takes the user tothe administrator’s control panel.5.2.4 Browsing DatasetsThe user can browse datasets that they have created or imported byclicking the “Browse Data” link in the left-hand navigation menu. This willtake the user to the Browse Datasets page (/browse). This page provides apaginated table of datasets belonging to the currently logged-in user. Thetable lists the name, version, type, UUID, and last-modified date for eachdataset, and provides a basic search box that allows users to filter datasets435.2. Feature WalkthroughFigure 5.4: SimpLCIty Application Homepage.Figure 5.5: Dropdown User Menu. Note Admin Console option, denotinga user with administrator permissions.based on search term. Clicking the name of the dataset (shown in blue, todenote a link) will immediately take the user to the viewing page for thatdataset.5.2.5 Viewing DatasetsClicking the name-link for a dataset on your recent datasets (homepage)or on the Browse Datasets page will result in the user being navigated to thedataset viewing page. These pages have the URL format of (/browse/<typeof dataset>/<UUID>). On this page, you will be able to see the values ofeach field in the dataset.The name of the dataset being viewed is provided at the top of the page,and may use either the shortName or baseName field, depending on thetype of dataset. Also at the top of the page will be a banner informing theuser whether the dataset they are viewing is considered complete or not;445.2. Feature WalkthroughFigure 5.6: Browsing datasets page. Results can be filtered based on thesearch term provided.incomplete datasets may not be exported as they lack required data fields.Where a dataset references another dataset (such as a process referencinga flow), SimpLCIty will provide a link to view the referenced dataset. Thisallows users to quickly follow the dependencies of a given dataset. If a field ismissing a value, it will instead be highlighted in red and will display “Empty”in red italics. Note that because some fields are considered optional, it ispossible to have a dataset that is considered complete, but has an emptyfield.It is also possible for a user to view datasets that may not belong to them.Specifically, a user may choose to view an ILCD reference dataset that isused in one of their own datasets. Because the ILCD reference datasets areprimarily stored as files and are static, the contents of the ILCD referenceflow is simply rendered as XML in a standard text window. A warningmessage is displayed to notify the user that they are viewing an un-editable,static dataset.5.2.6 Managing DatasetsIf the user is currently viewing an editable dataset, a “Select Action”button will appear on the upper-right of the page. Clicking it will providetwo possible options: “Edit Dataset”, which will immediately take the userto the editing view for this dataset, or “Submit to CALDC”, which willsubmit the current dataset to the CALDC for review and public release.455.2. Feature WalkthroughFigure 5.7: Viewing a dataset in SimpLCIty.Figure 5.8: Message informing the user this dataset is complete.5.2.7 Creating a New DatasetThe user can create a new LCI dataset by selecting the “Create Dataset”link from the left-hand navigation bar, which will navigate them to the firstdataset creation page (/create-dataset). This page prompts the user to selectwhat kind of dataset they wish to create. Due to dependency ordering inthe ILCD dataset format, a user will first be required to create a Contactdataset and then a Source dataset, before they are able to create Flows,Processes, or Flow Properties.A warning will appear if this applies to the user, informing them theymust first create a Contact and a Source.Once the user has selected the type of dataset they wish to create, click-ing the “Next Step” button will navigate the user into the dataset editinginterface. Before clicking the Next Step button, the user may leave the page,cancelling the dataset creation.465.2. Feature WalkthroughFigure 5.9: An example of a dataset with missing fields in the datasetviewer.Figure 5.10: User viewing a static, non-editable ILCD reference flow.5.2.8 Editing a DatasetWhen creating a new dataset or editing an existing dataset, the interfaceused is the same. During the editing process, the user is presented with anumber of steps. Each step includes attributes for a given topic or sectionof the output data format, i.e. ‘Contact Information’ or ‘AdministrativeInformation’. The user can advance to the next step using the ‘Next Step’button, or return to the previous step using the ‘Previous Step’ button.User-submitted data is saved between steps, making it possible for a user toleave part way through editing and later come back to continue editing. Thestep number, in the form of a progress bar, the title, and a brief descriptionof the step is provided at the top of the page.Each dataset field generates a form field in the editing page, with thetype of form fields including text, email, numeric, select (with both static anddynamically-generated entries, depending on context), and textarea types.All inputs have a short descriptive label provided underneath, as well asadditional information available on mouseover to help identify the necessarycontext and content for a given field. In addition, placeholder values areused in inputs, providing an example to the user of content and format.Limits on input length and required fields are automatically generated475.2. Feature WalkthroughFigure 5.11: Options for managing an existing dataset.Figure 5.12: Graph of dataset dependencies. Solid arrows indicate a re-quired dependency, while dashed arrows represent an optional dependency.as part of the form elements. The forms use standard HTML5 client-sideform validation, which will prevent the user from moving to the next step inthe editing process until all required form fields have been filled. This alsohighlights the required empty fields for the user.Some types of data provide a unique interface, for example the In-put/Output Exchanges for a Process dataset. In this case, the user is pre-sented with a table for entering flow data. The user may add or removerows as needed for the required number of flows using the ‘+’ and ‘-’ but-tons. The first flow (Flow #0) is considered the default reference flow, andis highlighted in green. In each row, the user can select a flow compartmentfrom a dropdown. Choosing a flow compartment will then populate the‘Flow Reference’ dropdown for that row with appropriate User-created andILCD flows that match the specified compartment. The flow reference alsostates the default unit of the flow, i.e. kilograms, grams, liters, etc. Theuser can then choose the flow direction (Input or Output), and the meanand resulting amounts for that flow.The final editing step for each dataset type replaces the ‘Next Step’button with a ‘Finalize Dataset’ button. Once clicked, this will take the485.2. Feature WalkthroughFigure 5.13: Picking dataset type to create.Figure 5.14: Warning message informing the user they must first create aContact dataset.user to a confirmation page, informing the user that data entry is complete.It includes a direct link to the dataset viewing page via ‘My Dataset’, aswell as a ‘Return Home’ button that will return the user to the home page.5.2.9 Exporting a DatasetThe user can export a completed LCI dataset using the “Export Dataset”link from the left-hand navigation bar, which will take them to the exportdataset interface (/export-dataset). The export dataset interface providesthe user with a dropdown selection input, listing the type and name of eachcompleted dataset belonging to the user. Datasets may only be exportedif they include all required fields and are thus ‘complete’ – see subsection5.2.5 for the interface shown on complete datasets in viewing mode. Once the495.2. Feature WalkthroughFigure 5.15: Typical dataset editing interface, showing step 1 of creating aContact dataset.user has selected a dataset from the dropdown, clicking the ‘Export Dataset’button will result in a download prompt for the compressed dataset.During export, SimpLCIty will automatically find all required depen-dencies for the dataset and package them together into a ZIP archive usingthe ILCD format, named ‘ILCD’, allowing import directly into OpenLCA.The dependency-finding process will include both all necessary user-createddatasets, as well as supporting ILCD reference datasets. If the exporteddataset is of the Process type, it will also include a .SPOLD file, which isthe ecoSpold2-formatted Activity with ecoInvent nomenclature. Both the‘ILCD’ ZIP file and the SPOLD activity profile are compressed into a singleZIP, which is then downloaded by the user.Once downloaded, the user only needs to decompress the outer ZIP file.From there, the user may choose to use either the SPOLD formatted export,or the ILCD formatted export. Choice of which dataset format is used maydepend on the user’s preferred LCA software suite, and the nomenclatureand format used by other datasets.505.2. Feature WalkthroughFigure 5.16: Example of placeholder text, label, and mouseover tooltip.Figure 5.17: Example of form validation, highlighting the missing requiredfield.5.2.10 Importing a DatasetSimpLCIty also provides an interface for importing existing datasets,which can be reached by selecting ‘Import Dataset’ in the left-hand nav-igation menu, and takes the user to the import page (/import-dataset).Datasets may be imported as single XML files, either as an ILCD-formatteddataset (Contact, Source, Flow, Process, etc), or as an ecoSpold2 Activity,which will be imported as a Process. The user may upload a file by draggingand dropping it onto the ‘Upload a file’ button, or by clicking the buttonand finding the file through a navigator.Once the user has selected a file for upload, they can select the ‘ImportDataset’ button to import. This will immediately take the user to an editingpage with an interface identical to that used when editing an existing dataset(see subsection 5.2.8). The editing interface will fill out all fields identifiedfrom the imported dataset, while allowing the user to enter any missing data.Datasets that are ‘complete’ and have all required fields when imported willnot require additional data entry, while incomplete datasets will. Note that ifdatasets are imported, they should be imported in order of dependency, suchthat datasets that are dependent on other datasets are imported afterwards,to preserve the links between datasets.515.2. Feature WalkthroughFigure 5.18: An example of the Input/Output exchange interface, showingdropdown flow reference options.Figure 5.19: The dataset confirmation page shown after editing a dataset.5.2.11 Support PageIn order to be more user-friendly, SimpLCIty includes a basic supportpage that provides answers to questions users may have about using theservice. This includes information about what the SimpLCIty applicationdoes, how to use it, error descriptions, and general information regardingusage of the application. This page can be navigated to using the ‘Support’link in the left-hand navigation menu, which takes you to the support page(/support).The support page includes a topic list of links, which will automaticallyscroll the user to the corresponding topic on the support page.5.2.12 Managing User SettingsUser settings are available under the ‘Settings’ link in the left-hand nav-igation menu, which will take you to the settings page (/settings). The525.2. Feature WalkthroughFigure 5.20: Export dataset interface, including download of the ZIP-compressed dataset.user settings page allows configuration of user-specific settings, which aresaved in the database and persist between user sessions. Currently, the onlyuser setting available is the choice to ‘Use Mapped Flows Only’. Whenset to ‘True’, choice of ILCD reference flows in the Input/Output exchangeinterface (see subsection 5.2.8) will be limited to those flows that have anavailable ILCD-to-ecoInvent mapping, as described in the flowmap table (seesubsection 4.2.4). This setting is ‘True’ by default.If the user selects ‘False’, all ILCD reference flows will be available whencreating an Input/Output exchange. However, use of unmapped ILCD ref-erence flows will result in interoperability issues when exporting a dataset,as not all flows will be mapped to ecoInvent nomenclature. Once a user hasselected their preference, they can click the ‘Save Settings’ button, whichwill save the current settings into the database and refresh the page.5.2.13 Submitting User FeedbackSimpLCIty includes a built-in feedback function, allowing users to anony-mously submit feedback. The feedback page (/feedback) is available by se-lecting ‘Provide Feedback’ from the left-hand navigation menu. On thispage, the user is presented with several questions to gauge user interest inSimpLCIty and the CALDC, as well as provide a rating for the SimpLCItyapplication. The user is also provided with free-text inputs to suggest fea-tures, describe problems or bugs with the application or its datasets, as wellas provide any other comment on the software.535.2. Feature WalkthroughFigure 5.21: Contents of an exported Process ZIP file, showing SPOLD fileand ILCD ZIP with hierarchy.Once a user has provided feedback, they can click the ‘Submit Feedback’button to submit. There is no requirement that the user completely fill outthe feedback form. When the feedback has been successfully submitted, anotification is provided to the user informing them that it has been success-fully saved. User feedback is stored in the feedback table in the form of aJSON-encoded object. The feedback table does not store any informationon the submitting user, ensuring that feedback is collected anonymously andcannot be linked back to a user account.5.2.14 Using the Admin ConsoleClicking the ‘Admin Console’ link from the drop-down user menu de-scribed in subsection 5.2.2 will take the user the administration page (/ad-min). Only users that have the administrator permissions may access thispage. Here, the user may view and approve datasets submitted to theCALDC for public release, view approved datasets, and add new admin-istrators.The first table presented to the user shows datasets that users have sub-mitted using the ‘Submit to CALDC’ dropdown menu item on the viewingpage. The table includes the UUID, type of dataset, dataset name, the sub-mitting user’s email, and the time that the dataset was last submitted. Thetable can be paginated, sorted, and searched by the user.545.2. Feature WalkthroughFigure 5.22: The Import dataset interface.Clicking the ‘UUID’ link will download an exported copy of the submit-ted dataset with all dependencies, identical to that produced by the ExportDataset interface. This allows an administrator to download the submitteddataset for review in LCA software of their choice. Clicking the ‘Submit-ted By’ email link will automatically open up the administrator’s defaultmail utility to send an email to the user, should the administrator need torequest additional information from the submitting user. Once an admin-istrator has decided whether the dataset meets the necessary completenesscriteria, they can then select either ‘Approve Dataset’ or ‘Decline Dataset’from the dropdown ‘Actions’ menu.If a dataset is declined, it will be removed from the submissions ta-ble. The submitting user will then need to edit or revise their dataset andre-submit it for review. If a dataset is approved, the dataset will be re-moved from the submissions table, and will instead appear in the ‘ApprovedDatasets’ table underneath. The ‘Approved Datasets’ table can also be pagi-nated, searched, and sorted, and allows administrators to view datasets thathave already been accepted. Once a dataset has been approved, it will beimmediately listed on the public-facing CALDC database.Finally, the Admin Console also allows an administrator to add addi-tional administrators. A table of all administrators, listed by email address,is displayed at the bottom of the page. A dropdown input lists all non-administrator users by email. To give administrator privileges to a user, theadministrator can select the user from the dropdown menu, and then clickthe ‘Add Administrator’ button. This will refresh the page, and the new555.2. Feature WalkthroughFigure 5.23: The Support page, showing the topic listing and initial topics.Figure 5.24: The Settings page, showing the ’Use Mapped Flows Only’setting.administrator will now appear in the ‘Current Admins’ table. All adminis-trators may approve or decline datasets, as well as add new administrators;it is therefore recommended that only those users actively involved in datasetreview are given administrator privileges.5.2.15 Public CALDC HomepageThe public CALDC database provides access to approved datasets forall users, without requiring a login. There are two ways of accessing thepublic CALDC: if the user is already logged into SimpLCIty, they can selectthe ‘Go To CALDC’ option at the bottom of the left-hand navigation menu.565.2. Feature WalkthroughFigure 5.25: Feedback page, showing Agree/Neutral/Disagree interface forfeedback.Figure 5.26: Success message upon submitted user feedback.Alternatively, the user can click the ‘View Public Datasets’ button on thesplash page, without registering or logging in. In both cases, the user willbe redirected to the public CALDC home page at /public/home.The public CALDC pages maintain the same format and style as thoseused in the SimpLCIty application. The home page provides some generalsummary statistics, such as total number of datasets being hosted, the totalnumber of each type of dataset, and when the last new dataset was approvedfor each type. It also provides a brief explanation on what the CALDC is,and how it relates to the SimpLCIty application. The user can navigateback to this page using the ‘About’ link in the left-hand navigation menu.575.2. Feature WalkthroughFigure 5.27: The submissions table in the Admin Console interface.Figure 5.28: The action menu allows an administrator to approve or declinea submitted dataset.5.2.16 Navigating the Public CALDCThe public CALDC allows users to browse datasets based on type ofdataset. The left-hand navigation menu provides links based on datasettype. Selecting a type will take the user to a listing of all publicly availabledatasets of that type in the CALDC. These listings include the name ofthe dataset, the dataset UUID, and the date that it was submitted to theCALDC. These listings can be paginated, searched, and sorted by the user– for example, the user may sort based on submission time to get the newestdatasets, or search for a specific UUID or dataset name. Clicking the ‘Name’link for a specific dataset will redirect the user to the public viewing pagefor that dataset.Each of these pages can be described using the URL format /pub-lic/data/<type>, where type describes an ILCD dataset type which willbe listed on that page. In addition, the ‘Go to SimpLCIty’ link at the bot-585.2. Feature WalkthroughFigure 5.29: The ’Approved Datasets’ table, showing datasets that havebeen publicly released in the CALDC.Figure 5.30: The administrator management interface, showing existingadministrators and allowing new administrators to be specified.tom of the left-hand navigation menu will allow a user to navigate back tothe SimpLCIty application. If the user is already logged in, they will beredirected to the SimpLCIty home page, otherwise they will be returned tothe splash page to either log in, register an account, or navigate elsewhere.5.2.17 Viewing and Downloading Public DatasetsWhen a user clicks a ‘Name’ link in the Public Dataset tables, theywill be redirected to the viewing page for that dataset. This viewing pageis similar to viewing a dataset in SimpLCIty, but provides the user withdifferent options. Dataset views have the following URL format: /pub-lic/data/detail/<type>/<UUID>. On this page, the user is presented witha table consisting of data field names and values. This table can be pagi-nated, sorted, and searched for specific data. Dependent or linked datasetssuch as Contacts, Flows, or Sources are rendered as links which will redirect595.2. Feature WalkthroughFigure 5.31: The ’View Public Datasets’ button available on the splashpage will take the user to the public CALDC.Figure 5.32: The CALDC public home page.the user to the viewing page for the dependent dataset.At the top of the page, a ‘Download Now’ button is provided. Clickingthis button will prompt the user to download the complete ZIP version of thedataset, identical to that produced through the export function as describedin subsection 5.2.9. In addition, a message will be shown specifying whattype of dataset is available; if the dataset is a Process, it will also includethe ecoSpold2 equivalent Activity in the export and this will be noted in themessage.When navigating to other datasets listed as dependencies, behaviour maychange depending on whether the dataset has been made public, or is part ofthe ILCD standard datasets, such as ILCD elementary flows or unit groups.If a dataset has been included in a published dataset, but it has not yet605.2. Feature WalkthroughFigure 5.33: Public listing of processes available in the CALDC.Figure 5.34: Example of a public viewing page for a process dataset, show-ing the field values it contains.been submitted or approved, the dataset will be included as a dependencywhen the published dataset is exported. However, the unpublished datasetwill not be available through the public viewer, instead returning an errormessage stating that the dataset is not yet publicly available. If the datasetthe user wishes to view is part of the static ILCD reference files, the datasetwill be shown, but in a plain XML format. In addition, it will include awarning informing the user that the dataset is part of the ILCD standardreference datasets.615.2. Feature WalkthroughFigure 5.35: ’Download Now’ button and message informing the user thedataset will contain both ILCD and EcoSpold2 formatted datasets.Figure 5.36: Example of viewing an ILCD reference flow in the publicCALDC.62Chapter 6Discussion andRecommendationsAs part of the development of the CALDC, a set of recommendationswere developed, designed to promote interoperability, good technical prac-tice, and the use of third-party database distributors. These recommen-dations were subsequently presented and published at the LCA Food 2018Conference as well as in the International Journal of Life Cycle Assessment.The recommendations are designed to be general guidelines for new LCIdatabase initiatives, with focus being primarily on ensuring that datasetsproduced for these initiatives are interoperable with other data sources.Not all of the recommendations made were implemented within theCALDC, or were only partially implemented. This was due to both timeconstraints in development, as well as a lack of implementable solutions forsome issues, such as the mapping of EcoSpold2 and ILCD flows. Wherethe recommendations have not been implemented represents areas for po-tential future updates to the CALDC database system, as well as areas ofLCA interoperability that require additional research. While the CALDCpresents a new approach to LCI database development in promoting interop-erability and the inclusion of the ability to create and edit datasets withinthe database application itself, there remain unresolved issues in the LCIdatabase field that will require further consensus among the LCA commu-nity to solve.With the public release of the CALDC, external users have begun tomake use of the application. User uptake is summarized in Table 6.1 below.Due to the relatively niche application of the CALDC and the short timesince release, current user count remains low. In addition, very little userfeedback has been provided, consisting of only nine user feedback reports.Much of this feedback was generated during the internal and stakeholdertesting phases, and represents bugs and/or features that have since beenpatched prior to public release. It is our hope that we will continue toreceive feedback on the web application as more users have a chance to usethe CALDC and SimpLCIty.636.1. Interoperability RecommendationsTable 6.1: Total Counts as of July 2020.Metric Total CountRegistered Users 130User-Created Flows 143User-Created Contacts 44User-Created Processes 57Datasets Approved 896.1 Interoperability RecommendationsReviewing the present state of interoperability in the LCI database field,it becomes apparent that developers of a new LCI database must weighthe benefits and costs of creating an interoperability system. While thebenefits of some interoperability measures are abundantly clear, others arepotentially too new, or too costly, to merit inclusion in the initial release of anew LCI database. However, the potential costs in terms of time and effortconverting data to be included within these services at a later date, amongeither dataset creators or database administrators must also be considered.In this regard, the changing landscape of the LCI database field, particularlyin terms of newer semantic data schemes and third-party data providers,requires consideration. The summary of these recommendations is presentedin Table 6.2.It is clear that the two most accepted formats for data exchange in theLCI field are the EcoSpold2 and ILCD formats. For this reason, both wereimplemented in the CALDC. Other new LCI database initiatives should sim-ilarly support both formats from the outset to ensure maximum databaseinteroperability, as well as compatibility with current LCA software suites.The development of data collection/provision templates that contain allfields required for both formats is therefore strongly recommended. Thismay result in a more resource-intensive LCI data compilation and report-ing process, but is ultimately necessary for interoperability across databasesusing these formats. It is essential that loss of data during conversion fromone format to the other is avoided for those fields which do not have anequivalent across the two formats. This system of using an intermediatedata collection format has been implemented in the CALDC, showing theability to perform lossless conversion into both EcoSpold2 and ILCD at thecost of slightly more intensive data entry.In addition to EcoSpold2 and ILCD, other dataset formats exist, such646.1. Interoperability RecommendationsTable 6.2: Recommendations for LCI Database Initiatives.Consideration RecommendationFormat Provide, at a minimum, datasets in both the ILCDand EcoSpold 2 formats in XML encoding, considerproviding datasets in JSON format.Nomenclature Enforce use of a subset of common nomenclatures, par-ticularly the ILCD and EcoSpold nomenclatures, withnomenclature choice dependent on popularity and us-age in other databasesThird-PartyProvidersNetworks & Integrate datasets with third-partyproviders where possible, particularly those with lowbarrier to entry such as ecoinvent and OpenLCA. As-sess cost/benefit ratio of third-party network integra-tion such as LCDN and GLAD, integrate early to min-imize necessary dataset conversions.Third-Party Ini-tiativesFollow recommended practices in the UNEP/SETACGlobal Guidance Principles for data documentation,review, and quality.Technical Imple-mentationImplement the LCI database using proven databaseand web development technologies, such as SQL, Mi-crosoft IIS, Apache/NGINX, etc. Implement APIswhere possible to expose underlying database infor-mation to developers and users.as the proprietary CSV format used by the SimaPro LCA software. WhileLCA software suites usually support either ILCD or EcoSpold2 import, orboth, it may be beneficial in the future to consider the ability to also exportdatasets in these formats. This would ease the integration of data froman LCI database into a practitioner’s LCA software, but potentially createsadditional interoperability issues with regard to nomenclature.XML is currently the standard encoding. However, also providing data inJSON-LD is recommended so as to facilitate interoperability with databasesthat have moved to the JSON-LD format, such as the USDA LCA Com-mons. This would also allow for easier parsing and semantic data work.JSON-LD data would also be ideal for a public API, as the lower overheadwould reduce bandwidth requirements and be easily parsed with standardJSON parsers. While the JSON-LD encoding does not share the same pop-ularity as XML encoding, it would be in the interest of LCI database initia-656.1. Interoperability Recommendationstives to support it as a means of future-proofing should JSON-LD becomea more predominant encoding for LCA data. While the CALDC does notcurrently support JSON-LD encoding, it would be relatively trivial to im-plement. JSON enjoys good, built-in support in the Python environmentthat underlies the CALDC, and data is primarily stored in a neutral formatwithin the database, making creation of a JSON-LD encoded object fairlystraightforward. Implementation of this feature in the future would helpensure that datasets developed and distributed through the CALDC canalso be distributed alongside other JSON-LD datasets through third-partyinitiatives that have adopted this encoding.In terms of nomenclature, it is highly desirable that all new LCI databases,including the CALDC, enforce the use of a specified set of common nomen-clatures from the outset, with mapping between each to allow for conversionvia semantic cataloging or simple equivalence matrices. Ideally, LCI datashould be downloadable in multiple nomenclatures to ensure interoperabilitywith LCI databases sourced from third parties and their effective integrationusing common LCA software. However, this would require further advance-ment of existing LCI nomenclature mappings, or the widespread adoptionof a single nomenclature standard across the LCA field. Until such map-pings are made available or a singular format is adopted, the best strategyin terms of nomenclature is to use one that is already popular (such as theILCD or ecoinvent nomenclatures), and use the mappings that do exist toprovide conversion where possible.Nomenclature within the CALDC is currently restricted to the use ofILCD elementary reference flows, and a subset of EcoSpold2 reference flowsthat have been mapped. This mapping is not ideal, as many ILCD refer-ence flows remain unmapped and thus unusable when creating EcoSpold2-compatible datasets. The mapping of LCA nomenclatures is an active topicof research within the LCA community, and it may be necessary in the fu-ture to update the mappings within the CALDC should a better mappingbecome available. In addition, alternative approaches, such as the use ofsemantic cataloging or the development of a ‘universal’ nomenclature, maybecome feasible in the future. It will be necessary for the CALDC to remainup-to-date on existing mappings and nomenclature solutions to ensure thatdatasets remain interoperable.666.2. Technical Recommendations6.2 Technical RecommendationsThe choice of actual software for web architecture as well as back-endsoftware is unimportant for interoperability. As such, choice of database,web framework, and web server should be predicated on the stability andlongevity of the software. Apache, Microsoft IIS, MySQL and MSSQL areall mature software packages with a long history of use in web database ap-plications and would be suitable for development of new LCI databases suchas the CALDC. Providers may also consider the LCA Collaboration Server,LCDN, and GLAD networks as alternatives to developing a standalone LCIdatabase system; this would reduce the time and expense of development,allowing those expenditures to be directed towards dataset development.This also has the effect of making it easier for smaller data providers to en-ter the LCI database field. New LCI databases should, however, include anextensive API that allows full access to the datasets and metadata in bothXML and JSON-LD formats. APIs have become commonplace in web devel-opment as a means of facilitating third party support. The ability for thirdparties to develop applications that pull data directly from the databasewould promote the creation of new LCA utilities at no further expense tothe maintainers of the database. In addition, this would further promoteopen, public distribution of LCI data, a core concept for the CALDC andany other public LCI database.In terms of technical implementation, the CALDC is typical of a mod-ern, database-driven web application. Use of a common language and webframework, in the form of Python/Flask, helps ensure that code will bemaintainable in the future; while the use of enterprise and open-source soft-ware such as the Apache web server and MariaDB SQL database ensurecontinuing software support and updates. These choices of software andback-end scripting language do not directly impact the interoperability of theCALDC, but instead ensure the longevity and stability of the LCI databaseapplication, which should be of concern to any LCI database developer.While a public API has not been implemented within the CALDC, theweb application largely relies on an underlying routing schema that couldeasily accommodate the development of a documented, public API. As theCALDC continues to grow, the development of a public API would allowthird parties as well as practitioners to programmatically fetch datasetsreleased through the CALDC, potentially easing the integration of CALDCdatasets into third-party databases and initiatives.676.3. Third Party Data Providers and Initiatives Recommendations6.3 Third Party Data Providers and InitiativesRecommendationsAt the external level, new LCI database initiatives should work withthird party data providers to further increase the reach of their data andensure interoperability with existing datasets. As both ILCD and EcoSpold2 formats should already be supported, there are minimal costs to submit-ting the data to the ecoinvent and OpenLCA Nexus providers, assuming thatnomenclatures are chosen that will function properly with these providers.The ability to have additional datasets immediately available to populatebackground processes is a convincing argument for their inclusion as interop-erability measures, particularly in the case of OpenLCA Nexus, where muchof the data conversion and packaging work is handled by a third party. LCIinitiatives should also strongly consider participation in a network-based LCIdatabase such as the LCDN, GLAD, or the LCA Commons. In particular,the ability to submit datasets directly through tools such as the Soda4LCAapplication or the LCA Collaboration Server means that datasets could po-tentially be shared across multiple networks with relatively little effort.Presently, the CALDC has only been in public release for a short periodof time, and only a small selection of datasets have been publicly released.As a result, the CALDC has not yet integrated its datasets with any third-party databases or initiatives. The lack of an appropriate mapping betweenEcoSpold2 and ILCD in particular limits the ability to immediately submitdatasets to the ecoinvent database, as ILCD reference flows used within theCALDC may not be automatically mapped to an appropriate EcoSpold2flow, requiring manual intervention to ensure interoperability. Until a bet-ter mapping is available, this will necessarily restrict the ability to submitdatasets to alternative providers to those datasets that use only properly-mapped flows.As the number of datasets available through the CALDC continues togrow, it is recommended that third parties be approached to ensure thatdatasets enjoy a wide distribution through other databases, where LCApractitioners who are not aware of the CALDC may find them. Of partic-ular interest is the LCA2 Initiative, which seeks to create a Canadian LCIdatabase for all materials used and produced in Canada. This is a muchlarger scope than the CALDC, and it may be possible to integrate most ifnot all of the datasets produced through the CALDC into the LCA2 Initia-tive, providing users with a more centralized repository for Canadian LCIdata.68Chapter 7ConclusionAs ecological concerns associated with industrial activity continue togrow the further expansion of the Life Cycle Assessment field seems in-evitable. As new database providers and initiatives continue to come on-line, LCA practitioners are able to call upon a growing library of datasets.Despite the growing amount of data being made available, the research sug-gests that barriers remain to the effective sharing and re-use of Life CycleInventory datasets between practitioners. This research identified key areasof interoperability that negatively impact the ability to effectively integratedatasets into existing models. Where possible, these issues were addressed inthe development of the Canadian Agri-food Life Cycle Data Centre, whichserves as a demonstration of potential solutions to interoperability problemsin the LCA domain.This thesis serves as both documentation for the development and us-age of the CALDC, as well as a set of recommendations for developing newLCI database applications. Based on background research, prototype de-velopment, and consultation with other LCA database providers, it was de-termined that the underlying application software was not of concern withregards to interoperability. Rather, it was determined that differences inboth file format, between databases and LCA software, as well as the useof multiple nomenclatures posed the most significant barriers to the re-useof LCI data sets. To this end, an application called SimpLCIty was devel-oped to allow the use of standardized ILCD nomenclature and format, withmapping allowing for the simultaneous creation of EcoSpold2 datasets. Thisapplication was integrated directly into the CALDC, allowing datasets to becreated, edited, viewed, and downloaded through a single online interface.In terms of computer science, the novelty of this research stems fromthe research domain itself. The field of Life Cycle Assessment is heavilybased on analytical calculation and estimation; it is an extremely data-driven process, often requiring very large inventories of data. The lackof a single standardized format or nomenclature introduces difficulties indeveloping an interoperable system, requiring extensive research of existingLCI data formats and the development of new mappings between formats.69Chapter 7. ConclusionIn addition, due to the frequent need to create many datasets for an LCAstudy, the idea of making data entry more efficient and user-friendly alsohas merit. At this time, SimpLCIty is the only fully-online applicationfor the development of ILCD or EcoSpold2 datasets, providing a simple,step-by-step interface to create and modify datasets. While not a completesolution to the interoperability challenges that LCA faces, the CALDC andthe SimpLCIty application represent a positive step forward towards greaterformat support and dataset sharing.In conclusion, a data entry web application and database were devel-oped for the creation and storage of LCA datasets. In doing so, it wasnecessary to develop solutions to interoperability problems that would pre-vent the easy integration of CALDC data into existing LCA models. Whilethe CALDC implements a basic mapping of ILCD flows to EcoSpold2 flowsfor cross-compatibility, it remains incomplete. In developing the CALDC,the application alleviates many interoperability issues through the use offormat and nomenclature mapping, but it cannot be said that these issueshave been entirely resolved. Further effort in mapping existing nomencla-tures would be necessary for the CALDC to become truly interoperable.Nevertheless, the application serves as a new and novel approach to the de-velopment of an LCA database and data entry application while addressinginteroperability concerns.70Bibliography[Aru20] Vivek Arulnathan. Simplcity training. In Sustainability ofCanadian Agriculture Conference, March 12-13, 2020 March12-13, 2020. → pages 38[BGC19] Jonas Bunsen, Sebastian Greve, and Andreas Ciroth. Lca col-laboration server user manual and introduction. Technical re-port, GreenDelta GmbH, January 2019. → pages 11[BPSM+08] Tim Bray, Jean Paoli, C. M. Sperberg-McQueen, Eve Maler,and Franc¸ois Yergeau. Extensible markup language (xml) 1.0(fifth edition). Technical report, World Wide Web Consortium(W3C), November 2008. → pages 9[Bre99] Rolf Bretz. Setac lca workgroup: Data availability and dataquality. The International Journal of Life Cycle Assessment,4(1):15, Jan 1999. → pages 8[CAC+17] Andreas Ciroth, Peter Arbuckle, Edivan Cherubini, CassiaUgaya, and Ashley Edelen. . Technical report, UNEP, June2017. → pages 13[CAM+15] Vincent Colomb, Samy Ait Amar, Claudine Basset Mens,Armelle Gac, Ge´rard Gaillard, Peter Koch, Jerome Mousset,Thibault Salou, Aure´lie Tailleur, and Hays M.G van der Werf.Agribalyse®, the french lci database for agricultural products:high quality data for producers and environmental labelling.OCL, 22(1):D104, Jan 2015. → pages 25[CEF+03] Raul Carlson, Markus Erlandsson, Karolina Flemstro¨m, Ann-Christin P˚alsson, and Johan Tivander. Data format mappingbetween spine and iso/ts 14048. Technical report, ChalmersUniversity of Technology, Go¨teborg, 2003. → pages 871Bibliography[CF06] Joyce Smith Cooper and James A. Fava. Life-cycle assessmentpractitioner survey: Summary of results. Journal of IndustrialEcology, 10(4):12–14, Oct 2006. → pages 1[CTSL98] Raul Carlson, Anne-Marie Tillman, Bengt Steen, and Go¨ranLo¨fgren. Lci data modelling and a database design. The Inter-national Journal of Life Cycle Assessment, 3(2):106–113, Mar1998. → pages 6[Cur04] M. Curran. The status of the life-cycle assessment as anenvironmental management tool. Environmental progress,23(4):277–283, 2004. → pages 8[dBG02] Hans P. de Bruijn and Jerome B. Guine´e. Handbook on lifecycle assessment, volume 7. Kluwer Acad. Publ, Dordrecht,2002. → pages 4, 5, 6, 7[EIR+17] Ashley Edelen, Wesley W. Ingwersen, Cristina Rodr’iguez, Ro-drigo A. F. Alvarenga, Artur Ribeiro de Almeida, and GregorWernet. Critical review of elementary flows in lca data. TheInternational Journal of Life Cycle Assessment, Jul 2017. →pages 9[Exc18] Stack Exchange. Stack overflow developer survey results, 2018.→ pages 23[FIT+06] Matthias Finkbeiner, Atsushi Inaba, Reginald Tan, Kim Chris-tiansen, and Hans-Ju¨rgen Klu¨ppel. The new international stan-dards for life cycle assessment: Iso 14040 and iso 14044. TheInternational Journal of Life Cycle Assessment, 11(2):80–85,Mar 2006. → pages 4[FKL16] Simone Fazio, Oliver Kusche, and Zampori Luca. Life cycledata network - handbook for data developers and providers.Technical report, Publications Office of the European Union,2016. → pages 10[FR05] Rolf Frischknecht and Gerald Rebitzer. The ecoinvent databasesystem: a comprehensive web-based lca database. Journal ofCleaner Production, 13(13):1337–1343, 2005. → pages 24, 25[GHH+11] Jeroen B. Guine´e, Reinout Heijungs, Gjalt Huppes, AlessandraZamagni, Paolo Masoni, Roberto Buonamici, Tomas Ekvall,72Bibliographyand Tomas Rydberg. Life cycle assessment: past, present, andfuture. Environmental science & technology, 45(1):90–96, Jan1, 2011. → pages 3[GM18] Grinberg and Miguel. Flask Web Development. O’Reilly, Se-bastopol, 2 edition, Mar 5, 2018. → pages 29[HBOM17] Michael Z. Hauschild, Anders Bjørn, Mikolaj Owsianiak, andChristine Molin. Life Cycle Assessment. Springer InternationalPublishing AG, Cham, 2017. → pages 1[HGH+14] Patrik Henriksson, Jeroen Guine´e, Reinout Heijungs, Arjande Koning, and Darren Green. A protocol for horizontal av-eraging of unit process data—including estimates for uncer-tainty. The International Journal of Life Cycle Assessment,19(2):429–436, Feb 2014. → pages 7[HHD+15] Patrik J. G. Henriksson, Reinout Heijungs, Hai M. Dao, Lam T.Phan, Geert R. de Snoo, and Jeroen B. Guine´e. Product car-bon footprints and their uncertainties in comparative decisioncontexts. PloS one, 10(3):e0121221, 2015. → pages 7[IHT+15] Wesley Ingwersen, Troy Hawkins, Thomas Transue, DavidMeyer, Gary Moore, Ezra Kahn, Peter Arbuckle, Heidi Paulsen,and Gregory Norris. A new data architecture for advancing lifecycle assessment. The International Journal of Life Cycle As-sessment, 20(4):520–526, Apr 2015. → pages 8, 27[ISO06] ISO. Environmental management, life cycle assessment, re-quirements and guidelines, 2006. → pages 5, 6, 7[JE17] JRC-EPLCA. European life cycle database, 2017. → pages 28[JI10] JRC-IES. General guide for life cycle assessment : Detailedguidance, 2010. → pages 6, 7, 9[JI12] JRC-IES. International reference life cycle data system (ilcd)data network compliance rules and entry-level requirementsversion 1.1. Technical report, Publications Office of the Eu-ropean Union, 2012. → pages 10[JI18] JRC-IES. European life cycle database, June 2018. → pages 973Bibliography[KDRJ16] Brandon Kuczenski, Christopher B. Davis, Beatriz Rivela, andKrzysztof Janowicz. Semantic catalogs for life cycle assessmentdata. Journal of Cleaner Production, 137:1109–1117, Nov 2016.→ pages 7, 27[Kel07] Daniel Kellenberger. Modelling principles for the collectionof consistent and comprehensive lci data, November 2007. →pages 8[KG14] Walter Klo¨pffer and Birgit Grahl. Life Cycle Assessment(LCA) : A Guide to Best Practice. Wiley-VCH, Weinheim,1 edition, Mar 21, 2014. → pages 5, 6[KL14] Walter Klo¨pffer. Background and future prospects in life cycleassessment. Springer, Dordrecht, 2014. → pages 4[Kne18] Ralf Kneuper. Software Processes and Life Cycle Models.Springer, Cham, 1st ed. 2018 edition, 2018. → pages 20, 22[LBG18] Shaobo Liang, Richard Bergman, and Hongmei Gu. Workflowfor publishing forestry lci data through the lca commons a casestudy. Technical report, United States Department of Agricul-ture, October 2018. → pages 11[LHPC15] Se´bastien Lasvaux, Guillaume Habert, Bruno Peuportier, andJacques Chevalier. Comparison of generic and product-specificlife cycle assessment databases: application to construction ma-terials used in building lca studies. The International Journal ofLife Cycle Assessment, 20(11):1473–1490, Nov 2015. → pages5[LILS04] National Renewable Energy Laboratory, Athena Sustain-able Materials Institute, Franklin Associates Ltd., and Sylvat-ica. U.s. lci database project - user’s guide. Technical report,National Renewable Energy Laboratory, February 2004. →pages 25[LS16] Pascal Lesage and Re´jean Samson. The quebec life cycle inven-tory database project. The International Journal of Life CycleAssessment, 21(9):1282–1289, Sep 2016. → pages 1, 12[MMBV16] Ingo Meinshausen, Peter Mu¨ller-Beilschmidt, and Tobias Viere.The ecospold 2 format—why a new format? The International74BibliographyJournal of Life Cycle Assessment, 21(9):1231–1235, Sep 2016.→ pages 8, 9[MMC06] Karl MacMillan, Frank Mayer, and David Caplan. Selinuxby example: using security enhanced linux. Technical report,Prentice Hall, 2006. → pages 34[Mor17] K. Moriarty. Pkcs #5: Password-based cryptography specifi-cation. RFC 8018, IETF, 1 2017. → pages 35[MSO17] Brenda Macdougall and Nicole St-Onge. Digital archivedatabase project summary, 2017. → pages 29[MT15] Marcelle C. McManus and Caroline M. Taylor. The changingnature of life cycle assessment. Biomass and Bioenergy, 82:13–26, Nov 2015. → pages 3, 4[NRL+14] Thomas Nemecek, Vincent Rossi, Jens Lansche, SebastienHumbert, and Patrik Mouron. World food lca databasemethodological guidelines for the life cycle inventory of agri-cultural products. Technical report, Quantis and Agroscope,July 2014. → pages 25[NSA+17] Bruno Notarnicola, Serenella Sala, Assumpcio´ Anton, Sarah J.McLaren, Erwan Saouter, and Ulf Sonesson. The role of lifecycle assessment in supporting sustainable agri-food systems:A review of the challenges. Journal of Cleaner Production,140:399–409, Jan 2017. → pages 5[Ope15] OpenLCA/GreenDelta. Openlca format converter, 2015. →pages 9, 27, 33[Ope18] OpenLCA/GreenDelta. Openlca nexus, 2018. → pages 11[oW] University of Waterloo. Canadian raw materials database. →pages 1[OWA17] OWASP. Owasp top ten, 2017. → pages 34, 37[Owe06] Michael Owens. The Definitive Guide to SQLite. Apress, Berke-ley, CA, 2006 edition, 2006. → pages 30[PAB+15] Nathan Pelletier, Fulvio Ardente, Miguel Branda˜o, Camillo DeCamillis, and David Pennington. Rationales for and limitations75Bibliographyof preferred solutions for multi-functionality problems in lca: isincreased consistency possible? The International Journal ofLife Cycle Assessment, 20(1):74–86, Jan 2015. → pages 4[Pel] Nathan Pelletier. Prism lab. → pages 2[RBF+15] Marco Recchioni, Gian Blengini, Simone Fazio, Fabrice Math-ieux, and David Pennington. Challenges and opportunities forweb-shared publication of quality-assured life cycle data: thecontributions of the life cycle data network. The InternationalJournal of Life Cycle Assessment, 20(7):895–902, Jul 2015. →pages 1[REF+04] G. Rebitzer, Tomas Ekvall, R. Frischknecht, D. Hunkeler,G. Norris, T. Rydberg, W-P Schmidt, S. Suh, B. P. Weidema,and D. W. Pennington. Life cycle assessment - part 1: Frame-work, goal & scope definition, inventory analysis, and applica-tions. 2004. → pages 5, 6[Ref20] Netcraft - january 2020 web server survey, January 2020. →pages 29[RJ00] L. Rising and N. S. Janoff. The scrum software developmentprocess for small teams. IEEE Software, 17(4):26–32, 2000. →pages 19, 20[RRDB08a] John Reap, Felipe Roman, Scott Duncan, and Bert Bras. Asurvey of unresolved problems in life cycle assessment: part 1.The International Journal of Life Cycle Assessment, 13(4):290–300, Jun 2008. → pages 4, 5, 7, 10[RRDB08b] John Reap, Felipe Roman, Scott Duncan, and Bert Bras. Asurvey of unresolved problems in life cycle assessment: part 2.The International Journal of Life Cycle Assessment, 13(5):374–388, Aug 2008. → pages 5, 6, 7, 8[SLTC16] Sangwon Suh, Matthew Leighton, Shivira Tomar, and Chris-tine Chen. Interoperability between ecoinvent ver. 3 and uslci database: a case study. The International Journal of LifeCycle Assessment, 21(9):1290–1298, Sep 2016. → pages 10[Tiv15] Johan Tivander. A minimal ontology pattern for life cycle as-sessment data. volume 1461, 2015. → pages 19, 2776Bibliography[TSAP20] Ian Turner, Alyssa Smart, Emily Adams, and Nathan Pelletier.Building an ilcd/ecospold2–compliant data-reporting templatewith application to canadian agri-food lci data. The Interna-tional Journal of Life Cycle Assessment, Mar 18, 2020.→ pages26[UNE17] UNEP/SETAC. Glad network, 2017. → pages 7, 13[US17] UNEP-SETAC. Glad network api/sdk documentation, 2017.→ pages 13[vZLLR14] R. van Zelm, P. Larrey-Lassalle, and P. Roux. . Chemosphere,100:175–181, 2014. → pages 6[W3C08] W3C. Web content accessibility guidelines 2.0. Technical re-port, W3C, 2008. → pages 28[WBH+13] Bo Pedersen Weidema, Christian Bauer, Roland Hischier, ChrisMutel, Thomas Nemecek, Juergen Reinhard, Carl Vadenbo,and G. Wernet. Overview and methodology: Data qualityguideline for the ecoinvent database version 3. Technical re-port, ecoInvent Center, May 2013. → pages 12[WDK11] Marc-Andree Wolf, Clemens Du¨pmeier, and Oliver Kusche.The international reference life cycle data system (ilcd) format– basic concepts and implementation of life cycle impact assess-ment (lcia) method data sets. In 25th International Conferenceon Informatics for Environmental Protection, EnviroInfo 2011,Aachen, October 5-7, 2011 2011. Shaker Verlag. → pages 9[Wei03] Bo Weidema. Market information in life cycle assessment. Tech-nical report, 2003. → pages 4[WPC+12] Marc-Andree Wolf, Rana Pant, Kirana Chomkhamsri,Serenella Sala, and David Pennington. The international ref-erence life cycle data system. Technical report, PublicationsOffice of the European Union, 2012. → pages 977Appendix ARisk AssessmentThis risk assessment is based on the OWASP Top Ten application se-curity risks. Each risk is assigned an exploitability, weakness prevalance,weakness detectability, and technical impact score out of three in accor-dance with the OWASP Risk Rating Methodology. Three indicates a majorrisk in a given category, while one indicates a minor risk. Mitigating factorsare listed for each risk.A.1 InjectionTable A.1: Injection Risks.Metric Risk (1-3)Exploitability 3Prevalence 2Detectability 3Technical 3Risk of malicious code injection is highly mitigated. The use of preparedSQL statements without direct concatenation prevents SQL injection, whileautomatic escaping prevents Cross-Site Scripting. Checking of dataset own-ership prevents injection of UUIDs for datasets that do not belong to theuser. Some risk may be posed by injection via uploaded XML file, in par-ticular to ’billion laugh’ (XML bomb) type attacks.78A.2. Broken AuthenticationA.2 Broken AuthenticationTable A.2: Broken Authentication Risks.Metric Risk (1-3)Exploitability 3Prevalence 2Detectability 2Technical 3Risks of broken authentication are partially mitigated. User sessions arestored in encrypted, expiring cookies to minimize the chance of cookie theft.User passwords have an enforced minimum input length of eight characters,but are not compared against known bad passwords or required to have aminimal complexity. Lack of password recovery system means no attackvector for falsely recovering a password, but does potentially allow for asocial engineering attack against the system administrator. Use of a saltedSHA-256 password column provides some security against lookup or rainbowtable attacks, but could be improved through the use of a key-stretchingfunction.A.3 Sensitive Data ExposureTable A.3: Sensitive Data Exposuren Risks.Metric Risk (1-3)Exploitability 2Prevalence 3Detectability 2Technical 3Risk of sensitive data exposure is largely mitigated. Most data storedwithin the CALDC is of low sensitivity and presents minimal risk if leakeddue to the public nature of the CALDC mission. User passwords present themajor sensitive information stored within the application. As mentioned,the security of user password storage could be improved through the useof alternative hashing/salting arrangements. All standard communication79A.4. XML External Entitieswith the server is done via encrypted HTTPS, SSH, or SFTP protocols,preventing data from being exposed while in-transit.A.4 XML External EntitiesTable A.4: XML External Entities.Metric Risk (1-3)Exploitability 2Prevalence 2Detectability 3Technical 3Risk of XML external entities is completely mitigated. The Python3eTree XML parser implementation does not allow external entity expansionor document type definition retrieval, and returns a parse error if it encoun-ters either. Only a problem when using an older XML parser, or a parserthat enables external entities and document type definitions.A.5 Broken Access ControlTable A.5: Broken Access Control.Metric Risk (1-3)Exploitability 2Prevalence 2Detectability 2Technical 3Risk of broken access control is largely mitigated. Access control is han-dled server-side via database checks against an encrypted cookie generatedat login on a per-page basis. SELinux and default Linux permissions areconfigured to minimize privileges of the web server application to only thoseneeded to directly run the CALDC. Use of an .htaccess file prevents usersfrom accessing directories and source code via HTTP/HTTPS, restrictinguser access to those files that are directly served to the user via applicationlogic.80A.6. Security MisconfigurationA.6 Security MisconfigurationTable A.6: Security Misconfiguration.Metric Risk (1-3)Exploitability 3Prevalence 3Detectability 3Technical 2Risk of security misconfiguration is largely mitigated through previouslyenumerated security features. CentOS operating system comes partially pre-configured and pre-hardened against attack, but additional security harden-ing could be used. Use of an additional stateful firewall, or active securitymodule such as the Fail2Ban or mod security Apache modules could provideadditional protection against common automated attacks.A.7 Cross-Site ScriptingTable A.7: Cross-Site Scripting.Metric Risk (1-3)Exploitability 3Prevalence 3Detectability 3Technical 2Risk of cross-site scripting is mostly mitigated. Use of dynamically gen-erated web pages without GET parameters prevents the use of typical URL-based reflected XSS attacks. Use of Flask’s built-in escaping prevents storedXSS scripting attacks by escaping sensitive characters in user input prior tothe page being served. There may be potential for DOM XSS attacks target-ing a user’s browser environment for session theft or redirection via insecurebrowser extensions. A Content Security Policy (CSP) should be used toprotect users from such XSS attacks that manage to avoid the built-in es-caping.81A.8. Insecure DeserializationA.8 Insecure DeserializationTable A.8: Insecure Deserialization.Metric Risk (1-3)Exploitability 1Prevalence 2Detectability 2Technical 3Risk of insecure de-serialization is completely mitigated. All serializationof data is done on the server-side by the application. All user inputs are inunserialized form. For example, all data collected in a flow exchange table issent as individual integers and strings, and is serialized to JSON for storageon the server-side after being appropriately cast to necessary data types.A.9 Using Components with KnownVulnerabilitiesTable A.9: Using Components with Known Vulnerabilities.Metric Risk (1-3)Exploitability 2Prevalence 3Detectability 2Technical 2Risk of using components with known vulnerabilities is somewhat miti-gated. The use of well-maintained and frequently updated software packageswith long term support (LTS) largely prevents vulnerabilities, or patchesthem quickly after they are made public. Zero-day exploits remain a riskeven with updates and LTS. Automation of patching and updating wouldensure the most timely application of security-critical patches, but with thepotential for issues if package updates contain any bugs or changes to un-derlying functionality.82A.10. Insufficient Logging & MonitoringA.10 Insufficient Logging & MonitoringTable A.10: Insufficient Logging & Monitoring.Metric Risk (1-3)Exploitability 2Prevalence 3Detectability 1Technical 2Risk of insufficient logging and monitoring is somewhat mitigated. SELinuxand Apache provide good logging at the external web server and internalaudit levels. Long average time until intrusion is identified suggests thatcurrent 30-day backup cycle is not long enough. Backup cycle could bestrengthened through the use of longer-term offline backups in addition todaily ’hot’ backups. In addition, the use of additional modules such asFail2Ban would allow better identification and logging of malicious activity.83
Thesis/Dissertation
eng
Computer Science
Vancouver : University of British Columbia Library
Attribution-NonCommercial-NoDerivatives 4.0 International
Graduate
Development of the Canadian agri-food lifecycle data centre with data format interoperability requirements
Text