opengeospatial/architecture-dwg

Welcome to OGC's Github page.

architecture-dwg's Issues

Upload initial version of the JSON Best Practice document

Upload the initial version of the JSON Best Practice document.

How to address Geospatial content. Requirements for Geopatial content

It is not clear how to do Geospatial JSON that performs ok in normal "cartographic" cirscumstances. What we should do with geospatial information encoded in JSON?
GeoJSON has limitations (RFC 7946)

• Geometry cannot be extended
• CRS are not introduced
• Features has only one geometry representation
• Ignoring coverages
• Ignoring sensors

Solutions?, Necessary requirements?

Update the location of ISO/TC211 xsd files in the OGC Schemas repository

We have been notified that the location of ISO/TC211 xsd files has changed to https://schemas.isotc211.org

Below is a list of updates we would like to make to xsd files at schemas.opengis.net in order to reference the new location of the ISO/TC211 xsd files.

Please let us know by 21 January 2022, by replying on this thread, if you have any concerns about the updates.

SCHEMAS_OPENGIS_NET/guf/1.0/pqm.xsd

Line 18: Replace "http://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_19136_Schemas/gml.xsd" with "https://schemas.isotc211.org/schemas/19136/-/gml/1.0/gml.xsd"

SCHEMAS_OPENGIS_NET/iso/19139/20070417/ReadMe.txt

Line 22: Replace "http://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_19139_Schemas/" with "https://schemas.isotc211.org/schemas/19139/"

SCHEMAS_OPENGIS_NET/iso/19139/20070417/gco/ReadMe.txt

Line 13: Replace "http://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_19139_Schemas/" with "https://schemas.isotc211.org/schemas/19139/"

SCHEMAS_OPENGIS_NET/iso/19139/20070417/gmd/ReadMe.txt

Line 13: Replace "http://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_19139_Schemas/" with "https://schemas.isotc211.org/schemas/19139/"

SCHEMAS_OPENGIS_NET/iso/19139/20070417/gmx/ReadMe.txt

Line 13: Replace "http://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_19139_Schemas/" with "https://schemas.isotc211.org/schemas/19139/"

SCHEMAS_OPENGIS_NET/iso/19139/20070417/gsr/ReadMe.txt

Line 13: Replace "http://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_19139_Schemas/" with "https://schemas.isotc211.org/schemas/19139/"

SCHEMAS_OPENGIS_NET/iso/19139/20070417/gss/ReadMe.txt

Line 13: Replace "http://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_19139_Schemas/" with "https://schemas.isotc211.org/schemas/19139/"

SCHEMAS_OPENGIS_NET/iso/19139/20070417/gts/ReadMe.txt

Line 13: Replace "http://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_19139_Schemas/" with "https://schemas.isotc211.org/schemas/19139/"

SCHEMAS_OPENGIS_NET/iso/19139/20070417/srv/1.0/serviceMetadata.xsd

Line 23: Replace "http://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_19139_Schemas/gmd/gmd.xsd" with "https://schemas.isotc211.org/schemas/19139/-/gmd/1.0/gmd.xsd"

Line 24: Replace "http://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_19139_Schemas/gco/gco.xsd" with "https://schemas.isotc211.org/schemas/19139/-/gco/1.0/gco.xsd"

SCHEMAS_OPENGIS_NET/iso/19139/20070417/srv/1.0/serviceModel.xsd

Line 13: Replace "http://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_19139_Schemas/gmd/gmd.xsd" with "https://schemas.isotc211.org/schemas/19139/-/gmd/1.0/gmd.xsd"

Line 14: Replace "http://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_19139_Schemas/gco/gco.xsd" with "https://schemas.isotc211.org/schemas/19139/-/gco/1.0/gco.xsd"

SCHEMAS_OPENGIS_NET/security/1.0/codelist/authentication.xml

Line 7: Replace "http://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_19139_Schemas/gmx/gmx.xsd" with "https://schemas.isotc211.org/schemas/19139/-/gmx/1.0/gmx.xsd"

