Clarification on foaf:homepage / dcat:landingPage for dcat:Catalog

[andrea-perego]

dcat:landingPage is implicitly added to dcat:Catalog as inherited from dcat:Resource.

Since its use in this context semantically overlaps with foaf:homepage (legacy from DCAT 2014, and explicitly associated with dcat:Catalog), we need to clarify the use of these properties.

[agbeltran]

Adding clarification on usage of properties is always good, so I agree in the context of this issue.

About the semantic overlap between them, I think we could clarify when is relevant to use the properties in different ways for dcat:Catalog, especially when describing a catalogue of catalogues. In this case, foaf:homepage will point to the main page of the catalogue and dcat:landingPage will be the page of that catalogue within the catalogue of catalogues (when considering the catalogue as a dataset).

e.g. for the list of catalogues in EDP, the dcat:landingPage for the Open Data Portal Estonia is https://www.europeandataportal.eu/data/en/organization/avaandmete-portaal, while the foaf:homepage is https://opendata.riik.ee

When considering a single catalogue of datasets, both properties may indeed overlap, but it is also possible that they differ.

e.g. for the Belgium Open Data portal, foaf:homepage would be https://data.gov.be/en, while the dcat:landingPage could be https://data.gov.be/en/search/datasets

Now checking the definitions...

In DCAT2014, dcat:landingPage was defined as: A Web page that can be navigated to in a Web browser to gain access to the dataset, its distributions and/or additional information. with domain dcat:Dataset and range foaf:Document.

We have now relaxed the domain (see #122) and changed the text of the definition to:
A Web page that can be navigated to in a Web browser to gain access to the catalog, a dataset, its distributions and/or additional information.

For foaf:homepage for dcat:Catalog we have:

• DCAT2014: The homepage of the catalog.
• DCATrev: A homepage of the catalog (a public web document usually available in HTML).
  and we have notes clarifying that is an inverse functional property.

So, the subtle distinction is between identifying the primary page of the resource and a page that allows to gain access to the resource.

So, what about adding these clarifications and examples?

[davebrowning]

Note also discussion at #352 which came the the conclusion that this was best addressed by some examples.

We don't have time to do that in the recommendation document itself but we could do it as primer or just an example - I've tagged it like that to hopefully provoke discussion

[aisaac]

This is one issue I've seen when I reviewed DCAT this week indeed. Is there really no way to add a clarifying sentence in the definition? I mean, if the DCAT group has a n opinion it's probably doable to write it down. If not, then there's a deeper problem...

[dr-shorthair]

@agbeltran makes a rather subtle case for the distinction between homepage and landingPage, also backing it up with evidence from actual usage.

Nevertheless, I think the issue was actually triggered by us not spotting this consequence of the (new in version 2) sub-class relationships to dcat:Resource. In most cases there would be not distinction between homepage and landingPage. I would advocate deprecating foaf:homepage in favour of dcat:landingPage whose name is a bit clearer. Probably too late for v2 though.

[aisaac]

I find @agbeltran 's case quite subtle indeed, but I think I can buy it, and there may be editorial ways to muscle it up. If just by reminding some basic lines as a note that could be added later on (I don't think there should be objections to adding notes between CR and PR):

• foaf:homepage is only for catalogs
• dcat:landingPage is for anything for which data can be accessed
• dcat:landingPage has been minted specifically for this purpose, while foaf:homepage is more general.

This would seem much more backward compatible than deprecating foaf:homepage, especially if there's a valid case for foaf:homepage.

This said I'm afraid now that this clarification into the "access" dimension of dcat:landingPage would call for a clarification of the meaning of dcat:accessURL - and maybe an acknowledge that sometimes a Distribution may have the same value in dcat:landingPage and dcat:accessURL. Has there been an issue about this?

NB: in the end all this may be the object of a specific session in a primer about "access/home URLs" properties. But this section does not exist yet, and it's probably better to check that there is consensus on the intention behind all these properties now, rather than realize only latter that there's disagreement...

[bertvannuffelen]

Maybe I might throw a stone in the water, but is this not because dcat:Catalog is defined as a subclass of dcat:Dataset?

Why not simply removing that restriction? I personally find this too restrictive from DCAT and it blocks profile building. (See another issue I raised).

Lifting the restriction is not stating that dcat:Catalog cannot be viewed as Dataset, but it is a different notion.

E.g. dct:spatial for a catalog in any simple DCAT instance is different from dct:spatial for a dataset in that catalogue.
Namely for the dataset is it geographical coverage of the data in that dataset, while for the catalog is its the legal spatial coverage (country/ supranational entity)
Those are different spatial notions. E.g. the dataset of all embassies of France has as spatial coverage the world, while the spatial coverage of the France open data catalog will be France (as legal responsible entity).

Just consider them as different notions and leave the complex case where a profile wants to enforce that all Catalogs are a subclass of Datasets for them to solve.