Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add resourceType or itemType property to Collection metadata #310

Open
ghobona opened this issue May 12, 2022 · 5 comments
Open

Add resourceType or itemType property to Collection metadata #310

ghobona opened this issue May 12, 2022 · 5 comments
Labels
2022-05 Sprint Part 2 Issues to be resolved prior to TC vote Progress: solution merged

Comments

@ghobona
Copy link
Contributor

ghobona commented May 12, 2022

There are several implementations that support multiple OGC API Standards.

Further, in the Compliance Program the Validator(TEAM Engine) needs to be able to support software that implements multiple OGC API Standards. In order to differentiate between collections of different resources, it is necessary to provide a hint or some metadata to identify the resource type offered by a collection.

During the May 2022, there was a suggestion for itemType/resourceType to be an array.

@ghobona ghobona added the Collections Applicable to Collections (consider to use Part 2 instead) label May 12, 2022
@cmheazel cmheazel added Part 2 Issues to be resolved prior to TC vote and removed Collections Applicable to Collections (consider to use Part 2 instead) labels Jun 5, 2022
@cmheazel
Copy link
Contributor

cmheazel commented Jun 5, 2022

To maintain compatibility with API-Features, we could add an itemTypes property. ItemType is string. ItemTypes an array of strings. Since neither property is required, this should not break interoperability.

@cmheazel
Copy link
Contributor

SWG meeting June 15, 2022 - Consensus is that the behavior of the ItemType element can vary between different API Standards that deal with items (/item). This makes if inappropriate to specify it in Common.

Suggested approach is to look at the rel element of the link from /collections and /collections/{collectionId} to the collection. This element should indicate the type of resource.

@cmheazel
Copy link
Contributor

Action for Naming Authority - establish a way of checking that two different API Standards are not using a rel in a manner which is inconsistent with other API Standards.

@cmheazel
Copy link
Contributor

Remove itemtype from document, contingent on not breaking EDR API.

@cmheazel
Copy link
Contributor

A review of the text shows that while itemType is included in the schema, it is not a required element. Furthermore there are no requirements governing the use of the itemType element. Recommendation (4) "If the members (items) that make up a collection can be individually accessed by a client, then the itemType key SHOULD be included in the Collection resource to indicate the type of the items (e.g. feature or record)" seems both correct and useful. It should be retained.
No change to the document seems to be required.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
2022-05 Sprint Part 2 Issues to be resolved prior to TC vote Progress: solution merged
Projects
Development

No branches or pull requests

2 participants