Second Environmental Linked Features Experiment:

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

Contacts

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.

The first Environmental Linked Features Interoperability Experiment (ELFIE) sought to answer the question, "what linked data content should be included in a landing page describing an environmental feature and its relationship to other features and data?". Limiting scope in this way allowed the team to avoid the complex issues related to network behavior and the semantics of requesting default or alternate representations of a feature, representations of it, or other features and data in some way related to it. These issues were discussed in the first ELFIE — but often only briefly or in the context of defining what was expressly out of scope for the project [1]. The Second Environmental Linked Features Interoperability Experiment (SELFIE) took these issues on in earnest.

Objectives of SELFIE, from the project charter were:

These can be summarized with the question, "what is the expected network behavior and resource model when resolving a Web identifier for a non-information resource?". While fairly simple on its face, this question proved to be challenging on a number of levels.

Objectives added during the IE:

Due to these challenges, many issues discussed in SELFIE were tabled for later once more example implementations have had a chance to experiment and understand what works and why we might choose some approaches over others.

The SELFIE relied on participants’ domain-specific use cases to provide context and drive decision making in the context of the IE. The use cases included hydrogeology, soils, hydrology, and land-survey information. Common to these use cases was the need to work with identifiers for environmental features for which multiple representations are available. Each of the use cases was implemented to one extent or another. Full details of the use cases are included in Domain Use Cases, domain use cases. Taken together and harmonized, these domain-specific use cases provided sufficient scope to determine a useful set of general use cases that are summarized in the following sections.

General, as opposed to domain-specific, SELFIE use cases are described in the section that follows. To provide greater insight into their purpose, the organizational architecture and functionalities they entail are first described in some detail. The use cases aim to maintain technical rigor while being practical and approachable. This can be seen as a balance or tension, but rather, ease of implementation was used as a filter on technically rigorous solutions — leaving complexity out where the team was not ready to recommend an easy-to-implement approach. While technical, and in some cases very specific, these use cases do not imply complete technical approaches.

The SELFIE model for web resources is based on the notion of information resources and non-information resources as defined by the W3C document ‘Dereferencing HTTP URIs’. This summarizes the so-called ‘Range-14’ decision that, while unofficial, is useful especially when read in conjunction with ‘Cool URIs for the Semantic Web’.

Information resources are the currency of the web - the pages and data served in a digital form to be consumed by web browsers and applications. Non-information resources are the things these information resources may describe (for example people, mountains, or Aristotelian philosophical constructs). For SELFIE, the critical distinction between them is that an information resource has a location (expressed as a URL) while a non-information resource has identity, expressed as an HTTP URI.

HTTP URIs have two roles:

Several representative information resources describing given non-information resources may exist. For example, information resources available according to various media-types, ontologies and/or content models (e.g. data quality rules, controlled vocabularies or units of measure) may be available. SELFIE sought to refine the classification of these representative information resources to help data-providers clarify what type of resource they publish providing guidance for implementation of resolvers, catalogs, and data services.

The Environmental Linked Features in SELFIE are non-information resources. These can be thought of in the following groups (in the following, all 'features' are 'non-information resources'):

Each of these groups occupy different meta-levels but can be interlinked. For example, allowing an agent traversing a knowledge graph to move from the description of a domain feature to how that description was obtained (sampling features). The links between the domain and sampling features are described with ontologies such as SOSA. Given that SELFIE has adopted JSON-LD as its RDF encoding syntax, links to semantic resources are provided via JSON-LD contexts that map JSON keys and types to RDF ontology property and class HTTP URIs.

For SELFIE, nodes in a knowledge graph are non-information resources, and the nodes of most interest are those that identify domain features. Sampling and semantic resources provide metadata that describe those features and organize available knowledge about them. Therefore, the SELFIE knowledge graph describes relationships between non-information resources in the 'real world'. The links between information resources that describe them is an important but separate concern. In SELFIE, how to transition from non-information resources in the knowledge graph to those in the web of information resources was an important consideration where further work is needed.

