Clarification question

[cdharbin]

In the json example, https://github.com/opengeospatial/ogcapi-records/blob/master/core/examples/json/record-collection.json?short_path=5198f78, the property, "features" is used. I was following the requirements doc, https://github.com/opengeospatial/ogcapi-records/blob/master/core/standard/requirements/building-blocks/records-api/REQ_resource-name-mapping.adoc, which states to rename features to records. Does the example need updating or is it okay to leave "features" in the FeatureCollection?

[pvretano]

@cdharbin the example is correct. It does not need to be updated and, actually, changing "features" to "records" would make the response invalid since the response is a GeoJSON document.

Requirement "/req/records-api/resource-name-mapping" is about "reading" and "interpreting" the Features specification with respect to Records. I put it there so that I don't have to copy the entire text of OGC API Features into the Records specification and change every instance of the word "feature/s" to "record/s". It is meant to highlight the equivalence of a record and a feature with respect to the API. When you read the Features specification, everywhere where is says "feature/s" is the narrative text substitute "record/s".

For example, there is a requirement in OGC API Features that reads ...

For every feature in a feature collection (path /collections/{collectionId}), the server SHALL support the HTTP GET operation at the path /collections/{collectionId}/items/{featureId}.

when you are reading with regards to records you should (in your head) read it as

For every RECORD in a RECORD collection (path /collections/{collectionId}), the server SHALL support the HTTP GET operation at the path /collections/{collectionId}/items/{featureId}.

In other words, in a searchable catalog the "records" are represented as "features" in the OGC API Features API.

[pvretano]

@cdharbin I'll try to update the requirement to make the intent more clear. As mentioned it is only meant to help the reader of the Records specification interpret the Features specification and thus alleviate us of having to copy the entire text of the Features API into the Records standard.

[cdharbin]

Thanks for the clarification!