-
Notifications
You must be signed in to change notification settings - Fork 55
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Clarification on foaf:homepage / dcat:landingPage for dcat:Catalog #763
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 e.g. for the list of catalogues in EDP, the 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, Now checking the definitions... In DCAT2014, We have now relaxed the domain (see #122) and changed the text of the definition to: For
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 Nevertheless, I think the issue was actually triggered by us not spotting this consequence of the (new in version 2) sub-class relationships to |
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):
This would seem much more backward compatible than deprecating This said I'm afraid now that this clarification into the "access" dimension of 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... |
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. 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. |
dcat:landingPage
is implicitly added todcat:Catalog
as inherited fromdcat:Resource
.Since its use in this context semantically overlaps with
foaf:homepage
(legacy from DCAT 2014, and explicitly associated withdcat:Catalog
), we need to clarify the use of these properties.The text was updated successfully, but these errors were encountered: