- From: Jakub Klímek via GitHub <sysbot+gh@w3.org>
- Date: Thu, 30 Aug 2018 05:53:46 +0000
- To: public-dxwg-wg@w3.org
>If this is wrong practice, those profiles will have to be revised. @makxdekkers I think those profiles will have to be revised after DCAT revision anyway. @kcoyle Isn't the main goal of DCAT to increase interoperability? If there is a set of different APs, each with a different set of restrictions and specifics, those will not be interoperable. What is the point then? I actually view what schema.org does as a bit evil. It creates mess in the data, making its processing so hard, only people with a lot of resources are able to process it. I think that having a semantically clean model is a must, and publishers have to be properly motivated to publish their data right. This means there have to be applications able to (easily) process the data (think e.g. simple catalog software). This in my opinion will not be possible if we allow things like properties without ranges, or properties allowing both resources and literals as values. Anyway, we digressed a bit here. The original issue was with the `dct:type` property. This property is already established. If it was used in a wrong way in DCAT2014, and this was then "imported" to DCAT-AP, and from there to GeoDCAT-AP, I think now is the time to correct that by introducing the new property for this, with clearly established range (skos:Concept) - and I really do not think this is "too strict". Btw. errors like this in DCAT2014 were already fixed in the revision (e.g. the literal used as a media type in DCAT2014 examples https://github.com/w3c/dxwg/issues/170, which some implementations started using) so this would not be the first case. -- GitHub Notification of comment by jakubklimek Please view or discuss this issue at https://github.com/w3c/dxwg/issues/314#issuecomment-417198415 using your GitHub account
Received on Thursday, 30 August 2018 05:53:47 UTC