-
Notifications
You must be signed in to change notification settings - Fork 15
Description
The code currently skips blank nodes when deleting including when the blank nodes have received a UUID.
Hmm... After reading various specs and #8 this is more complicated than I thought.
It seems that the default behavior should be that blank nodes are not persistent or portable in other words blank node identifiers are understood to denote a fresh blank node (as described for LD Patch), so following the PATCH DELETE operation (without the possibility to BIND), then the default should be to NOT be able to delete blank nodes.
In that sense the previous levelgraph-jsonld's del function acted more like the LD Patch CUT operation which can delete a whole tree made of blank nodes.
So this means that my original intuition that after assigning a blank node identifier, then you should be able to refer to that identifier is not how blank nodes should be handled in the general case, however there is a provision for handling blank nodes in that way which is skolemization which assigns a unique IRI to a blank node, which then makes it persistent and portable, and can also allow to differentiate IRIs that have been generated for a blank nodes to allow other systems to treat them as such (all of which is an optional part of the spec).
So what I propose is as follow:
- Rename the previous
delfunction which has thedelAllTriplesrecursive blank node deletion, as a newcutoperation (and maybe also have acutoption available for del). - Change the default behavior of
delto not delete blank nodes at all. (maybe except when store scope identifiers are provided, see below). - Introduce a new
skolemizeoption toputwhich would generate IRIs for blank nodes with the recommended path/.well-known/genid/(not sure how that works with no@base). - Introduce
skolemizeandunskolemizefunctions which would take a document (implying a selection of triples, see below comment aboutframe) and persist blank nodes to skolem IRIs, and respectively revert skolem IRIs to blank nodes.
This might mean exposing frame in get and elsewhere (which touches on #2) to help specify the right part of the document that needs to be handled. More long term, this work might benefit from being seen as part as a lower-level API for an LDP implementation (which touches levelgraph/levelgraph#111).
The remaining case is for rdf store scope blank node identifiers which are close to what we have now (i.e. blank nodes are assigned a uuid - _:abcd... which is returned in the callback of put). Then it seems that:
- When a document is passed to
delwithout@idfor its blank nodes then they are treated as blank and not deleted. - When a document is passed to
delin the shape returned fromput(i.e. with store scope blank node identifiers) then they should be deleted (this seems to me like a intuitive - ? - default which most people would expect), with an option toignore_blanks(where it would treat store blanks as abstract blanks and ignore them). That's the main bit where I feel this might be twisting the meaning of the spec.
This behavior would mean that we need to distinguish blanks from assigned store scope blanks, is that what the prefix _:c14n is for?