Line 8: Replace "http://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_19139_Schemas/gco/gco.xsd" with "https://schemas.isotc211.org/schemas/19139/-/gco/1.0/gco.xsd"

Line 9: Replace "http://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_19136_Schemas/gml.xsd" with "https://schemas.isotc211.org/schemas/19136/-/gml/1.0/gml.xsd"

Consistent versioning approach on OpenAPI definition documents

There is a need to harmonise the versioning approach used by SWGs while the specifications are in draft form.

Conformance class URIs during development

In ldproxy we usually set the version number of conformance class URIs to "0.0" instead of "1.0" until the standard has been published. We want to avoid that a client that implements a standard thinks that an API implements the published standard, but the API really implements some draft.

For the Tiles conformance classes I had to (temporarily) change this now to "1.0" because this is what the draft ETS expects, but this can only lead to problems in the future.

I think we need an approach how we use versions in conformance class URI for standards that have not been published.

Consider role of JSON-LD context

ELFIE project settled on using contexts as an expression of the expected profile of underlying ontologies.

BP will need to consider issues of schema and profile, including validation discovery and comparison (is object A compatible with object B)

Need for an OGC DWG on Feature Encodings?

In the Architecture DWG meeting during the June 2021 Member Meeting it was decided to open an issue on this subject and invite comments.

The issue was triggered by the need to find the right working group(s) where the Testbed-17 Engineering Reports from the Features and Geometries JSON task should be presented and reviewed. There is, of course, the new Features and Geometries JSON SWG that is a natural fit. There are, however, multiple OGC working groups that are / have been / will be working on feature encodings, but there is currently no Domain Working Group for cross-SWG or cross-domain discussions on such topic - beside the Architecture DWG.

Would OGC benefit from an active DWG focussed on discussions on Features and their representations?

Some considerations:

• For years, the Simple Feature and GML groups were sufficient, because this is where most of the feature encoding work happened in OGC. This has changed and will continue to change and it would be good to have an open discussion forum for topics beyond a single standard and to discuss developments that might impact OGC standardization.
• There are existing DWGs related to the topic that have been inactive for years (Features WG - dormant, GML DWG). The option would either be to reactivate and recharter one of them or to start a new DWG. In any case, a new charter is required.

To move the topic forward, there would also need to be volunteers for drafting the charter and leading the activity.

Consider Testbed 14 OGC 18-091r2: Application Schemas and JSON Technologies ER

Available at: http://docs.opengeospatial.org/per/18-091r2.html
OGC Testbed-14: Application Schemas and JSON Technologies Engineering Report
(Johannes Echterhoff)

It uses draft 07 while that master of this JSON best practice still follows draft 04

Recommending an expression/transformation type for JSON-LD

There is more than one way to express Linked Data using JSON-LD syntax (e.g. expansion, compaction, flattening). It may be useful to recommend one expression/transformation type so that OGC JSON-LD documents may be more easily consumed by applications.

For some background information, it is worth reading https://www.w3.org/TR/json-ld-api/#features

Feedback to JSON-LD standard

The authors of this document perceive the current documentation of JSON-LD as confusing. That is why another approach in explaining how to use JSON-LD is exposed here.

W3C is starting up a working group to work on a new JSON-LD version. We should feed things like this back to them. That will be appreciated.

Also, the problem with coordinates in GeoJSON-LD.

We could use this issue to gather comments we have on JSON-LD and we can feed them back to W3C in various ways.

Minor editorial naming

In English, names are standardized thus:
[ ] are Brackets. Calling them square brackets is fine.
{ } are Braces. Calling them curly braces is fine.
( ) are Parentheses. Calling them ordinary brackets is not.

In dealing with JSON, let us give things their proper name.

Consider SHACL for validating JSON-LD

I do not know the exact implications of this but it was previously suggested.

The suggestion is supported by some web page authors:
https://www.topquadrant.com/technology/shacl/tutorial/

