- From: Simon Cox via GitHub <sysbot+gh@w3.org>
- Date: Sun, 25 Mar 2018 23:35:09 +0000
- To: public-dxwg-wg@w3.org
@andrea-perego > I think we need to take into account backward compatibility Do you mean 1. backward compatibility with DCAT 1.0 vocabulary or 2. backward compatibility with some DCAT installations? Looking at the latter, I understand that in the GeoDCAT-AP implementations you have implemented a work-around to allow services to be catalogued, with - individuals of type `dctype:Service` in the `dcat:Catalog` - `dct:type` used for soft-typing according to the high-level INSPIRE classification of (discovery, view, download) services - `dct:conformsTo` used to indicate the service standard (e.g. WMS, WFS, SOS, ...) - `dct:hasPart` to point to the datasets served. This looks like a clear demonstration of the requirements, but a sub-optimal solution because 1. contrary to what was done with `dcat:Dataset`, for services you use an old dctype class with some additional constraints added informally 2. the semantics of at least one of these properties (`dct:hasPart`) are not very precise That is why I propose adding an explicit class for services to DCAT, so that we have a clean platform to achieve the outcome that you describe. There is a clear and easy correspondence with the GeoDCAT-AP solution: - Catalog and DataService are both subclasses of `dctype:Service` - `dcat:dataset`, `dcat:dataService`, and `dcat-s:servesDataset` can be sub-properties of `dct:hasPart` - the value of `dct:type` is fixed to **discovery** for `dcat:Catalog`, and to **download** for `dcat:DataService` See #172 and https://github.com/w3c/dxwg/wiki/Cataloguing-data-services -- GitHub Notification of comment by dr-shorthair Please view or discuss this issue at https://github.com/w3c/dxwg/issues/56#issuecomment-376012914 using your GitHub account
Received on Sunday, 25 March 2018 23:35:13 UTC