EDI is a general purpose, template-driven metadata editor for creating XML-based descriptions. Originally aimed at defining rich and standard metadata for geospatial resources, It can be easily customised in order to comply with a broad range of schemata and domains.
EDI creates HTML5  metadata forms with advanced assisted editing capabilities and compiles them into XML files. The examples included in the distribution implement profiles of the ISO 19139 standard for geographic information , such as core INSPIRE metadata , as well as the OGC  standard for sensor description, SensorML .
Templates (the blueprints for a specific metadata format) drive form behaviour by element data types and provide advanced features like codelists1 underlying combo boxes or autocompletion functionalities.
Virtually, the editing of any metadata format can be supported by creating a specific template.
EDI is stored on GitHub at https://github.com/SP7-Ritmare/EDI-NG_client and https://github.com/SP7-Ritmare/EDI-NG_server.
The effective provisioning of spatial resources on the Internet has always been hampered by the intrinsic characteristics of this category of data: They are either of non-textual nature or, even when utilizing a text-based format for their encoding, generally convey little information on their semantics, purpose, and associated principals. For this reason, metadata is typically associated with resources in order to ground search, retrieval, and ultimately reuse of spatial information. Also, once instances of this category of resources are successfully “discovered” through the ad-hoc search engines generally referred to as geoportals, compliance with a number of access protocols is required by user agents in order to actually exploit the associated data.
The management of geospatial information in Europe is regulated by the INSPIRE (INfrastructure for SPatial InfoRmation in Europe) Directive , which itself is based on the groundwork set by the ISO 19115 (“Geographic information – Metadata) and ISO 19119 (Geographic information – Services) standards. Unfortunately, these standards can easily become inadequate because of the emergence of categories of data not previously considered. As an example, spatial data (in the broadest sense) have been recently enriched by the new category of data sources constituted by real-time/near-real-time data pulled from sensors. Consequently, these new data sources require specific data and metadata representations for management and enactment.
In this context, metadata editing plays a pivotal role that requires a flexible strategy. EDI, is a template-based metadata editor that is capable of abstracting from the specific XML schema a given metadata format is complying with. Also, the service-based deployment strategy allows users to retain full control on the data structures that are produced. Further details on EDI’s role can be found in [1, 3]
EDI’s main goals are depicted in Figure 1 and listed here:
EDI allows system administrators to easily associate codelists, controlled vocabularies, and any kind of context information that are specific to their domain with the application. This capability is supported by allowing the editing interface to draw information from generic RDF data structures  made available as SPARQL endpoints.
EDI was developed as part of sub-project 7 (http://www.ritmare.it/en/articolazione/sottoprogetto-7.html) of the Italian Flagship Project RITMARE (http://www.ritmare.it/).
Creating a form based on a specific template is as easy as inserting the following line inside a script tag:
edi.loadLocalTemplate(“INSPIRE_dataset”, “1.00”, onTemplateLoaded);
Templates are described by XML files, in terms of elements (groups of controls somehow related to one another) and items (single controls).
EDI consists of a client- and a server-side components.
The relationship between them is shown in Figure 2.
The EDI client gathers input from the user.
It then packs the information provided by the user into an intermediate data structure (referred to as EDIML) and sends it to the EDI server to be compiled into the specific metadata (XML) format the template refers to.
The server sends the XML metadata back to the client for further usage (e.g. storage, CSW4 sharing, …).
Its main components are:
The server is written in Java as a Spring5 Boot Application.
The server consists of:
Listings 1, 2, 3, 4 show excerpts of the template for SensorML v2.0.0 and allow to pinpoint the main characteristics of the EDI meta-language. The outer template tag contains a settings section that defines the general parameters that are taken into account for creating the HTML editing front-end: Particularly, the metadataEndpoint and sparqlEndpoint tags contain, respectively, the URL of the web service processing the client input and the default SPARQL endpoint for the datasources below. The baseDocument tag contains the outermost levels of the document’s XML hierarchy that is shared by all descriptions that are created with a given template. The next essential component of a template is the definition of datasources, that is, the specification of where to look up when the editor fills drop-down lists, provides alternatives for the autocompletion features, etc. For convenience, these can also be clustered into endpointTypes in order to avoid duplication of parameters that are shared by all instances of a specific triple store (i.e., the data base for RDF).
The template then contains a sequence of group tags that allow the developer, as the name suggests, to group metadata elements together, a feature that can be employed to divide the editing interface into sections or tabs. Group tags contain a number of element tags that represent metadata fields, even when these are composite entities made up by a number of distinct items. Each of these three constructs can be given multilingual labels in order to tailor the interface to multiple languages (and automatically switch between them). Each element tag specifies whether the metadata element isMandatory or isMultiple. Also, tag hasRoot specifies at which level of the XML node tree multiple instances of the same element shall be rooted. Finally, item tags represent all the nodes that are required in order to fully define the metadata item (ISO metadata is particularly redundant in the specification of these).
A key component in the specification of items is the associated data type, specified by means of the hasDatatype attribute.
EDI templates define the primitives necessary for the definition of metadata elements.
Each element defines one or more items that correspond to the individual XML nodes that are populated in the metadata record.
The essential information defining an element is:
Elements contain items, which have a data type declared for validation purposes.
A list of available data types is shown in Table 1.
|Simple||Composite||External sources||Internal references|
|string||dateRange||code (alias: codelist)||copy|
EDIML is an XML format we devised to pass on user-entered metadata from the EDI client to the EDI server and backwards, without losing the semantic enrichment EDI is capable of when the destination format is semantics-unaware, as ISO standards, unfortunately, are.
This is the reason why EDI constantly keeps two versions of each metadata: one in EDIML, e.g. for subsequent editing, and one in the destination format (e.g. SensorML 2.00).
Listing 7 shows an example of the EDIML format. Please note that, for item manuf_name_3, the value is “DeepSea Power & Light”, but the URI (i.e. “http://sp7.irea.cnr.it/rdfdata/sensors/manufacturer/31”) is brought along.
Functional testing was conducted by manually creating a collection of metadata, used as a test bench for validation.
Both Sensor ML (ver 1.0.0 and 2.0.0) and INSPIRE metadata are created by different experts of different disciplines (physical and chemical oceanography, marine geology, geophysics, coastal systems, marine ecology, fishery and aquaculture, marine biomolecular science, human impacts, climatology, biogeochemistry, remote sensing, agriculture) and for different type of data resources, in order to account for the huge variability of contents, lexicons, outlooks, as well as for the subjectivity, in the metadata filling. Several experts participating to research projects, mainly RITMARE, are involved in the testing; metadata are manually compiled using the template available in the standard distribution that refers to one specific metadata (XML) format. More than 60 samples of Sensor ML and more than 50 samples of INSPIRE metadata are compiled for the purpose.
The consistency was carried out for the whole metadata collection against the corresponding XML Schemas6 (as declared in the baseDocument tag), by means of SensorML and ISO XSDs.
Quality has been further tested specifically for the INSPIRE profile by means of the official INSPIRE validator (available at http://inspire-geoportal.ec.europa.eu/validator2/), manually uploading the samples, and getting positive returns.
Any OS that can run Java 1.7 for the back end, any OS for the client
EDI Client is tested on Mozilla Firefox
Java 1.7 (EDI Server only)
PostgreSQL9 9.0+ (EDI Server only, tested on 9.3.4)
Archive (e.g. institutional repository, general repository) (required)
EDI Server: https://github.com/SP7-Ritmare/EDI-NG_server.git
Distribution (v1.2, commit ID b351a9d): https://github.com/SP7-Ritmare/EDI-NG_server/releases/download/v1.2/edi.zip
EDI Client: https://github.com/SP7-Ritmare/EDI-NG_client.gitDistribution (v 1.2, commit ID 2f4f05c): https://github.com/SP7-Ritmare/EDI-NG_client/releases/tag/v1.2
Licence: GPL v3
Publisher: Fabio Pavesi
Date published: 15/12/14
EDI actually has great reuse potential.
In fact, it can generate documents according to any XML schema and then any data formats with an XML serialisation can be produced.
Plenty of templates are available in the EDI-NG_templates repository10, which we have been using in several research projects, also serve as samples of what can be attained with templates.
For instance, we provide both SensorML 1.0.1 and SensorML 2.0
As an example, an EDI template11 producing an RDF/XML output has been developed.
On the other hand, as EDI allows for specifying an arbitrary chain of XSL Transformations for post-processing the XML output, it can generate any text-based output format as well.
1a codelist is a flat terminology (as opposed to hierarchical ones, such as taxonomies) that is defined to indicate the possible values of a specific data item; as an example, the ISO standards for geographic information define a number of codelists for specifying the resource type (whose possible values are dataset, series, and service), the role of a point of contact (creator, custodian, distributor, etc.).
3Uniform Resource Identifier (URI): https://tools.ietf.org/html/rfc3986
4Catalog Service for the Web – http://www.opengeospatial.org/standards/cat
5Spring – http://spring.io
6XML Schema – http://www.w3.org/standards/xml/schema
9PostgreSQL – http://www.postgresql.org
10EDI-NG_templates repository – https://github.com/SP7-Ritmare/EDI-NG_templates.git
The activities described in this paper have been funded by the Italian Flagship Project RITMARE and LifeWatch Italy.
The authors declare that they have no competing interests.
Basoni, B, Bastianini, M, Fugazza, C, Menegon, S, Minuzzo, T, Oggioni, A, Pavesi, F, Sarretta, A, Tagliolato, P, Vianello, A and Carrara, P (2014). EDI: Software per la metadatazione di risorse geografiche, dati osservativi e documenti, conformi RNDT e INSPIRE. Available at: https:// github.com/SP7-Ritmare?query=EDI.
European Commission (2008). Commission Regulation (EC) No 1205/2008 of 3 December 2008 implementing Directive 2007/2/EC of the European Parliament and of the Council as regards metadata. Official Journal of the European Union L 326((1205)): 12–30. Available at: http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2008:326:0012:0030:EN:PDF.
Fugazza, C et al. (2014). A Holistic, Semantics-aware Approach to Spatial Data Infrastructures. Proceedings of 3rd International Conference on Data Management Technologies and Applications. SCITEPRESS – Science and and Technology Publications: 349–356, DOI: https://doi.org/10.5220/0004997603490356 Available at: http://www.scitepress.org/DigitalLibrary/Link.aspx?.
Harris, S and Seaborne, A (2013). SPARQL 1.1 Overview. W3C recommendation. March 21 2013 Available at: http://www.w3.org/TR/sparql11-query/.
W3C (2014). RDF 1.1 Semantics – W3C Recommendation In: W3C. February 25 2014 Available at: http://www.w3.org/TR/rdf11-mt/.
Fugazza, C et al. (2014). The RITMARE Starter Kit: Bottom-up Capacity Building for Geospatial Data Providers. Proceedings of the 9th International Conference on Software Paradigm Trends. : 169–176. Available at: http://www.scitepress.org/DigitalLibrary/Link.aspx?doi=10.5220/0004999801690176.
Fielding, R T and Taylor, R N (2000). Principled design of the modern Web architecture. Proceedings of the 2000 International Conference on Software Engineering. ICSE 2000 the New Millennium. 2(2): 115–150.
Open Geospatial Consortium (). http://www.opengeospatial.org/
Hickson, I, Berjon, R, Faulkner, S, Leithead, T, Navara, E, O’Connor, E and Pfeiffer, S (2014). HTML5, W3C Recommendation. REC-html5-20141028. Available at: <http://www.w3.org/TR/2014/REC-html5-20141028>.
European Commission Joint Research Centre (2013). INSPIRE Metadata Implementing Rules: Technical Guidelines based on EN ISO 19115 and EN ISO 19119, version 1.3. Available at: http://inspire.ec.europa.eu/documents/Metadata/MD_IR_and_ISO_20131029.pdf.
Open Geospatial Consortium (2014). OGC® SensorML: Model and XML Encoding Standard, version 2.0.0. Available at: https://portal.opengeospatial.org/files/?artifact_id=55939.
International Organization for Standardization (2007). ISO/TS 19139:2007 Geographic information – Metadata – XML schema implementation In: ISO. Available at: http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=32557.