International Journal of Geo-Information Article Geospatial Queries on Data Collection Using a Common Provenance Model Guillem Closa 1, *, Joan Masó 1 , Núria Julià 1 and Xavier Pons 2 1 Grumets Research Group, CREAF, Edifici C, Universitat Autònoma de Barcelona, 08193 Bellaterra, Catalonia, Spain; joan.maso@uab.cat (J.M.); n.julia@creaf.uab.cat (N.J.) 2 Grumets Research Group, Dep de Geografia, Edifici B, Universitat Autònoma de Barcelona, 08193 Bellaterra, Catalonia, Spain; Xavier.Pons@uab.cat * Correspondence: guillem.closa@uab.cat Abstract: Lineage information is the part of the metadata that describes “what”, “when”, “who”, “how”, and “where” geospatial data were generated. If it is well-presented and queryable, lineage becomes very useful information for inferring data quality, tracing error sources and increasing trust in geospatial information. In addition, if the lineage of a collection of datasets can be related and presented together, datasets, process chains, and methodologies can be compared. This paper proposes extending process step lineage descriptions into four explicit levels of abstraction (process run, tool, algorithm and functionality). Including functionalities and algorithm descriptions as a part of lineage provides high-level information that is independent from the details of the software used. Therefore, it is possible to transform lineage metadata that is initially documenting specific processing steps into a reusable workflow that describes a set of operations as a processing chain. This paper presents a system that provides lineage information as a service in a distributed environment. The   system is complemented by an integrated provenance web application that is capable of visualizing Citation: Closa, G.; Masó, J.; Julià, N.; and querying a provenance graph that is composed by the lineage of a collection of datasets. The Pons, X. Geospatial Queries on Data International Organization for Standardization (ISO) 19115 standards family with World Wide Collection Using a Common Web Consortium (W3C) provenance initiative (W3C PROV) were combined in order to integrate Provenance Model. ISPRS Int. J. provenance of a collection of datasets. To represent lineage elements, the ISO 19115-2 lineage class Geo-Inf. 2021, 10, 139. https:// names were chosen, because they express the names of the geospatial objects that are involved more doi.org/10.3390/ijgi10030139 precisely. The relationship naming conventions of W3C PROV are used to represent relationships among these elements. The elements and relationships are presented in a queryable graph. Academic Editors: Wolfgang Kainz and Mohsen Kalantari Keywords: provenance; lineage; graph; data queries; metadata Received: 9 January 2021 Accepted: 1 March 2021 Published: 5 March 2021 1. Introduction Publisher’s Note: MDPI stays neutral According to [1], over two-thirds of Earth and Environment works cannot be repro- with regard to jurisdictional claims in duced, due to (1) the lack of methodology or code, (2) access limitations to raw data, or (3) published maps and institutional affil- incomplete metadata documentation. This so called “usability gap” [2] can be resolved by iations. a solid data model for provenance information, which includes a mechanism for inferring common processing chains form it. This can be supported by new tools that improve the user understanding of the data production process [3]. Some recommendations for increasing the level of transparency and for capturing the “Whole Tale” of the computa- Copyright: © 2021 by the authors. tional environments are presented in [4]. In the geospatial world, the Committee on Earth Licensee MDPI, Basel, Switzerland. Observation Satellites (CEOS) [5] Analysis Ready Data (ARD) prepared with minimum This article is an open access article processing requirements and metadata [6]. This facilitates the use and interoperability of distributed under the terms and Remote Sensing (RS) products and it aims to reduce the usability gap. One of the require- conditions of the Creative Commons ments in the ARD product family specification is to clearly state the processes applied to Attribution (CC BY) license (https:// the data. However, ARD data may not be applicable under certain circumstances, because creativecommons.org/licenses/by/ case studies occasionally generate slightly and sometimes clearly different products for 4.0/). apparently identical implementations of common algorithms [7,8]. An example of this ISPRS Int. J. Geo-Inf. 2021, 10, 139. https://doi.org/10.3390/ijgi10030139 https://www.mdpi.com/journal/ijgi ISPRS Int. J. Geo-Inf. 2021, 10, 139 2 of 23 is processing methods that favor a particular condition (e.g., mountain areas or Mediter- ranean climate). Therefore, it is necessary to have precise information regarding how an ARD product was created and, thus, be able to define its a priori limitations. There- fore, information at the different abstraction levels of geoprocessing services will help to distinguish and discriminate geoprocessing tools [9]. In this paradigm, geospatial lineage, information regarding the origins of geospatial data products has been indicated to be a fundamental issue in spatial information [10]. Tracking back the production workflow, scientists can assess the usability in terms of data quality, which is conditioned by steps that are more sensitive to uncertainties and error propagation [11,12]. Moreover, when lineage information is complete and indicates actual data sources and process code, it can be used for data replication (reproducibility purposes) and workflow reuse (with other inputs). Summarizing, lineage information helps to overcome the knowledge gap between data providers and data consumers who want to reuse these models, data, or algorithms in different contexts, regions, or purposes. We could assume that an accurate statement would be enough for documenting lineage; however, a well-known internal structure is necessary for extracting the maximum benefit from it. The usefulness of lineage increases when an interoperable metadata model is used, which makes it possible to exchange and share lineage in a distributed information environment [13]. The Provenance Working Group of the World Wide Web Consortium (W3C) established a model to represent domain independent provenance over the web. The W3C PROV (PROV from now on) defines provenance as information regarding the entities, activities, and people involved in producing a piece of data or thing [14]. In the geospatial domain, the term lineage has been used to define the provenance of Geographic Information System (GIS) products [15]. The Spatial Data Transfer Standard (SDTS) [16] of the Federal Geographic Data Committee (FGDC) defined a lineage model, and the International Organization for Standardization (ISO) included a lineage model first in ISO 19115:2003 [17] and later in ISO 19115-1:2014 [18] and ISO 19115-2 [19]. Although the term lineage is preferred by geospatial standards, several works also use provenance as a synonym [20,21]. In this paper, a slight differentiation between them is used: the term lineage is the history of a single dataset, while provenance refers to the integrated history of one or more datasets. According to [22], the initial version of the ISO model offered an unstructured narrative of the history of the spatial resource and, therefore, it is unsuitable for automation purposes. To cover this gap, Refs. [23,24] propose adapting the PROV model to the requirements of the geospatial community. Other authors, such as [10,13], went further and semantically enriched the PROV structure with geospatial particularities. However, the recently edited version of the ISO metadata standard [19] has been substantially improved in structure and it is now able to better represent the process chain of a production line [25]. The selected provenance visualization approach is another key factor in enhancing the understanding of the data production. In complex environments, scientists rely on visualization tools to help them understand large amounts of data that are generated from experiments [26]. Visualization tools are essential in the phases of discovery and inspection of data and process chains [27]. Provenance can have a complex structure with multiple relationships and dependencies. This can overwhelm users exploring the different process steps that lead to a dataset. Given the linked nature of provenance information, Ref. [28] suggests a graph approach that effectively summarizes the process chain. Some GIS and RS tools provide users with a functionality to store lineage information. However, despite the potential of the recorded lineage information, systems rarely provide query capabilities that go beyond basic metadata visualization. Therefore, there is a need for interactive systems and tools able to visualize, query, or mine provenance information [29]. However, given the multiple relationships and dependencies between different datasets that provenance information can describe, designing these tools is a challenging task. This contribution tackles this issue, presenting a system that provides query capa- bilities for a graph representing the provenance of a collection of datasets or federated ISPRS Int. J. Geo-Inf. 2021, 10, 139 3 of 23 metadata services. Our graphs go beyond the typical lineage graphs that are sources or process chain oriented. Instead, the system can show the tools used, executions carried out, outputs generated, and agents that are involved in the collection of datasets. Four different levels of geoprocessing abstraction are proposed in order to be able to include all the heterogeneity and variety of provenance information in a single graph, namely the execution, tool, algorithm, and functionality levels. The preliminary results have been implemented and tested in a web map browser. The rest of this paper is organized, as follows: in Section 2, we present the chosen provenance representation model, paying special attention to the different levels of ab- straction of the geoprocessing tools; in Section 3, the potential for provenance query is described; in Section 4, a query provenance system is presented; in Section 5, we describe a use case to show the implementation of the system and the visualization tool. Section 5 also provides a discussion that is based on a use case that exemplifies the usefulness of our proposal. In Section 6, we identify future work and, finally, a summary of the conclusions is presented in Section 7. 2. Provenance Model This paper makes the most of the legacy of the lineage model in the ISO 19115 family standard and the W3C PROV provenance model to propose an evolved model that relates collections of datasets in a network, while using provenance as a basis and considering a set of levels of abstraction for process steps. 2.1. Levels of Abstraction of Process Steps The definition and capture of different levels of granularity of geospatial provenance data have motivated some works, such as [30]. A comparison between ISO and PROV describes the provenance at different levels of granularity of geospatial data (feature types, features, attribute types, attributes) and proposes a description of the different levels of granularity with PROV [24]. In this paper, different levels of abstraction of the process steps: process run, processing tool, algorithm, and functionality are proposed (see Figure 1). The definitions of these concepts are as follows (going from more concrete to more abstract): • Process run (process step): an individual execution of a processing tool with a specific set of parameters. It is a single GIS execution. Represented by LE_ProcessStep in ISO and as an Activity in PROV. • Processing tool (executable or web service): a specific version of an implementation of an algorithm in a piece of software that can obviously be executed several times with different sources and parameters. This is what we can find in the GitHub, buy from a software vendor, use in a web processing service, etc. Represented by LE_Processing in ISO and as an Entity in PROV. • Algorithm (model): a set of mathematical and logical steps that allow for transform- ing some inputs into some outputs. It can be implemented in software in different ways and programming languages. This is what a scientific paper usually describes. Represented by LE_Algorithm in ISO and as an Entity in PROV. • Functionality (operation): an operation that transforms data into other data with spatial problem-solving orientation. This is a black box that can be implemented with different algorithms, potentially giving slightly different results. This is what a GIS and RS textbooks describe. It does not exist in ISO and is represented as an Entity in PROV. These levels of abstraction are related, as follows (see Figure 1): the process runs as a single execution and executes a processing tool. The processing tool implements an algorithm. Finally, the algorithm gives a functionality. ISPRS Int. J. Geo-Inf. 2021, 10, x FOR PEER REVIEW 4 of 23 ISPRS Int. J. Geo-Inf. 2021, 10, 139 These levels of abstraction are related, as follows (see Figure 1): the process runs 4 ofas 23a single execution and executes a processing tool. The processing tool implements an algo- rithm. Finally, the algorithm gives a functionality. Figure1.1.Representation Figure Representationofofthe thefour fourlevels levelsofofprocess processstep stepabstraction. abstraction. Theinclusion The inclusionofoffunctionality functionalityand andalgorithm algorithmdescriptions descriptionsas asaapart partofofprovenance provenance provides high-level provenance information that is independent from the software ororweb provides high-level provenance information that is independent from the software web processing tool used. This makes it possible to take a provenance graph that processing tool used. This makes it possible to take a provenance graph that is initially is initially documentingspecific documenting specificprocessing processingtools toolsand andthen thenabstract abstractititinto intoaahigher-level higher-leveldiagram diagramthatthat describesthe describes theaim aimofofthe theprocessing processingchain. chain.This Thisidea ideagoes goesbeyond beyondpure purereproducibility reproducibilityby by providingreasoning providing reasoningandandthe theintentions intentionsthat thatare arebehind behindeacheachprocess processstep. step.Exploiting Exploitingthisthis approachmakes approach makesititpossible possibleto: to: • Representtogether Represent togetherinin a single a single provenance provenance representation representation the origin the origin of different of different da- datasets. • tasets. Formalize provenance queries at different levels of abstraction. For instance, (from  more abstract Formalize to more specific): provenance queries at different levels of abstraction. For instance, (from #more abstract to more specific): What functionalities are used more frequently in my organization? #o What What is the best algorithm functionalities are usedthat more I can use for ain frequently quality test of my final products? my organization? #o What How are best is the my results algorithm affected that I bycanausespecific processing for a quality test oftool myversion that has final products? o How a bug? are my results affected by a specific processing tool version that has a bug? • Translate Translatea alineage lineage description description that is executed that is executedwithwith one onesoftware vendor software into another vendor into an- software productproduct other software and reproduce the results. and reproduce the results. The Thedescription descriptionofofall allfunctionalities functionalitiesused usedininaaprocessing processingchain chaindepicts depictsthe thetask taskthat that the workflow was designed for. In the geospatial domain, a task describes the workflow was designed for. In the geospatial domain, a task describes all of the actions all of the actions that thatrequire requirehuman humaninputinputor orthe theknowledge knowledgeabout aboutcontext contextand andititisisusually usuallycomposed composedby by functions [31,32] (e.g., watershed delineation or a polluting industry functions [31,32] (e.g., watershed delineation or a polluting industry buffer zone buffer zone delimita- delimi- tion). In any tation). case, In any tasks case, are not tasks are bound to specific not bound tools. tools. to specific Back in 1998, Back inRef. [31] 1998, demonstrated Ref. [31] demon- that it is feasible to translate flow charts that are based on a universal strated that it is feasible to translate flow charts that are based on a universal GIS functionality GIS func- into specific GIS software flow charts when functionalities can tionality into specific GIS software flow charts when functionalities can be mapped tobe mapped to GIS oper- GIS ations operations (tools used). However, although several classifications of the principles ofGIS (tools used). However, although several classifications of the principles of GIS functionalities functionalitieshave havebeen beenformulated formulated[33,34], [33,34],semantic semanticdescriptions descriptionsare arestill stillambiguous ambiguousoror incomplete incomplete[35]. [35].Nevertheless, Nevertheless,the themain mainGIS GISandandRS RSsoftware softwareproducts productsperform performaacommon common core core of functionalities (tools with the same problem-solving intentionality).Table of functionalities (tools with the same problem-solving intentionality). Table11shows shows a subset of the common GIS and RS functionalities and the name of the implementation in a subset of the common GIS and RS functionalities and the name of the implementation ArcGIS [36], MiraMon [37], GRASS [38], and SNAP [39]. in ArcGIS [36], MiraMon [37], GRASS [38], and SNAP [39]. ISPRS Int. J. Geo-Inf. 2021, 10, 139 5 of 23 Table 1. Some Geographic Information System (GIS) and Remote Sensing (RS) functionalities with the different names in the ArcGIS, MiraMon, GRASS, and SNAP software. GIS functionality ArcGIS tool MiraMon tool GRASS tool Geometric union Union CombiCapa v.overlay(or) Extraction Clip Retalla v.overlay(and) Proximity Buffer BufDist v.buffer Distance Distance BufDist r.distance Surface interpolation Interpolation InterPNT r.resamp.interp Slope Slope Pendent r.slope.aspect Aspect Aspect Pendent r.slope.aspect Shade Hillshade Illum r.relief Visibility Viewshed Visible r.viewshed Cell statistics Cell statistics EstRas r.univar Field statistics Field statistics EstCamp v.vect.stats Joining Join GestBD v.db.join Merging Merge GestBD v.patch Aggregation Dissolve Ciclar v.disolve Feature selection Select by features VecSelect v.extract RS functionality SNAP MiraMon tool GRASS tool Georeferencing Orthorectification CorrGeom i.ortho.photo Radiometric Sen2Cor CorRad i.atcorr correction 2.2. Linking Geospatial Dataset Collections Through the Process History One possible approach to present to present lineage is to build a system that is based on the ISO 19115 family standard [25]. More specifically, the interactive metadata visualization tool used (GeMM) [37] provides a graphical interface that shows lineage information in a hierarchical tree form. A tree represents the lineage of one geospatial dataset. While the lineage model in the ISO metadata standards focuses on the final product instances and their sources and process steps, the PROV Data Model (PROV-DM) focuses on the relationship between agents, entities and activities: • PROV:used → Relates activities (PROV:Activity) with entities (PROV:Entity). • PROV:wasAssociatedwith → Relates activities (PROV:Activity) with agents (PROV:Agent). • PROV:wasGeneratedBy → Relates entities (PROV:Entity) with activities (PROV:Activity). • PROV:wasAttributedTo → Relates entities (PROV:Entity) with agents (PROV:Agent). • PROV:wasInformedBy (These PROV core relationships are not used in this proposal) → Relates activities (PROV:Activity) activities (PROV:Activity). • PROV:wasDerivedFrom → Relates entities (PROV:Entity) with entities (PROV:Entity). • PROV:actedOnBehalfOf (These PROV core relationships are not used in this proposal) → Relates agents (PROV:Agent) with agents (PROV:Agent). Several authors, such as [10,40], have proven that it is possible to map both models. When considering that ISO datasets sources results and executable are PROV entities, the ISO process steps are PROV activities and ISO responsible parties (persons or institutions) are PROV agents, the set of PROV relationships between agents, entities, and activities (Figure 2) are immediately applicable to ISO model, as seen in Table 2. ISPRS Int. J. Geo-Inf. 2021, 10, 139 6 of 23 PRS Int. J. Geo-Inf. 2021, 10, x FOR PEER REVIEW 6 of 23 Figure Figure 2. The three 2. ThePoint Starting threeclasses Starting Point classes in PROV mapped in to PROV mapped Organization International to International forOrganization for (ISO) classes Standardization Standardization (ISO) classes for lineage. PROV properties that relate them emerge (from the for lineage. PROV properties that relate them emerge (from the PROV ontology modified). PROV ontology modified). Table 2. W3C PROV relationships and the ISO classes that they connect. Table 2. W3C PROV relationships and the ISO classes that they connect. W3C PROV Relationships ISO 19115 Classes W3C PROV Relationships ISO Connected 19115 Classes Connected Used Used LI_ProcessStep/source → LI_Source (or LI_ProcessStep/source LE_Source) LI_Source (or LE_Source) Was Associated with LI_ProcessStep/processor → CI_Responsability Was Associated with LI_ProcessStep/processor  CI_Responsability Was Generated By LI_ProcessStep/output → LE_Source Was Generated By LI_ProcessStep/output  LE_Source LE_ProcessStep/processingInformation/LE_Processing/softwareReference/CI_Citation/ Was Attributed To LE_ProcessStep/processingInformation/LE_Pro- citedResponsibleParty →CI_Responsability Was Attributed LE_ProcessStep/processingInformation/LE_Processing/procedureDescription To cessing/softwareReference/CI_Citation/citedResponsi- Was Derived From: gave →CharacterString (representing the Functionality; no existing in ISO) blePartyCI_Responsability Was Derived From: implemented LE_ProcessStep/processingInformation/LE_Processing/algorithm → LE_Algorithm Use: executed LE_ProcessStep/processingInformation/LE_Pro- LE_ProcessStep/processingInformation → LE_Processing Was Derived From: gave cessing/procedureDescription CharacterString (representing the Functionality; no existing in ISO) 2.3. W3C PROV for Representing the Process Abstraction Levels Was Derived From: imple- LE_ProcessStep/processingInformation/LE_Processing/al- mented In addition to gorithm  LE_Algorithm the presented PROV core type relationships, which are high-level de- scriptions, there is aLE_ProcessStep/processingInformation Use: executed mechanism to ‘open up’ these descriptions to a lower level specification. LE_Processing Therefore, three subtypes of PROV-DM core relationships were introduced to relate the four levels 2.3. W3C PROV of processing for Representing abstraction the Process that areLevels Abstraction described in Section 2.1: • In addition executed → The subtype to the presented PROV used:executed, core type is introduced to relate relationships, whicha LE_ProcessStep (PROV:Activity) are high-level de- scriptions, therewith is a its LE_Processing mechanism tool up’ to ‘open (PROV:Entity). A LE_ProcessSet these descriptions to a lowerexecuted a LE_Processing tool level specifica- tion. Therefore, once. three subtypes of PROV-DM core relationships were introduced to relate • ofimplemented the four levels processing→abstraction The subtype wasDerivedFrom:implemented that are described in Sectionis2.1:used to relate the LE_Processing tool (PROV:Entity) with an LE_Algorithm (PROV:Entity). A LE_Processing tool implemented  executed  The subtype used:executed, is introduced to relate a LE_ProcessStep an LE_Algorithm. (PROV:Activity) with its LE_Processing tool (PROV:Entity). A LE_ProcessSet exe- • gave → The subtype wasDerivedFrom:gave is used to relate an LE_Algorithm (PROV:Entity) cuted a LE_Processing tool once. with a Functionality (PROV:Entity). An LE_Algorithm gave a Functionality.  implemented  The subtype wasDerivedFrom:implemented is used to relate the LE_Pro- cessing toolCombining 2.3.1. (PROV:Entity)W3Cwith PROVan and LE_Algorithm ISO19115 to(PROV:Entity). A LE_Processing Represent Provenance tool implemented an LE_Algorithm. In this paper, a composed solution to encode the provenance of a collection of datasets:  gave  The subtype wasDerivedFrom:gave is used to relate an LE_Algorithm combining ISO with PROV is chosen. To present each element, we chose the ISO 19115- (PROV:Entity) with a Functionality (PROV:Entity). An LE_Algorithm gave a Func- 2 lineage class names (LI_Lineage), because they express the names of the geospatial tionality. objects that are involved more precisely, and we mapped them to PROV core types. The relationship naming conventions of PROV were used to represent relationships among 2.3.1. Combining W3C PROV and ISO19115 to Represent Provenance agents (CI_Responsability), actions (LE_ProcessingSteps), and entities (all other classes). In thisFigure paper,3 apresents composedthe solution to encode result of this the provenance of a collection of da- combination. tasets: combining ISO with PROV is chosen. To present each element, we chose the ISO 19115-2 lineage class names (LI_Lineage), because they express the names of the geospa- 19115-2 lineage class names (LI_Lineage), because they express the names of the geospa- tial objects that are involved more precisely, and we mapped them to PROV core types. tial objects that are involved more precisely, and we mapped them to PROV core types. The relationship naming conventions of PROV were used to represent relationships ISPRS Int. J. Geo-Inf. 2021, 10, 139 The relationship naming conventions of PROV were used to represent relationships 7 of 23 among agents (CI_Responsability), actions (LE_ProcessingSteps), and entities (all other among agents (CI_Responsability), actions (LE_ProcessingSteps), and entities (all other classes). Figure 3 presents the result of this combination. classes). Figure 3 presents the result of this combination. Functionality Functionality LE_Algorithm LE_Algorithm implemented LE_Source implemented LE_Source LE_Processing LE_Processing LE_ProcessStep LE_ProcessStep LE_Source LE_Source CI_Responsability CI_Responsability Figure 3. How the use of PROV relates the lineage ISO elements. Figure3.3.How Figure Howthe theuse useof ofPROV PROVrelates relatesthe thelineage lineageISO ISOelements. elements. By automatically transforming ISO lineage metadata into PROV, we can merge ISO Byautomatically By automaticallytransforming transforming ISOISO lineage lineage metadata into into PROV, PROV,we we canmerge mergeISO ISO diagrams for a single product and then describemetadata the provenance of manycanproducts in a diagrams for a single product and then describe the provenance of many products in aa diagrams for a single product and then describe the provenance of many products in single graph. Global identifiers for sources and processing tools that are supported by the singlegraph. single graph.Global Globalidentifiers identifiersfor forsources sourcesandandprocessing processingtools toolsthat thatare aresupported supportedbybythe the ISO MD_Identifier class [41] make it possible to coalesce repeated objects and integrate ISOMD_Identifier ISO MD_Identifier class class[41] [41]make makeititpossible possibletotocoalesce coalescerepeated repeatedobjects objectsand andintegrate integrate remaining objects in a provenance graph connected by PROV relationships (see Figure 4). remainingobjects remaining objectsin inaaprovenance provenancegraph graphconnected connectedbybyPROV PROVrelationships relationships(see (seeFigure Figure4). 4). Figure 4. Graph (A,B) represent individual executions with the same functionality carried out with MiraMon and GRASS, Figure4.4.Graph Figure Graph(A,B) (A,B)represent representindividual individualexecutions executionswith withthe thesame samefunctionality functionalitycarried carriedout outwith withMiraMon MiraMonand andGRASS, GRASS, respectively. (C) represents provenance of the two executions merged into one. respectively.(C) respectively. (C)represents representsprovenance provenanceofofthe thetwo twoexecutions executionsmerged mergedinto intoone. one. 2.3.1.1. Relating Lineage Elements in Different Levels of Abstraction Adding the four levels of abstraction that were introduced in Section 2.1 to this mapping makes representing provenance at a higher-level of abstraction possible. For instance, inputs and outputs can be directly related to the processing tool or even to the algorithm or functionality. To allow this, a set of different PROV relationships is introduced. Adding the four levels of abstraction that were introduced in Section 2.1 to this map ping makes representing provenance at a higher-level of abstraction possible. For in stance, inputs and outputs can be directly related to the processing tool or even to the algorithm or functionality. To allow this, a set of different PROV relationships is intro duced. There are three possible scenarios in which it is necessary to use this set of differen ISPRS Int. J. Geo-Inf. 2021, 10, 139 8 of 23 PROV relationships: 1. Relating outputs (LE_Source) with the different levels of process step abstraction (Figure 5A). The PROV core type relation wasDerivedFrom is used with LE_Pro There are three possible cessing, scenarios inand LE_Algorithm which it is necessary Funcionatily. to use isthis The reason setwhile that, of different LE_ProcessStep PROV relationships: can be assimilated to a PROV:Activity (and use wasGeneratedBy), the others are as 1. Relating similated to a PROV: Entity. outputs (LE_Source) with the different levels of process step abstraction 2. 5A). (Figure Relating inputscore The PROV (LE_Source) with type relation the different levels wasDerivedFrom ofwith is used abstraction (Figure 5B). The LE_Processing, LE_Algorithm and Funcionatily. relationship processed isTheintroduced, reason is that,a while LE_ProcessStep subtyping can be of the PROV-DM core assimilated to a PROV:Activity wasDerivedFrom. In this(and thewasGeneratedBy), case,use relationship changes the others from are assimilated connecting a PROV:Ac to a PROV: Entity. tivity (LE:ProcessStep) with a PROV:entity (LE_Source), to connecting entitie 2. Relating (LE_Processing, inputs (LE_Source) with the different LE_Algorithm, levelswith Functionality) of abstraction (Figure 5B). entities (LE_Source). Relating processed The3.relationship is introduced, the different a subtyping levels of abstraction of thethemselves between PROV-DM(Figure core was- 5C). In thi DerivedFrom. case,Inasthis case, there in the relationship no change changes in the from connecting relationship type (it is aalways PROV:Activity a PROV:Entity to (LE:ProcessStep) with a PROV:entity PROV:Entity), we are free (LE_Source), to connecting to use the lowest level (inentities terms (LE_Processing, of process abstraction LE_Algorithm, Functionality) with provenance element connector. entities (LE_Source). 3. Relating the different levels of abstraction between themselves (Figure 5C). In this case, as there Most in no change of the in the times, these relationshipare relationships typenot(itnecessary is alwaysand a PROV:Entity they may nottobe shown PROV:Entity), we are However, later, wefree willto use the present lowest level a practical use (in caseterms of process in which abstraction) simplifications in the graph provenance showingelement connector. only higher levels of abstraction require that some of them are made explicit. Figure 5. Figure 5. (A) connects (A) connects entitiesentities (LE_Source—outputs) (LE_Source—outputs) with with entities entities (LE_Processing, (LE_Processing, LE_Algorithm,Functionality). LE_Algorithm, Functionality). (B) con- nects entities (LE_Processing, LE_Algorithm, Functionality) with entities (LE_Source—intputs). (B) connects entities (LE_Processing, LE_Algorithm, Functionality) with entities (LE_Source—intputs). (C) (C) connects the LE_Pro- connects cessStep, LE_Processing, LE_Algorithm, and Functionality. the LE_ProcessStep, LE_Processing, LE_Algorithm, and Functionality. Most3.ofQueries Facilitated the times, by the Provenance these relationships Data Model are not necessary and they may not be shown. However, later, Theweexploitation will presentofa provenance practical useiscase in which deepened when simplifications in the graphThere are queries are formulated. showing several only higher levels of abstraction require that some of them are examples in the literature where a consolidated and standardized made explicit. data model and the associated interoperable vocabularies are the base for a query language that exploit 3. Queries Facilitated by the Provenance Data Model the data that are expressed in the data model, Ref. [42] look at this relationship for spati The otemporal exploitation of provenance data; is deepened Ref. [43] show when queries this relationship are formulated. in the linked There data; and, Ref. [44] recog are several examples nizes the linkinbetween the literature where a model and aquery consolidated languageand for standardized graphs. In ourdata case,model the separation and the associated of conceptsinteroperable vocabularies and the introduction of the are the base different levels forofaabstraction query language into thethat data mode exploits the data that are expressed in the data model, Ref. [42] look at this relationship facilitate formulating formal queries that involve concepts and relationships. In addition for spatiotemporal because the data; Ref. [43] model provenance show this relationship associates in the datasets, linkedqueries it allows data; and, to beRef. [44] formulated on a recognizes the link between dataset collection. a model and query language for graphs. In our case, the separation of concepts and the introduction of the different levels of abstraction into the data model facilitate formulating formal queries that involve concepts and relationships. In addition, because the provenance model associates datasets, it allows queries to be formulated on a dataset collection. Queries can be formulated over the different lineage elements. Table 3 provides forty-four general queries over lineage elements. These queries are only examples of the potential of what we can get by querying the provenance of a collection of datasets. Table 3 is a dual entry table that relates the different lineage elements between them, with the exception of the first row, which restricts queries to only one lineage element. Depending on which aspect of provenance is queried, different benefits can emerge: ISPRS Int. J. Geo-Inf. 2021, 10, 139 9 of 23 • Information and transparency: lineage allows for us to learn how datasets were devel- oped. • Trust and authority of the sources and tools used: the authority can help in determining liability. • Data quality: the sources and processes involved can be used to estimate uncertainty and blunder propagation. • Documentation and reproducibility: the documentation of the complete processing chain can help in the reproducibility, especially if provenance indicates the actual and exact datasets, parameters, and tools used. • License and accessibility: related to the authorship rights of the sources used. ISPRS Int. J. Geo-Inf. 2021, 10, 139 10 of 23 Table 3. Forty-four examples of queries about provenance. Process Run Processing Tool Algorithm Functionality Agent Source Time Output Did the user Bob Did any execution Was version 3 of Was a kriging Was a reprojection have a role in the Was a dataset called Was something Was a rain dataset cover Africa? InterPNT used? algorithm used? functionality used? creation of this Rivers used? executed in 2013? created? dataset? Functionality Algorithm Processing tool Process run Did Process step 5 Was Process step 5 a What was the Was Process step 5 Which data were What was executed Did Process step 5 How long did after Process step 5? use version 3 of krigring purpose of Process generated with interpolation? step 5? executed by Bob? use a DEM of 2 m? Process step 5 last? Process step 5? InterPNT? Did InterPNT and Which interpolation Which tool is often Does version 3 of r.resamp.intep tools were Did version 3 of Is version 3 of Which outputs were used right after InterPNT support an implement developed by a InterPNT use a InterPNT the last created with version InterPNT? IDW interpolation? equivalent trusted software GeoJSON format? version available? 3 of InterPNT? functionalities? vendor? Which different Did GRASS and Was Bob the author Is this algorithm When was this Which outputs were versions of the MiraMon buffer tools of any of the algorithm created using this buffer algorithm are use the same suitable for used? algorithm? algorithms used? categorical data? developed? algorithm? Have all the corrections been Who did the Which of the Was something Which outputs were made with the same radiometric datasets used were corrections? reprojected? reprojected in 2015? reprojected? software? Which of the sources Which institution Agent Who used tools used were produced When did Bob make his first execution in generated the developed by Bob? by a public this collection? resulting maps? institution? Are all the sources Was a rain intensity Source Which two sources from the same dataset needed to were used together? temporal interval as create a river flow the output? dataset? How long did it Time take to complete When was this production? output generated? Output Was this output a revision of another output?  Data quality: the sources and processes involved can be used to estimate uncer- tainty and blunder propagation.  Documentation and reproducibility: the documentation of the complete processing chain can help in the reproducibility, especially if provenance indicates the actual ISPRS Int. J. Geo-Inf. 2021, 10, 139 and exact datasets, parameters, and tools used. 11 of 23  License and accessibility: related to the authorship rights of the sources used. 4. Representation 4. Representationand andthe theQuery Query Provenance Provenance Tool Tool In this In this paper, paper, we we present present thethe design design of of aa new characteristic characteristic that that is is included included in in the the Provenance Web system to provide support to an integrated provenance Provenance Web system to provide support to an integrated provenance visualization visualization and enable and the the enable potentialities of querying potentialities of querying it. it. TheTheclient clientwill willneed needrequest request linage information linage information from the from the requested requested layers, layers, depending depending on on thethe user user actions actions (see (see Figure Figure 6,6, steps steps00 and and 1). 1). Lineage is communicated from servers hosting the ISO metadata Lineage is communicated from servers hosting the ISO metadata (as described in Section (as described in Section 4.1) to 4.1) tothe theclient, client,which whichisiscapable capableof ofmerging merging and and presenting presenting itit in in aa provenance provenance graphgraph (see (see Figure 6, step 2 and Section 4.2). A web client will present the lineage Figure 6, step 2 and Section 4.2). A web client will present the lineage in a window of in a window of aa map browser. Provenance is presented in a graph that takes advantage map browser. Provenance is presented in a graph that takes advantage of the data model, of the data model, the common the common processes processesor orsources, sources,andandthethe abstraction abstraction levels to create levels to createnewnew connections connections(see Figure (see 6, step Figure 3). On 6, step 3). top of this, On top the window of this, the window offers different offers ways different waysto filter andand to filter query the query graph (see Section 4.3). This allows for the user to control the amount the graph (see Section 4.3). This allows for the user to control the amount of content in the of content in the graph and graph and progressively progressively increase increase the the understanding understanding of of the the graph graph itself itself and, and, with with that, that, the the understanding of the provenance information that it represents. understanding of the provenance information that it represents. Figure Figure 6. 6. Provenance ProvenanceWeb Webmapping mappingsystem systemstep stepbyby step. AA step. Catalogue Service Catalogue forfor Service thethe Web (CSW) Web lineage (CSW) request lineage (1) to request (1)the to server allows the independent lineage of each requested dataset to be retrieved (2). Finally, the client generates the prov- the server allows the independent lineage of each requested dataset to be retrieved (2). Finally, the client generates the enance graph (3). provenance graph (3). 4.1. Lineage Server Lineage is part of the metadata, the natural solution for retrieving lineage in a standard way is to use the OGC Catalogue Service for the Web (CSW). The GetRecordById request retrieves the default representation of metadata records with this identifier. However, instead of getting the entire metadata record, we only wanted to retrieve the lineage information. Thus, we came up with a small extension of the CSW protocol that includes the ELEMENTSETNAME key that has “lineage” as a value. In addition, to facilitate the reading in the JavaScript client, the OUTPUTFORMAT key and for requesting the lineage in a JSON encoding was also included. The use of a JSON encoding is particularly convenient for a JavaScript client. A JSON file can be converted into a JavaScript data structure with only one sentence of code. There is currently no official JSON encoding for the ISO 19115, so we defined one using the draft rules that were proposed in the OGC Architecture DWG JSON best practice [45]. These extensions were implemented in the MiraMon Map Server. The MiraMon Server is a stand-alone CGI application that runs on the Windows operating systems in combination with a general-purpose web server (e.g., Internet Information Service, Apache, etc.). Figure 7 shows a CSW GetRecordById operation that returns the lineage information in JSON encoding. Figure 8 presents a fragment of the JSON response. ture 19115, ISO with only so weone sentence defined oneofusing code.theThere draftisrules currently no official that were JSON proposed inencoding the OGC for the Archi- ISO 19115, tecture DWG so JSON we defined one using best practice [45].the draft These rules thatwere extensions wereimplemented proposed in the OGC in the Archi- MiraMon tecture Map DWGThe Server. JSON best practice MiraMon Server[45]. is aThese extensions stand-alone CGIwere implemented application in the that runs onMiraMon the Win- Map Server. dows Thesystems operating MiraMon Server is a stand-alone in combination CGI application with a general-purpose webthat runs(e.g., server on the Win- Internet ISPRS Int. J. Geo-Inf. 2021, 10, 139 dows operating Information systems Service, in combination Apache, etc.). with a general-purpose web server (e.g., Internet 12 of 23 Information Figure 7Service, shows aApache, etc.). CSW GetRecordById operation that returns the lineage information Figure in JSON 7 showsFigure encoding. a CSW GetRecordById 8 presents operation a fragment of thethat returns JSON the lineage information response. in JSON encoding. Figure 8 presents a fragment of the JSON response. www.ogc3.uab.cat/cgi-bin/mcsc/MiraMon.cgi?SERVICE=CSW&REQUEST=GetRecordById&OUTPUTSCHEMA= http://www.isotc211.org/2005/gmd&ELEMENTSETNAME=lineage&id=MCSCv2Nivell2:EPSG:4326&OUTPUTFORMAT=application/json www.ogc3.uab.cat/cgi-bin/mcsc/MiraMon.cgi?SERVICE=CSW&REQUEST=GetRecordById&OUTPUTSCHEMA= http://www.isotc211.org/2005/gmd&ELEMENTSETNAME=lineage&id=MCSCv2Nivell2:EPSG:4326&OUTPUTFORMAT=application/json Figure7.7.A Figure A CSW CSW GetRecordById GetRecordById request requestoperation. operation. Figure 7. A CSW GetRecordById request operation. "lineage":{ "statement": "The present raster is the result of the change of cartographic projection of the CLCM2 level 2 layer "lineage":{ from"statement": SR UTM-31N-ED50 "The to SR UTM-31N-ETRS89.", present raster is the result of the change of cartographic projection of the CLCM2 level 2 layer from"processes":[ SR UTM-31N-ED50 to SR UTM-31N-ETRS89.", { "processes":[ { "processor":[ {"processor":[ { "role":"processor", "party":{ "role":"processor", "organisation": {"name":"CREAF"} "party":{ } "organisation": {"name":"CREAF"} } } ], } "purpose":"Metadata ], edition of the CLCM2 level 2", "timeDate":"2020-06-19T19:29:38.069+02:00", "purpose":"Metadata edition of the CLCM2 level 2", "executable":{ "timeDate":"2020-06-19T19:29:38.069+02:00", "reference": "c:/miramon/GeMM.exe", "executable":{ "compilationDate":"2020-06-19T19:29:38.069+02:00", "reference": "c:/miramon/GeMM.exe", "functionality": "Metadata management and edition " "compilationDate":"2020-06-19T19:29:38.069+02:00", }, "functionality": "Metadata management and edition " "parameters": }, [ { "parameters": [ { "id":"Param1", "name":"MCSCv2Nivell2_1", "id":"Param1", "direction":"in", "name":"MCSCv2Nivell2_1", "valueType":"source", "direction":"in", …"valueType":"source", … Figure 8. Fragment of the CSW GetRecordById operation response in JSON. Figure 8. Fragment of the CSW GetRecordById operation response in JSON. Figure 8. Fragment of the CSW GetRecordById operation response in JSON. 4.2. Provenance interface 4.2. Provenance The MiraMon interface Map Browser is a visualization, analysis, and download web applica- 4.2. Provenance Interface The runs tion that MiraMon in web Map Browser browsers thatis awere visualization, developedanalysis, and download by the MiraMon webThe team [46]. applica- map tionThe thatMiraMon browser runs is in web coded Map in Browser browsers HTML5 isJavaScript. that and awere visualization, developed analysis, and withdownload by the MiraMon It is compatible Open team webThe [46]. Geospatialapplication map Con- that runs in browser sortium is web web coded browsers in HTML5 standard thatand service were developed JavaScript. protocols by and ItAPIs the to MiraMon is compatible team with communicate Open[46].Geospatial with Theservices web map browser Con- to isobtain codedthe sortium in web HTML5 standard minimum and JavaScript. service subsets ofprotocols It isand the information compatible APIs with OpentoGeospatial toiscommunicate that necessary with createweb Consortium services a fast and dy-to web namicstandard obtain user service protocols the minimum interaction. subsets The mapof and the APIscan to communicate information browser with that is necessary be configured web services to create to present toand a fast an integratedobtain dy-the view minimum namic of usersubsets several datasets ofthat interaction. the information The map have browser something that iniscommon can necessary be configuredto create aorfast to present (geographic an and dynamic integrated thematic view or both).user interaction. The mapthat of several datasets browser can be configured have something in common to present an integrated (geographic or thematicview orofboth). several datasets that have something in common (geographic or thematic or both). These datasets might come from a single service or from several services of different institutions. In the map browser, we wanted to represent lineage of one dataset or to combine lineage from more than one dataset in a single provenance diagram. Thus, a graph representation that was provided by the vis.js library was selected. A graph is defined as a set of nodes that have identifiers and a set of edges that connect nodes. In the vis.js library, nodes and edges are described as two interlinked arrays of JavaScript objects in an encoding that is very different from our JSON encoding of ISO19115, which is based on the concept of objects (e.g., LE_ProcessStep) that have other objects (e.g., LE_Source) as properties, recurrently. A JavaScript piece of code converts the JSON encoding of ISO 19115 into the JSON arrays that are required by vis.js [47]. In this conversion, a process step is represented as a blue box with a purple border, a processing tool as a dark green box, an algorithm as a purple box and a functionality as a green box. A source is represented as a yellow ellipsis and an agent as an orange circle. Edges use the color of their origin and have the PROV relationships as labels (see Section 2.3). Finally, the bright yellow ellipse is reserved for the result (see Figure 9, panel B2). ISPRS Int. J. Geo-Inf. 2021, 10, 139 13 of 23 ISPRS Int. J. Geo-Inf. 2021, 10, x FOR PEER REVIEW 13 of 23 ISPRS Int. J. Geo-Inf. 2021, 10, x FOR PEER REVIEW 14 of 23 Figure 9. Figure 9. (A) (A)Legend Legendpanel to to panel click a layer click andand a layer select Lineage. select (B) Provenance Lineage. window: (B) Provenance 1—Visibil- window: 1— ity and query Visibility options and query panel (detailed options in Figure panel (detailed 10). 2—Provenance in Figure graph panel. 10). 2—Provenance graph3—Node attrib- panel. 3—Node utes panel. attributes panel.  Users can select and incorporate another dataset. The "incoming" lineage elements are accumulated in the provenance window. This combined graph can be repre- sented in different ways (see Figure 10, panel 3): o A new independent graph that is presented next to the previous one in the same window. o The union of all lineage elements in a provenance graph: the common elements are represented only once, allowing for users to see the full picture of the prov- enance, including provenance connections between two production processes, such as shared sources, tools, agents, etc. o The intersection between the two graphs: only the nodes that connect and are shared by both lineage graphs are presented. These elements are the ones that are most used. o The subtraction of the first graph: only elements of the first lineage that are not present on the other lineage are represented. This places the emphasis on what is different in the first layer from the second one. o The complement of the intersection: the elements that are not common in the two lineages are represented, placing the emphasis on the elements that are only Figure 10.used Visibility once.query and filter options panel: 1—Layers panel. 2—Lineage elements fil- Figure 10. Visibility query and filter options panel: 1—Layers panel. 2—Lineage elements fil- tered/visible panel. 3—Lineage fusion options. 4—Simple queries panel. 5—Complex queries  Users can tered/visible right-click panel. 3—Lineageon the box fusion of a4—Simple options. process steps and queries request panel. to group 5—Complex it with queries the panel. panel. previous step or with the next step. This creates a "virtual" process step that is the Users sequencestartofthe the process previous oftwo; visualizing integrated in the same way as we provenance by processes. create batch checking for the 4.3. Provenance presence Query Tool  Users can check the lineage statement by clicking with the right button on the all of lineage information of a layer in the legend (see Figure 9). Subsequently, the result- Queries processing steps, regarding processing the tools, provenance algorithms, dataset (bright yellow ellipsis). graph resulting functionalities, from agents, andthe datasets sources activated documented in in the the layers of lineage panel that(see Figure dataset are 10, panel 1)incan displayed be formulated. a provenance The selection window. The vis.jsoflibrary lineage elements calculates (see Figure 10, panel 2) described in Section 4.2 also applies to the query result. There are two types of queries:  The simple queries are facilitated by a simple query interface that offers two lists with all the objects that are present in the graph (classified per type). An algorithm deter- ISPRS Int. J. Geo-Inf. 2021, 10, 139 14 of 23 the optimal node positions in the provenance window to avoid overlaps. Users can still move nodes around as required. In addition, JavaScript code handles the onclick events and shows more information regarding the node in a text area (see Figure 9, panel B3). Once users have the provenance graph with a single dataset represented, there are several options to continue exploring provenance (see Figure 9, panel B1): • Users can unselect some lineage element types to hide them in order to simplify the visualization (see Figure 10, panel 2): # Agents can be hidden without consequences to simplify visualization. # Leaf sources (sources that existed independently of the executed process step) can be removed from the view in order to make the process chain simpler. # Internal and often temporary sources (datasets that were produced during the process chain execution) can be removed from the view in order to enhance the understanding of the process chain. # Process steps can be removed, and processing tools take their place. # Processing tools can be removed, and they are replaced by algorithms. # Algorithms can be removed, and they are replaced by the functionality provided. # Functionalities can be hidden with no consequences. In the last four points described, the provenance graph becomes more abstract and less dependent on the details of the software used. When this happens, the represented provenance uses the relationships introduced in Section 2.3.1.1. • Users can select and incorporate another dataset. The "incoming" lineage elements are accumulated in the provenance window. This combined graph can be represented in different ways (see Figure 10, panel 3): # A new independent graph that is presented next to the previous one in the same window. # The union of all lineage elements in a provenance graph: the common elements are represented only once, allowing for users to see the full picture of the prove- nance, including provenance connections between two production processes, such as shared sources, tools, agents, etc. # The intersection between the two graphs: only the nodes that connect and are shared by both lineage graphs are presented. These elements are the ones that are most used. # The subtraction of the first graph: only elements of the first lineage that are not present on the other lineage are represented. This places the emphasis on what is different in the first layer from the second one. # The complement of the intersection: the elements that are not common in the two lineages are represented, placing the emphasis on the elements that are only used once. • Users can right-click on the box of a process steps and request to group it with the previous step or with the next step. This creates a "virtual" process step that is the sequence of the previous two; in the same way as we create batch processes. • Users can check the lineage statement by clicking with the right button on the resulting dataset (bright yellow ellipsis). 4.3. Provenance Query Tool Queries regarding the provenance graph resulting from the datasets activated in the layers panel (see Figure 10, panel 1) can be formulated. The selection of lineage elements (see Figure 10, panel 2) described in Section 4.2 also applies to the query result. There are two types of queries: • The simple queries are facilitated by a simple query interface that offers two lists with all the objects that are present in the graph (classified per type). An algorithm determines whether the start object is connected with the end object and selects them as well as all intermediate nodes that connect them. For instance, we would like to ISPRS Int. J. Geo-Inf. 2021, 10, 139 15 of 23 check the activity of the agent “CREAF” regarding a specific “CanviPrj” processing tool (see Figure 10, panel 4). • The complex query allows us to select two object types and their respective attribute values. This results in several start and end nodes being marked as selected. Not filling in the attribute value will result in selecting all of the nodes with the same attribute type as the start or end points. For instance, we would like to check the activities of the agent “CREAF” regarding all of the processing tools (see Figure 10, panel 5), whatever they may be. As in the previous case, the objects that match the query and all the objects that connect them are selected. Once the provenance queries are solved, the provenance window can present the resulting provenance information in two different forms: • A graph representing only the elements that were selected by the query. The result is simpler, but some relationships to other objects that are essential in understanding the graph might not be visible. • A full graph with all elements, but with the selected elements emphasized. This option is more useful for graphs that contain a limited number of elements. 5. Use Case: Catalonia Land Use and Land Cover Map In this use case, we want to examine, compare, and query the provenance of Catalan land use and cover maps. The Catalonia Land Cover Maps service (http://www.opengis. uab.cat/mcsc/, accessed on 9 January 2021) provides the first (1993), the second (2000), third (2005), and fourth (2009) editions of the Catalonia Land Cover Map (MCSC) (https: //www.creaf.uab.cat/mcsc/, accessed on 9 January 2021), and the 1987, 1992, 1997, 2002, 2007, 2012, and 2017 editions of the Land Use and Cover Maps of Catalonia (MUCSC) [48] (see Figure 9). Even though the purpose of the two products is similar, their process chain generations and what they represent are quite different: • The MCSCs were made by photointerpretation of aerial photographs and, sometimes, by incorporating elements of other cartography. The base materials for the photoin- terpretation were a set of orthophotos in natural color from the Institut Cartogràfic i Geològic de Catalunya (ICGC). The legends of the MCSC 2005 and 2009 editions have hierarchical levels of complexity (the simplest is level 1 and the most complex is level 5) [49]. • MUCSCs were generated using automatic classification of satellite imagery and auxil- iary cartography. While the 1987, 1992, 1997, and 2002 maps were generated by the ICGC, the 2007, 2012, and 2017 editions were generated by the Geography Department of the Universitat Autònoma de Barcelona (UAB). In addition, the 1987, 1992, 1997, 2002, and 2012 maps were created using Landsat imagery (Landsat 5, Landsat 7, or Landsat 8, depending on the edition), and the 2017 map was based on Sentinel 2 im- agery [50,51]. The software used has evolved over the years, with new methodologies and new versions of the same applications. Finally, the maps have been manually edited to fix some unavoidable errors of the automatic classification. This scenario is a good example for validating the provenance visualization and queries techniques that were developed within the framework of MiraMon Map Browser. 5.1. Provenance Visualization Examples Some examples of provenance visualization are shown based on the MCSC layers: • Example 1 (see Figure 11—Left): a provenance graph shows the agents that are involved in the generation of the MCSC version 1. The visibility, query, and filter options panel only has the layer MCSCv1Nivell2 selected and the agents as visible. • Example 2 (see Figure 11—Right): the provenance graph panel shows the processing tools and sources involved in the generation of MCSC version 2. Process steps have been abstracted into used processing tools. The visibility query and filter options ISPRS Int. J. Geo-Inf. 2021, 10, 139 16 of 23 panel only has the layer MCSCv1Nivell2 selected and the internal sources, leaf sources, and processing tools as visible. • Example 3 (see Figure 12): the provenance graph panel shows a representation of the combination of the lineage of the MCSC versions 1 and 2. The shared lineage elements are detected and represented only once. The visibility, query, and filter options panel have both layers, MCSCv1Nivell2 and MCSCv2Nivell2 selected, and all of the lineage ISPRS Int. J. Geo-Inf. 2021, 10, x FOR PEER REVIEW 16 of 23 elements are selected. ISPRS Int. J. Geo-Inf. 2021, 10, x FOR PEER REVIEW 16 of 23 Figure 11. (A) agents involved in the generation of the MCSC version 1. (B) processing tools and sources involved in the Figure 11. (A) agents involved in the generation of the MCSC version 1. (B) processing tools and sources involved in the MCSC version Figure 11. (A)2.agents involved in the generation of the MCSC version 1. (B) processing tools and sources involved in the MCSC version 2. MCSC version 2. Figure 12. Provenance of the MCSC versions 1 and 2 merged together. Figure 12. Provenance of the MCSC versions 1 and 2 merged together. Figure 12. Provenance of the MCSC versions 1 and 2 merged together. 5.2. Provenance Query Examples 5.2. Provenance Query Table 4 shows Examples forty-four possible queries that we can apply to the provenance of the landTable use and land cover 4 shows map use forty-four case. The possible presented queries queries that we are only can apply examples to the of theof the provenance potential of querying provenance from a collection of datasets. In the dual entry table, land use and land cover map use case. The presented queries are only examples of the queries that relate two lineage elements are shown, with the exception of the first row, potential of querying provenance from a collection of datasets. In the dual entry table, From the forty-four examples, we selected one example tha Table 4 to show the results (see Figure 13): Over the complete MCSC dataset series, which versions ha ISPRS Int. J. Geo-Inf. 2021, 10, 139 kNN (Classification by number of nearest neighbors) algorithms 17 of 23 shows the kNN algorithm, including the functionality, related to tools that were implemented the kNN algorithm: ClassKnn_v2.ex 5.2. Provenance Query Examples TheseTable tools 4 showsare related forty-four toqueries possible the generated datasets. that we can apply The isolated to the provenance of the da land use and land cover map use case. The presented queries are only examples of the and 2002) mean that the kNN algorithm has not been used in potential of querying provenance from a collection of datasets. In the dual entry table, panelthat queries contains relate twoall MCSC lineage versions; elements are shown,in thethevisible with exceptionelements panel fu of the first row, which restricts queries to only one lineage element. andFromprocessing tools are selected, and, finally, a complex query i the forty-four examples, we selected one example that corresponds to Q29 in the 4target Table to show elements the results (see(those related to the kNN algorithm). Figure 13): Figure Figure 13. Query 13. Query example example and and result: Over the result: Overdataset complete MCSC the complete MCSC series, which versions dataset have been generated using kNN algorithms? (Q29 in Table 4). have been generated using kNN algorithms? (Q29 in Table 4). Over the complete MCSC dataset series, which versions have been generated using kNN (Classification by number of nearest neighbors) algorithms? The provenance graph shows the kNN algorithm, including the functionality, related to the different versions of tools that were implemented the kNN algorithm: ClassKnn_v2.exe and ClassKnn_v3.exe. These tools are related to the generated datasets. The isolated datasets (1987, 1992, 1997, and 2002) mean that the kNN algorithm has not been used in their lineage. The layers panel contains all MCSC versions; in the visible elements panel functionalities, algorithms and processing tools are selected, and, finally, a complex query is filled in to obtain only the target elements (those related to the kNN algorithm). ISPRS Int. J. Geo-Inf. 2021, 10, 139 18 of 23 Table 4. Forty-four examples of queries that can be formulated on the Catalonia Land Cover Maps. Process Run Processing Tool Algorithm Functionality Agent Source Time Output Q1. Did any of the Q4. Was the Q6. Was a dataset Q7. Was something Q8. Was any output (over a complete executions not use Q2. Was version 3 of Q3. Was the Knn supervised Q5. Which roles did called Orto25m ClassKnn used? algorithm used? classification CREAF do? executed before not owned by dataset) MiraMon software? functionality used? used? 2013? CREAF? Q10. Did process Q11. Was Process Q12. What is the Q13. Which process Q16. Which outputs Process run Q9. What was functionality Q14. Did Process (over MUCSC 2017 executed after Step 5 use version 3 step 5 a Knn steps were executed step 5 use a DEM of Q15. What was the provided by Process last process step? were generated with generation) ClassKnn v. 5? of ClassKnn? classification? by Grumets? 2m? Step 5 execution? step 5? Q17. Which tool was Q19. Do the tools Q20. Were the tools Q21. Did version 3 of Q22. Was version 3 Q23. Which versions Processing tool Q18. What algorithm ClasskNN tool need most often used ClassKnn and IsoMM used developed by of ClassKnn tool the of MUCSC used (over MUCSC series right after the implemented version provide equivalent PIA last version generation) trusted software (Pseudoinvariant version 2 of the ClassKnn tool? 3 of ClassKnn? functionalities? vendors? available? ClassKnn tool? areas) sources? Q27. Was the Algorithm Q24. Which different Q25. Did all the Q26. Was CREAF the reclassification Q28. When was the Q29. Which versions (over a complete versions of the Knn Sup.classification tools author and owner of algorithm suitable current version of of MUCSC were algorithm were use the same any of the the Sup.classification created using the dataset) algorithm? for working with developed? used? algorithms used? Knn algorithm? categorical data? Q30. Were all Q31. Which Functionality radiometric institution Q32. Which of the Q33. Were any of the Q34. Which Land (over a complete corrections made performed the datasets used were datasets classified Cover Maps were dataset) with the same radiometric reclassified? before 2015? photo-interpreted? software? corrections? Agent Q36. Which of the Q37. When did Q35. Who used tools sources used in this CREAF make their Q38. Did CREAF (over a complete developed by create a MUCSC collection have open first execution in this dataset) CREAF? collection? 2007dataset? access licenses? Q40. Did the orthos Q41 Which orthos Source were used in the (over 2012 and 2017 Q39. Which sources use the same were used in all temporal interval as generation of MUCSC series generation) processing chains? MUCSC of 2012 and the MUCSC outputs? 2017? Q42. How long did Time the complete Q43. When was the (over 2017 MUCSC MUCSC map generation) processing chain take finalized? to be completed? Output Q44. Was this LULC (over 20017 MUCSC a revision of another generation) MUCSC map? ISPRS Int. J. Geo-Inf. 2021, 10, 139 19 of 23 6. Discussion On the conceptual side, the levels of abstraction introduced for processes make it possible to transform a precise lineage graph into a more abstract workflow diagram or even into a list of functionalities that inform a GIS operator or student how to reproduce a dataset by chaining GIS tools. However, the main obstacle to apply this in a generic way is the lack of a single classification of the main GIS and RS functionalities and a well accepted ontology of semantic descriptions. The main GIS and RS software products could map their processing tools to this common set of functionalities if consensus could be achieved in the future. On the technical side, in the solution that is presented here, the lineage part of the ISO 19115 metadata documents is sent to a JavaScript map browser, where (using the extended PROV ontologies) are merged in a provenance graph. The queries that are discussed in this paper are resolved directly in the client side, with no service intervention and the results presented to the user as subgraphs. There are other ways to address the same technical problem. Another alternative could be to persuade data producers to adopt the extended PROV ontology that was proposed in this paper and expose their lineage metadata in RDF representations connected to the semantic web. For example, the use of RDF was suggested by [52] for provenance metadata in the field of bioinformatics. By doing that, we could use the RDF based technologies for exploding the semantic web, such as a triple store database and a SPARQL query language, to solve the queries and even associate provenance to the SPARWL query responses themselves [53]. However, this will require the collaboration of the producers that will need to embrace the semantic web technologies. Currently, most of the producers are following the Spatial Data Infrastructures best practices and concentrating their efforts in implementing ISO TC211 standards family and Open Geospatial Consortium standard services, and it will be difficult for them to invest resources in other approaches in the near future. Dependencies and relationships between elements are represented in a more natural way in a network graph than in a hierarchical tree form. However, and contrary to what we expect, a graph can be more difficult to follow than a tree representation, particularly in long process chains. The capability of present collections of datasets in a single view rapidly increases the complexity of the relations resulting in 2D representation that are too cluttered. In a 3D visualization, the user can navigate within the 3D scene to find the better perspective that reduces the number of line intersections helping to analyze data [54]. Although a provenance graph with full detail is more informative, filtering our unnecessary nodes in the graphs is a complementary strategy to simplify the diagram and make it understandable. However, where the graph fully deploys its potential is when queries are applied to it. Depending on which query is formulated, different benefits emerge (Some queries could provide more than one benefit. Only the most relevant benefit is presented in this classification): • Information and transparency. These provide a better understanding and compare methodologies in Table 4 Q1, Q3, Q4, Q10, Q11, Q12, Q15, Q16, Q18, Q21, Q24 and Q25, Q27, Q28. Q32, Q33, Q39, Q42, and Q43. • Trust and authority: agents and their responsibilities can be inferred based on the sources and tools used in Table 4 Q2, Q5, Q13, Q20, Q31, Q37, and Q38. • Data quality can be deduced from the quality of the sources and precision of the processing tools used in Table 4 Q6, Q7, Q10, Q14, Q19, Q21 Q22, Q25, Q30, Q34, Q40, and Q44. • Documentation and reproducibility can be achieved if all the necessary details about the actual dataset, metadata, or tools are present, such as in Table 4 Q9, Q16, Q17, Q23, Q24 Q29, and Q41. • License and accessibility: information about the needed resources that were accessed, and licenses needed are present in Table 4 Q8, Q26, Q35, and Q36. ISPRS Int. J. Geo-Inf. 2021, 10, 139 20 of 23 7. Future Work The levels of abstraction that were introduced for processes could also be combined with the abstraction of the sources into generic ones by indicating the schema of the product or, in the extreme case, by only providing the topic category that they belong to. This information can be extracted from the metadata of the sources by looking at ISO 19115 metadata fields not directly related to lineage. This paper presents a sketch of a provenance window that has been co-designed in collaboration with the MiraMon Map Browser implementers. The development has only completed the first loops of an agile methodology that has been prototyped and tested with the data presented in this paper. Further co-design sessions with more users may reveal the need for extra functionalities or the need to change some aspects of the user interface of the provenance query and filter panels. Extending the queries presented in this paper to larger collections is a challenge for the visualization; however, when combined with the right queries, it could be applied to an organization to determine the most useful datasets and tools. This will help organizations that are facing preservation challenges: for the first time, they have to decide which datasets should be preserved from the organizational digital legacy that is too big, and what information can be forgotten and erased from the archives. A comprehensive provenance study can help to determine this. 8. Conclusions The geospatial lineage is a necessary component in the metadata of spatial informa- tion distributed over the web. However, it is recognized that these benefits cannot be materialized if there are no proper tools to help users visualize and interpret the lineage. This paper makes two main contributions to overcome this situation. On one hand, the introduction of four levels of abstraction of the process step descrip- tion (process run, processing tool, algorithm, and functionality) has proven to be a valuable way to better describe lineage. The inclusion of functionalities and algorithm descriptions as a part of lineage provides high-level information and representation independent from the software used and the moment in time the step was executed. This solution has pro- vided certain benefits: it allows for datasets originated with different workflows to be interconnected and makes it possible to compare processing chains at the methodology level. Therefore, it was demonstrated that the lineage model of the ISO19115 family (to ex- press the object types of the geospatial objects that are involved in the production processes) can be combined with W3C PROV (to convey the relationship naming conventions). In this paper, a symbolization as a provenance graph instead of hierarchical tree was explored as a more flexible alternative. The web tool presented in this paper helps users to interpret lineage by making con- nections among processes and making sources more visible, as well as making it possible to filter and query lineage elements. The tool facilitates the formulation of queries to interrogate the origins of geospatial data of a collection of datasets. The tool generates on-demand visualizations that provide answers to queries that emphasize the benefits of lineage data: information and transparency; trust and authority; data quality; documenta- tion and reproducibility; and, license and accessibility. The possibility to formulate queries regarding a collection of datasets gives added value to provenance and provides scientists and technicians with the opportunity to inspect dataset interrelations and processing chain performance. Provenance graphs could help in the difficult task of determining the most useful datasets and eventually deciding what information should be preserved for future generations. Author Contributions: Conceptualization, Guillem Closa and Joan Masó; Research, Guillem Closa; Methodology, Guillem Closa and Joan Masó; Software, Joan Masó and Núria Julià; Writing—original draft, Guillem Closa; Writing—review & editing, Joan Masó, Núria Julià and Xavier Pons. All authors have read and agreed to the published version of the manuscript. ISPRS Int. J. Geo-Inf. 2021, 10, 139 21 of 23 Funding: This work was supported by the Catalan Government [SGR2017 1690]. This work was carried out under the ECOPOTENTIAL, e-shape, and ERA-PLANET projects. These projects have received funding from the European Union’s Horizon 2020 research and innovation program under grant agreement No. 641762-2, 776740 and 689443 respectively. This work has also been supported by the Spanish MCIU Ministry through the NEWFORLAND project (RTI2018-099397-B-C21/22 (MCIU/AEI/ERDF, EU)). Xavier Pons is the recipient of an ICREA Academia Excellence in Research Grant (2016–2020). Acknowledgments: We would like to thank the land cover time series team of CREAF and UAB for their valuable help. Conflicts of Interest: There are no conflict of interest to declare. References 1. Baker, M. 1,500 scientists lift the lid on reproducibility. Nat. Cell Biol. 2016, 533, 452–454. [CrossRef] 2. Lemos, M.C.; Kirchhoff, C.J.; Ramprasad, V. Narrowing the climate information usability gap. Nat. Clim. Chang. 2012, 2, 789–794. [CrossRef] 3. Spiekermann, R.; Jolly, B.; Herzig, A.; Burleigh, T.; Medyckyj-Scott, D. Implementations of fine-grained automated data provenance to support transparent environmental modelling. Environ. Model. Softw. 2019, 118, 134–145. [CrossRef] 4. Brinckman, A.; Chard, K.; Gaffney, N.; Hategan, M.; Jones, M.B.; Kowalik, K.; Stodden, V. Computing environments for reproducibility: Capturing the “Whole Tale”. Future Gener. Comput. Syst. 2019, 94, 854–867. [CrossRef] 5. Lewis, A.; Lacey, J.; Mecklenburg, S.; Ross, J.; Siqueira, A.; Killough, B.; Szantoi, Z.; Tadono, T.; Rosenavist, A.; Goryl, P.; et al. CEOS Analysis Ready Data for Land (CARD4L) Overview. In Proceedings of the IGARSS 2018—2018 IEEE International Geoscience and Remote Sensing Symposium, Valencia, Spain, 22–27 July 2018; IEEE: Piscataway, NJ, USA, 2018; pp. 7407–7410. 6. Giuliani, G.; Chatenoux, B.; Bono, A.D.; Rodila, D.; Richard, J.P.; Allenbach, K.; Peduzzi, P. Building an Earth Observations Data Cube: Lessons learned from the Swiss Data Cube (SDC) on generating Analysis Ready Data (ARD). Big Earth Data 2017, 1, 100–117. [CrossRef] 7. Fisher, P.F. Algorithm and Implementation Uncertainty: Any Advances? Int. J. Geogr. Inf. Sci. Syst. 2006, 225–228. 8. Lutz, M.; Riedemann, C.; Probst, F. A Classification Framework for Approaches to Achieving Semantic Interoperability between GI Web Services. In Proceedings of the International Conference on Spatial Information Theory, Kartause Ittingen, Switzerland, 24–28 September 2008; Springer: Berlin/Heidelberg, Germany, 2003; pp. 186–203. 9. CEOS Interoperability Terminology, Version 1.0. CEOS—WGISS Interoperability and Use Interest Group. 2020. Available online: https://ceos.org/document_management/Meetings/Plenary/34/Documents/CEOS_Interoperability_Terminology_ Report.pdf (accessed on 20 October 2020). 10. Jiang, L.; Yue, P.; Kuhn, W.; Zhang, C.; Yu, C.; Guo, X. Advancing interoperability of geospatial data provenance on the web: Gap analysis and strategies. Comput. Geosci. 2018, 117, 21–31. [CrossRef] 11. Yue, P.; Wei, Y.; Di, L.; He, L.; Gong, J.; Zhang, L. Sharing geospatial provenance in a service-oriented environment. Comput. Envi- ron. Urban Syst. 2011, 35, 333–343. [CrossRef] 12. Zhang, M.; Yue, P.; Wu, Z.; Ziebelin, D.; Wu, H.; Zhang, C. Model provenance tracking and inference for integrated environmental modelling. Environ. Model. Softw. 2017, 96, 95–105. [CrossRef] 13. He, L.; Yue, P.; Di, L.; Zhang, M.; Hu, L. Adding Geospatial Data Provenance into SDI—A Service-Oriented Approach. IEEE J. Sel. Top. Appl. Earth Obs. Remote Sens. 2015, 8, 926–936. [CrossRef] 14. Growth, P.; Moreau, L. PROV-Overview: An Overview of the PROV Family of Documents. W3C. 2013. Available online: https://eprints.soton.ac.uk/356854/ (accessed on 20 October 2020). 15. Lanter, D.P. Design of a Lineage-Based Meta-Data Base for GIS. Cartogr. Geogr. Inf. Syst. 1991, 18, 255–261. [CrossRef] 16. Spatial Data Transfer Standard (SDTS); American National Standards Institute’s (ANSI). ANSI/NCITS320.1998. 1998. Available online: https://www.fgdc.gov/standards/projects/SDTS/sdts_cadd/finalcadd.pdf (accessed on 15 October 2020). 17. ISO. Geographic Information—Metadata; ISO 19115:2003; ISO: Geneva, Switzerland, May 2003; 140p. 18. ISO. Geographic Information—Metadata—Part 1: Fundamentals; ISO 19115-1:2014; ISO: Geneva, Switzerland, April 2014; 167p. 19. ISO. Geographic Information—Metadata—Part 2: Extensions for Acquisition and Processing; ISO 19115-2: 2019; ISO: Geneva, Switzer- land, January 2019; 57p. 20. Di, L.; Shao, Y.; Kang, L. Implementation of Geospatial Data Provenance in a Web Service Workflow Environment with ISO 19115 and ISO 19115-2 Lineage Model. IEEE Trans. Geosci. Remote Sens. 2013, 51, 5082–5089. [CrossRef] 21. Di, L.; Yue, P.; Ramapriyan, H.K.; King, R.L. Geoscience Data Provenance: An Overview. IEEE Trans. Geosci. Remote Sens. 2013, 51, 5065–5072. [CrossRef] 22. Ivánová, I.; Armstrong, K.; McMeekin, D. Provenance in the next-generation spatial knowledge infrastructure. In Proceedings of the 22nd International Congress on Modelling and simulation (MODSIM 2017), Hobart, Tasmania, Australia, 3–8 December 2017; pp. 410–416. 23. Lopez-Pellicer, F.J.; Barrera, J. D16. 1 Call 2: Linked map VGI provenance schema. In Linked Map Subproject of Planet Data. Seventh Framework Programe; European Commission: Brussels, Belgium, 2014. ISPRS Int. J. Geo-Inf. 2021, 10, 139 22 of 23 24. Closa, G.; Masó, J.; Proß, B.; Pons, X. W3C PROV to describe provenance at the dataset, feature and attribute levels in a distributed environment. Comput. Environ. Urban Syst. 2017, 64, 103–117. [CrossRef] 25. Closa, G.; Masó, J.; Zabala, A.; Pesquer, L.; Pons, X. A provenance metadata model integrating ISO geospatial lineage and the OGC WPS: Conceptual model and implementation. Trans. GIS 2019, 23, 1102–1124. [CrossRef] 26. Salton, G.; Allan, J.; Buckley, C.; Singhal, A. Automatic analysis, theme generation, and summarization of machine-readable texts. Science 1994, 264, 1421–1426. [CrossRef] 27. Konkol, M.; Kray, C. In-depth examination of spatiotemporal figures in open reproducible research. Cartogr. Geogr. Inf. Sci. 2019, 46, 412–427. [CrossRef] 28. Yazici, I.M.; Karabulut, E.; Aktas, M.S. A Data Provenance Visualization Approach. In Proceedings of the 2018 14th International Conference on Semantics, Knowledge and Grids (SKG), Guangzhou, China, 12–14 September 2018; IEEE: Piscataway, NJ, USA, 2018; pp. 84–91. 29. Cohen-Boulakia, S.; Belhajjame, K.; Collin, O.; Chopard, J.; Froidevaux, C.; Gaignard, A.; Hinsen, K.; Larmande, P.; Le Bras, Y.; Lemoine, F.; et al. Scientific workflows for computational reproducibility in the life sciences: Status, challenges and opportunities. Future Gener. Comput. Syst. 2017, 75, 284–298. [CrossRef] 30. Yue, P.; Zhang, M.; Guo, X.; Tan, Z. Granularity of geospatial data provenance. In Proceedings of the 2014 IEEE Geoscience and Remote Sensing Symposium, Quebec, QC, Canada, 13–18 July 2014; IEEE: Piscataway, NJ, USA, 2014; pp. 4492–4495. 31. Albrecht, J. Universal Analytical GIS Operations: A Task-Oriented Systematization of Data Structure-Independent GIS Function- ality. Geogr. Inf. Res. Transatl. Perspect. 1998, 577–591. Available online: https://www.researchgate.net/publication/228530780_ Universal_analytical_GIS_operations_a_task-oriented_systematization_of_data_structure-independent_GIS_functionality (ac- cessed on 20 October 2020). 32. Sun, Z.; Yue, P.; Di, L. GeoPWTManager: A task-oriented web geoprocessing system. Comput. Geosci. 2012, 47, 34–45. [CrossRef] 33. Goodchild, M.F. Geographic information systems. Prog. Hum. Geogr. 1991, 15, 194–200. [CrossRef] 34. Kuhn, W.; Ballatore, A. Designing a Language for Spatial Computing. In Proceedings of the Agile 2015, Washington, DC, USA, 3–7 August 2015; Springer: Berlin/Heidelberg, Germany, 2015; pp. 309–326. 35. Yue, C.; Baumann, P.; Bugbee, P.; Jiang, L. Towards intelligent giservices. Earth Sci. Inf. 2015, 8, 463–481. [CrossRef] 36. ESRI. ArcGIS Desktop: Release 10; Environmental Systems Research Institute: Redlands, CA, USA, 2020. 37. Pons, X. MiraMon: Geographical Information System and Remote Sensing Software; Centre de Recerca Ecològica i Aplicacions Forestals: Barcelona, Spain, 2020. 38. GRASS Development Team. Geographic Resources Analysis Support System (GRASS) Software, Version 7.2. Open Source Ge-ospatial Foundation. 2017. Available online: http://grass.osgeo.org (accessed on 20 October 2020). 39. SNAP—ESA. Sentinel Application Platform v8.0.0. 2020. Available online: http://step.esa.int (accessed on 20 October 2020). 40. Lopez-Pellicer, F.J.; Lacasta, J.; Espejo, B.A.; Barrera, J.; Agudo, J.M. The standards bodies soup recipe: An experience of interoperability among ISO-OGC-W3C-IETF standards. In Proceedings of the Inspire-Geospatial World Forum, Lisbon, Portugal, 25–29 May 2015. 41. Masó, J.; Pons, X.; Zabala, A. Building the World Wide Hypermap (WWH) with a RESTful architecture. Int. J. Digit. Earth 2012, 7, 175–193. [CrossRef] 42. Erwig, M.; Schneider, M. Developments in spatio-temporal query languages. In Proceedings of the Tenth International Workshop on Database and Expert Systems Applications DEXA 99, Florence, Italy, 3 September 1999; IEEE: Piscataway, NJ, USA, 1999; pp. 441–449. 43. Koubarakis, M.; Karpathiotakis, M.; Kyzirakos, K.; Nikolaou, C.; Sioutis, M. Data Models and Query Languages for Linked Geospatial Data. In Reasoning Web International Summer School; Springer: Berlin/Heidelber, Germany, 2012; pp. 290–328. 44. Amann, B.; Scholl, M. Gram: A graph data model and query languages. In Proceedings of the ACM conference on Hypertext, Seattle, WA, USA, 14–18 November 1993; pp. 201–211. 45. Maso, J. OGC JSON Best Practice Draft. 2018. Available online: https://github.com/opengeospatial/architecture-dwg/tree/ master/json-best-practice (accessed on 15 October 2020). 46. Masó, J.; Zabala, A.; Pons, X. Protected Areas from Space Map Browser with Fast Visualization and Analytical Operations on the Fly. Characterizing Statistical Uncertainties and Balancing Them with Visual Perception. ISPRS Int. J. Geo-Inf. 2020, 9, 300. [CrossRef] 47. Vis.js. 2020. Available online: https://visjs.org/ (accessed on 25 October 2020). 48. Generalitat de Catalunya; Departament de Territori i Sostenibilitat. Land Use and Cover Open Data Page. 2020. Available online: https://territori.gencat.cat/ca/01_departament/12_cartografia_i_toponimia/bases_cartografiques/medi_ambient_i_ sostenibilitat/usos-del-sol/ (accessed on 20 October 2020). 49. Ibàñez, J.J.; Burriel, J.A. Mapa de cubiertas del suelo de Cataluña: Características de la tercera edición y relación con SIOSE. In Tecnologías de la Información Geográfica: La Información Geográfica al Servicio de los Ciudadanos; Ojeda, J., Pita, M.F., Vallejo, I., Eds.; Secretariado de Publicaciones de la Universidad de Sevilla: Sevilla, Spain, 2010; pp. 179–198, ISBN 978-84-472-1294-1. 50. González-Guerrero, Ò.; Pons, X.; Bassols-Morey, R.; Camps, F.X. Dinàmica de les Superfícies de Conreu a Catalunya Mitjançant Teledetecció en el període 1987–2012. Quaderns Agraris 2019, 59–91. 51. González-Guerrero, Ò.; Pons, X. The 2017 Land Use/Land Cover Map of Catalonia based on Sentinel-2 images and auxiliary data. Revista de Teledetección 2020, 55, 81–92. [CrossRef] ISPRS Int. J. Geo-Inf. 2021, 10, 139 23 of 23 52. Zhao, J.; Goble, C.; Stevens, R.; Turi, D. Mining Taverna’s semantic web of provenance. Concurr. Comput. Pract. Exp. 2008, 20, 463–472. [CrossRef] 53. Theoharis, Y.; Fundulaki, I.; Karvounarakis, G.; Christophides, V. On Provenance of Queries on Semantic Web Data. IEEE Internet Comput. 2010, 15, 31–39. [CrossRef] 54. Viola, F.; Roffia, L.; Antoniazzi, F.; D’Elia, A.; Aguzzi, C.; Cinotti, T.S. Interactive 3D Exploration of RDF Graphs through Semantic Planes. Future Internet 2018, 10, 81. [CrossRef]