The annotations in the documents reference to elements in external, RDF-based documents. These can either be directly downloadable documents on the Web, or be managed by RDF repositories. This module ) makes RDF documents accessible via a well-defined HTTP interface. It builds on top of the Sesame Repository. This service can either store local, application-specific ontologies or global domain ontologies (it works either way, since its only requirement is an existing RDF-encoding like RDF/XML or Notation3). This service has no further capabilities (e.g. reasoning for discovery). The major extensions are:
- well-defined description of the interface: further documentation is below.
- support of custom action to select the relevant subset of concepts
- we believe we've understood REST (and support HTTP headers, use HTTP error codes, support the whole stack of HTTP operations, ...)
- consistent URLs: Each element within the ontology has a URL as identifier. During import, URIs are transformed into URLs pointing to the local service URL.
The interface will be fully compatible to the W3C recommendation Best Practice Recipes for Publishing RDF Vocabularies. The request URL determines the look of the result: if I request a concept with a given URL, I expect to retrieve a concept with the given URL as identifier (yes, sounds trivial). We support parameters (such as subject or version) encoded in the path (e.g. http:/.../rdf/subject/Geology/Marble) or in the query (e.g. http:/.../rdf/Marble?subject=Geology). The following examples show how to access core (assuming that core is accessible through this URL).
(1) http://purl.org/net/concepts/rdf/subject/Geology/Marble (2) http://purl.org/net/concepts/rdf/Marble_(Geology) (3) http://purl.org/net/concepts/rdf/Marble?subject=geology (4) http://purl.org/net/concepts/rdf/concept?title=Marble&subject=geology (5) http://purl.org/net/concepts/rdf/subject/transportation/ (6) http://purl.org/net/concepts/rdf/all?subject=transportation (7) http://purl.org/net/concepts/rdf/neighbors?subject=transportation
How to start developing …
First of all you have to know a bit about Wicket. It consists in a WebApplication which is the ApplicationCore class in our case. From there, several Pages can be defined. We have one main page that catches all requests below /rdf/. Have a look at the different WebPage subclasses. If you wonder how magically some of the member variables are filled in, then you need to understand Guice, the dependency injection framework. The third important part is Sesame, the RDF database. Don't be scared about the complexity of the ApplicationCore class, we just can't use the wicket default way in some cases so we had to overwrite a few methods.
Building custom query/update actions
- Application core stable
- GUICE (dependency injection)
- base URL definition in the servlet parameters
- GET html works
- would be nice to make concept's clickable (so you can jump from service to service in future)
- GET rdf unclear, see #19, the problem is still how to properly write out the RDF.
- GET ?neighbor planning
- SPARQL query
- GET ?all planning
- SPARQL query
- GET ?related planning
- SPARQL query
- PUT/POST planning
- The supplied RDF document has to be parsed, checked if it is N3 / XML the base-namespace has to be changed and the file must finally be added to the repository