foaf:homepage vs. dcat:landingPage

[dr-shorthair]

@fellahst pointed out in #122 (comment) that dcat:landingPage (a property of all dcat:Resources) is very similar to foaf:homepage (recommended on dcat:Catalog). Now we have recognised that dcat:Catalog is a sub-class of dcat:Dataset, this means that both of these properties are available on a catalog description. What is recommended best practice? Should the use of one of these (foaf:homepage) be deprecated in the context of a catalog?

[kcoyle]

Is this relevant? from the FOAF specification:

"FOAF allows a thing to have multiple homepages, but constrains homepage so that there can be only one thing that has any particular homepage."

[davebrowning]

I think what we've got doesn't break anything - a catalog could have a number of foaf:homepage that were purely descriptive, as well as some dcat:landingPage that are more access oriented (as per the definition 'to gain access to the resource') , especially if some kind of access control is applied for access beyond the landing page.

[larsgsvensson]

a catalog could have a number of foaf:homepage that were purely descriptive

Right, but we still must be careful since foaf:homepage is inverse functional. I. e. if a catalogue or dataset has a foaf:homepage, implementers must ensure that it is the homepage of the Catalogue (or Dataset) and not of the publishing institution.

[makxdekkers]

Looks to me that the statement at FOAF does not say that one thing can have only one homepage. Instead, it says that a page can be a homepage of not more than one thing. So two things must not share the same homepage. Sounds like an odd constraint that is difficult to enforce.

[danbri]

@makxdekkers is correct, the idea in FOAF/RDFWeb was to facilitate (rather than require) "reference by description". If you know for example that there is a company whose name is Apple, whose homepage is https://www.apple.com/, ... that is a pretty strong referring expression. So we made part of the concept of "homepage" the idea that there's a single thing whose homepage it is. It is not a particularly odd or obscure constraint, e.g. see @rvguha's paper on related theoretical issues.

In FOAF we then generalized this pattern to cases where you wouldn't intuitively want to call it a "homepage". The FOAF name for this was isPrimaryTopicOf. In Schema.org, we can used the less verbose "http://schema.org/sameAs" relationship, but the idea is similar: a relationship between something and a (relatively well known) page primarily about it. Another related relation is https://schema.org/mainEntityOfPage which drops the expectation that the page/document is well known. Some notes on these overlaps are at https://schema.org/docs/datamodel.html#mainEntityBackground

[riccardoAlbertoni]

I think some explanations and examples would help users in a deeper understanding. Can we consider to add the following items to the document?

• An example of dcat:landingPage for catalog
• An example/ note/ whatever suggesting that the use of foaf:homepage requires some extra care, in particular,
  1. foaf:homepage must not be used as a replacement for dcat:landingPage;
  2. Reasoning will consider catalog descriptions having the same foaf: homePage as referring to the same real entity. That implies that different releases of the same catalog might collapse if they are pointing to the same foaf:homePage. Depending on the context this kind of collapsing can be desirable or undesirable. If it is undesirable use dcat:landingPage instead of foaf:homepage.

I am willing in drafting a proposal by extending the basic example if the group thinks this can close the issue.

[andrea-perego]

It seems the discussion on this issue moved to #763

I propose to close it, and continue the discussion there (if still relevant).

[riccardoAlbertoni]

We are closing this issue as proposed above and as a result of tonight's DCAT subgroup meeting