At the outset of SELFIE, the team was thinking in terms of a "three-tiered resource model" where "resource" was a thing identified by a URI. The resource model involved "non-information resources", "meta-information resources", and "data-information resources". Conceptually, the "non-information" "meta" and "data" scheme is useful, but the word "resource" is wrong when applied to the terminology of particular technologies (such as HTTP Resources). As such, the team found a need to change its language to more accurately reflect what was found to be useful ways to describe what is actually a set of use-cases that can be described in terms of non-information, metadata, and data.

Everything in this scheme is identified by a HTTP URI. In general, we have three categories that can be described as follows:

Tier 1. is clear — there should be URIs that only ever return a 300 series redirect and are identifiers for real-world features. Tier 2. is hard to define precisely. It can only be defined strictly by the application retrieving it rather than by specific characteristics of its content. Tier 3. is clear in most cases but has potential overlap with tier 2 in that some applications may consider metadata about a feature to actually be data representing the feature. Since self-describing data always contains metadata, we would expect most if not all of tier 2 to be contained in tier 3.

If we think about it this way, then tier 2 is a convenience layer to achieve a certain functional goal. In SELFIE, tier 2 is a convenience layer for search-engine crawlers and humans looking for an idea of what a real-world feature is, what it’s related to, and if there’s interesting data available representing it.

This should make it clear that resource is the wrong word to describe the distinction being drawn here. It is ok for tier 1, but it breaks down for tier 2 and 3. A single URL may have one or more representations designed to be metadata and one or more representations intended to be data — each intended for a different use pertaining to the same real-world feature. This is not saying that tier 2 and tier 3 are always to be represented variously based on the same URL — they very well may be represented as different resources. This technical diversity is what SELFIE sought to enable.

Consider a typical use case considered by the SELFIE:

As the project dissected this use case the HTTP-Range 14 (303 redirects), OGC API - Features (html landing pages for features), and schema.org JSON-LD in a <script> tag of a landing page were all embraced as useful technical solutions that serve it. None of the above requires alternative resource representations (media types). With an HTML landing page, a human user or crawler designed around natural language and schema.org are satisfied.

However, the IE recognized the potential to bring structure to data (including semantically enabled data) underlying the landing page content. Going further, the SELFIE was premised on the idea that html landing pages are layered on top of a potentially wide range of data systems that need such a discovery layer. Given this, while not addressed specifically in SELFIE, alternative media types and content negotiation are expected in a system that the SELFIE model is applied to. However, the complexity and lack of broad implementation made making progress on this front difficult.

Participants in the IE agreed that they would avoid specifying how to use content negotiation between the "meta" and "data" tiers. Standards for content negotiation by profile are emerging but we have not been able to evaluate them rigorously. Instead, SELFIE was limited to describing how to advertise that multiple content-types are available for a given URL in structured JSON-LD data. The scope and summary architecture are described in Figure 2.

The idea of "in-band" and "out-of-band" has been brought up as a useful distinction between resource representations that can provide information that is useful to a given application (in-band) and resource representations that are opaque to an application (out-of-band). In reality, there are many bands that correspond to various applications. Here, we define the SELFIE-band which is intended to foster interoperability toward the goals of the IE.

There are three defining characteristics of the SELFIE "band":

A SELFIE resource is recognizable because:

To illustrate the distinction, consider the following JSON-LD example which has one schema:sameAs and one schema:subjectOf property for an identified feature:

Alternatively, when we resolve `https://feature.id` we might get a more limited document that does not include pre-fetched content about `https://someresource`:

Which would mean we would need to resolve and interrogate `https://someresource` to retrieve information needed to decide whether it is of interest, which is possible with the "in-band" `https://someresource`, and might give us the JSON-LD below, but impossible with the "out-of-band" `https://blobby` which might only return xml or linked data using an unknown ontology.

Note that we have avoided discussing @type and conformsTo. Use of these properties, while valuable, introduces complexities that were determined to go beyond the scope SELFIE was able to accomplish.

The Range-14 decision, to identify real-world features with URIs that HTTP-303 redirect to resources providing information about the real-world feature, was accepted by SELFIE. Figure 3 illustrates the complete solution.

However, to simplify implementation, some landing resource providers skip the 303 redirect entirely, using a URL for a landing resource as an indirect identifier of a real world feature. Figure 4 Illustrates this less complicated, but limited approach.

There are two related problems with the indirect identification approach: one technical and one social. Both issues stem from the need to maintain stable identifiers for real world features and very real needs to change URLs to retrieve digital resources.

The technical issue is related to how URLs are used to drive server behavior. Changes to server software implementation often necessitate changes to URL paths or parameters. The requirement to maintain URL stability is in conflict with this and causes needless complexity for server-implementers.

Socially, real-world feature identification is a process undertaken by a group of people that is likely not the same as those who implement the server software used to retrieve information about those features. Identification of features may work best with a different URI structure than retrieval of digital information about those features; forcing the two groups of people to reconcile these patterns is an unneeded, complicated, and likely fraught interaction that can be eliminated by separating real world feature identification from information index resource identification.

Adding content negotiation to the discussion of resource resolution, a 303 redirect works fine as long as the client passes the same accept header to the redirect target URL. However, there is a common content negotiation override practice involving URL parameters such as ?f=mime-type or ?format=mime-type that may be desirable to have passed along as part of a 303 redirect. Some SELFIE participants support such mime-type overrides, but additional experimentation will be required to determine if there is a solution that should be recommended for this in general. Note that this says nothing about content-negotiation "by profile", an emerging technique that was decided to be beyond the scope SELFIE would be able to address.

Extending the resource resolution use case to include retrieving representations of a feature introduces additional functions that were the subject of some SELFIE experiments. Two such resolution schemes were tested. One required a client to inspect information index hypermedia and make an additional request for an available representation. The other used media-type content negotiation to return a representation available via that media-type directly from a URL-14 indirect identifier without the client needing to review information index hypermedia. These two schemes are illustrated in Figure 5. These alternatives are equally valid and further work is needed to determine if one is preferable to the other.

The SELFIE evolved several JSON-LD contexts that were initially created for the first ELFIE. IE participants also worked to establish a number of contexts containing UML classes and associations (used as feature types and property associations in RDF/JSON-LD) from domain feature models such as GeoSciML, GWML2 and HY_Features. The content of the SELFIE-contexts is described in the meta-content section below. The purpose of the domain-specific contexts is to provide semantics that describe the basic associations between non-information resources (e.g. upstream/downstream associations) and domain-specific type (e.g. a feature is a water well). In order to ensure the contexts are usable by a broad audience and to foster adoption, the contexts and ontologies that they reference were kept purposefully focused and minimal; including feature types and associations from the normative UML models only.

With regard to style of contexts themselves, IE participants agreed that we should alias only properties and not classes/feature types. Only namespace URI prefixes (e.g. "schema": "http://schema.org/") and property keys (e.g. "sameAs": "schema:sameAs") are aliased. Classes are not, instead they are returned as compact URIs (CURIs) in the JSON documents: "@type": "gw:GW_HydrogeoUnit".

The argument for namespace is very common practice. They simplify documents, making URIs shorter and clearer in documents. For example, gw:GW_Well is easier to work with than `https://www.opengis.net/def/gwml2#GW_Well`.

The first ELFIE made the decision not to use CURIs for property key names as a simplification to make JSON-LD documents more approachable and limit colons in JSON keywords. See this description of ELFIE context design for more… context. The downside of this decision is we lose the ability to distinguish between the use of the same label in different JSON-LD contexts. CURIs disambiguate identical property keys (schema:comment; rdfs:comment) but this can also be accomplished with longer key aliases ("schemaComment": "schema:comment"; "rdfsComment": "rdfs:comment"). This workaround will be required very rarely and isn’t necessary for classes (@type values) as they are property values and not used as JSON keys so problematic characters (like colons) are not a problem.

The SELFIE content model, with its loosely-defined non-information, meta, and data tiers, is focused on the nature of a resource and not the structure of the identifier used to dereference the resource. However, there is a need to establish expected behavior when dereferencing URIs for information at each of these three tiers. As discussed in ELFIE Resources, the SELFIE project found that the distinction between meta and data tiers is loose and should be the subject of future work. The IE considered two behaviors between non-information and information resources that provide landing content: 1) A 303 redirect from a URI-14 to a URL-14, and 2) Indirect identification of the non-information resource where the URI-14 and URL-14 are identical.
The distinction between non-information resources and resources that provide landing-content located with different URIs introduces the potential for confusion. This confusion was anticipated to produce two issues:

Indirect identification of URI-14s using URL-14s has been tested by SELFIE participants successfully. It was found that this practice limits flexibility of systems to accommodate multiple agencies and the tight coupling of URI-14 and URL-14 introduces technical challenges for landing content resolution. However, the practice is less complicated from a user perspective and, as long as the URL-14s are stable, is compatible with future decoupling of URI-14 and URL-14 when the separation is needed. These two cases, 303 and 200 response codes to a non-information resource identifier, illustrate the flexibility of the SELFIE content model as well as the nature of landing-content as a convenient resource that encodes content relating URI-14s to each other and data resources.

An important recommendation IE participants agreed to is that when a 303-redirect from a URI-14 to URL-14 exists, the URL-14 should not be referenced in structured data. This follows from the fact that the URL-14 is a locator for landing content with one and only one subject — the URI-14. That is, a JSON-LD representation of a URL-14 resource would have one and only one root @id that is the URI-14 that the JSON-LD documents. As such, the URL-14 should never appear in a linked data graph as it will never return linked data about itself.

The following sections describe the purpose and some logic for SELFIE landing content.
As an overview, Table 1 contains the most precise use-case descriptions the SELFIE team was able to craft that pertain to URL-14 landing-content "groups". These groups can be seen as building blocks that are used to construct landing-content structured data.

The content groups described in Table 1 have been encoded in JSON-LD contexts that can be used as a guide for implementers and by-reference in structured data. These contexts are grouped functionally around indexing, documenting data-resources, describing topological feature associations, and providing simple spatial representations of features.

Resources containing data content are extremely diverse. Examples include but are by no means limited to geospatial feature data whether a feature of interest or a reference feature, monitoring result data, monitoring location data, and related remote sensing data. As described above, such data can be said to be "in-band" or "out-of-band". The former would be a data resource that generally conforms to the system of linked data, GeoJSON, and HTML prescribed by the OGC-W3C Spatial Data on the Web best practices and emerging practices such as is described here. The latter is any other data resource that, while of interest and associated with a non-information resource, does not conform to linked data / semantic web practices.

The distinction between what is landing content and what is data content depends on the context in which the resource is being accessed. That is, in one context, landing content will be seen as data about a non-information resource; in another context, that same landing content will be used merely as hypermedia and metadata to help choose data content of interest. Because of this, semantic annotation of data will look very similar to landing content except that the URL for a resource that is intended to provide landing content (a URL-14) will not appear in the subject or object of linked data. The URL of a resource that provides data content (a URL-200) must appear in the subject or object of linked data.

The SELFIE focused most of its efforts on details of landing content and how to link to data content. The actual structure of linked data or way to architect resources that provide data content is assumed to be either status quo or left for future work. The potential for resources to have multiple media-type formats and potentially multiple profiles that map onto certain use cases is of great interest and documentation of alternate formats and media types is supported by the landing-content concepts described here.

