Do we need "composite" or can we use "tuple" and "polygon" directly?

[jonblower]

Looking at the profiles document, I wondered if the structure:

"axes": {
      "composite": {
        "dataType": "Tuple",
        "components": ["x","y","z"],
        "values": [ ... ]
      }
    }

might be a bit redundant. Couldn't we simplify a bit and use:

"axes": {
      "tuple": {
        "components": ["x","y","z"],
        "values": [ ... ]
      }
    }

And the same for "polygon"? I doubt there will be many more types of "composite" axis, and we can define special rules when the name of the axis is "tuple" or "polygon", just as we have a special rule when the axis name is "composite". It's unlikely that anyone would choose the names "tuple" or "polygon" for a "normal" axis.

[letmaik]

Strongly against that. Axis names should not carry any meaning in my opinion. Also, it would make inventing new dataTypes harder since then you have to think about a new axis name that doesn't collide with whatever people may use already. So we would have to anticipate a list of reserved axis names or something like that. I think it would make life way too hard with not much gain, possible just more confusion and surprises.

Am 14.04.2016 um 10:58 schrieb Jon Blower:

Looking at the profiles document, I wondered if the structure:

|"axes": { "composite": { "dataType": "Tuple", "components": ["x","y","z"], "values": [ ... ] } } |

might be a bit redundant. Couldn't we simplify a bit and use:

|"axes": { "tuple": { "components": ["x","y","z"], "values": [ ... ] } } |

And the same for "polygon"? I doubt there will be many more types of "composite" axis, and we can define special rules when the name of the axis is "tuple" or "polygon", just as we have a special rule when the axis name is "composite". It's unlikely that anyone would choose the names "tuple" or "polygon" for a "normal" axis.

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/Reading-eScience-Centre/coveragejson/issues/59

[jonblower]

Sorry, I think I misunderstood. I thought "composite" already had a special meaning. Now I've read the spec more carefully I see that there is always a "dataType", but it defaults to "primitive" if not specified. And that axis names are always arbitrary (although it seems that in the profiles the axis names can be given special meaning?). So I'm happy to forget this.

(As a side note I wonder if it's worth having a document that describes what a profile is allowed to do - for example it can give special meanings to axis names.)

[letmaik]

Yes. In the profiles the axis names carry additional semantics, but not anything that is relevant for generic clients, just for simpler clients to know what to look for (for example, x is always longitude or easting, if the CRS is defined in such terms).

I think a profile should be allowed to do anything, it should not be restricted, except for the scope to which it applies (Domain, Coverage, Collection). In the main spec we define a "standalone" profile URI which says that all domain and ranges have to be embedded, and I use that quite nicely in content negotiation to express the wish that I'd like to get that coverage/collection document with everything being embedded:

Accept: application/prs.coverage+json; profile="http://coveragejson.org/profiles/standalone"

I think this is a good case for using profiles. I even aliased the standalone variant with a custom extension in our experimental java server, so that you can do /foam.covjson to get the non-embedded variant (or whatever the server thinks makes sense for the majority of clients) and /foam.covjsons for the standalone one.

On 14/04/2016 11:36, Jon Blower wrote:

Sorry, I think I misunderstood. I thought "composite" already had a special meaning. Now I've read the spec more carefully I see that there is always a "dataType", but it defaults to "primitive" if not specified. And that axis names are always arbitrary (although it seems that in the profiles the axis names can be given special meaning?). So I'm happy to forget this.

(As a side note I wonder if it's worth having a document that describes what a profile is allowed to do - for example it can give special meanings to axis names.)

— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/Reading-eScience-Centre/coveragejson/issues/59#issuecomment-209872531

[jonblower]

Yes, the "standalone" case is a nice use for profiles and I can see how this works with conneg. The profile is defining a high-level behaviour.

How might this work with the profiles that define specific domain types? Could a client say to the server "I only understand domain types that are defined in a certain profile?" So you could imagine a profile of CovJSON that defines typical coverages that are found in, say, hydrology, and another profile that defines coverages used in, say, climate science?

Does the Accept header allow you to specify multiple profiles?

[letmaik]

I think you may be on to something. Yes, the profile field as defined in the RFC accepts multiple URIs seperated by whitespace, and those should then all be fulfilled.

To be honest, I haven't thought of creating a profile URI for the set of domain/coverage "types" that we currently define as "common profiles". But maybe this makes more sense, a bit like "I follow the CF-1.6 conventions", or in our case "I follow the common domain types specification 1.0".. or something like that. But then I'm not sure how to handle the domain subType field. If that is just a string like Grid, then that wouldn't have any meaning if you don't check for the profiles, meaning that every CovJSON document following those common domain types would have to include something like "profiles": ["http://coveragejson.org/profiles/common-domain-types/1.0"]. So that would mean the field "subType" is not even defined in the core CovJSON specification, but rather introduced in that common domain types profile, together with the names it defines. And this in turn means that someone else could invent his own domain type collection and use that instead: "profiles": ["http://nasa.gov/covjson/better-domain-types/1.0"]. I think that actually makes sense!

If you think about it, data publishers could even offer their data in multiple conventions if multiple turn out to be popular, and the client would know how to fetch it:

Accept: application/prs.coverage+json; profile="http://coveragejson.org/profiles/common-domain-types/1.0"

or

Accept: application/prs.coverage+json; profile="http://nasa.gov/covjson/better-domain-types/1.0"

Is that the solution?

[letmaik]

The original issue is resolved, continuing here: #58