"SHACL validation tools can verify whether your data fulfills the constraints described by your data model, similar to how XML Schema or JSON Schema are being used."
"SHACL is based on RDF and supports the validation of graph-based and object-oriented data. Since SHACL is based on RDF, it may also serve as a schema language for JSON via its JSON-LD dialect"

Establish draft policy for OGC Building Blocks

The building blocks register development has identified a need for an OGC-NA policy to govetn the registration of building blocks. The Architecture DWG has an action to draft the policy and then submit it to the OGC-NA for approval.

• Hold a telecon in Dec 2023
• Hold a discussion at the March 2024 OGC Member Meeting - OGC NA session

Add consideration to JSON Pointer and JSON Path

JSON pointer

• https://tools.ietf.org/html/rfc6901
• This specification defines JSON Pointer, a string syntax for identifying a specific value within a JSON document. JSON Pointer is intended to be easily expressed in JSON string values as well as URI fragment identifiers.
• Example:
• /foo/0

JSON path

• https://goessner.net/articles/JsonPath/index.html#e2
• Like XMLPath.
• More expresive
• Not an standard
• Examples
• $.foo[0] $[‘foo’][0]
• $.store.book[?(@.price < 10)].title

JSON reference

• https://tools.ietf.org/html/draft-pbryan-zyp-json-ref-03
• The role of $ref

Take into account ELFIE json-ld experiences

ELFIE project has done a range of experiments exploring use of JSON.

Incorporate JSON-LD 1.1

JSON-LD is undergoing an update @ W3C at the moment. Some of the changes made are relevant to geospatial data so it is important to incorporate this in the OGC JSON BP, if possible.

Current editor's draft of the JSON-LD 1.1 spec: https://w3c.github.io/json-ld-syntax/

JSON-LD 1.1 supports lists of lists / ordered lists as stated here: https://w3c.github.io/json-ld-syntax/#lists

Current status: W3C working draft.

We should update the OGC JSON BP to incorporate the new JSON-LD version.

Define the scope of the document

Who is the target of the document?:

• A standard writer?
• A developer of JavaScript apps?
  What it should contain?
• How to generate a JSON encoding from UML...

What we want to cover?

• JSON, JSON schema, JSON-LD?

Delegation of the development of Extensions (OGC API parts) to different OGC API SWGs

This issue was raised during the 2021-04-19 OGC API - Common SWG meeting.

The question is how to improve the delegation of the development of Extensions (OGC API parts) such that all OGC API SWGs contribute to extensions before they are passed to the OGC API - Common SWG for further development.

crs-compound: Support compound CRS including ISO-8601/Gregorian

Currently, Common and Features reference http://www.opengis.net/def/uom/ISO-8601/0/Gregorian as the temporal reference system.

However, that does not resolve with http://www.opengis.net/def/crs-compound as can be seen e.g. with:

http://www.opengis.net/def/crs-compound?1=http://www.opengis.net/def/crs/EPSG/0/4326&2=http://www.opengis.net/def/uom/ISO-8601/0/Gregorian

This is preventing to define spatio-temoral reference systems that would be commonly used with OGC API - Coverages.

This may be because that definition is currently mistakenly defined as a unit of measurement rather than a CRS or TRS.

Related to opengeospatial/NamingAuthority#101

provide consistent guidance on JSON/YAML schemas

It would be valuable to have definitive guidance on OGC OpenAPI workflow, from the perspective of:

• specification contributors
  • whether to build an "all-in-one" yaml in the GitHub repo, or just schema fragments
  • docs on how to validate schemas/YAMLs (UI tools, programmatically)
  • what gets published to schemas.opengis.net
    • schema fragments
    • all-in-one
• specification implementers who want to use/reference schemas
  • guidance/recommendations on:
  • reference "all-in-one" YAML and traverse via #/.... notation
  • use fragments directly

cc @cportele @pvretano @jerstlouis @Schpidi @chris-little