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.
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 https://github.com/w3c/dxwg/issues/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:
The homepage of the catalog.A homepage of the catalog (a public web document usually available in HTML).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?
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
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...
@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.
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 catalogsdcat:landingPage is for anything for which data can be accesseddcat: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...
Most helpful comment
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:homepageis only for catalogsdcat:landingPageis for anything for which data can be accesseddcat:landingPagehas 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 forfoaf:homepage.This said I'm afraid now that this clarification into the "access" dimension of
dcat:landingPagewould call for a clarification of the meaning ofdcat:accessURL- and maybe an acknowledge that sometimes a Distribution may have the same value indcat:landingPageanddcat: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...