How to specify the multiple endpoints of a SPARQL service

[marcelotto]

I am seeking clarification on the recommendations for specifying the multiple endpoints of a SPARQL service for its different operations (query, update, graph store) with a dcat:DataService. Although the vocabulary definition of dcat:endpointURL does not impose any cardinality restrictions, it seems to be intended to be used for a single endpoint. Is the creation of multiple dcat:DataService instances for each endpoint the preferred approach, or are there other recommended methods within DCAT for handling this scenario?

[bertvannuffelen]

@marcelotto this is a question of granularity: Is your intend to manage for each "Operation" a different Data Service?

Consider an OpenAPI specification of a system: That has multiple resources and multiple operations for each resource. If you want to publish this as a catalogue of resources and operations than there will be for each resource a dataset and for each operation a data service. This catalogue organisation can drive to create a website similar to what the OpenAPI specification.

However this granularity is not to be shared as such with the public in a broad data ecosystem: I think the chance it low that people would ask to google search (or chatGPT): give me a dataset for which there is an open Update SPARQL endpoint for a resource A.
In this usecase you will abstract away the indiviual resources and the operations of the API. And thus therefore you end with a Dataservice that points with its endpointURL to the root of the API.

In Open Data Portals such as https://data.europa.eu there is little need for the fine grained expressing. It makes your Dataservice only harder to find. But if you are managing an API platform such a APIGEE then it is critical. So it depends on you target and maybe you need both.

[marcelotto]

@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.
• The update operation as defined by the SPARQL protocol.
• The graph management operations of the SPARQL Graph Store Protocol.

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.