search

w3c / sparql-dev

SPARQL dev Community Group
https://w3c.github.io/sparql-dev/
Other
123 stars 19 forks source link

SPARQL Service Description: add "features/dialects" and a client protocol #152

Open VladimirAlexiev opened 3 years ago

VladimirAlexiev commented 3 years ago

Why?

@rubensworks (https://github.com/w3c/EasierRDF/issues/88#issuecomment-912883867) and @holgerknublauch (https://github.com/w3c/EasierRDF/issues/88#issuecomment-905237060) motivate the need to express SPARQL "features" and "dialects" to enable piece-wise extension of SPARQL.

Previous work

Proposed solution

Not a solution, but some considerations:

Considerations for backward compatibility

This is a strong enabler for backward compatibility, so that new SPARQL features can be introduced and implemented in a piece-wise way, rather than all together in globally coordinated versions (1.2, 1.3, etc)

rubensworks commented 3 years ago

I agree that the SD is a great place to describe these features, so that client can detect these features, and possibly modify their query according to the supported features. (this is in essence how the Comunica query engine handles heterogeneous sources)

If this were to be added, I think it would be important that the SD would be made mandatory: #153. Otherwise it will become very hard for clients to figure out with certainty what the server supports exactly.

Related work:

The TPF interface makes use of a feature-based hypermedia description, which builds upon the Hydra ontology.

kasei commented 3 years ago

sd:feature, sd:languageExtension, and other related terms were designed to support this sort of development. Can you describe an example of wanting to "express SPARQL 'features' and 'dialects'" that wouldn't be supported by the current Service Description terms?

But we also need to devise a client protocol

I don't understand this. What would this client protocol do? Would this be completely orthogonal to the service description (which is accessed through a simple HTTP request)?

afs commented 3 years ago

I would have thought the number one concern in looking at an endpoint is what data it has. Then, if there are choices of endpoints does the question of how to get the data become significant.

There are now related approaches like content-negotiation by profile that play into the mix.

VladimirAlexiev commented 3 years ago

@kasei If we can just instantiate these mechanisms (catalog of features could be developed from this issue list) that would be perfect. But the depth and complexity of ideas discussed here may in some cases require:

Examples:

BTW, https://gist.github.com/VladimirAlexiev/8c861db09c08ff202311bae2ee0d6b30 gets the extra 3 flavors of individuals for SD (noticed some problems and emailed Ivan).

What would this client protocol do? Would this be completely orthogonal to the service description (which is accessed through a simple HTTP request)?

Ideally, they should be the same for consistency. But client "accept" instructions have a tradition:

I don't think a client will necessarily be happy to send a bunch of RDF just to state what he prefers. In other words:

@afs Agree, DX-PROF is very relevant.

VladimirAlexiev commented 9 months ago