OGC Environmental Linked Features Interoperability Experiment Engineering Report

Services and linked data for distributed spatio-temporal information on the internet hold the promise to increase interoperability and expressivity while decreasing duplication and data maintenance overhead. In order to achieve this potential, web service APIs and payloads need to work seamlessly with linked open data ontologies and hypermedia. Current OGC services, while flexible and capable, do not directly allow exposure of features in a REST-ful way or provide traversable hypermedia describing available methods, data, or interfaces to related (linked) content. Linked open data has the potential to turn the normal OGC service pattern (GetCapabilities request followed by introspection to understand contents) inside out by encoding associations between features as linked data predicates but specific implementation conventions and best practices are yet to be established.

Two core functional goals motivated the engineering described in this report: 1) The need to encode relationships between and among environmental features, and 2) the need to link observational data to the features they describe. Given that relationships in the absence of context are of little value, a third goal was the need for an ultimately general preview of a feature to provide just enough context in a ubiquitous form. These three functional goals coupled with a non-functional goal of using highly-adoptable technologies provided more than enough problem space for the interoperability experiment to take on.

Prior to initiating ELFIE, significant work had been completed on data models for numerous domains and types of data including hydrology, hydrogeology, soils, observations, and timeseries but almost never used together. The OGC services baseline was well implemented across the community but practices for use of OGC services, primarily those based on the Web Feature Service (WFS) standard, were extremely varied and fully interoperable. ELFIE sought to provide implementation conventions as a target for 1) future data model encodings to integrate data across domains, 2) design and use of web services in a linked data context, and 3) design of future services and software to fill an important gap in open distributed environmental data systems.

At the conclusion of the project, technical best practices for encoding links between and among features and observations are in sight. A general approach to using the power of OGC web service APIs to expose features in the context of rich domain-feature-model-based linked data while following W3C best practices has been described. The solution requires additional work to establish and publish ontologies and points to a number of opportunities to evolve data and service standards to meet the needs of environmental features and observations. This work has begun or will be proposed under the OGC Naming Authority, relevant OGC and W3C Standards and Domain Working Groups, and a follow-on Second ELFIE (SELFIE) focused on URI dereferencing and default content is being planned.

The ELFIE provides recommendations and conventions for work in working groups across OGC and W3C. The WFS Standards Working Group (SWG)'s work on WFS 3.0 appears to be well-suited to ELFIE goals, but consideration for HTTP URIs to identify and query for features should be clearly supported by the future incarnation of WFS. Various OGC Working Groups need to establish ontologies and work through the OGC Naming Authority to publish their feature types and associations for broad use in linked data. Similarly, all data providers should pursue enterprise or community capabilities to mint and publish URIs and available representations of features and observations they own. Without this critical foundation, which can and should be recognized as a rudimentary starting point, linked data applications cannot move forward. Finally, the scope of ELFIE was purposefully limited to encoding of links in linked data documents. A future IE should look at an expanded scope to include URL dereferencing and default response content for URIs that identify real world features and content that links to various information resources that represent or are linked to the real-world non-information resource.

All questions regarding this document should be directed to the editor or the contributors:

Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. The Open Geospatial Consortium shall not be held responsible for identifying any or all such patent rights.

Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the standard set forth in this document, and to provide supporting documentation.

Abstraction of real-world phenomena. [ISO 19101:2002, definition 4.11].

Facet or attribute of an object referenced by a name [ISO 19143:2010, definition 4.21]

