This is a documentation of Corese Semantic Web Server. Corese can run inside an HTTP Web server (currently Jetty) and can be accessed by means of HTTP requests. There are two main functionalities. 1) SPARQL endpoint that responds to SPARQL Query and Update according to SPARQL Protocol. 2) Semantic workflow engine that return dynamic HTML pages generated from an RDF Dataset by means of SPARQL query and STTL transformation.
This document uses prefix and namespaces.
prefix st: <http://ns.inria.fr/sparql-template/> prefix sw: <http://ns.inria.fr/sparql-workflow/>
Corese can run as a SPARQL endpoint accessible at a URL.
http://corese.inria.fr/sparql?query=select * where {?x ?p ?y}
A Workflow defines a sequence of Semantic Web processes such as: Load, Query, Update, RuleBase, Transformation. It may return HTML pages and hence can be used to define a dynamic Web server on top of an RDF triple store. A workflow is associated to an URL and is defined in a profile.ttl RDF document associated to the Web server. There are two concepts for defining workflows in profile.ttl: Server and Profile.
Server defines a TripleStore with a name and defines its RDF content with a Load Workflow.
Corese Web server is able to manage and access several triple stores.
Several stores may share the same content (the same RDF graph, not a copy).
Profile defines a Workflow to be executed on a specific store in response to an HTTP request, e.g. query + transformation.
Profile "pname" is triggered (on the sparql endpoint default store) using /template?profile=pname
Server "name" is triggered using /tutorial/name
It is possible to combine a server and a profile: /tutorial/name?profile=pname
Corese server manages a predefined profile.ttl with demos. It is possible to define a user profile.ttl with custom applications. It is loaded with the option shown below.
java -jar corese-server.jar -pp "/home/user/demo/myprofile.ttl"
A profile is triggered on Corese server using an URL following the scheme shown below.
http://corese.inria.fr/srv/template?profile=st:dbpedia
A profile is defined in the profile.ttl as shown below.
The URI of the profile resource (st:dbpedia) is the name by which the profile is identified.
Slot st:workflow is the URI (or blank node) of the Workflow that realizes the profile service.
st:dbpedia a st:Profile ; st:workflow st:dbpediawf .
Slot sw:body is the list of workflow actions. The URIs are relative to the profile.ttl document location.
st:dbpediawf a sw:Workflow ;
sw:body (
<query/frdbpedia.rq>
<query/frdbpediaclean.rq>
[ a sw:Transformation ; sw:uri st:navlab ]
)
.
A server (triple store) is triggered on Corese server using an URL following the scheme shown below.
http://corese.inria.fr/srv/tutorial/rdf
A server is defined in the profile.ttl as shown below.
Slot st:service is a string that defines the name of the server (here rdf) that is used in the URL to access it.
Slot st:content defines a Workflow that specifies the RDF Dataset to be loaded into the triple store.
st:tutorial a st:Server ; st:service "rdf" ; st:content st:tutocontent ; .
Slot st:shareContent : several servers can share same content (same RDF graph, not a copy) by both using st:shareContent.
st:s1 a st:Server ; st:shareContent st:tutocontent . st:s2 a st:Server ; st:shareContent st:tutocontent .
The RDF content of a server is defined using a Workflow
st:tutocontent a sw:Workflow ; sw:body (
[ a sw:Load ; sw:path <tutorial/workflow.ttl> ; sw:name st:context ]
st:indexQuery
).
st:indexQuery a sw:Query ;
sw:body
"insert { ?q st:index ?n } where { ?q a sw:Query bind (kg:number() as ?n) }"
A server may have a default profile that is executed when accessing the server.
Slot st:workflow defines the default profile workflow that is executed when accessing the server by means of an URL without argument profile=pname.
st:tutorial a st:Server ;
st:service "rdf" ;
st:content st:tutocontent ;
st:workflow [ a sw:Workflow ;
sw:body ( [ a sw:Transformation ; sw:uri st:sparql ] )
]
.
Some HTTP request URL parameters play a specific role.
http://corese.inria.fr/srv/tutorial/rdf?uri=http://example.org/John&profile=st:sparqlThe uri parameter enables to specify the URI of an RDF resource that is the focus of the current request.
The URL parameters are passed to the Workflow and are accessible in SPARQL and STTL using the st:get function. For example, the profile parameter is accessed by means of st:get(st:profile) and the uri parameter by st:get(st:uri). Hence an STTL transformation can focus on a specific RDF resource by means of st:get(st:uri).
It is possible to define additional parameters and parameter values in profile.ttl, that are passed to Workflow. Parameters are defined using the st:param property. They are accessible in SPARQL and STTL using st:get(name) where name is the URI of the parameter, e.g. st:get(st:mode) = st:test in the example below. Hence it is possible to parameterize the behaviour of a workflow with parameters defined in profile.ttl.
st:test a st:Profile ;
st:param [
st:mode st:test ;
st:debug true
] ;
st:workflow st:aWorkflow .
It is possible to share and import parameters using the st:import slot in the st:param slot.
st:param [
st:import st:mapParam ;
] ;
st:mapParam
st:param [
st:mapzoom 6 ;
st:mapsize "mapmedium" ;
st:mapicon1 "/img/bmarker.png" ;
st:mapicon2 "/img/smarker.png"
] .
The st:export true statement in st:param specifies that parameters are exported to nested transformations, that is transformations that are called from a transformation. Default behaviour is that parameters are not exported to sub transformations.
st:param [
st:export true
]
An STTL transformation can be used to generate HTML pages according to the RDF Dataset content and the focus URI. It is usually the case that the generated HTML pages contain hypertext links to related RDF resources. In this context, function st:plink(URI) generates an URL such that, when dereferenced, the URL triggers the appropriate server and profile to process the URI. The function can be used to generate hypertext link without hardcoding the server and profile names that are retrieved from the context of the execution. For example, if current server is sname and current profile is pname, function st:plink(URI) generates the relative URL shown below.
/tutorial/sname?uri=URI&profile=pname
It is possible to specify a specific profile: st:plink(URI, st:display) generates URL shown below.
/tutorial/sname?uri=URI&profile=st:display
In profile definition, slot st:include defines additional argument to be included in URL generated by st:plink(URI), e.g. value of parameter st:mode. Hence, same transformation can be used with several modes (e.g. test, debug, std).
st:param [
st:include (("mode" st:mode)) ;
st:mode st:test
]
With definition above, the URL below is generated by st:plink(URI).
/tutorial/sname?uri=URI&profile=pname&mode=st:test
Slot st:lodprofile : associate namespaces to profiles. When URI matches namespace, st:plink generates associated profile. In example shown below, URI matches example.org, hence profile=st:sparql
st:param [
st:lodprofile (
( <http://fr.dbpedia.org/resource> st:dbsparql )
( <http://example.org/resource/> st:sparql )
( "*" st:sparql )
);
]
/tutorial/sname?uri=http://example.org/resource/rname&profile=st:sparql
Function st:getprofile(URI) returns the profile associated to URI by st:lodprofile. Hence it is possible so specifiy a neutral profile in st:lodprofile, say st:lod, such that when st:getprofile(URI) = st:lod, the user generates a hyperlink to URI directly instead of using st:plink.