oslc / ldp-service Goto Github PK

When creating a new LDPC member, the new member in the POST entity request body might be an LDPC. The entity request body could include all the information needed to specify the interaction model, but the user could override the interaction model details using a Link header.

If this is optional, then it might not be worth implementing. The reason is that it's probably a better practice to have the resource explicitly define the interaction model instead of putting that information in HTTP headers. This is temporary information that represents significant control coupling and may not be a good practice.

ldp-service/storage.js defines abstract storage services it needs. storage.js exports a set of functions that ldp-service/service.js expects.

ldp-service-jena/storage.js is an example of a concrete implementation of ldp-service/storage.js

An app such as ldp-app (or oslc-server) needs to be able to instantiate one or more ldp-services on its desired storage implementations.

The question is: how should ldp-service/storage.js be instantiated by for example ldp-service-jena/storage.js, which replaces the abstract methods with concrete implementations?

ldp-service/service.js mostly supports DirectContainers with isMemberOfRelation, but needs to be checked and tested.

GET on a resource with Accept=application/ld+json gives:

jsonld.ParseError: Error while parsing N-Quads; invalid quad.
at _parseNQuads (/Users/jamsden/Developer/LDP/ldp-service/node_modules/rdflib/node_modules/jsonld/js/jsonld.js:6964:13)
at /Users/jamsden/Developer/LDP/ldp-service/node_modules/rdflib/node_modules/jsonld/js/jsonld.js:881:17
at process._tickCallback (internal/process/next_tick.js:61:11)

The ldp-service database service should be configurable in terms of database specific URIs, admin authentication, root LDPC URIs, ports, etc. But the database service should also be completely optional for this situations where the ldp-service is just handling LDP headers and an adapter service is actually handling all the data read/write access.

See Persistence for motivation and background. ldp-service database access should be abstracted into an abstract layer, and then implemented using Fuseki2 with Apache Jena TDB providing persistence services. A SPARQL endpoint for the database should also be exposed in the API and made available to Web applications for routing configuration.

The MongoDB implementation should be maintained on a branch for possible future use.

An app or services such as oslc-service that uses ldp-service could:

1. Delegate whatever it can to ldp-service, especially the CRUD resource operations
2. Access storage services directly to implement some things such as Query Capability that are not part of LDP
3. Combine the two by having ldp-service refactor the implementations of its CRUD methods into reusable functions that it calls to implement its own express middleware, but that could also be called by other services like oslc-service that need similar capability, but have to make additional response modifications. The ldp-service middleware subApp methods would simply call the correspond functions, then do res.sent to complete the result.

There can be many ldp-service instantiations on different storage services used by the same oslc-server. Since oslc-service also depends on storage services (for resource preview, attachments, OSLC 2.0 discovery resources, OSLC query, selective properties), then it is oslc-service that will instantiate the storage services for a particular route, providing that implementation to the ldp-service it uses.

Although the LDP Paging specification is only a working draft note, it is likely to be approved as part of the LDP.next work and ldp-service would be a good place to support a prototype implementation.

The purpose of this method is to allow concrete storage service implementations to implement OSLC query if desired. The parsing of the OSLC query can be done by the oslc-service.

This might be a future activity to leverage graph databases and Gremlin for more scaleable server implementations.

ldp-service/service.js has only partial implementation of GET on BasicContainers. The Prefer header implementation needs to be completed. In particular, if includeContainment is false, the {document.url ldp:contains } triples would need to be removed from the BasicContainer on a GET request.

Also POST to add members to BasicContainers is only partially implemented and not yet tested.

The current ldp-service implementation it is hard-coded to instantiate its abstract storage.js using ldp-service-mongodb. This needs to be configured in the env, not hard-coded, or better, through a subApp so that different URLs can be directed at different DB implementations in the same server.