In-band out-of-band definition.

[dblodgett-usgs]

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 and resource representations that are opaque to an application.

Proposed definitions for the ER:

• In-band: Any resource representation that is compatible with a given system. An in-band link is one advertised as being available via compatible standard/profile and media-type/format.
• Out-of-band: Any resource representation that is incompatible with a given system. Either available via incompatible profile and format or via unknown profile and format.

In discussion about SELFIE and the GSIP system, we made some interesting realizations that I want to share here for consideration.

1. A resource with unknown or known to be unstructured representations is always out-of-band until inspected and determined to be otherwise.
2. A resource known to conform to a given profile or standard may be in-band if the client application is compatible.

These points bring up the idea that, for a linked data provider, in-band might be defined differently than for a linked data consumer.

(Removed example in subsequent edit)

[bsimons14]

To my simplistic thinking the url links are like deferred resolution. If you resolved the link, i.e. put the result 'in-line', and the whole document remains valid then it is 'in-band'. If not, such as having a GML response to the url in a JSON-LD document then it is 'out-of-band'. Is this correct?

[dblodgett-usgs]

That is my understanding, yes. But if the GML response is expected (can be used by) the system, then it would be in-band in a sense. In the comments over here. there's some speculation about two kinds of "in-band" -- one that's strictly semantic and one that's compatible with the current architecture.

I actually think I may be off base with this issue / this distinction should be treated more casually. Hopefully @abhritchie can respond and clarify where this is off base with his thinking. I think this distinction is maybe not worth dwelling on.

[dblodgett-usgs]

I think a less specific definition might be in order...

• In-band: A resource that is compatible with a given system or architecture. Typically a semantic (RDF) representation but may be other common formats (e.g. html, geojson for SELFIE).
• Out-of-band: A resource that is incompatible with a given system. (e.g. GML, etc.)

I'm also going to retract my "how to encode" part of this issue. It's not helpful.

[abhritchie]

There are many bands - that's a part of the rich tapestry that is the internet - so we must focus. Our band is the ELFIE system. Our community is data providers - telling them how to provide data in a way that will work in a larger graph of data. If we are consistent, and describe our resources and links properly, users will know they are traversing the ELFIE system. If we describe all links properly users could discover links to resources in a band they also understand, but that is a bonus. We can't anticipate all possible uses of the internet.

[abhritchie]

What is the ELFIE band? There are three defining characteristics: The resources: ELFIE is a graph of non-information resources. The access protocol: The HTTP protocol (with no extensions [perhaps controversial?]) with responses managed according to the range-14 decision. The encoding: HTML + JSON-LD and JSON-LD in which ELFIE non-information resources are identified, and linked to, using the JSON-LD @id key.

[abhritchie]

There's arguably a content characteristic, but I'm little uncomfortable here because if we follow it too enthusiastically we could get too distracted. Anyway, here goes: The ELFIE profile: we use an agreed set of schema.org properties and OGC domain models.

[abhritchie]

This all means an ELFIE resource is recognisable because:

1. it has an @id;
2. it has a format property that includes application/ld+json;
3. it has a @context that links to 'ELFIE' contexts (the URLs are in an OGC/ELFIE domain)
4. it has a @type value that comes from a class declared via the @context in 3.

A link to an ELFIE resource would include 1, 2 and 4 (it is, basically, a pre-fetched stub of an JSON-LD representation of the related resource).

[abhritchie]

We could make band-membership explicit by defining an ELFIE profile. That could be included as a conformsTo value on a resource and a resource link.

[abhritchie]

Out-of-band (ELFIE band) is therefore anything linked to using a URL (an information resource) or any linked non-information resource that doesn't provide an HTML + JSON-LD and JSON-LD encoding.

[abhritchie]

The @type, format and conformsTo values could still be added to an out-of-band link and should be because it is a helpful thing to do.

[abhritchie]

@bsimons14’s comment above describes a good test of in-band.

[dblodgett-usgs]

OK, sorry guys, I'm slow. but think I'm getting there.

In-band: A URI that, if dereferenced with appropriate content negotiation, will return additional linked-data associations about the URI and contains a SELFIE-compatible @type and linked data associations. Out-of-band: A URI that is not capable of providing additional linked data associations about itself or is otherwise incompatible with the linked domain feature SELFIE architecture.

Considering this minimal example using one sameAs and one subjectOf: (note sameAs may not be the right choice here, Sorry!)

{
  "@id": "https://feature.id",
  "http://www.w3.org/2002/07/owl#sameAs":
  {
      "@id": "https://someresource",
      "http://www.w3.org/2000/01/rdf-schema#label": "A resource that can extend the linked data graph."
  },
  "http://schema.org/subjectOf":
  {
    "http://schema.org/url": "https://blobby",
    "http://www.w3.org/2000/01/rdf-schema#label": "blobby thing with the feature as its subject?"
  }
}

As @bsimons14 was alluding to above, but I missed the significance of, the rdfs:label of https://someresource is a prefetched piece of information that we could get from further linked data requests otherwise. In contrast, the rdfs:label of the schema:subjectOf blank node with schema:url https://blobby is a piece of information included in this json-ld document that could never be retrieved from https://blobby.

To drive this home, we might get this from a call to https://feature.id:

{
  "@id": "https://feature.id",
  "http://www.w3.org/2002/07/owl#sameAs":
  {
    "@id": "https://someresource"
  },
  "http://schema.org/subjectOf": {
    "http://schema.org/url": "https://blobby",
    "http://www.w3.org/2000/01/rdf-schema#label": "blobby thing with the feature as its subject?"
  }
}

Since https://someresource is encoded as it is, we could then go dereference https://someresource to find out more about it. Maybe getting a document like:

