- From: Simon Cox via GitHub <sysbot+gh@w3.org>
- Date: Tue, 16 Jun 2020 22:41:27 +0000
- To: public-dxwg-wg@w3.org
Good work @mathib . This general approach is what we expect - extend the DCAT model with elements from other RDF vocabularies, while being appropriately careful about imported entailments. Regarding the **subset** issue: DCAT provides a generic mechanism for dataset-dataset relationships - see https://www.w3.org/TR/vocab-dcat-2/#qualified-forms . This requires a separate enumeration of 'roles' for the related resource. Regarding the description of a SPARQL endpoint, with named graphs etc: I made a start on this in the background, and you can see traces of it in https://www.w3.org/TR/vocab-dcat-2/#ex-elaborated-bag but I was not sufficiently familiar with the details of the [SPARQL Service Description](https://www.w3.org/TR/sparql11-service-description/) vocabulary to do it justice, so I deferred a more rigorous version. However, the general expectation was that the [dcat:endpointDescription](https://www.w3.org/TR/vocab-dcat-2/#Property:data_service_endpoint_description) would do the heavy lifting. It looks like you have gone in a slightly different direction, attempting to describe each named-graph as a distinct DCATA dataset, with associated distributions. This is reasonable. But the level of detail that you are suggesting here is very RDF-specific, and as the scope of DCAT is much broader, my hunch is that this probably would not be suitable for the DCAT core. In fact it looks more like VOID work. -- GitHub Notification of comment by dr-shorthair Please view or discuss this issue at https://github.com/w3c/dxwg/issues/1241#issuecomment-645048021 using your GitHub account
Received on Tuesday, 16 June 2020 22:41:28 UTC