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

PAV Review edits. #342

Merged
merged 1 commit into from
Jan 22, 2024
Merged

PAV Review edits. #342

merged 1 commit into from
Jan 22, 2024

Conversation

pvretano
Copy link
Contributor

No description provided.

@kalxas
Copy link
Member

kalxas commented Jan 22, 2024

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.
Copy link
Member

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.
Copy link
Member

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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Replace Specification to Standard?

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.
Copy link
Member

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.
Copy link
Member

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>>.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Replace Specification to Standard?

@pvretano
Copy link
Contributor Author

pvretano commented Jan 22, 2024

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.
@pvretano will also review "this Standard" vs "this Specification" and make everything consistent to "this Specification".
@pvretano will also check the usage of "OGC API" as per the issue @ghobona added. There are "OGC API" standards but there are no "OGC APIs".

@pvretano
Copy link
Contributor Author

22-JAN-2024: Merging to verify that CI is working OK. The changes discussed in the last comment with be implemented in another PR.

@pvretano pvretano merged commit 755628c into opengeospatial:master Jan 22, 2024
1 check failed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants