Status of Neil's work - OSLC/ldp-service GitHub Wiki

Neil Davis did a lot of work on ldp-service in the summer of 2016 as an IBM co-op. Here's the status of his work, and some direction on what might be done next to complete ldp-service.

ldp-service

ldp-service is still uses the original MongoDB implementation. We need to develop an abstract implementation of the storage services required by ldp-service with a concrete implementation on:

• the file system - ldp-service-fs
• MongoDB - ldp-service
• Jena - ldp-service-jena

ldp-service-fs

A simple file system storage of subject, predicate, object, no N-Triples was developed to demonstrate a minimal approach to persistence. This is not (yet) and instantiation of an abstract LSP storage services module.

• The implementation does not use rdflib.js.
• Using an internal tripel representation and this is used to create a dictionary to access the content in the code in ldp-service-fs. Not n-triples or any other standard RDF representation.
• Tested with ldp-app

ldp-service-jena

• Uses Jena to read and write the resources
• uses request to make REST services calls to Jena
• Does not use the Jena API to access the RDF results, converts to the original MongoDB triple representation and uses that internally.

TODO:

[ ] Update to the latest rdflib.js and ensure the parse type XML-LITERAL is working correctly [ ] Abstract out the LDP storage services into an abstract implementation [ ] Then re-implement the three instantiations above using this abstract implementation [ ] Convert all the implementation to use rdflib.js as the internal representation of RDF for a richer way to access the RDF in memory

Update to the latest rdflib.js

rdflib.js did not handle parseType=‘XMLLiteral’ properly. It currently sets the property to the DOM for the whole property (not just its content). It should set the property to the XML text in the property content, parsed and normalized (attributes sorted).

See: RDF/XML Literals not being parsed properly, this issue appears to be still opened but may have been fixed. Needs to be verified and possibly re-implemented.

Abstract out the LDP storage services into an abstract implementation

Re-implement the three instantiations above using this abstract implementation

Convert all the implementation to use rdflib.js as the internal representation of RDF

Reorganizing the GitHub repositories.

The GitHub OSLC organization provides a container and team management for all the OSLC4JS GitHub repositories. The issue is how the different components of OSLC4JS should be organized.

Ideally there would be a different GitHub repository for each logically independent deliverable. But for LDP, that results in a lot of repositories and a bit of fragmentation:

• ldp-app - the sample LDP application
• ldp-service - the Express middleware LDP service
• ldp-storage-jena - LDP storage services using Jena
• ldp-storage-fs - LDP storage services using the local file system
• ldp-storage-mongodb - LDP storage services using MongoDB (the original implementation)

Issues that could result from too many closely related repositories

1. fragmented documentation, too many places to look for relevant documentation
2. possible redundancy across the wikies for crosscutting concerns
3. No clear place to put documentation for LDP as a whole
4. Too many places to look for LDP issues
5. No clear place to put issues for LDP as a whole

npm can publish any folder that contains a package.json file as an npm module. Often there would be a separate GitHub repository for each module that is intended to be at least somewhat independently evolve and be reused. However, npm publish can use .gitignore or .npmighore.

npm uses the git information in the pacakge.json file to provide the git URI on the published site.

So a Git repository per npm module makes pretty good sense.

The organization on your local disk can be facilitated by using a folder such as LDP as the place you clone all the LDP related repositories. Any git or GitHub repository can simply be moved into a different director on your machine without impacting the origin repository. GitHub desktop will not be able to find the repository after it is moved. ON Windows, simply click on the blue circle with the !, select Find It and then browse to the new directory. MacOS GitHub desktop seemed to automatically deal with the move.

In the context of OSLC4JS, LDP general issues can be centralized in ldp-service. The other repositories can be used for issues specific to those packages.