Subtle differences in property naming between DCAT and Records

[pvretano]

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.

[pvretano]

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

• NOTE 1: Possible target for renaming.
• NOTE 2: OAPIR uses are array to express one or more instances of this property, thus the use of the plural form.
• NOTE 3: DCAT segregates proeprties into various classes. OAPIR, on the other hand, maps properties into the GeoJSON structure to take advantage of GeoJSON clients. Since it is bad practice in JSON to have DUPLICATE keys, OAPIR uses the prefix "record" to distiguish record-specific properties versus catalogued resource properties (e.g. updated, recordUpdated).
• NOTE 4: It is bad JSON practice to use key names with spaces. Convention in OAPIR is lower camel case.

[pvretano]

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.

[pvretano]

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.

[kalxas]

Do we perhaps need a separate issue just for folding associations into links?

[tomkralidis]

+1, support/makes sense.

[ycespb]

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.

• $.properties.isPrimaryTopicOf.created (metadata property)
• $.properties.created (resource property)

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.

[m-mohr]

After solving #178, some additional notes:

• stac_extensions has the same purpose as conformsTo basically. Still, they can be separate, no issues expected.
• I heard today that records may also have a field for temporal information, but I don't see it captured here.
• type is listed twice in the table?
• keywords will likely also be present in STAC: Extend common metadata by keywords radiantearth/stac-spec#1187
• for keywordsCodespaces / themes, I think there's a proposal for a subjects extension: https://github.com/stac-extensions/subjects, which we might want to align to themes: Alignment with OGC API - Records? stac-extensions/themes#4
• language: I'll propose to use the same term in STAC: Multi-language support radiantearth/stac-api-spec#306
• How close is the content of license and providers aligned in STAC and Records?
• What is the extent useful for if you already have bbox and potentially the time property from JSON-FG?

[pvretano]

@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

[m-mohr]

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.

[pvretano]

@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.

[m-mohr]

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 ;-) )

[pvretano]

07-APR-2023:

1. The schema of records has been set for quite some time now and has been harmonized with DCAT to the extent possible taking into account all the other conflicting interests.
2. There is a conformsTo tag in records that allow additional GeoDCAT members to be added to a record.
3. There is now a GeoDCAT SWG forming/formed in OGC that will handle all GeoDCAT issues.

[rob-metalinkage]

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.