TC E-vote Comment 6b: Clarify relationships with other OGC Standards

[chris-little]

Comment 6 is split into separate issues: 6a,b,c.

- The relation of the proposed standard vis a vis the pre-existing and emerging OGC APIs is unclear : OGC API-Features, ST API and others.

[chris-little]

Issues #211, and #217 arising from the TC E-vote Comments are basically the same.

[chris-little]

Annex, without content, to be added in PR #227, and page added to GitHub Wiki.

[chris-little]

EDR API SWG 46: Annex added. Close when PR merged

[chris-little]

also covered by Issue #211

[dr-shorthair]

This issue is an example of many that have been created to reflect comments made during the OGC review period. Good - that allows for some traceability.

However, I see it (and may others) was then closed without any comment from the people who submitted the comment in the first place. Good practice is generally that issues should be reviewed and closed only by the original submitter, when they are satisfied with the resolution. There is a complication because of the double handling here, but I hope there is an inventory of changes made in response to the OGC comments, so the original commenters can be assured that the matter they raised has been properly addressed.

(I'd prefer it, if the commenter's name is known, for their opinion on the proposed resolution to be canvassed, and recorded in the issue thread directly.)

[chris-little]

@dr-shorthair The several comments, from all of the No/Yes/Abstain votes, that were received in the OGC TC vote were each copied into a separate Issue in this repo. As the vote is a closed process on the OGC Portal, I suppressed the Member organisations and their representatives who posted the original comments, in case they were uncomfortable with having the full details made public.

As several of the comments were multi-threaded, we split them into seperate issues, so that discussion could be scoped to each topic. The individual issues were all cross-referenced to the original comments, and the multi-threaded issues closed.

It was clear that several of the individual issues were the same, so they were renamed to reflect this. Three of the original multi-threaded comments referred to the same document on the OGC Portal, and the new names were based on that document.

It was then decided, as the issues were the same, that they be cross-referenced to the first instance of that issue and closed, so that discussion could be focussed on the one topic in one place. Comments from the other instances that might be helpful, or clearer or identified a nuance, were copied into the remaining open Issue.

If any aspects of an issue were missed, they can still be copied across.

We think this is reasonable, and maintains an audit trail.

An aspect that may be relevant is that because of renaming of URLs for tests/requirements/conformance classes, the ASCIIDoc script failed and the draft spec was not regularly rebuilt, though the updated files were up-to-date.

Does that answer your concerns satisfactorily?

[KathiSchleidt]

A bit unclear is the status of the proposed relationship annex, I see 2 competing solutions:

• The current version in the asciidoc referenced above
• The work linked to many of the comments on adding an empty annex, also visible in the github project

Any pointers on which will be the final solution?

[pebau]

IMHO the work undertaken would greatly benefit from an open, detailed documentation of

• where are overlaps with other OGC standards? Such as: OGC Coverage Implementation Schema, Web Coverage Service
• where are concepts different, and what is the rationale for deviating from best practice of adopted standards? Example: OGC coverage JSON encoding vs CoverageJSON
• where are concepts realized in a way compatible with existing standards, so that harmonization has been accomplished?

[KathiSchleidt]

Btw - in order to try and connect with related SWGs, we've got a slot during the O&M SWG at the upcoming TC on: “Observation & Sampling coherence in OGC“: Liaising with related SWGs

O&M SWG is Thursday, March 25th starting at 9am EDT, if the previous points stay on track the cross SWG part should start at 9:45 - look forward to continuing this discussion there, seeing if we can't find commonalities to build on :)

[dr-shorthair]

@pebau I agree that on closer inspection the EDR-API is primarily a coverage service. @chris-little confirmed as much in https://github.com/opengeospatial/ogcapi-environmental-data-retrieval/issues/59#issuecomment-625453113 and nearby. So perhaps I was somewhat misguided in focussing my comments on the overlap with SOS and SensorThings, while the real issue is relationships with WCS.

(The title 'Environmental Data Retrieval' is also part of the problem here. If this is primarily about slices through dense data-cubes, then it could be applied to all sorts of applications, certainly not restricted to those normally thought of as 'environmental'. Metadata around observations tends to be quite important for environmental data particularly when it is sparse, which is why the observational-metadata focus of SOS and O&M tend to jump to front of mind when I see the adjective "environmental". ALso see #206 )

[dr-shorthair]

@chris-little asked 'Does that answer your concerns satisfactorily?'

It explains the strategy of the editors creating the issues. However, it does not explain the rule for closing them.

It is more common, in a multi-participant project anyway, to only close an issue when a pull-request that resolves the issue is merged. In fact you can annotate the PR so that happens automatically - just enter the comment 'Fixes #{issue-number}' when you create the PR. IMAO it is best to use this strategy, and never manually close an issue unless the consensus is to reject the issue so no fix is needed. Also, adjust the repository settings so that a PR can only be merged when it has received a specified number of assenting reviews.

[chris-little]

@dr-shorthair @KathiSchleidt @pebau Unfortunately we still haven't fixed all the ASCIIDoc batch file problems, so the draft is still out-dated, but the Annex explaining some of the relationships with some of the other OGC standards was populated 8 days ago. The SWG and OGC Staff think that this is ample and addresses the issue. It is not intended to be a Guide to OGC standards.

[KathiSchleidt]

@chris-little All I can get for the Annex at present is "Not Found" :?

[chris-little]

@KathiSchleidt I see it at ogcapi-environmental-data-retrieval/candidate-standard/annex_relationship.adoc

[KathiSchleidt]

@chris-little thanks for confirming ogcapi-environmental-data-retrieval/candidate-standard/annex_relationship.adoc

One minor insert in the last sentence, could you add the snippet in bold below, as to my experience users don't need conceptual models, they need relevant parts of the data. The conceptual model supports this need by providing a standardized structure.

Similarly users and developers that do not need the full details of the additional metainformation provided by observational, feature or coverage conceptual models could use the EDR API to hide the extra complexity.

[chris-little]

@dr-shorthair You wrote:

However, it does not explain the rule for closing them.

The rules for closure of issues were written at the start of the SWG. Perhaps with hindsight, we should have revised them for GitHub users who are not SWG members, though nearly all comments over the last two years have been from OGC members who are able to become members of the SWG, and are in any case able to access the records of the meetings, whether here in the GitHub or the OGC Portal.

[dr-shorthair]

OK - Rule 8 is the problem for me. Without an explicit link to a meeting minute, then there is not enough transparency on how issues are closed. I'd like to see a link to a minuted discussion and decision, not just a vague reference to an undated meeting that I wasn't present for. While I don't want to pretend that I've been missing participation in meetings (as I live in UTC+10:00 I'm asleep during most of them), GitHub issue threads do enable asynchronous interactions and reviews, which is what I've been trying to offer. Sometimes the way they've been resolved seemed rather cursory, from the information provided in the issue thread.

[chris-little]

@dr-shorthair OK - we try to put explicit mention of the meeting (all numbered, but # causes GitHb side effects) in an issue closure or PR merge. I agree that a direct link to the meeting agenda and minutes would be good, but hard to do in real time as the meeting progresses, usually against a ticking clock. We'll try day after tomorrow if we succeed in closing anything.

[chris-little]

@KathiSchleidt EDR API SWG 47 agreed to improve wording like you suggested. Will close when PR #263 merged

[chris-little]

PR #263 merged last week