OGC API - Features was evaluated for providing both URL-14 landing-content and URL-200 data-content and found to be largely compatible with both. For provision of landing content, a feature would be provided as JSON-LD and HTML with JSON-LD structured data in a <script> element containing the URI-14 as its primary subject. In this case, hypermedia containing links to items in a feature-collection would contain links to URI-14s rather than display any URL-14s. Since OGC API-Features supports feature-level access by item id (/collections/{collectionid}/items/{itemid}) or a feature attribute (/collections/{collectionid}/items?uri=https://id.com/id) it can be used as a flexible building block in linked data architectures.

During the IE, SELFIE participants funded, drove, tested, enhanced (depending on the cases) the support for JSON-LD in two major implementations of OGC API - Features namely:

The logic for selection of relations in SELFIE followed from the more content-focused ELFIE. That logic is described in detail in the ELFIE engineering report and on the ELFIE contexts web page. To summarize, broad adoption and commonality on the web was the primary driver of selection of relations. Spatial topology, temporal, and monitoring concepts were taken from established OGC and W3C ontologies, and domain concepts were sought from OGC domain feature models (GeoSciML, GWML2, HY_Features). The following lists relations by source with comments for selected relations as necessary.

In order to use classes and properties (or relations) defined in domain models, the SELFIE project needed minimal ontologies to reference. "Minimal ontologies" means having basic classes and relations (associations) from a model without the constraints and axioms that could otherwise be generated in the process of transforming UML models to OWL ontologies. The focus was on having resolvable names for the classes and properties that are used in simple linked data payloads. The packaging pattern used in organizing UML domain models was also not used in this exercise, i.e. one UML model = one minimal ontology.

The creation of such minimal ontologies for a specific domain model was realized by using ShapeChange processes for the every package of that model, with rules that kept the minimum creations of classes from FeatureTypes and properties with their range definitions. Since there is no rule (known to the IE participants) that specifically constrains the creation of properties from associations only, a second step was to filter (using SPARQL queries) properties by their ranges to keep only ObjectProperties that originated from associations in the UML Model. The last step was to merge content from different packages into one simple ontology having one base URI. This exercise was performed on GeoSciML, HY_Features and GWML2 domain models.

While this simplification has its merits with regards to linked data applications, a discussion with the OGC Naming Authority (OGC-NA) about how to push this ontologies behind OGC-NA servers concluded that they cannot be published in this state. These minimal ontologies do not respect the OGC-NA content negotiation and naming policy patterns, which allows having different possible views of domain models. The inclusion of all properties (and not only associations) respecting the packaging and naming pattern as defined following the UML models should be guaranteed before issuing a request for integration in the OGC-NA server. A work is being carried out to capitalize on what have done for the minimal ontologies to have more detailed and well-organized ontologies that respect the OGC-NA specifications. This would provide a better way to have resolvable JSON-LD contexts directly from the OGC-NA server.

SELFIE participants experienced difficulty communicating about the nature of the issues at hand. Examples included, but were not limited to:

As a result, the IE’s primary outcomes are a deeper understanding of the problem at hand rather than fully-fledged and tested solutions.

First and foremost, the IE demonstrated that use of the HTTP-Range14 303 redirection between so-called URI-14 URIs and URL-14 resources that provide "landing content" has great utility and is not incompatible with modern web infrastructure. There is a strong logical and technical case for using URI-14 → URL-14 redirection. A critical additional consideration here is that URL-14 HTTP URIs should almost never be used as identifiers in and of themselves. That is, landing content should only ever be retrieved by first dereferencing the URI-14 identifier.

The SELFIE refined the linked data predicates defined for use in landing content by the first ELFIE especially as it relates to links between and among URI-14 identifiers and URL-200 data resources. While more work is needed here, the core-relation to link between identification and representation is https://schema.org/subjectOf. Other aspects of the ELFIE content model (such as domain-feature model associations between URI-14 identifiers) were vetted, and proved to work in the context of URI-14 → URL-14 redirection. Further work is needed to enrich the semantics between identification and representation — especially in the context of multiple representations of the same feature where each representation is of a different type.

While the SELFIE set out to test content negotiation by profile and potentially other ways to negotiate between various representations of a resource, the complexities and communication difficulties regarding the core-problem proved enough for one IE.