IDs as domain axis values / Custom coverage/domain types

[letmaik]

While thinking about #3 it became clearer how to model a domain where one axis may have IDs as axis values, like station IDs. For example, there may be several measuring devices in a lake where the individual positions don't matter that much as they may be averaged later on. The important part is the lake as a polygon and the device IDs.

As an example, three sensors measuring something at the same time:

{
  "type": "NewDomainType",
  "axes": {
    "composite": {
      "valueType": "Polygon",
      "components": ["x","y"],
      "values": [
        [ [ [100.0, 0.0], [101.0, 0.0], [101.0, 1.0], [100.0, 1.0], [100.0, 0.0] ]  ]
      ]
    }
    "t": { "values": ["2008-01-01T04:00:00Z"] },
    "device": { "values": ["A74834", "A4394", "A548395"] }
  },
  "referencing": [{
    "identifiers": ["device"],
    "rs": { // rs=referencing system
      "type": "URIMapping"
      "namespace": "http://www.ceh.ac.uk/def/sensors/",
      "concept": "http://www.ceh.ac.uk/def/Sensor"
    }
  }, ...]
}

[jonblower]

Yes, although there may be simpler examples. Essentially this is about domain axes that are categorical. I wonder if we will always be able to map to URIs or whether we may need a “plain string” fallback.

Examples might be:

1. Ensemble members (CF has the concept of an “ensemble dimension”)
2. Geographic regions (e.g. population figures for a number of countries)

[letmaik]

Yes, URIs were just a random linked-web example. It's up to the one defining the reference system. This could be an interesting extension point that we should leave open deliberately for others to exploit. Over time, people may converge on certain custom reference systems (like above for URIs).

[jonblower]

Yes, allowing for different reference systems (i.e. more metadata about axis values) would be a good extension point I think.

[letmaik]

Ok, what I have written now is that for the domain types defined in the spec, the identifiers x,y,z must be referenced by a spatial reference system, and t by a temporal one. The extension therefore does only work if we allow custom domain/coverage types. And currently this is forbidden. Maybe we should revisit that.

[jonblower]

Is there any reason to forbid custom domain/coverage types? And what is the real meaning of a coverage type - does it just give the client a shortcut so that it knows what to expect for common cases?

Perhaps we could allow "untyped" coverages, or allow users to defined their own types. Even without an explicit coverage type the coverage is pretty self-describing.

Alternatively we could define that the coverage type just constrains the spatiotemporal axes, and there can be zero or more "categorical" axes that add other dimensions.

[letmaik]

In my opinion coverage/domain types are just what you would call a "profile", with specific restrictions on the content while still conforming to the base standard. Since we want CoverageJSON to be an open format (I guess), this has to be more flexible in some way. The challenge is that you should still be able to say whether a CoverageJSON document is a domain, coverage, or range document, even if you use custom profiles. One possible way would be to just use "type": "Coverage" together with "profile": "GridCoverage", where the profile can also be a URL for non-standard ones. Popular profiles could then be incorporated into future CoverageJSON versions as short names without causing problems.

I can imagine that people might want to place restrictions via a coverage profile not just on the domain but on the parameters as well. This would mean that the tight coupling we currently have between coverage "profile" and domain "profile" may not be ideal. For example, there might be a new coverage profile "http://../WaterMLTimeSeries" which reuses the "PointSeries" domain profile but places restrictions on the parameters and possibly the domain as well. Now there's suddenly the issue that when you don't embed the domain (but reference it via URL) you don't know what domain profile you will get, and while this may be irrelevant for clients that understand the WaterML coverage profile, it would be a problem for generic clients that only understand the predefined domain profiles and that want to know in advance which renderer class (or similar) they should use.

And of course, from an RDF point of view, profile is really just a subclass I think... It's a shame that JSON-LD doesn't allow to alias multiple fields to @type:

{
  "@context": {
    "type": "@type",
    "profile": "@type"
  },
  "type": "cov:Coverage",
  "profile": "cov:GridCoverage"
}

throws Invalid JSON-LD syntax; colliding keywords detected.

Whereas the following works:

{
  "@context": {
    "type": {"@id": "rdf:type", "@type": "@id" },
    "profile": {"@id": "rdf:type", "@type": "@id" }
  },
  "type": "cov:Coverage",
  "profile": "cov:GridCoverage"
}

I should open a feature request for JSON-LD 1.1... (EDIT: here)

Does that in general make sense?

To solve the domain-not-embedded issue, you could require that the coverage must have a "domainProfile" field if the domain is not embedded and actually has a profile. Having said that, profiles seem to be optional but recommended even for the pre-defined ones like Grid etc. I think this is useful if people start experimenting with new coverage types (well, profiles) where they don't have a profile URL yet and can rely on generic clients to inspect the domain axes etc. as it is.

[letmaik]

Implemented my suggestion.