-
Notifications
You must be signed in to change notification settings - Fork 27
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
PAV Review edits. #342
PAV Review edits. #342
Conversation
Shall the checks pass before we merge? |
@@ -33,7 +33,7 @@ Using these building blocks a catalog can be deployed as: | |||
* a set of web-accessible records that can be crawled by a search engine crawler, using (for example) a web browser, or by using automated tools | |||
* a searchable catalog with records accessible through an API | |||
|
|||
A special use case of the _searchable catalog_ is the _**local resources catalog**_. The OGC API resource tree has a number of endpoints that provide lists of resources. Examples of such endpoints include the `/collections` and the `/processes` endpoints. One can readily imagine a large OGC API deployment with thousands of collections where the ability to search would enhance the client's interaction with the server. Using the building blocks defined in this specification, these endpoints can be extended to support catalog-like searching using filter expressions that may also include spatial and/or temporal predicates. OGC API endpoints extended in this way behave like a catalog of local resources. | |||
A special use case of the _searchable catalog_ is the _**local resources catalog**_. The OGC API resource tree has a number of endpoints that provide lists of resources. Examples of such endpoints include the `/collections` and the `/processes` endpoints. One can readily imagine a large OGC API deployment with thousands of collections where the ability to search would enhance the client's interaction with the server. Using the building blocks defined in this Specification, these endpoints can be extended to support catalog-like searching using filter expressions that may also include spatial and/or temporal predicates. OGC API endpoints extended in this way behave like a catalog of local resources. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Replace Specification to Standard?
|
||
It is anticipated that this _core_ set of properties will be extended to describe specific resource types (e.g. datasets, dataset series, Earth observation products, machine models, services, etc.) and also extended by information communities wishing to enrich the information content of the record to suit their needs. Extending the information content of a record to suit specific needs is allowed, expected and encouraged by this specification. | ||
It is anticipated that this _core_ set of properties will be extended to describe specific resource types (e.g. datasets, dataset series, Earth observation products, machine models, services, etc.) and also extended by information communities wishing to enrich the information content of the record to suit their needs. Extending the information content of a record to suit specific needs is allowed, expected and encouraged by this Specification. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Replace Specification to Standard?
@@ -82,7 +82,7 @@ include::recommendations/record-core/PER_additional-properties-record.adoc[] | |||
[[sc_record_extensions]] | |||
===== Record extensions | |||
|
|||
In tables <<core-properties-record-table>> and <<core-properties-resource-table>> this standard defines a set of core properties for describing discoverable resources. It is anticipated that this set of core properties will be extended to suite specific use cases or requirements. For example, a catalog record may be extended to include additional properties from the https://semiceu.github.io/GeoDCAT-AP/releases/[GeoDCAT] vocabulary. The fact that a catalog record has been extended in this way can be advertised using the `conformsTo` member. The `conformsTo` member is a list of identifiers that indicate each extension used in a record. This specification does not define the specific identifiers that are used to identify specific extensions; it simply provides a place where these identifiers can be listed. | |||
In <<core-properties-record-table>> and <<core-properties-resource-table>> this Standard defines a set of core properties for describing discoverable resources. It is anticipated that this set of core properties will be extended to suite specific use cases or requirements. For example, a catalog record may be extended to include additional properties from the https://semiceu.github.io/GeoDCAT-AP/releases/[GeoDCAT] vocabulary. The fact that a catalog record has been extended in this way can be advertised using the `conformsTo` member. The `conformsTo` member is a list of identifiers that indicate each extension used in a record. This Specification does not define the specific identifiers that are used to identify specific extensions; it simply provides a place where these identifiers can be listed. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Replace Specification to Standard?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@kalxas OGC Policy is that OGC documents that specify requirements/conformance and are approved by the OGC Membership are called Standards (with a capital "S". Used to be called Implementation Specifications but in the mid 2000s the OAB approved and Members agreed to a policy change to call these documents Standards.
@@ -292,7 +292,7 @@ In some instances additional context may be desirable or required in order to ac | |||
|
|||
include::recommendations/record-core/REC_record-associations_templated.adoc[] | |||
|
|||
NOTE: This specification does not define any specific link relations that should be used for links in the `links` or <<sc_templated_links_with_variables,`linkTemplates`>> sections. Such relationships are typically domain specific and so it is left to communities of interest to standardize the relations that links should use. | |||
NOTE: This Specification does not define any specific link relations that should be used for links in the `links` or <<sc_templated_links_with_variables,`linkTemplates`>> sections. Such relationships are typically domain specific and so it is left to communities of interest to standardize the relations that links should use. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Replace Specification to Standard?
@@ -320,15 +320,15 @@ Consider the case where a record describing a coverage resource is discovered by | |||
|
|||
Templated links may also be used to bind to resources that may require additional information in order to access the resources. For example, simply knowing the URL of a legacy OGC service such as https://portal.ogc.org/files/?artifact_id=14416[WMS] or https://docs.ogc.org/is/09-025r2/09-025r2.html[WFS] is not sufficient to access resources offered by those services. Additional information in the form of request parameters and values are required in order to have a complete link to a resource. A templated link with variables can provide this additional context. | |||
|
|||
This specification defines a new schema, https://github.com/opengeospatial/ogcapi-common/blob/master/core/openapi/schemas/linkTemplate.yaml[linkTemplate.yaml], based on the https://github.com/opengeospatial/ogcapi-common/blob/master/core/openapi/schemas/link.json[schema for a link] that includes substitution variables who's values are filled in at runtime prior to resolving the link. | |||
This Specification defines a new schema, https://github.com/opengeospatial/ogcapi-records/blob/master/core/openapi/schemas/linkTemplate.yaml[linkTemplate.yaml], based on the https://schemas.opengis.net/ogcapi/features/part1/1.0/openapi/schemas/link.yaml[schema for a link] that includes substitution variables who's values are filled in at runtime prior to resolving the link. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Replace Specification to Standard?
@@ -501,7 +501,7 @@ include::recommendations/record-collection/REC_record-langs.adoc[] | |||
|
|||
==== Encodings | |||
|
|||
This specification defines requirements for JSON and HTML encoding of a catalog. See <<clause-catalog-encoding,Encodings>>. | |||
This Specification defines requirements for JSON and HTML encoding of a catalog. See <<clause-catalog-encoding,Encodings>>. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Replace Specification to Standard?
22-JAN-2024: Need to add a requirement that describes what sorting by geometry means. There was an previous issue (i'll have to look it up) that mentioned sorting by geometry means that smaller (by area) geometries come before larger (by area) geometries. |
22-JAN-2024: Merging to verify that CI is working OK. The changes discussed in the last comment with be implemented in another PR. |
No description provided.