{
  "@id": "https://someresource",
  "http://www.w3.org/2000/01/rdf-schema#label": "A resource that can extend the linked data graph.",
  "http://www.w3.org/2000/01/rdf-schema#seeAlso": "https://someOtherThing"
}

But we couldn't do that with https://blobby.

So regardless of what else https://someresource does, since it is capable of providing additional linked data about https://someresource it is an "in-band" link.

The idea that there are many bands as @abhritchie alludes to is also important here. In ELFIE, in-band resources are constrained a little more than "can return linked data content".

1. We expect use of a recognized @context -- meaning known associations are present.
2. We expect a single @id rather than an @graph -- meaning the document is about a single resource.
3. It has an @type that is referenced in one of our contexts -- it is part of the domain feature model cannon we are working in.

-- ok, I realize I'm restating what you guys already know, but hopefully getting this basic is useful to others too. This list becomes the definition of in-band IMHO.

[abhritchie]

And JSON-LD as a supported media-type for the (S)ELFIE band. Remember our goal: be nice to the script kiddies and support their overwhelmingly preferred encoding.

[dblodgett-usgs]

Todo in the ER: add this discussion here.

[sgrellet]

@id, ld+JSON : no issue @type that only come from from (S)ELFIE contexts (=hosted at OGC/ELFIE domain) feels like creating a 'closed-linked data world'. we would prefer the following for @type: "value that comes from a well defined context bound to community endorsed ontologies" because

• we need context declaring URI that DO resolve
• and we need to consider work done by other communities (=not on SELFIE webconf). For example, we would consider in-band an equivalent exercise done exposing EU INSPIRE datasets according to ontologies describing INSPIRE themes (unfortunately, not pushed to the OGC).

[sgrellet]

quick note with regard the 'blobby' (bloody :) ) example. We would keep the rdfs:label next to the "@id": "https://someresource" for the following reasons

• feel we agreed on ELFIE on the use of the @id, @type, name pattern
• that's really useful to set up GUIs as colleagues don't always (? never ?) know the URI by heart but the label yes
• thus avoid unnecessay bounce

[dblodgett-usgs]

@sgrellet -- I'm in full agreement.

re:

"value that comes from a well defined context bound to community endorsed ontologies"

Note @abhritchie's "There are many bands". There is one fairly restrictive band that we could think of that is limited to OGC/W3C/ISO space. But there is an adjacent and ever so slightly more general band that is inclusive of all community endorsed ontologies that identify feature types and associations in an architecturally consistent way with SELFIE.

So one more evolution of these definitions: In-band: A URI that, if dereferenced with appropriate content negotiation [1], will return additional linked-data associations about the URI [2] and contains a SELFIE-compatible @type and linked data associations [3]. Out-of-band: A URI that is not capable of providing additional linked data associations about itself or is otherwise incompatible with the linked domain feature SELFIE architecture.

[1] - For SELFIE, support for JSON-LD is expected. [2] - An in-band JSON-LD resource documents a single @id identified subject. [3] - Associations and types used are from either SELFIE contexts or architecturally compatible community endorsed contexts.

re:

keep the rdfs:label next to the "@id": "https://someresource"

My example there was really just to make a point about why we would use schema:url rather than the @id pattern. I think we are in full agreement about pre-fetching rdfs:label, @type, and other(?) desirable content for client app development.

[abhritchie]

We need to pull apart the discussion of @context and @type as introduced by @sgrellet.

[abhritchie]

Good point about @type - it is too restrictive. We want a small band that can be extended by multiple communities. General rule if the discussion starts using the word restrictive we've done something wrong. Proposal: we say nothing about @type. PS I assume when @sgrellet says 'we would consider in-band an equivalent exercise done exposing EU INSPIRE' the 'we' is BRGM and other European actors.

[abhritchie]

For @context ('we need context declaring URI that DO resolve').

If (S)ELFIE matures past an IE and becomes a spec/recommendation there must be published contexts.

If you're not using at least one (S)ELFIE context you're not doing (S)ELFIE. (Which is fine, it didn't offer what you needed.)

In the spirit of not being too restrictive there shouldn't be many of these contexts. I'm assuming:

1. Core schema.org properties;
2. Feature linking by spatial topology (GeoSparQL);
3. Feature linking by temporal topology (OWL time).

Note that these don't affect the @type value. The can be used for most features.

Stretching things a bit:

1. Observation and sampling data by SOSA/O&M3.

[dblodgett-usgs]

Do we need to evolve the above definitions based on this? I'm thinking "compatible" is a soft enough word to be inclusive of non-SELFIE domain feature models?

Still a todo to get this written up in the ER, but can we call this issue settled?

[abhritchie]

I'm a little uncomfortable with my suggestion around contexts - it's mixing content into system again which has lead to confusion.

Proposal: the definition of the SELFIE band is based on https://github.com/opengeospatial/SELFIE/issues/88#issuecomment-578467488 and points 1. and 2. in https://github.com/opengeospatial/SELFIE/issues/88#issuecomment-578467955. This gets the architectural concerns nailed down. It comes with an 'architectural profile' that covers @id, url, format, conformsTo and name and therefore basic resource description and linking.

If that's cool close this issue and we can ...

... start on a (S)ELFIE+ profile (in a separate issue) to present ideal cross community content using suggestions in https://github.com/opengeospatial/SELFIE/issues/88#issuecomment-578934175.

[dblodgett-usgs]

Sounds good. I'll leave it to someone else to make the follow on issue.

[dblodgett-usgs]

I copied content out of this issue and rewrote it here: https://docs.google.com/document/d/1b-TdqWl3jf2jJD7dYvLkxTa6JEGxtUJAue7jSiaEE2s/edit#bookmark=id.vncsogk4k6go