Best practices for linking DCAT-AP datasets to alternative metadata descriptions in INSPIRE/ISO19139, MARC21, DataCite, etc.

[mjanez]

Context

In Spain, we are currently developing DCAT-AP-ES, our national profile. During this process, we have identified a common scenario where a single dataset is described using multiple metadata standards (e.g., INSPIRE ISO 19139 Metadata records, MARC21, DataCite, EML, Dublin Core), and we need to establish explicit relationships between these alternative metadata descriptions.

For example:

• A geographic dataset may have metadata in ISO19139/INSPIRE and also be described in DCAT-AP-ES.
• A bibliographic dataset may have a MARC21 record and also a DCAT-AP-ES description.

We want to enable traceability, cross-enrichment, and interoperability between these metadata representations, especially in federation and migration scenarios.

---

Question

What is the recommended approach in DCAT-AP (and the broader DCAT ecosystem) to link a DCAT-AP dataset to its alternative metadata descriptions in other standards?

Specifically:

• Should we use a generic property like dct:relation?
• Is there a more semantically precise property recommended for this use case (SKOS, skos:closeMatch, skos:broaderMatch)?
• Should we model the alternative metadata record as a foaf:Document and enrich it with properties like dct:conformsTo, dct:format, dcatap:applicableLegislation and foaf:page?
• Should we use a dcat:CatalogRecord? Does EDP accept catalog records?

---

Current Proposal: datosgobes/DCAT-AP-ES#58

We are considering the use of rdfs:seeAlso as a semantically appropriate and lightweight solution, based on its definition in RDFS 1.2 and the W3C guidance on using rdfs:seeAlso:

"A triple of the form: S rdfs:seeAlso O states that the resource O may provide additional information about S."

This fits our use case: the ISO19139/INSPIRE (or MARC21, DataCite, etc.) metadata record provides additional information about the dataset described in DCAT-AP-ES.

Example: Linking a DCAT-AP-ES dataset to INSPIRE/ISO19139 metadata

@prefix dcat: <http://www.w3.org/ns/dcat#> .
@prefix dct: <http://purl.org/dc/terms/> .
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .

# Dataset in DCAT-AP-ES
<http://example.org/dataset/123> a dcat:Dataset ;
    dct:title "Example geographic dataset"@en ;
    
    # Link to INSPIRE/ISO19139 metadata
    rdfs:seeAlso <http://inspire.example.org/metadata/abcdefg.xml> .

# Description of the related resource (ISO19139 metadata record)
<http://inspire.example.org/metadata/abcdefg.xml> a foaf:Document ;
    dct:title "ISO19139 metadata record"@en ;
    dct:description "Metadata for the dataset in ISO19139/INSPIRE format"@en ;
    
    # Standard it conforms to
    dct:conformsTo [
        a dct:Standard ;
        dct:title "Commission Regulation (EC) No 1205/2008"@en ;
        dct:identifier <https://eur-lex.europa.eu/eli/reg/2008/1205>
    ] ;
    dct:conformsTo <http://www.isotc211.org/2005/gmd> ;
    
    # Format
    dct:format <http://publications.europa.eu/resource/authority/file-type/XML> ;
    
    # Link to the landing page (e.g., GeoNetwork record page)
    foaf:page <http://geonetwork.example.org/metadata/abcdefg> .

[bertvannuffelen]

@mjanez this is an interesting use case.

I think we should start this conversation with the following question:

Why is in your perspective a dataset being described in ISO XML, DCAT RDF and MARC21 XML a different entity?
( meaning why must there be a RDF representation of a ISO XML, MARC21, ... ? )

This is the key in the whole story.

Encoding a property relating different representations of the same entity for the purpose of "this is a different serialization of the same metadata" is not addressing the common quality of the metadata.

For instance, if your answer of my question is that is are just representations of the same dataset, then (first) a mapping of the semantical structure is needed.
And secondly you need to align the identifiers. As this represents the same dataset, the identifier of the dataset is expected to be the same.

Lets consider your proposal of adding / using a (new) property to relate the metadata representations with each other, then your use case proposal will lead to a situation that someone having interest in the ISO metadata has to find that property in the RDF metadata, and then gets a an RDF representation of the ISO/MARC21 metadata. Not only is knowing about this property a challenge, also there is no guarantee that this information is universally present, but mostly the information retrieved is in a format that is not native for the targetted community (being ISO XML, MARC21 etc.) That brings challenges on mappings and semantical bridges.

An alternative, existing in DCAT-AP from the beginning, is to list all identifiers of the dataset as another identifier. (see https://semiceu.github.io/DCAT-AP/releases/3.0.1/#identifiers )
By providing all identifiers that exists for a dataset, users from other communities, have an easier way to find the representation. Namely through their known methodes and processes.
This corresponds to the practice that many metadata schemes impose in addition to a semantical structure, a identifier scheme for that ecosystem. This leads to multiple identifiers for the same dataset, one in ISO, one in MARC21, one DOI, one RDF, ...

Returning back to you suggestion, your challenge is also reciprocal. Namely how does MARC21 adds a reference to the DCAT-AP representation or the ISO representation, and similary for the ISO to the MARC21 and DCAT-AP representation?
If they cannot be changed, or do not provide support for it, then there is an interoperability issue.
Namely when having multiple representations of the same dataset, all specifications are impacted.
If not, then this means there is a defacto creation of multiple copies of the same dataset descriptions, making the maintenance of the dataset publisher more difficult, but also reduces the findability of the dataset.

As one cannot expect that all metadata representations are as flexible as DCAT-AP, we might agree between the specifications that there are multiple identifiers for the same dataset. And focus on enabling this minimal alignment in all metadata standards.

Associated with your core use case, there is one specific sub use case that is being addressed by DCAT-AP: What is the source from which the metadata in DCAT-AP representation is being created. This is the property source metadata (https://semiceu.github.io/DCAT-AP/releases/3.0.1/#CatalogueRecord.sourcemetadata) .
It fullfils the goal of automated conversion, or tracking somehow a provenance chain.
Yet this is more technical, more targetted for the management of the metadata rather than for the possible reuser of the dataset.

[dportoles]

First of all, I agree that the Dataset remains always unique, but it has several independent metadata about them. I think that's the way EDP and other open data works nowadays.

If one of the metadata is generated from another (e.g. harvesting ISO and converting to DCAT-AP, like EDP) it should be a good approach using CatalogRecord and dct:source.
But that's not always the case; metadata could have independent life-cycle generation.
Apart from that, AFAIK CatalogRecords are not harvested between Catalog so this relation will be missed after harvesting.

Your approach for using adms:identifier is a great approach. We (@mjanez and myself) have been thinking about this and we hope to use it with additional comments:

• A new rdf:type (adms:Identifier) for URI INSPIRE should be declared for Range restrictions to adms:identifier
• A new triple <URI_INSPIRE_Dataset> dct:conformsTo <ELI_INSPIRE> should be included in order to distinguish this relation from other adms:identifier that could exist before.

<http://datos.gob.es/recurso/dataset/123> a dcat:Dataset ;
   dct:title "Dataset geográfico de ejemplo"@es ;
   dct:identifier <http://datos.gob.es/recurso/dataset/123> ;
   
   # INSPIRE identifier with context
   adms:identifier <http://www.idee.es/csw-codsi-idee/ES-INSPIRE-456>.

<http://www.idee.es/csw-codsi-idee/ES-INSPIRE-456>
       a adms:Identifier ;
       skos:notation "ES-INSPIRE-456" ;
       dct:identifier <http://www.idee.es/csw-codsi-idee/ES-INSPIRE-456>;
       rdfs:comment "Identificador INSPIRE del mismo dataset"@es ;
       
       # Propiedades contextuales adicionales
       dct:conformsTo <http://data.europa.eu/eli/reg/2008/1205>;  # Reglamento de Metadatos INSPIRE
       foaf:page <http://geonetwork.example.org/metadata/ES-INSPIRE-456> ;    # Página HTML de destino
       dct:format <http://publications.europa.eu/resource/authority/file-type/XML> ;
       dct:issued "2020-01-15"^^xsd:date.