schema:encodingFormat SPARQL

[coret]

ref: https://twitter.com/markuitheiloo/status/1554838166174965761

In the example, and also SHACL and demonstrator, application/sparql-query is used as an example for a distributions schema:encodingFormat. But application/sparql-query applies to the request type, and scheme:encodingFormat should describe the response type, for a SPARQL endpoint this is application/sparql-results+xml.

TODO: correct requirements, correct SHACL and add to demonstrator iana mediatypes json.

[ddeboer]

We had some discussion about this in #45 already.

A possible downside of using application/sparql-results+xml is that there’s also application/sparql-results+json and even CSV and TSV, so describing a SPARQL endpoint becomes more cumbersome. At the very least, we need to decide whether to prescribe just one or all of the possible result formats.

[coret]

The default Content-type of the response of an SPARQL endpoint is not defined in the SPARQL 1.1 Protocol and differs per implementation. Some examples:

• for GraphDB (at least @ GoudaTijdmachine) it's text/csv;charset=UTF-8
• for Virtuoso (at least @ KB) it's application/sparql-results+json
• with Triply (at least @ data.netwerkdigitaalerfgoed.nl) it's application/json; charset=UTF-8
• Wikidata it's application/sparql-results+xml;charset=utf-8

In a request you can specify the Accept HTTP header to indicate the desired Content-type of the response. Some implementations (such as Virtuoso) also allow for a format parameter in the URL.

This leads to the following conclusion (to be included in the specification):

The schema:encodingFormat should indicate the Media type of the response of the schema:contentUrl when no Accept header is included in the request. It is recommended to provide an URL of documentation via the schema:usageInfo property in which the supported encoding formats which can be requested via an Accept HTTP header are listed.

Downside: it's harder to query for SPARQL-endpoints, you cannot rely on the "Linked Data" encodingFormats (because an SPARQL endpoint may respond with text/csv) and distinguishing distribution types is not yet defined (see issue #45)

[ddeboer]

Alternatively, require all supported SPARQL response formats to be specified in encodingFormat, so for example:

  "encodingFormat": ["application/sparql-results+xml", "application/sparql-results+json"],

A complication is that SPARQL CONSTRUCT queries return a different format, i.e. one of the RDF serialisations such as application/n-triples.

All things considered, I think we should specify SPARQL endpoints differently. In DCAT we would use dcterms:conformsTo <https://www.w3.org/TR/sparql11-protocol/> :

dcat:distribution [
    rdf:type dcat:Distribution ;
    dcterms:conformsTo <https://www.w3.org/TR/rdf-schema/> ;
    dcterms:title "RDF representation of the data"@en ;
    dcat:accessService [
      rdf:type dcat:DataService ;
      dcterms:conformsTo <https://www.w3.org/TR/sparql11-protocol/> ;
      dcterms:title "International Chronostratigraphic Chart hosted at Research Vocabularies Australia"@en ;
      dcterms:description "Service that supports queries to obtain RDF representations of subsets of the data"@en ;
      dcat:endpointURL <http://vocabs.ands.org.au/repository/api/sparql/csiro_international-chronostratigraphic-chart_2017> ;
      dcat:landingPage <https://vocabs.ands.org.au/viewById/196> ;
    ] ;
  ] ;