- From: Simon Cox via GitHub <sysbot+gh@w3.org>
- Date: Mon, 03 Sep 2018 00:15:38 +0000
- To: public-dxwg-wg@w3.org
@makxdekkers yes I understand and to a certain extent agree that there is a risk. However, I'd make a slightly different emphasis concerning the 'coathanger classes'. The point is that there really is a common pattern here: there are (1) conceptual things, and (2) concrete realizations of them, with often more than one realization of each conceptual thing. In the REST literature they are called `Resource` and `Representation`. DCAT-2014 considered a _subset_ of them and called them `Dataset` and `Distribution`. This is all good, as the different terminology between DCAT-2014 and REST reflects the more limited scope of DCAT-2014. Now in DCAT-rev we have expanded the scope, and we have agreed that new things - in particular _services_ - are not _datasets_, but some other kind of resource. The proposed model respects all of these precedents, preserving the terminology from each in a consistent way, so it should not surprise anyone, while still being backward compatible with DCAT-2014. I've been involved in a number of initiatives that set up an abstract framework (GML, O&M), and have observed that implementers are incredibly reluctant and non-creative in actually extending the abstract- or stub-classes in the way that we had intended. So your prediction that implementers might just use the 'abstract' classes as-is is based in experience. Is this enough reason to shy away from a clean model? In my opinion, no - for one thing, we would have to replace it with something else, which will likely be messier! In previous discussion you have advocated making sure the documentation is right, and also supplementing it with good pedagogical material. I think we should do that here. -- GitHub Notification of comment by dr-shorthair Please view or discuss this issue at https://github.com/w3c/dxwg/issues/317#issuecomment-417970169 using your GitHub account
Received on Monday, 3 September 2018 00:15:39 UTC