oslc / ldp-service-jena Goto Github PK

Handling of err vs. status code is not consistent. storage.js isn’t necessarily HTTP, so it might have error codes that don’t correspond to HTTP status codes.

On the other hand, since storage and HTTP are both essentially CRUD, the same status codes might be used for both. And other errors, say from parsing or serializing, can be statusCode 500. So be consistent, any err returned from a callback should be considered an HTTP status code.

Translate an OSLC query AST to the underlying database query, execute the query and return the results.

Perhaps the default interaction model should be LDPR, not null. Or perhaps RDFSource if the server is only dealing with LDP-RS RDF resources, which a Fuseki/Jena persistence implementation would. A server of course could have different routes for different data sources.

Should it be null unless its specified in a Link header?

Need to test loading resources in external files

Called ldp-service in https://github.com/OSLC/ldp-service-jena/blob/master/package.json#L2

LDP should not be aware of OSLC query capability syntax. ldp-service may however need to exposed some generic query capability to make OSLC query easier to implement on different storage.js implementations.

So that it is easy to include it in the project: https://docs.npmjs.com/getting-started/publishing-npm-packages

Alternatively all projects (starting with oslc-service) should properly reference it in the package.json: https://stackoverflow.com/a/10391718/464590

ldp-service-jena is currently a full implementation of ldp-service on Jena, using request to send SPARQL queries to Fuseki.

This needs to be refactored into a concrete implementation of ldp-service/storage.js so that express web apps can use ldp-service, and select ldp-service-jena as the underlying concrete db implementation for specific routes.

See ldp-service-mongodb as an example of such a refactoring.

Note that ldp-service-mongodb, ldp-service-jena, and ldp-service-fs are intended to be three different backend storage implementations for ldp-service. The idea was to use these three implementations to do some commonality/variability analysis in order to design ldp-service/storage.js as a good abstract implementation of ldp-service's required storage facilities that can be easily implemented on different DBMS technologies.

Probably the only thing that needs to be done is to remove the containment triples from the BasicContainer resource representation if the Prefer header is ldp:PreferMinimalContainer.

Also need to create an example of a BasicContainer, and do the testing of GET using the prefer header, and the POST methods for adding and removing members.