How do we apply CURIEs to compound CRSs?

[ghobona]

Clause 5.3 of the OGC Name Type Specification - definitions - part 1 – basic name policy describes the use of Compact URIs as shorthand for URIs.

There's a need to establish how the approach should be applied to compound Coordinate Reference Systems. That is, if it can be applied to compound CRSs.

An example of a compound CRS containing a 3-dimensional CRS with dimensions latitude, longitude, and time is shown below:

http://www.opengis.net/def/crs-compound?
 1=http://www.opengis.net/def/crs/EPSG/0/4326
&2=http://www.opengis.net/def/crs/OGC/1.0/Gregorian-Date

The example is from Page 3 of OGC 11-053r1.

Please share your thoughts on this topic.

[pebau]

Here is a suggestion: [ EPSG:4326,DateTime ]

IMHO simple + straightforward.

[rob-metalinkage]

Allowing an ordered list may make sense, we have 2d + vertical datum combinations as well, and dynamic datums.

Issue will be interpreting the order, or forcing placeholders.

Coordinate is a special case of dimension, so an alternative would be to have a dimensions element with range [dimensionDescriptor], allow CRS, TRS identifers, and leave crs element range as a simple URI

[pebau]

@rob-metalinkage

Allowing an ordered list may make sense, we have 2d + vertical datum combinations as well, and dynamic datums.

yes, and we never can define any possible CRS in the universe.

Issue will be interpreting the order, or forcing placeholders.

hm, placeholders? Order is no issue - after all, this is just another notation for the Compound CRS in practice since many years.

Coordinate is a special case of dimension, so an alternative would be to have a dimensions element with range [dimensionDescriptor], allow CRS, TRS identifers, and leave crs element range as a simple URI

Let us not define extra gimmicks now which go beyond Compound CRS a la 19111. This is just about a syntax convention for the existing mechanism.

PS: This I do not understand "Coordinate is a special case of dimension". Coordinates describe dimensions, see 19111, 19123, etc.

[cportele]

Based on clause 5.3, there needs to be a namespace and base URI registered in the CURIE register. The CURIE value on the right side of the colon is appended to the base URI.

So, if the namespace would be ogc-compound-crs and the base URI would be http://www.opengis.net/def/crs-compound? then the safe CURIE would be [ogc-compound-crs:1%3Dhttp%3A%2F%2Fwww.opengis.net%2Fdef%2Fcrs%2FEPSG%2F0%2F4326%262%3Dhttp%3A%2F%2Fwww.opengis.net%2Fdef%2Fcrs%2FOGC%2F1.0%2FGregorian-Date]. This is not very helpful.

I think what would really be required, is a OGC-NA URI policy for ad-hoc compound CRSs that is CURIE-friendly. Currently there is no such OGC-NA rule, only the "crs-compound" convention from CIS. However, this is probably not simple since each component CRS is represented by a URI or CURIE and at least the colons need to be percent encoded.

An alternative and in my view cleaner approach would be to not specify a new CURIE namespace for Compound CRSs, but to allow an array/list of CRS CURIEs where ever a (Compound) CRS can be specified. So, e.g., in an API, a crs query parameter could take the value crs=[EPSG:4326],[OGC:GregorianDateTime] or in a JSON encoding the value could be "coordRefSys": [ "[EPSG:4326]", "[OGC:GregorianDateTime]" ] (this is how the Compound CRS is encoded in JSON-FG).

[pebau]

@cportele I see your points with the CURIEs, but the shorthand for single CRSs is already in place, with the expansion mechanics (versions are omitted for simplicity which is ok, one can always resort to the fully fledged URL, and also assuming a default namespace, etc.). Re compound-crs syntax, therefore, we just need to find a syntax similar in spirit. The "[...]" indicate the compound CRS behind in a syntactically convenient fashion, so far we seem to agree.

Options discussed:

• [ "[EPSG:4326]", "[OGC:GregorianDateTime]" ] - unnecessary complexity, this is its own microsyntax, not JSON (and there is life outside the JSON sphere ;-) ); quotes need to be escaped, a known source of errors according to our helpdesk
• [EPSG:4326],[OGC:GregorianDateTime] - if necessary for a compromise I agree, although not my topmost favourite
• [EPSG:4326,OGC:GregorianDateTime] - still my favourite because most user- and machine-friendly

[cportele]

@pebau - I think you misread my last paragraph, which was not about a new, general microformat for identifying ad-hoc compound CRSs, but the proposal to represent an ad-hoc compound as a list of CRSs (which it really is) and allow CURIEs for each CRS. That is, there is nothing that the OGC NA needs to specify in addition to what we already have.

How this would be represented depends on the context. I just gave two examples: a HTTP query parameter and a JSON document. For other cases the representation will depend on the context.

[pebau]

@cportele I was just summarizing what we had so far; we seem to be very close anyway, with the (array) list. Emphasizing for a moment the (little) differences for the sake of clarification and polishing:

• IMHO there needs to be a statement by OGC-NA as the concept (and syntax) of an arraylist is not yet defined/allowed in a CRS context
• not sure that the arraylist syntax for CRSs should be defined differently in different contexts, that contributes to confusion and implementation errors IMHO
• you seem to prefer list of CURIEs "C1,C2,...." for Ci="[xxx:yyy]" where I suggested a "compound CURIE" like "[x1:y1,x2:y2,...]"

@ghobona Bottom line, we have 2 suggestions on the table, exemplified:

• [EPSG:.4326,OGC:date]
• [EPSG:.4326],[OGC:date]

...any preference from OGC-NA perspective?

[rob-metalinkage]

The list implementation needs no NA decision, however the swg ownership of conceptual model and each implementation needs to established.

Keep on working on it as a reusable pattern now.

We have an ogcincubator space for precisely this scenario

[ghobona]

I agree that specifying how the CURIEs are implemented is outside of the scope of the OGC-NA. However, the OGC-NA can make a recommendation to be considered and possibly endorsed by the TC.

We should keep in mind that we introduced CURIEs into OGC-NA policy so that OGC could use a web-wide approach for shortening URIs instead of one that was specific to our community. For the purpose of this discussion, we can refer to this as the 'principle'.

Considering the two options:

1. [EPSG:4326,OGC:date]
2. [EPSG:4326],[OGC:date]

Option 1 does not appear to be a valid CURIE and therefore it breaks the principle. Option 2 presents two valid CURIEs concatenated by a comma. So this approach appears to preserve the principle.

We do not have a session at the Member Meeting in Delft, so I will plan a mid-quarter telecon to enable us to discuss further and reach a consensus.

In the meantime, please feel free to share any thoughts here.

[pebau]

@ghobona thanks for detailing the situation. As it seems we have only one viable option, that is a CURIE list. We might propose it in the envisaged meeting, asking for any objection and hoping for none :)