Closed pvretano closed 1 year ago
STILL IN PROGRESS (@pvretano 20MAR2022)
NOTE: Top-level members for OAPIR and STAC are in bold.
OAPIR Property | STAC Property | DCAT Property | DCAT Class | Discussion |
---|---|---|---|---|
stac_version | ||||
stac_extensions | ||||
id | id | identifier | catalogued resource | NOTE 1. |
conformsTo | conforms to | record | NOTE 4. | |
type | type | Fixed by GeoJSON ("Feature"). | ||
geometry | geometry | geometry | location | Fixed by GeoJSON. |
bbox | bbox | |||
properties | properties | Fixed by GeoJSON. | ||
properties.datetime / properties.start_datetime,properties.end_datetime | ||||
properties.created | properties.created | listing date | catalog record | NOTE 3. |
properties.updated | properties.updated | update/modification date | catalog record | NOTE 3. |
properties.type | (see assets) | type/genre | catalogued resource | |
properties.title | properties.title | title | catalogued resource | |
properties.description | properties.description | description | catalogued resource | |
properties.keywords | keyword/tag | catalogued resource | NOTE 2. | |
properties.language | language | catalogued resource | ||
properties.externalId | ||||
properties.themes | theme/category | catalogued resource | NOTE 2. | |
properties.formats | format | distribution | NOTE 2. | |
properties.providers | properties.providers | publisher, resource creator, contact point | catalogued resource | NOTE 2. |
properties.license | properties.license | license | catalogued resource | |
properties.rights | rights | catalogued resource | ||
properties.extent | ||||
properties.platform | ||||
properties.instruments | ||||
properties.constellation | ||||
properties.mission | ||||
properties.gsd | ||||
links | links | |||
links.href | links.href | |||
links.rel | links.rel | |||
links.type | links.type | |||
links.title | links.title | |||
links.created | (see assets) | release date | catalogued resource | NOTE 1. |
links.updated | (see assets) | update/modification date | catalogued resource | NOTE 1. |
assets | ||||
assets.href | ||||
assets.title | ||||
assets.description | ||||
assets.type | ||||
assets.roles | ||||
assets.created | ||||
assets.updated | ||||
collection |
07-MAR-2022: In order to try and resolve the tension between OAPIR, DCAT and STAC property names it was proposed in today's SWG teleconference that we include the above crosswalk table in the specification. Then, as much as possible align the OAPIR key named with DCAT and extend the table to include STAC names and say that those names can also be used as aliases. This way client can be prepared to see with the OAPIR/DCAT key names or their STAC equivalent. We will give this a try and see how it flies.
04-APR-2022: Long discussion about the purpose of the links and associations sections related to the assets section in STAC. It is not completely clear to us why the assets section is something separate in STAC but there seems to be consensus among the SWG members that having both the links and associations sections in a record can be confusing since the distinction is not that strong. So, the SWG decided today to collapse associations into links and let the rel indicate the semantic of the link.
Do we perhaps need a separate issue just for folding associations into links?
+1, support/makes sense.
About the duplicate keys such as "created" etc... A JSON solution aligned with DCAT/GeoDCAT-AP, avoiding to have to invent new key names is to use the following encoding where the metadata information goes in $.properties.isPrimaryTopicOf.
See https://docs.ogc.org/bp/17-084r1/17-084r1.html#toc27 and Figure 1 in the DCAT spec https://www.w3.org/TR/vocab-dcat-2/#dcat-scope which shows the foaf:primaryTopic relation between dcat:CatalogRecord and dcat:Resource. IsPrimarytopicOf is the inverse relation of primaryTopic.
After solving #178, some additional notes:
type
is listed twice in the table?@m-mohr about one type ... one "type" is for the record and the other "type" is for the link ... actually href, rel, type and title are all meant to be fields of the link. My table needs a bit of restructuring! ;) Also, keywordsCodespaces is not part of the record any longer ... sorry I have been negligent in keeping this table up-to-date! I need to cross-reference that table with the current record schema ...https://github.com/opengeospatial/ogcapi-records/blob/master/core/openapi/schemas/recordGeoJSON.yaml
Oh, no, I actually meant the types at the beginning (so not in links/assets/...) of the list, but I now see that the one is in properties. Nevermind.
I've just also found themes instead of keywordNamespaces, which seems to be the equivalent to the subjects STAC extension proposal. I'll try to convince people to use themes, too.
@m-mohr hold off on the convincing until after the code sprint. keywords and themes are meant to do similar things. The biggest difference is that keywords are a "free-form" list of keywords, whereas themes are from a formal vocabulary or thesaurus or classification scheme.
Yes, we have the same distinction and will definitively keep "keywords" as free-form ones / tags. And I think we are happy to adopt anything that you define for vocabulary-defined keywords in addition. For now I'm just trying to convince to align with Records, whatever that might be. (Although it might be that they want to define it "asap" and not just in a year ;-) )
07-APR-2023:
conformsTo
tag in records that allow additional GeoDCAT members to be added to a record.There is a formalism of this mapping using JSON-LD in this activity: https://ogcincubator.github.io/geodcat-ogcapi-records/
This is part of the development and testing methodology of GeoDCAT (not to be confused with, but intended to the "common" - no EC centric - part of GeoDCAT-AP).
As part of the testing process, STAC/Records compatibility has been tested - and GeoDCAT profiles matching STAC extensions are being described.
At the SWG meeting at the DEC2021 members meeting there was an observation that the names of RECORD properties that correspond to DCAT are in some cases slightly different (e.g. plural instead of singular, etc.). We should crosswalk the RECORD property names with the DCAT property names and make sure that the ones that coincide are the same ... or at least explain why they are slightly different.