-
Notifications
You must be signed in to change notification settings - Fork 8
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
Update JSON-LD text, context doc and prefix registry? #147
Comments
@jonblower @letmaik The OGC Schema Repository is not a GitHub repo, but just a hierarchical file system. Could we put everything into a single folder, called for example: |
I would roughly follow https://schemas.opengis.net/cis/, so there would be at minimum: https://schemas.opengis.net/covjson/ I'm not sure about the JSON-LD context doc and the prefix registry. They are a mix of schema and vocabulary. Maybe new vocabulary would go in https://defs.opengis.net/vocprez/vocab/ but then the JSON-LD context doc still has to live somewhere. Maybe it's ok for 1.0 to keep them at covjson.org and only host the JSON Schema on opengis.net. |
@ghobona @ogcscotts I think the structure of the CoverageJSON schema files from @letmaik is good. |
Agreed on 25 Jan 2023 to put all the files (schemas, context files, prefixes) on the OGC Schema file repository under the URL http://schemas.opengis.net/covjson/ |
When schemas etc copied into OGC schema repo, and the Community Standard is published, the community needs to agree on a closing date for the community site. It could be a few years away. |
@chris-little Some additional considerations that we did not discuss on Wednesday. Location of the Context document Clause 3.1 of JSON-LD 1.1 implies that the context document should be accessible from the URL that is specified in documents that use the context document. Note that the section is non-normative. Although some specifications (e.g. schema.org) do not appear to follow this principle, perhaps we should for CoverageJSON. Clause 9.8 of CoverageJSON suggests that the context document will be accessible from https://covjson.org/context.jsonld Example CoverageJSON documents encoded in JSON-LD should state the actual location of where the context document is going to be. Based on the discussion on Wednesday, if the context documents are to be placed on schemas.opengis.net, then the example documents should use the schemas.opengis.net URL that resolves to the actual document. For example, this could be http://schemas.opengis.net/covjson/1.0/context.jsonld The same goes for if the context documents are to be placed at https://covjson.org/context.jsonld Versioning Another key consideration is versioning. All of the schemas at schemas.opengis.net are versioned. Usually this is done by placing the schema files in a folder path that contains a segment that identifies the version number. For example, http://schemas.opengis.net/covjson/1.0/context.jsonld So v1.1 of CoverageJSON would be placed at http://schemas.opengis.net/covjson/1.1/context.jsonld and so on. Please factor this into your consideration of whether to place the context documents on schemas.opengis.net or covjson.org Perhaps we should discuss these further during the next CoverageJSON team call? |
@ghobona I envisaged we would make an editorial change to Clause 9.8, and the examples, etc., to point to the OGC repository. |
@chris-little and @ghobona discussed the topic during the 2023-02-08 CoverageJSON telecon and agreed that the context document should be placed at https://covjson.org/context.jsonld There was also agreement to leave the prefix page at https://covjson.org/prefixes/ @jonblower @letmaik Do you have any objection to this resolution? |
Decision from telecon on 29th March 2023, with @jonblower, @chris-little, @ghobona and @letmaik:
|
It is probably worth reviewing the text around the use of JSON-LD (see spec daily build), and consider whether we need to move the context doc and prefix registry to new homes in the OGC space?
Note that this relates to the issue about extracting building blocks from the CoverageJSON spec (see #139), as it would greatly help to have stable URIs.
What do you think, @letmaik?
The text was updated successfully, but these errors were encountered: