Why default Dataset resources to dcat:landingPage instead of foaf:page?

[streino]

The reference ISO-19139 to GeoDCAT-AP XSLT defaults to converting Dataset online resources as dcat:landingPage.

This is consistent with GeoDCAT-AP 2.0:

In INSPIRE, this element, quoting, "defines the link(s) to the resource and/or the link to additional information about the resource". [VOCAB-DCAT-2] has a property, namely, dcat:landingPage, having exactly the same purpose.
[...]
Based on this, the mappings of element “resource locator” for data sets and data set series will vary depending on the function code (when available), based on the following table.

ISO 19115 – CI_OnlineFunctionCode	Property	Domain	Range
(not provided)	dcat:landingPage	dcat:Dataset	foaf:Document
download	dcat:accessURL	dcat:Distribution	rdfs:Resource
Information	foaf:page	dcat:Dataset	foaf:Document
offlineAccess	dcat:accessURL	dcat:Distribution	rdfs:Resource
order	dcat:accessURL	dcat:Distribution	rdfs:Resource
search	foaf:page	dcat:Dataset	foaf:Document

It however seems inconsistent with DCAT definitions I could find:

DCAT-AP 2.0.1 section 4.4.3:

Property	URI	Range	Usage note	Card.
documentation	foaf:page	foaf:Document	This property refers to a page or document about this Dataset.	0..n
landing page	dcat:landingPage	foaf:Document	This property refers to a web page that provides access to the Dataset, its Distributions and/or additional information. It is intended to point to a landing page at the original data provider, not to a page on a site of a third party, such as an aggregator.	0..n

w3c/dxwg#122 (comment): (definition of landingPage cited below is the one used in DCAT v2/v3):

foaf:page: A page or document about this thing.
dcat:landingPage: A Web page that can be navigated to in a Web browser to gain access to the dataset, its distributions and/or additional information.
First of all, dcat:landingPage must be a Web page while foaf:page allows as object "things which are, broadly conceived, 'documents'". Secondly, foaf:page links to information "about this thing" while dcat:landingPage requires information that serves "to gain access to the dataset, its distributions and/or additional information". To me, these two specialisations of foaf:page justify the existence of the DCAT property.
Please also note that in the European DCAT-AP both dcat:landingPage and foaf:page are specified for Dataset, the latter to allow a link to any kind of documentation about the dataset.

From the above definitions I would expect un- or under-qualified "documents" about a Dataset to end up as foaf:page, with only "true landing pages" qualified as dcat:landingPage, as it seems to be the case for resources described directly in DCAT (as opposed to resources converted from ISO)?

The INSPIRE standard is missing a way to identify the "true landing page" for a record, ie the original record page on the original catalog (MD_Identifier could serve that purpose but it is only recommended and not required in the INSPIRE Technical Guidance, and in practice isn't always set that way). It is however quite an important information to capture. Short of a standard, we'd at least like to have a suitable recommendation for our catalogs (French administration). We could imagine ways forward such as :

• Request a dedicated CI_OnlineFunctionCode or a dedicated INSPIRE gmd:protocol for "landing page" (possibly far fetched, but likely the best option).
• Restrict (by convention) gmd:function with code Information to "landing page" material, while more general information would go without a gmd:function.

There may be other ways, but in any case we'd want those resources to be the only one(s) identified as dcat:landingPage, with other resources defaulting to the more generic foaf:page.

We tried to find context for the choice of dcat:landingPage vs foaf:page but could not find much besides what I'm quoting above. Has this issue been raised already, with maybe some solution to the "true landing page" issue we're facing?

[streino]

Adding some more concrete context.

Some of our INSPIRE catalogs have gmd:distributionInfo linking to studies or other types of publications that used the Dataset as a source of data. For instance a Dataset record with "Related works" (ISO XML).

Having no relevant CI_OnlineFunctionCode, those resources can't declare a gmd:function and therefore end up as dcat:landingPage -- despite the fact those resources are not "about" the Dataset. While not ideal (dct:isReferencedBy would be more appropriate), the more generic definition of foaf:page seems better than dcat:landingPage in those cases.

[fxprunayre]

The approach planned in GeoNetwork (geonetwork/core-geonetwork#7600) for this is:

• in ISO19115-3, metadatalinkage is used as the dcat:landingPage (https://github.com/SPW-DIG/metawal-core-geonetwork/blob/dcat/schemas/iso19115-3.2018/src/main/plugin/iso19115-3.2018/formatter/dcat/dcat-core-distribution.xsl#L81-L97). Also for records with a DOI (eg. https://sextant.ifremer.fr/Donnees/Catalogue#/metadata/cf5048f6-5bbf-4e44-ba74-e6f429af51ea) maybe the DOI is a good candidate for the landing page.
• graphic overview is a foaf:page https://github.com/SPW-DIG/metawal-core-geonetwork/blob/dcat/schemas/iso19115-3.2018/src/main/plugin/iso19115-3.2018/formatter/dcat/dcat-core-distribution.xsl#L101-L109
• online resources are mapped to foaf:page or dcat:distribution based on function or protocol values. https://github.com/SPW-DIG/metawal-core-geonetwork/blob/dcat/schemas/iso19115-3.2018/src/main/plugin/iso19115-3.2018/formatter/dcat/dcat-core-distribution.xsl#L142

[jakubklimek]

@streino Is your proposal to switch the mapping from

1. "undefined" => dcat:landingPage
2. Information => foaf:page

to the other way around, i.e.

1. "undefined" => foaf:page
2. Information => dcat:landingPage

?

[streino]

Thanks for looking into this!

Yes that's basically our suggestion, with "undefined" => foaf:page being the most important.

Information => dcat:landingPage is more of a stretch, as the definition of Information is broader than dcat:landingPage. Ideally we'd want another CI_OnlineFunctionCode dedicated to landingPage, but I'm not sure how feasible that is. Short of that, Information might be a good approximation?

[streino]

@jakubklimek what's the process to accept/reject this change? We'll be happy to help with a PR, but we don't want to get ahead of the process.

[jakubklimek]

@streino We were hoping to get some more community feedback on this. Since the release of GeoDCAT-AP is imminent, we have pushed this into the next cycle. PR here is not necessary, as the change is relatively trivial.