Status of Neil's work

Neil Davis made significant contributions to oslc-service as an IBM co-op during the summer of 2016. This is a summary of where he left of and some ideas on next steps.

OSLC Service

In Neil’s implementation, oslc-service is not delegating to a subApp for ldp-service. Rather he is instantiating a particular implementation of ldpService, and using its ldpService.db.* operations to do the database operations directly in oslc-service.

A typical oslc-service request implementation would look something like this:

1. examine the request headers
2. Use if-then-else statements to examine the request URI and headers for OSLC specific capabilities
3. Handle each capability by using an asynchronous call to ldpService.db.get to get the resource and process the request implementation in the callback function
4. call next() only on the last else, sending the request to ldp-service if there was nothing else to do for OSLC.

These OSLC cases should probably have all been done with different URI routing to direct the request to a function that directly implements the OSLC capability, similar to how the Toolchain Modeler and code generator creates different URIs for the JAX-RS HTTP method annotations. But this would only eliminate the coupling in the if-then-else statements, it wouldn’t eliminate the need to actually get the resource in order to process the OSLC request.

Neil did this for some requests such as subApp.get ('/properties')

Needs to be checked or implemented:

1. Initialization, needs to take into account external files
2. TrackedResourceSet not implemented
3. QueryCapability is implemented, but not finished for nested properties (e.g. oslc.select=name{firstName, lastName}) or oslc.selectTerms
4. Takes the OSLC query and puts it into an AST. The AST is sent over to the db.js file in LDP Service which navigates the tree and converts it into its own version of the query
5. Has not checked if properties listed in the query matches the ResourceShape
6. Has not checked if syntax is valid, just fails if the query is invalid
7. CreationFactory implemented, need to look at if POST is working now (doesn't go to the LDP layer from the OSLC layer)
8. if database is running with the services but a server reruns, how to populate the dictionaries of ResourceShapes with QueryCapability and CreationFactory
9. Link headers are implemented. Need to fix creating a header for the compact resource
10. UI Preview has code written, but it is unfinished, and not tested
11. Delegated dialogs have code written, but it is unfinished, not completely tested
12. Paths to routes "/properties" and "/all" used for creationDialog and selectionDialog, respectively. The former is used to get the properties of a Resource Shape in order for the user to create the respective resource. The latter gets all resources in the database for the user to select. The selectionDialog has a search feature to filter out those resources.
13. Test code from Sam Padgett, hadn't looked at yet

Implementation Notes:

1. changed "mongoURL" to just "URL" in configuration file. Added in a resources variable as a prepend for POSTed resources
2. in "vocab" folder, I added in an "oslc" to access URI's in the same way as rdf and ldp
3. QueryCapability is executed when the code detects a '?' in the uri after it checks if '?compact' is not in the uri. It executes the method queryResource after getting the correct resourceShape. it then assembles the AST while parsing the query. For every property, it checks if that is a property of the ResourceShape in validResource (function implemented, execution in queryResource commented out). The code does not check for '{' or '}' for nested properties; I could not think of a valid way to assemble the tree with that syntax
4. CreationFactory is executed when a POST method occurs. It executes the method check, then preProcessValidShape, then validShape. validShape loops through the shape and the resource to check that the properties are good. PUT also implements these methods, but because it can do a PUT method on a resource itself I had not thought about how to get the ResourceShape associated with the resource
5. when the database and server are initiated for the first time, oslc-service checks if the root service is present in the database. if not, it recursively looks through a defaultServices file in JSON-LD (method is called findBlankNodes). It creates a new resource for every service, translates it to JSON-LD, and inserts it into the database. It also assembles a local dictionary to find the resourceShapes and other properties of certain services. The service, however, cannot assemble that dictionary if it its initiated for the first time and database is already populated. It also hasn't been tested to see if it can load services from files that the defaultServices refers to externally (e.g. "ex:otherServices")

Additional Notes:

• The implementation use to do direct SPARQL queries, but instead uses an AST for OSLC query.
• It does not use rdflib.js for processing RDF resources.
• Includes ResourceShape validation implementation.
• Validation is done on POST, but not PUT

TODO:

• Convert the implementation to use rdflib.js for parsing and access to in-memory manipulation of RDF
• Diff with the OSLC3 rio implementation Sam and Steve did in Java to verify the approach and see what else needs to be done

LDP Service

1. db.js, make sure the exports.query code is fully functional. It navigates the provided AST. It assumes knowledge of OSLC Query syntax, so please edit as needed