The subject is the first part of an RDF statement. A subject in the context of a triple <?s ?p ?o> refers to who or what the RDF statement is about. (See https://www.w3.org/TR/ld-glossary/#subject [1])

The middle term (the linkage, or "verb") in an RDF statement. For example, in the statement "Alice knows Bob" then "knows" is the predicate which connects "Alice" (the subject of the statement) to "Bob" (the object of the statement). (See https://www.w3.org/TR/ld-glossary [1])

In the context of RDF, the object is the final part of an RDF statement. (See https://www.w3.org/TR/ld-glossary/#object [1])

A resource represents anything that can be identified, including physical things, documents, abstract concepts, numbers and strings (see https://www.w3.org/TR/rdf11-concepts/ [2])

Act of measuring or otherwise determining the value of a property [ISO19156:2011, definition 4.11]

specific (simplified and useful) subset of a rich (complete but complicated) linked data graph

A URI for a non-information resource, which is a web resource that cannot be transmitted electronically. A URI is defined as a non-information URI when a HTTP Get Request does not return a 2xx “Success” response when dereferenced. No data are returned because the URI represents something other than a web information resource. i. e. a person or object.

A physiographic unit defined by a common hydrologic outlet and potentially defined input(s). May have several representations per OGC 14-111r6 HY_Features. Note that “watershed” translations may be problematic (e.g. translating the term into German leads to two valid but different terms, i.e. “Wasserscheide”, which is the actual drainage divide, and “Einzugsgebiet”, which is the area. The definition here encompases both.).

The ELFIE tested the assumption that broadly adopted web technologies for linked data could be applied in the environmental domain to satisfy the needs of a number of compelling use cases. The Objectives section describes engineering design goals and details the assumptions and scope that were used to constrain the magnitude of the IE. Much of the IE involved design discussions amongst participants where candidate use cases were considered and potential technologies and implementations were explored. The Use Case Summary section describes these use cases and the select set that were more thoroughly tested to evolve the technologies that were agreed upon during design discussions.

The ELFIE technology selection criteria were that they be adoptable, common, and suitable to the needs of the ELFIE use cases. In some cases, new and thus lightly tested domain feature models were applied with the chosen, well established, technologies. The Applicable Best Practices and Standards section is a brief discussion of the technologies and standards tested in the ELFIE. The technology chosen to provide a precise but not overly prescriptive description of the RDF views is the JSON-LD context. Details of the contexts defined in the ELFIE are discussed in the Relations and JSON-LD Contexts section.

The outcomes of the ELFIE provide guidance for creating (graph) views of environmental features and observations. A simple view intended to be a preview, suitable for basic indexing is specified. Views intended to provide topological as well as observational and domain feature model relationships were also explored. The Preview view was largely successful, but there was no one satisfactory solution for expression of a preview geometry because GeoJSON is incompatible with JSON-LD, WKT is thought to be difficult to work with in typical web environments, and the schema.org geometries were found to have limited utility. The experimentation with domain feature models led to the conclusion that the underlying linked data technologies are mature enough, but progress is still needed on domain feature ontologies and encoding geometry. These issues are discussed in more detail in the Summary of Experiment and Analysis of Outcomes and Issues and Recommendations for Future Work sections.

The ELFIE explored a number of interesting but tangential topics. Annex A: Strategies for Publishing Domain Ontologies as Linked Data from OGC domain standards is a summary of one important topic discussed; how to generate a feature ontology from a UML model. Annex B: Default Response for Multiple Representions and Relations is a brief discussion of issues related to what the default response should be when resolving a URI for a non-information resource that may have multiple representations.

To test the assumptions described above, a number of example test cases (described below) were used to guide the design and testing of potential technical solutions. The use cases were hypothetical, clearly of value to the domain, and technically difficult using existing technologies and practices. Discussion of use cases was predicated on the assumption that these would be implemented as test cases under the IE. While time and resources did not allow all these use cases to be implemented for the ELFIE, the use cases provided invaluable context and example systems to guide discussion and vetting of design alternatives.

The specifics of technologies and practices the IE tested are described below. With a clear direction, participants implemented test data and code to exercise and demonstrate the IE outcomes. Application of the use cases considered in the design phase led to some refinement to the design, but the design selected largely satisfied the goals of the IE with some clear next steps and further work needed to formalize data models, encodings, and best practices. The experiment succeeded in identifying shortcomings of some existing practices and gaps in the standards base line that need to be filled. Putting further work and needed new work aside, the IE failed to find significant or fundamental problems with the best practices and standards tested.

The design phase of the ELFIE focused on identification of a number of use cases with extensive need for linked environmental data. These use cases focused on known difficulties of the systems the ELFIE participants maintain or depend on as users. Many of these use cases were used for the discovery and vetting of ideas only. Others were further developed with implementation of example encoded linked data and client code to produce desired results of the use case.

Test cases that were implemented as demonstrations of the design outcomes are described below in full detail to include notional diagrams of how datasets involved link to each other, a thorough description of the use case, and an example application that speaks to and/or satisfies the needs of the use case.

The full suite of use cases considered during the design phase of the project are described in the Use Cases Considered in Design Process appendix. Each use case takes the form of a simple description of who or what system has an interest in what related datasets. Specific datasets are listed to clarify the scope and provide a starting point for future technical design work.

Water budget summary: This use case provides a person interested in a basic summary of the water budget for a given watershed information about a collection of watersheds and their water budget data. It links together various hydrographic representations of each watershed as well as observational water budget data and related web resources.

As shown in the Figure 1, the watershed feature (black) is linked to various representations of it or information characterizing it (white). This follows the HY_Features HY_Catchment concept (Watershed in figure 1) as an unrealized feature that is related to various realization features, there is no canonical representation of the watershed itself.

Additional details about the water budget summary use case implementation is available on the demonstration ELFIE web page.

Flood risks and impacts: This use case provides a decision maker needing to respond to flooded transportation infrastructure the information they need to understand the impacted assets and flooded roads for a forecast flood. Under this use case, a flood forecasting system would be able to discover vulnerable infrastructure and assets published by local jurisdictions as linked data and publish flood forecasts that include potentially impacted features in forecast information products.

Additional details about the flood risk use case implementation is available on the demonstration ELFIE web page.

Ground water level monitoring: This use case is meant to demonstrate how from a given well URI any user (domain expert, machine) can then traverse to the monitoring strategy deployed (piezometer information etc.) and then access ground water level time series and/or information about the monitored aquifer.

Additional details about the ground water level monitoring use case implementation is available on the demonstration ELFIE web page.

Surface-ground water networks interaction: This use case is meant to demonstrate how, from a given Piezometer URI, any user (domain expert, machine) can traverse to the ground water monitoring strategy (see Ground water level monitoring Use Case) but also to the associated surface water monitoring one. Provided each surface/groundwater feature is properly linked together (River network, Aquifer system), it is then feasible to discover information about the full, comprehensive water system. This use case can be seen as a flagship demonstration of the usefulness of linked data in the environmental/cross-domain context.

Additional details about the surface-ground water networks interaction use case implementation is available on the demonstration ELFIE web page.

Watershed data index: This use case is meant to demonstrate the use of HY_Features to link a catchment to the data representing it as well as the monitoring network associated with it. It serves as a general demonstration that could be used for a wide array of linked watershed information use cases.

Additional details about the watershed data index use case implementation is available on the demonstration ELFIE web page.

This use case is introduced in more detail than those above and its technical details are presented below. Technical details of other use cases can be found at the ELFIE demonstration web page.

The watershed data index use case is focused on a single HY_Catchment feature with an identifier of "070900020601" from the U.S. watershed boundary dataset. Given that HY_Catchment is an unrealized feature type, the document describing "070900020601" links to realizations of "070900020601". Three catchment realizations are included:

A more complete implementation could include multiple versions of any of these feature types as well as additional realization types such as a network of channels, or a network of sub-catchments. The boundary polygon and hydrographic network are geospatial features that only link back to the catchment they realize. The hydrometric network is a more complex feature that aggregates a set of network stations, each of type HY_HydrometricFeature.

This use case is introduced in more detail than those above and its technical details are presented below as it makes intensive use of linked data technologies.

The Surface-ground water networks interaction use case is focused on a single Piezometer with an identifier from the French Ground Water Information Network (00463X0036-H1.2). From its JSON-LD description it is possible to dereference URIs of observations, the monitored Hydrogeounit, and also the associated Stream gage. In hydrological contexts where surface water - groundwater interactions are properly described, groundwater and surface water monitoring stations can be ‘associated’ with correlation coefficients as behavior of their monitored featured has an impact on the other. The associated Stream gage description is also linked to the river network.

The implementation use case tested during ELFIE allowed traversal of the data graph depicted below. Using a dedicated application, it was possible to interact with it: either displaying on maps geographical features or triggering observation display widgets (timeseries).

The approach taken in the ELFIE was limited in contrast to recent IEs concerning environmental information models. The ELFIE focused on linked data documents that contain collections of linked features and related observations. With regard to the OGC Reference Model, this IE seeks to understand how features (geospatial information, observations) can be linked to each other in specific resolved views (as in Box 1: Linked Data Graph Views) of the linked data graph or by reference through use of HTTP URIs. The ELFIE did not seek to solve problems regarding network architecture for resolving links or systems design and governance for applications.

Given this, the ELFIE sought to define a common approach to encoding links between environmental domain features that would allow cross-domain and cross-system sharing and interoperability of such linked information. To do this, the ELFIE worked with existing and pending OGC standards for encoding of environmental observation data in an integrated dataset of features. Such OGC data models were then linked together according to W3C and other Linked Data best practices.

OGC Web Service standards for features and observations (WFS, Sensor Observation Service (SOS), and SensorThings API) were used to construct HTTP URLs for use in the ELFIE linked data documents as much as possible. While the WFS and SOS APIs present some challenges in creating URLs for use in linked data, the APIs do offer sufficient HTTP GET functionality to embed useful content in linked data with a great degree of flexibility. The situation is different with the SensorThings API, which has HTTP GET functionality, but only supports 'internal ids' to request desired features. Workarounds have been tried but they involve URL encoding features URIs which is not seen as an ideal solution. Issues related to URL structure and a given API-call’s relation to a canonical non-information resource URI were encountered but deferred for future investigations.

OGC data models were used extensively in the ELFIE. The Observations and Measurements (O&M) conceptual model provided a high-level organizing framework for most ELFIE documents. The OGC-W3C Spatial Data On the Web Working Group implementation of O&M (Sensor, Observation, Sample, and Actuator (SOSA)) was used directly because of its applicability to the linked data technology pursued in the ELFIE. The GeoSPARQL ontology was also used directly for representing geometries and spatial relations between features.

Domain specific data models such as HY_Features, GWML2 and GeoSciML were also used for feature types and relations in the ELFIE linked data documents.

W3C best practices for data on the web, spatial data on the web, and linked data were used to guide decisions related to the ELFIE linked data documents. Several members of the ELFIE project team were involved in the development of these best practices and represented them throughout the project. Given this, the ELFIE was an opportunity to apply these best practices in a practical engineering process, using them together and attempting to apply them to OGC web service and information models.

This was largely successful and no major issues were encountered related to the best practices themselves. However, they were not achieved fully due to realities of the internet, organizational operational constraints, and limitations of current APIs and data models. In other words, a project seeking to apply current OGC standards on their infrastructure within the suggested W3C data on the web best practices would have to implement ad hoc system behavior (proxy negotiation by 'profiles', feature request by its URI, rewriting to JSON-LD, etc.). This situation is mainly due to the fact that several standardization efforts needed to support these practices are in progress (W3C DXWG, OGC WFS 3, etc.) and that enterprise systems are slow to evolve.

Experiences from the ELFIE project are being taken forward into influencing future W3C standards through the Data Exchange Working Group, where the concept of views is being addressed within the scope of the profiles concept. Description, discovery, metadata and negotiation according to formally identified profiles mirrors the ELFIE architectural choice to publish and reuse JSON-LD contexts.

Given the ELFIE goals related to adoptability of solutions and support of mass market search techniques, JSON-LD was used as the encoding for the ELFIE documents. While there were other potential options that could be used, the ease of use (parsing and serialization) of JSON-LD across practically all programming languages made it the clear choice for use in ELFIE. The decision to use JSON-LD was further supported by ongoing work within the OGC Architecture Domain Working Group to modernize OGC standards to supported JSON. As described below, some technical limitations inherent to RDF and thus JSON-LD were encountered while attempting to encode preview geometries, but all basic requirements of the ELFIE were satisfied by the JSON-LD encoding.

The incompatibility of JSON-LD and GeoJSON is a finding that will need further consideration by the OGC community.

An important goal of the ELFIE was "adoptability" by web developers and compatibility with technologies that are ubiquitous on the internet. Given these goals, the IE team started to think in terms of "views" (concept introduced in Box 1: Linked Data Graph Views) of the linked data graph describing a given environmental feature or observation. Two conceptual views, "preview" and "network", were the primary focus of the ELFIE. "Preview" is meant to be a very simple summary of a feature including type, name, and geometry. "Network" is meant to be a summary of relevant first-neighbor features in a topological network. These two form the core interoperable set of ELFIE views but lack domain specific relations such as observational relations and hydrologic topology.

Initial ELFIE discussions of the graph view concept used the Shapes Constraint Language SHACL [5] technology as the logical implementation. Further evaluation and consideration of the ELFIE goals regarding adoptability and ubiquity, the JSON-LD context was chosen as the most appropriate technical solution to express the graph views. The ELFIE contexts are meant to be precise descriptions of what the IE found to be the most appropriate linked data properties (attributes and relations) and types. They are not intended to be used as a schema to specify or validate the contents of a given document. However, they could provide a useful set of aliases for the subset of types and properties that could be expected to be parsed and interpreted by the client.

From a practical perspective, the contexts provide clear guidelines for what properties and types to use while not being overly prescriptive, limiting, or difficult to use in a typical web development workflow. Unlike schemas, such contexts support the “Open World Assumption” where missing elements simply indicate that this information is not currently available to the data provider, without the burden (and potential for misuse) of stating a placeholder value. Furthermore, to simplify the use of the contexts and reduce possible errors while parsing the views, Type Coercion [6] was not used while aliasing properties in the contexts files.

More information about the design and engineering of ELFIE contexts can be found on the ELFIE JOSN-LD web page.

The ELFIE "preview" graph view, is described by the elf.jsonld context. It uses schema.org, skos [7], and geosparql properties and types. Schema.org is used whenever possible to maintain compatibility with search engines, uses SKOS for a lose "related" relationship, and GeoSPARQL for precise specification of a geometric preview. The geometric preview of a feature was an area of contention for the IE.

GeoJSON-LD was seen as a logical solution, but as described in the outstanding issues for GeoJSON-LD, nested GeoJSON coordinate arrays are not supported by JSON-LD parsers. Additionally, the schema.org geometry schema was seen as under specified in that among other reasons, it does not provide a default coordinate reference system or a mechanism to declare one. For this reason, the GeoSPARQL well known text format was included providing a precise and JSON-LD compatible geometry format. However, provided the technical limitations listed below, if some logical assumptions are made for the use of schema.org geometry (schema:GeoShape), it can be used to satisfy the basic geometry preview use case with significantly lower technical overhead than support for the full well known text standard. Further work should look more closely at this issue in an attempt to reconcile and provide guidance.

The ELFIE "network" view, is described by the elf-network.jsonld context. It uses GeoSPARQL and OWL-time relations. As shown below, its emphasis is on simple topological relationships such as touches, intersects, before, etc. A "network" context would logically include additional domain specific topological relations derived from other contexts, but they are not included in the general "network" context.

Two extended general contexts and five domain specific contexts were created for testing in ELFIE. The extended general contexts have content from the timeseriesML and SOSA data models. The domain specific contexts have content from HY_Features, GWML2, soilIE, GeoSciML, and the floodcast use case. All of these contexts, except SOSA, were created as part of the ELFIE project without formal ontologies to back them. Work on these ontologies should follow ELFIE.

As can be seen in the main watershed entry point to the index here, the watershed data index use case uses two contexts. elf.jsonld and and hyf.jsonld shown below in Box 4: elf.jsonld and Box 5: hyf.jsonld respectively.

Note that the JSON-LD document that describes the watershed using these two contexts does not implement all the relations in either context. Rather, they are limited to relations from them and only implement the relations from them that make sense or have content for the feature that is being described. Box 6: Watershed Data Index Use Case Entry JSON-LD Document shows this entry point JSON-LD document. Note that it uses elf.jsonld relations like schema:name, and schema:description, but not gsp:hasGeometry or schema:image. This is because a feature of type HY_Catchment is not expected to have a particular geometry and there is no image available for the feature. The flexibility of the JSON-LD context approach is a strength in that it can be applied to many cases easily, but this may be seen as a weakness if specific requirements and validations need to be implemented.

While additional content is available on the ELFIE demo pages, the watershed data index use case, that was described in greater detail in previous sections, is described in greater detail here. As shown in the JSON-LD example here, this use case has a primary entry point JSON-LD document for a single HY_Catchment feature that uses the elf.jsonld and hyf.jsonld contexts. As described in this section, the HY_Catchment is thought of as an unrealized feature that has multiple features that “realize” one of the ways we conceptualize catchments. The JSON-LD documents for these are shown in the source code box below.

Items to note below:

While additional content is available on the ELFIE demo pages, experience gained from the Surface-ground water networks interaction use case, that was described in greater detail in previous sections, is provided here.

Developing a generic client (here BLiV.) in parallel to populating JSON-LD files helped in various ways:

The experiments exposed several issues with existing and new technologies that need to be addressed to realize the full potential of the core linked data encoding technologies tested. The issue of representation of a preview geometry for a feature should be addressed and seems to be a tractable problem that could lead to significant benefits. Another tractable and important issue is creation of ontologies for domain features. As of the completion of the ELFIE, this work was already being undertaken for existing domain models where a UML to OWL conversion is possible. This was the topic of an ad hoc meeting during the OGC TC meeting in March 2018 in Orléans, France. The main outcomes are summarized in Annex A: Strategies for Publishing Domain Ontologies as Linked Data from OGC domain standards. Other domain models, such as flood impact features, need to be created and or vetted by a community.

There were also several issues highlighted by the ELFIE that were deemed out of scope and purposefully left for future efforts. The foundational issue in this category is the "landing page" or "default representation" problem. That is, how should we handle the case where a dereferenceable URI is meant to identify a real-world entity with multiple digital representations. There are many related issues related to the network architecture and expected behavior when dereferencing URIs. These were generally out of scope for the ELFIE but need to be addressed to achieve interoperability and include: URI structure, use of non-information URIs with WFS and other services, and strategies for managing collections of potentially temporary linked data among many data providers. Use of the domain feature ontologies declared in the JSON-LD contexts was also out of scope. That is, JSON-LD files produced by ELFIE were not ingested by reasoning software. The extra vocabulary source was not yet taken into account by major search engines crawlers that focus mainly on the schema.org ontology.

OGC service interfaces were not the primary focus of ELFIE. However, along the way, both WFS and SOS services were discussed and tested. The major issues encountered were around querying these services by feature identifier. There is something of a chicken and egg situation in that, in most cases, http feature identifiers have not been published so are not available to use to query a web service, but the OGC services also do not lend themselves to publishing feature identifiers.

If queries to WFS or SOS services are used as un-structured links that return representations of features or results of observations, they can be used readily in linked data systems. But to be used with embedded feature identifiers or with more sophisticated content-negotiated retrievals, changes to the web service APIs will be needed.

The work ongoing with WFS appears promising with regard to the issues outlined above. The ability to query by a specific id that can be an http url is supported and is a clear solution that would solve the problem illustrated here. e.g. something like: http://server.com/wfs/getfeature?id=http://feature.x.y.x

A similar discussion has taken place in sensor-related services. SOS V2.0 specification (OGC 12-006), discusses identifier handling in Annex B and promotes reuse of a global identifier (here gml:identifier) as opposed to local identifier (gml:id) when querying services. The SensorThings API Part 1 implementations use their own internal identifier for REST API operations (ex : http://sensorthings.brgm-rec.fr/SensorThingsGroundWater/v1.0/Observations(1752377)). Both services' endpoints (SOS, SensorThingsAPI) were tested, passing them URIs for featuresOfInterest, observed properties, process, observation identifier, etc. to use them in a linked data context. Resulting queries work but further implementation is required to improve usability of the approach.

A JSON-LD response from these services is not available. While response rewriters (to convert existing encodings to a linked data form) have been tested on top of the SensorThings API (JSON to JSON-LD). It may be useful to include JSON-LD capabilities in the standards themselves.

Apart from the semantic association and serialization of features and observations, assignment of URIs to observational resources remains a system by system and use-case by use-case problem that is not necessarily trivial. Identification of unique observations and maintaining identifiers for them can become very complicated considering that time series subsetting is a complex subject in and of itself. The Research Data Alliance 'Data Citation WG Recommendations' [<https://doi.org/10.15497/rda00016,8>] might help guide the community to a useful solution on this front.

Domain feature models, such as GWML2 and SoilML, are defined for encoding and exchange of representations of environmental features. Other models, like HY_Features, are only available in conceptual (UML) form. For use in linked data, best practices and publication workflows for domain feature models as linked data ontologies need to be established. As described in Box 8: HY_Features Ontology Note and Strategies for Publishing Domain Ontologies as Linked Data from OGC domain standards this work has begun and needs to be brought to conclusion for use across the community.

W3C and OGC work on Observations and Measurements and Sensor Ontologies (See https://www.w3.org/TR/vocab-ssn/ [9]) is among the most advanced with regard to support for linked data approaches as pursued by ELFIE. While attempting to use the Semantic Sensor Network ontology, the concept of a monitoring network was found to be missing or not handled directly. Ad-hoc collections of monitoring features are a common need. Either as a collection that is meant to characterize a specific regional environmental feature, such as a watershed, or as a collection of monitoring features with common ownership, data offerings, or quality. In any case, further analysis of the nature of collections of monitoring features for use within and among environmental monitoring domains is warranted.

A major issue (which was known and was out of scope for ELFIE) was the lack of published feature identifiers and a linked-data baseline to build on. It is clear that, to grow the linked-data baseline, features and data linked to them need to be published using existing basic practices as a starting point. This starting point could be as trivial as a URL that returns a JSON-LD document with ID, Type, Name, and representative point location. The addition of a URI broker, content negotiation to provide HTML and RDF representations, and additional linked content would be possible given current techniques. However, it should not be seen as a necessary prerequisite to publishing linked data. Without a rudimentary starting point, the community has nothing to build on and could continue to debate the nuances of eventual solutions for ever.

Similar to publication of features and other linked data, URLs that define feature types and relations are not available in many cases. Without these referenceable, resolvable definitions, the linked data practices described here are very difficult to use across multiple systems that need to use common types and associations. Further, even when URIs have been established, the network behavior and content received when dereferencing them is not consistent across the community. For example, https://schema.org/GeoCoordinates returns an html page by default and implements both HTTP "accept" headers (e.g. "Accept: application/ld+json") and URL suffixes (e.g. https://schema.org/GeoCoordinates.jsonld) to request specific content types and http://www.w3.org/2004/02/skos/core#related defaults to an html page and implements accept headers but does not support the same content types as schema.org and does not support URL suffixes. Other linked data URIs, those from GeoSPARQL for example (http://www.opengeospatial.org/standards/geosparql/asWKT), do not resolve anything. If the community is going to start building cross-organization solutions based on linked data, these baseline feature types and associations need to be available and well described in a common way. It should be no surprise that schema.org’s linked data is used very broadly given that they provide a rich and approachable suite of content for their types and associations.

Non-information resource identifiers, URIs that are an identifier for a thing that may or may not have information representations, are useful to provide persistent and reusable identifiers for entities such as real-world features. These non-information resource identifiers provide a means for global identification across a distributed system such that multiple members of the system can contain information about and/or in reference to shared entities. There is a basic conundrum with non-information resource identifiers in that there can only be one default response (for a given encoding) when dereferencing a URI and only one member of a distributed system can be the source of that default response. Further, in order to achieve linked system interoperability, dereferencing behavior of non-information resource URIs needs to be in accord with the expectations of a member node of a system. The httpRange-14 and the Cool URIs Technical Report [10] provide a significant basis for solving this conundrum and W3C working groups continue to focus on it, but many details remain to be agreed upon for use cases such as are being pursued by the ELFIE.

While details of the default dereferencing behavior of non-information resource identifiers and subsequent redirects to information resources was discussed in the ELFIE, the IE has attempted to focus on encoding of linked data information resources rather than the network behavior for discovery and retrieval of non-information resources. Future work and best practice development will be needed to address these issues:

OGC Environmental Linked Features Interoperability Experiment (ELFIE) has explored publishing environmental observations as linked data, with data interpretation supported by having unambiguous references to key domain concepts in the data represented by additional links (URIs). Such concepts cover the nature of the properties of a data object, but also the key Use Case of linking an observation to the Feature of Interest.

Parallel to this activity, members from several OGC SWGs (GeoSciML, Groundwater, Hydrologic Features) are attempting to ‘port’ the initial work done using ISO 191xx series UML paradigm to OWL.

Taking the opportunity of having all the involved parties available during the 2018 Orléans TC an ad-hoc meeting was organized on March 23rd, 2018.

This document builds on those joint discussions in order to share best practices. It is shared under the GeoSciML SWG GitHub repository (https://github.com/opengeospatial/GeoSciML/tree/master/documents ).

Common semantics for the description of key domain concepts and the type of observations’ the Feature of Interest are identified by using published models – such as HY_Features, GWML, GeoSciML. These models (currently) are available in normative forms as UML notation, and in some cases as XML schema, neither of which is conducive to easily dereference a URI for a concept to get more detail about that specific concept, or even to confidently match the identity of any references to concepts.

The requirement therefore is to be able to publish such models, as stable URIs, dereferencing as fine-grained Linked Data. This means that a predictable and human readable URI naming scheme for elements in a model is required. (this may not be strictly necessary for a single model, but when a body of such models are managed by a single authority – such as OGC and its delegated Standards Working Groups – then commonality is necessary to avoid revisiting the naming strategy for each case, and to allow users to become familiar and comfortable with a consistent product.) Within the ELFIE context the need has been identified for at least two models, HY_Features and GWML2, and their multiple component Application Schemas. The GeoSciML community is also looking at the same issues. There is a need for both efficiency and consistency to harmonize and document a common approach.

ISO 19150-2 defines a set of rules for encoding UML as an OWL ontology referencing the suite of OWL artifacts created to model the ISO Harmonized Model. This form of OWL has an unknown utility – by tying data types and concepts into the extensive ISO model this adds a high burden on clients to reason over the entire model (quite a large set of content) in order to identify fairly simple, but highly important, semantic baseline information – such as that a property may be treated as an xsd:integer for purposes of a calculation). The feasibility of such reasoning is unknown, as there is no way yet to test the ISO models behave as expected under reasoning conditions. Furthermore, for the purposes of Linked Data, much of the modeling of behavior of low-level data types is not relevant, when the main requirement is to identify concepts, access explanations, or potentially access information about implementations of these concepts that may be available. Finally, from the perspective of infrastructure support, OGC provides a "definitions server" that is designed around the SKOS meta-model and will provide dereferencing services and Linked Data representations. The OGC Definitions Server is controlled by the OGC Naming Authority Subcommittee (OGC-NA).

BRGM and GSC have performed an initial analysis of the issues and questions that arise in the context of:

The output of that exercise has been shared under the BRGM repository (https://github.com/BRGM/GeoSciMLontology/blob/master/documents/ISO191xx_2_OWL_NoteBRGM.docx)

Identified issues and questions are relevant to the equivalent challenges for the ELFIE, and collaboration with the GeoSciML, GWML, HY_Features and the ELFIE activities has been initiated to develop a common solution. Those elements have then been further characterized from the perspective of definition publication process and governance.

Building on this during the 2018 Orléans TC ad-hoc meeting on March 23rd, identified issues were discussed.

Resources, time and testing methodology for "hand building" optimal equivalent ontologies are not available (notwithstanding comments that these may lead to iterative refinement and improvement of the model). The only automated pathway available to all participants currently is using ShapeChange (http://shapechange.net), which means developing a set of encoding rules from a wide range of choices and options from previous experiments in encoding different styles of UML model. The ISO 19150-2 artefacts will be seen as an intermediate artefact available by an annotation property reference in the metadata describing the provenance of the ontology. For such perspective the use of PROV-O should be used. "Manual interventions" to artefact to correct bugs or apply further rules will be encoded as RDF transformations or additional statements that can be applied in sequence.

The process can be summarized like this:

If necessary, rules to extract basic OWL and xsd: datatype equivalence, without embedded reference to ISO datatypes will be developed and applied as part of OGC-NA infrastructure. Rules to extract SKOS equivalent glossary/taxonomy from OWL class models will be developed and applied as part of OGC-NA infrastructure. URIs under www.opengis.net/def will be assigned, and content will be marked as draft, as an exercise in publication governance by OGC-NA, to make content and process available for wider discussion.