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.