Server.js
Server.js copied to clipboard
LinkedDataFragments
Allow to PUT fragments in MemoryDatasource
I foresee these changes:
- Allow PUT in LinkedDataFragmentsServer.js#L57
- Add controller that responds to PUT
- Loop over parsed request data and call
this._datasources[query.datasource].datasource.addTriple
Do you think I will encounter other obstacles?
Looks good, but:
- What will the
HTTPinterface look like? I.e., to what resource do youPUT? - Be sure to provide an
addTriplestub in the generic Datasource (which should throw an exception) - Be sure to only loop over data that is in the default graph (if a quad representation is received)
I implemented something similar in the past with in a hackish way by adding POST over here: https://github.com/LinkedDataFragments/Server.js/blob/master/lib/LinkedDataFragmentsServer.js#L49 and just writing the triples to a file, which then can be read by a datasource. Mind that in this case POST makes more sense than PUT as the request is not idempotent: you "add" triples to the existing collection of triples.
I also implemented this a while ago (in a less hackish way ;-) ) I pushed it to the feature-insert branch, it starts from 6ca4aca2678c08fb549724e3905a554214750728. The branch is a bit behind on the master, so there might be some minor conflicts.
Take into account that this currently has no authentication checks, this means that everyone will be able to insert data using a POST.
@pietercolpaert Since the repeated addition of the same triples results in the same as having them one time, I'd argue that it is idempotent (blank nodes aside). However, PUT is a replacement operation, not an addition, so that would be the main problem.
I'd a argue that it isn't idempotent as each POST triggers a new context. E.g., if I have a sensor that sends out the temperature, I can POST the temperature each second. There will be a lot of the same triples yet each second the time context has changed and it is relevant to store this POST action of adding triples under a new id chosen by the server.
But on topic: I think that having a strategy to POST triples should also contain the cross cutting concern of authentication and maybe even authorisation. Any idea of existing npm libs for this?
Idempotence depends on server implementation; if it is just inserts in a triple store (as I assumed), it is idempotent (blank nodes aside). Other implementations might do other things, such as attaching a timestamp, which make the operation non-idempotent.
Authentication: regardless of libs, we should first decide on HTTP level what happens.
I suggest PUT /mygraph?subject=http://... which would
- Delete triples from
mygraphthat match the query - Add input triples to
mygraph(or only those that match the query?)
POST /mygraph should probably also be available.
@thgh Both options are good. Open question: what about POST to more specific fragments?
Also, how will we deal with blank nodes (especially regarding deletion and addition)? I think skolemization is the way to go.
@rubensworks yes, it would. Although no authorization layer has been implemented yet.
Not yet, still focusing on read. For read/write solutions, you might be interested in Solid, and the TPF solution I built on top of it.