The configuration file states which models this server is hosting, what their external URL should be, what operations can be performed on each model as well as defining some properties of the server itself.
The important concepts are
The configuration file is in RDF. This document walks through an example below, dsicussing each of the features. It has used N3 because it can give a more readable layout. The server determines the syntax of the configuration file based on the file extension: .n3 for N3, .nt for N-TRIPLES, and RDF/XML for anything else. See also Notation3 specification.
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> . @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> . @prefix joseki: <http://joseki.org/2002/12/configuration#> . <> rdfs:comment "Server configuration and data source mapping".
Some initial declaration of namespaces and a comment about this file. The namespace for terms defined is http://joseki.org/2002/12/configuration.
## Server configuration
<> rdf:type joseki:JosekiServer ;
joseki:josekiSchema joseki: ;
joseki:alsoInclude <file:joseki-defs.n3> ;
joseki:useContentType "application/n3" ;
.
The description of the server itself – <> is "this" document. The server configuration
is a resource with type joseki:JosekiServer.
The joseki:alsoInclude property identifies another file of convenience
declarations; this is an import mechanism and the referenced RDf is also read
into the configuration model.
Having set up the server we attach the models to the server:
<http://server/model>
a joseki:AttachedModel ;
joseki:attachedModel <file:data.nt> ;
These statements identify the type ('a' is N3 shoirthand for rdf:type) and describe where the data for the model
should come from. In this case, it is a file which expected to be in
N-Triples syntax
(the file extension is .nt).
The URL for the model will depend on how and where the web server was run. The http://server/
is replaced by the root of the URLs for this web application or the host name for
a standalone server. Its like http://localhost/.
Next we define what query operations this model supports:
joseki:hasQueryOperation joseki:BindingGET ;
joseki:hasQueryOperation joseki:BindingRDQL ;
Each attached model has a number of query and other operation bindings. A query language binding defines the local name for the query language and the processor code to be used in processing queries in that language. We use the common definitions here for two query processors over HTTP GET, first plain GET which will return the whole model (just as if you had put the RDF file at this URL with a regular web server) and the second allows RDQL queries on the model.
Suppose we are running standalone on host josekihost port 2020. The URL for this model is http://josekihost:2020/model. An RDQL query might look like:
GET http://josekihost:2020/model?query=...&lang=RDQL HTTP/1.1
See the section on the protocol.
Next, we add some other operations: we allow queries to be done by HTTP POST (such as ones too large for a GET) and for clients to get details about this model using the "options" operation:
joseki:hasOperation joseki:BindingQueryModel ;
joseki:hasOperation joseki:BindingOptions ;
.
and there's a final '.' because that's the end of statements about this resource.
So the complete configuration for this model is:
<http://server/model>
a joseki:AttachedModel ;
joseki:attachedModel <file:data.nt> ;
joseki:hasQueryOperation joseki:BindingGET ;
joseki:hasQueryOperation joseki:BindingRDQL ;
joseki:hasOperation joseki:BindingQueryModel ;
joseki:hasOperation joseki:BindingOptions ;
.
A configuration does not have to use the standard terms in joseki-defs.n3. Here is an example of add a binding and a processor inline.
joseki:hasOperation
[ joseki:operationName "ping" ;
joseki:operation
[ a joseki:Operation ;
joseki:className
"org.joseki.server.processors.PingProcessor" ]
] ;