Closed dblodgett-usgs closed 4 years ago
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?
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.
I think a less specific definition might be in order...
I'm also going to retract my "how to encode" part of this issue. It's not helpful.
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.
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.
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.
This all means an ELFIE resource is recognisable because:
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).
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.
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.
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.
@bsimons14’s comment above describes a good test of in-band.
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".
@context
-- meaning known associations are present.@id
rather than an @graph
-- meaning the document is about a single resource.@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.
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.
Todo in the ER: add this discussion here.
@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
quick note with regard the 'blobby' (bloody :) ) example. We would keep the rdfs:label next to the "@id": "https://someresource" for the following reasons
@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.
We need to pull apart the discussion of @context
and @type
as introduced by @sgrellet.
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.
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:
Note that these don't affect the @type
value. The can be used for most features.
Stretching things a bit:
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?
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.
Sounds good. I'll leave it to someone else to make the follow on issue.
I copied content out of this issue and rewrote it here: https://docs.google.com/document/d/1b-TdqWl3jf2jJD7dYvLkxTa6JEGxtUJAue7jSiaEE2s/edit#bookmark=id.vncsogk4k6go
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 discussion about SELFIE and the GSIP system, we made some interesting realizations that I want to share here for consideration.
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)