On 27/08/2024 02:52, Paul Tyson wrote:
I have a few questions to help me figure out the relationship between
fuseki service descriptions and the SPARQL service-description schema
[1]. My goal is to translate between fuseki:* and sd:* graphs, to use
fuseki:* internally in the app, and expose service information as sd:*
graphs.
Is there any code or documentation that would establish a mapping
between the fuseki and sd schemas? E.g. between fuseki:Service and
sd:Service, and fuseki:endpoint and sd:endpoint. I can infer some
relationships from the examples, but would like to put it on a more
solid footing.
That would be interesting to hear about.
The Fuseki configuration was not intended to be SPARQL
service-descriptions; it is purely about configuring a Fuseki server.
> Is the http://jena.apache.org/fuseki# schema declared anywhere? Or, is
> there code or documentation to help understand it?
Code:
org.apache.jena.fuseki.build.FusekiConfig and nearby.
It is a mix of Jena assemblers for the datasets and Fuseki-specific for
the services/endpoints
Examples:
https://github.com/apache/jena/tree/main/jena-fuseki2/examples
Description:
https://jena.apache.org/documentation/fuseki2/fuseki-configuration.html
An additional question, at the operational level. Using fuseki 5.1.0.
The SPARQL service description spec Section 2 says conforming SPARQL
protocol servers [2] should provide a service description in response to
a GET request with no query params at the root endpoint. But my services
at localhost:3030/{dataset-name}/ just return the text:
Service Description: /{dataset-name}
if I have all the services mapped to "/" as well as "/gsp", "/query", "/
update".
When I remove the "/" mappings, I get "No endpoint for request".
Is there a way to configure fuseki so it returns an SD graph from the
root of the endpoint when no query is present?
No currently.
The problem is that "GET /dataset" is normally mapped to an HTTP GET of
the dataset data. That's natural for HTTP.
It competes with providing service descriptions. They overlap in their
content types as well.
There could be a fuseki:operation fuseki:ServiceDescription - and it
can be Content-type sensitive - that would add the fucntionality and the
system provide either "GET dataset" (GSP-R supports quads) xor service
description.
Andy
Thanks,
--Paul
[1] https://www.w3.org/TR/sparql11-service-description/
[2] https://www.w3.org/TR/sparql11-protocol/
