opengeospatial / CoverageJSON

Public repo for CoverageJSON project
Apache License 2.0
10 stars 8 forks source link

Several clarifications to the text requested - 6 #109

Closed chris-little closed 2 years ago

chris-little commented 2 years ago

@joanma747 identified several areas of confusion requiring improvements to the text. These have been split into 8 separate sub-issues:

  1. I do not like the sentence: "Future improvements have been identified, such as the use of multiple time dimensions, or to use JSON-LD V1.1 which may give better compatibility with the OGC Coverage Implementation Schema (CIS) Version 1.1".

I do not understand why JSON-LD 1.1 will give better compatibility with CIS. The compatibility with CIS is another issue altogether.

chris-little commented 2 years ago

@joanma747 My understanding is that JSON-LD1.0 only allows links from top level objects, for performance reasons. JSON-LD1.1 potentially allows links from deeply nested objects, as used in CIS. Whether this will be performant is not clear. Let us delete the section, and replace with a pointer to future projects on the repo.

jonblower commented 2 years ago

Yes, I'm in favour of deleting that section. Personally I don't understand the details of the difference between versions 1.0 and 1.1 of JSON-LD.

joanma747 commented 2 years ago

I believe the differences between the coverageJSON and the CIS are much more than just this detail about JSON-LD arrays of arrays. "While CIS tried to recycle O&M for the rangetype, the converageJSON took a more pragmatic approach. The domain part is similar in some aspects but again take a pragmatic approach Instead of defining the domain of the dataset defines the domain of what is needed to describe a trajectory etc." Even if my sentence is not comprehensive in describing all differences, the sentence that I'm proposing goes more in the right direction of what needs to be said. I believe we need to be brave here and recognise the overlay in a transparent way.

jonblower commented 2 years ago

Personally I think the only value of referencing CIS is to acknowledge that we know it exists. CIS has not been used as the starting point for CovJSON and there are many differences, although both standards are dealing with basically the same kind of data. The work to do a comprehensive comparison between CovJSON and CIS is planned for the future (after the publication of this Community Standard) and I would rather not make partial statements here - we have done so before and it has caused some (more) controversy.

So for me, I would be happy with a sentence somewhere that acknowledges that CovJSON and CIS are somewhat in the same space, but not attempting to make any concrete points of comparison, as any such comparison could only be partial and may cause more comment. The scope of this document is to describe CovJSON as a Community Standard, and I don't think it's necessary to anchor it to other standards from which it is not derived.

Does this make sense?

joanma747 commented 2 years ago

@jonblower, I think you are right. Let's do what you suggest in the second paragraph.

chris-little commented 2 years ago

@jonblower @joanma747 Agreed and we will quietly add CIS to the bibliography

chris-little commented 2 years ago

@jonblower @joanma747 The mention of CIS has been removed in a merged PR. CIS will be added to the Bibliography