atomgraph / core Goto Github PK

Generic Linked Data framework for SPARQL tripestore backends. Apache license.

License: Apache License 2.0

Java 99.98% Shell 0.02%

rdf linked-data sparql jax-rs server apache-jena generic framework

core's Introduction

Core is a Linked Data framework. It crosses Apache Jena RDF API with the JAX-RS REST API (Eclipse Jersey implementation), providing in a uniform Linked Data API.

Core serves as a base for AtomGraph Processor. It is implemented as a Java Web application (uses Maven).

Features

AtomGraph Core server provides features similar to that of Pubby:

serving Linked Data from a SPARQL endpoint
HTTP Basic authentication for endpoints

For more advanced features and configuration, see AtomGraph Processor.

Configuration

The Core is configured in web.xml

Uncomment http://www.w3.org/ns/sparql-service-description#endpoint and https://w3id.org/atomgraph/core#graphStore init parameters and provide their values. Otherwise the server will not start.

Linked Data API

low-level access to remote Linked Data resources and SPARQL endpoints
JAX-RS interfaces and implementations of a Linked Data resources
JAX-RS providers for input and output of RDF data

Documentation

JavaDoc

Dependencies

core's People

Contributors

Stargazers

Watchers

Forkers

bsletten sgopalan vimalktv imclab anukat2015 aahmadai

core's Issues

pom.xml missing

It seems pom.xml is in the .gitignore file, and has not been checked in. This makes it difficult for others to build the source code.

ResourceXSLTWriter is not generic

Cannot use ResourceXSLTWriter with LinkedDataResource subclasses.

Probably need to refactor into MessageBodyWriter<Object>.

Read authentication config per request

SPARQL endpoint Context should be set per request (in Resource constructor) instead of Application initialization as it is now.

configureServiceContext() can be reused:
https://github.com/Graphity/graphity-ldp/blob/master/src/main/java/org/graphity/server/ApplicationBase.java#L126

Use Jersey Client API for HTTP I/O

Right now the RDF and SPARQL access over HTTP is handled by DataManager which extends Jena's FileManager. A nicer design would be to use Jersey's Client API with @Providers, as the Graphity Client currently does: https://jersey.java.net/documentation/1.18/client-api.html

CSV/TSV output for ResultSet

SPARQL 1.1 Protocol specifies CSV/TSV output formats for SELECT results:
https://www.w3.org/TR/2013/REC-sparql11-results-csv-tsv-20130321/

However, ResultSetProvider currently only supports XML and JSON:
https://github.com/AtomGraph/Core/blob/master/src/main/java/com/atomgraph/core/io/ResultSetProvider.java#L72

Multivalued Link headers

Multivalued Link headers cannot be parsed by the Link::valueOf method.

Accept header based on Jena-supported formats

Instead of hand-crafted list, generate the Accept header value according to the list of RDF readers/parsers the current Jena dependecy supports.
There will still be a need to qualify (prioritize) the media types.

g:LabelMode

Templates for labels needed as g:label() function is too inflexible (templates are easier to override)

Streaming RDF/POST parser

Right now the RDF/POST parser is implemented in the Client as MessageBodyReader<Model> and reads String. Instead, make it streaming (read InputStream) and plug it into Jena as described in Reading RDF in Apache Jena: Add a new language.

g:label() function compatible with blank nodes

Create a version of g:label() that can handle @rdf:nodeID or string

Upgrade Jena

We could upgrade Jena to 3.8.0 because that is what SPINRDF is at:
spinrdf/spinrdf#17

Refactor Resource.xsl into LinkedDataResource.xsl and QueriedResource.xsl

Separate the templates into 2 layers and split ResourceXSLTWriter provider accordingly

Response EntityTag should depend on Variant

Right now the EntityTag is generated as a hash of the RDF response Model, which means all serializations, including XHTML, get the same value. This leads to caching issues (wrong response body returned on 304 Not Modified. The solution is to add Variant hash to the Model hash.

RDF/POST writer

Now the core contains a streaming Jena-compatible RDFPostReader, but the writer implementation is missing. It would effectively make RDF/POST another Jena-supported RDF serialization, with media type application/rdf+x-www-form-urlencoded and file extension .rpo.

Incomplete support of RDF/POST

Update RDFPostReader to support typed and multilingual literals (lt and ll)

Configuration for pre-emptive authentication

web.xml should support a configuration property like gs:preemptiveAuth which would trigger pre-emptive authentication in Jena (sending credentials without being challenged first).

http://jena.staging.apache.org/documentation/query/http-auth.html

Enable JSON-LD and TriX again

TriX is ignored because of this bug: https://issues.apache.org/jira/browse/JENA-1211
JSON-LD is also ignored because the reader attempts to make HTTP calls: https://mail-archives.apache.org/mod_mbox/jena-users/201712.mbox/%3CCAE35VmyGk-biQ1Fayp3zoOyiMikZhvjA8dTuGEd3JaYR98uYOA@mail.gmail.com%3E

g:query-string() with #fragment

Create a version of XSLT g:query-string() function that takes fragment identifier as a parameter

Javadoc 404

The link http://atomgraph.github.io/atomgraph-core/apidocs/ is not working

Create g:uri() XSLT function

Create a generic function returning URIs for all types of nodes: attributes (subjects/objects) and elements (predicates).
Mostly to avoid code like this: concat(namespace-uri(.), local-name(.))

Origin subclasses unnecessary

Origin subclasses SPARQLEndpointOrigin and GraphStoreOrigin differ only in configuration properties (sd:endpoint and g:graphStore). If it would be possible to indicate the property in providers (something like @Context(SD.endpoint) Origin origin), then the subclasses could be removed and Origin reused both for SPARQL endpoints and Graph Stores.

Test suite

Create JUnit tests starting with core classes such as DataManager.
Full test coverage is the ultimate goal.