- From: Andrea Perego via GitHub <sysbot+gh@w3.org>
- Date: Fri, 18 May 2018 21:41:14 +0000
- To: public-dxwg-wg@w3.org
Thanks, @dr-shorthair , for the revised example. My comments below: 1. I'm happy with using `dcat:DiscoveryService` for the moment, modulo the ongoing discussion on whether we are going to model service types by defining specific subclasses, or rather by using another approach (as `dct:type`). 2. I see your point on `dcat:Catalog` - if a service is not a dataset and a catalogue is a dataset, a service cannot be a catalogue. However, one thing could be both, depending on how you look at it: it can be seen either as a curated collection of datasets or the service giving access to them. And actually this is normally the case for data catalogues: they have a curated collection of datasets, exposed via a number of service interfaces (including the human-oriented ones). 3. About the service URI, I was tempted when I started drafting the example to use it, but then I started thinking whether it was appropriate. Does the URL of the service endpoint (always) correspond to the service URI? I don't have yet the answer, so I preferred to use a placeholder. I think we need to be careful here, as the example can be taken as an implicit statement about their identity. BTW, following from point (2), probably the URI should be the one of the EEA catalogue: `https://sdi.eea.europa.eu/catalogue` 4. Thanks for proposing property `dcat:endPoint`. I was looking around to see the terminology used in existing vocabularies (as VoID or [SD](https://www.w3.org/TR/sparql11-service-description/#sd-supportedLanguage)) to get some "inspiration". Taking on board @jakubklimek's point on a property for the service description/capabilities (thanks, @jakubklimek ), I was thinking that we can rename `dcat:endPoint` into `dcat:endpointURL`, and `dcat:endpointDescription` can be the property pointing to the service capabilities. 5. About the service description/capabilities, the idea we discussed is that this will be linked to by using the URL of the OGC capabilities (WSDL, OpenSearch, OpenAPI, SD, etc.) document. However, I wonder whether we should leave the door open to other options (e.g., by adding a placeholder class `dcat:EndpointDescription`). On this, I would be keen to know @fellahst's opinion - we had an interesting discussion on this issue in #56 , and @fellahst mentioned that Geoplatform.gov decided to specify the service description in RDF, and directly into the metadata record. Looking forward to your feedback. -- GitHub Notification of comment by andrea-perego Please view or discuss this issue at https://github.com/w3c/dxwg/issues/237#issuecomment-390340086 using your GitHub account
Received on Friday, 18 May 2018 21:41:25 UTC