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

Created on 17 Feb 2019  路  5Comments  路  Source: w3c/dxwg

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.

dcat dcat-primer landingPage homepage future-work requires discussion

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

All 5 comments

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:

  • 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?

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

Was this page helpful?
0 / 5 - 0 ratings

Related issues

nicholascar picture nicholascar  路  5Comments

bertvannuffelen picture bertvannuffelen  路  4Comments

andrea-perego picture andrea-perego  路  3Comments

andrea-perego picture andrea-perego  路  5Comments

jakubklimek picture jakubklimek  路  6Comments