- From: Marcel Otto via GitHub <sysbot+gh@w3.org>
- Date: Thu, 08 Feb 2024 14:17:37 +0000
- To: public-dxwg-wg@w3.org
@bertvannuffelen Thank you for your detailed response. Regarding the question of whether to manage each "operation" as a different Data Service, my intention is actually the opposite. By "operations," I refer to the typical endpoints found in a SPARQL store, including: - The [query operation as defined by the SPARQL protocol](https://www.w3.org/TR/sparql11-protocol/#query-operation). - The [update operation as defined by the SPARQL protocol](https://www.w3.org/TR/sparql11-protocol/#update-operation). - The graph management operations of the [SPARQL Graph Store Protocol](https://www.w3.org/TR/sparql11-http-rdf-update/). I am interested in describing a SPARQL service that hosts a `dcat:Catalog`, encompassing these endpoints within a single `dcat:DataService`. However, given that `dcat:endpointURL` is defined as "the root location or primary endpoint of the service" it seems not straightforward to achieve this with DCAT alone without introducing new properties. I was hoping there might be specific recommendations for this case, especially since SPARQL is also a W3C standard. Absent such guidance, I might lean towards defining my own properties derived from `dcat:endpointURL` rather than representing each endpoint as a separate `dcat:DataService`. -- GitHub Notification of comment by marcelotto Please view or discuss this issue at https://github.com/w3c/dxwg/issues/1587#issuecomment-1934215288 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 8 February 2024 14:17:39 UTC