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

Principle #3a - Use Well-Known Resource Classes #18

Closed
cmheazel opened this issue Jul 11, 2018 · 8 comments
Closed

Principle #3a - Use Well-Known Resource Classes #18

cmheazel opened this issue Jul 11, 2018 · 8 comments

Comments

@cmheazel
Copy link
Collaborator

An additional principle from the Testbed 12 REST User Guide

@cmheazel
Copy link
Collaborator Author

The title of this principle appears to be miss leading. This principle is NOT about MIME types or content negotiation.

The first, are arguably hardest, step in designing a RESTful API is to define the resources. Without a clear and coherent resource (aka data) architecture, the API will rapidly become crap. TB-12 produced an initial list of OGC Resource types. This list is incomplete, and most likely wrong. But it is a start.

@joanma747 joanma747 changed the title Principle #16 - Use Well-Known Resource Classes Principle #3b - Use Well-Known Resource Classes Aug 3, 2018
@joanma747 joanma747 changed the title Principle #3b - Use Well-Known Resource Classes Principle #3a - Use Well-Known Resource Classes Aug 3, 2018
@joanma747
Copy link
Collaborator

In the ROA approach used in the guidelines, this principle seems a good starting point. IMHO it need to be in the start so I have moved it to #3a

@joanma747
Copy link
Collaborator

There is not only about resources identification. There is also a need to identify explicit and implicit relations. See issue #23 about principle #19

@cportele
Copy link
Member

I would not include the list from Testbed 12. It is not a definitive list of resources and should therefore not be part of the principle. I suggest to build the list of resources incrementally. One approach could be to register resource types that are covered by a (draft) OGC standard with the OGC NA and link to that OGC register.

@lvdbrink
Copy link

I'm wondering what we consider "well-known". Terms like 'feature' and 'coverage' are not well-known outside the geospatial community. We felt we had to explain and avoid the terms in the Spatial data on the web best practices doc.

@rob-metalinkage
Copy link

Agree with @cportele - the list should be an authoritative managed list - under the auspices of the OGC-NA (but delegated to an appropriate working group as a the register owner.

This leads to the principle that all vocabularies/terms needed for interoperability should have explicit governance and should be accessible on the Web at stable URIs as multiple machine and human readable views (as per OGC definitions server)

@rob-metalinkage
Copy link

Note sure this issue is correctly referenced in two different places.
See the W3C work here on profiles and mime types : https://www.w3.org/TR/2018/WD-dx-prof-conneg-20181218/

@securedimensions
Copy link
Collaborator

now addressed in master

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants