-
Notifications
You must be signed in to change notification settings - Fork 47
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
naming convention of dcat:catalog #1156
Comments
@aisaac, thanks for the comment. I understand your point, I am not sure that your point offers a reason to change the property name in the future. Surely that is something we cannot do at this stage. Anyway, I agree that your observation is something to consider for discussion in future. For this reason, I have labelled this issue as "future work". |
@aisaac: I was reconsidering this issue after a while. My apologies for having kept this pending so long. I think Besides, changing the name of I wonder if your point implies any concerns that I am not fully catching. Otherwise, if you have no objections I would close this issue. |
Hi @riccardoAlbertoni sorry for taking so long. I missed the notification. |
Thanks, @aisaac
Would this rephasing work for you? |
@riccardoAlbertoni said:
Or, more simply:
This would be in line with the definitions of |
It works for me. |
changing definition dcat:catalog according to #1156
Yes it's perfect! |
This is probably too late for this round, but re-reading the spec I realize that the naming of dcat:catalog is not great: if follows the same convention as dcat:service, dcat:record and dcat:dataset, but instead of linking to a resource that is being catalogues, it links to a resource that catalogues. The naming could instead have better represented that the case here is to represent a part (and that the superproperty is dcterms:hasPart).
For future work?
The text was updated successfully, but these errors were encountered: