Perform RDF Merge for POST to existing LDP-RS

[kjetilk]

The way I have previously implemented a POST operation on an existing LDP RDF Source is to perform an RDF Merge between the existing resource and the payload body.

I could have bet I read that in a spec at some point, but I can't find it, and it doesn't seem to be implemented? Intuitively, I think it makes sense, and is a very simple operation.

[melvincarvalho]

Do you have a use case?

Isnt that covered by PATCH with and INSERT the body. As RDF is a set, the dups would be removed.

questions

• What do you return when something cant be merged (like form encoded POSTs)
• What happens when you post an empty body?
• Does it trigger the websocket?

[kjetilk]

Do you have a use case?

The simple case of just adding a few triples to a resource. Like in solid-yo.

Isnt that covered by PATCH with and INSERT the body. As RDF is a set, the dups would be removed.

It is covered by the PATCH, but at the cost of writing SPARQL and firing up a SPARQL engine. It seems overkill and bad DevX to require that for just adding a triple.

You could have servers that don't wish to support PATCH because of SPARQL, but they could support POST and the RDF Merge algorithm. An example of this is a microcontroller, you can't have SPARQL on 64 kB RAM. :-)

Just adding a few triples is the actual thing you would do, tying it to the RDF Merge definition is just for ensuring that it is rigorously defined for the blank node-induced corner cases. :-)

questions

* What do you return when something cant be merged (like form encoded POSTs)

It works if all payloads are RDF, the details need to be worked out if that is not the case, I would think a 400 would be the right response.

* What happens when you post an empty body?

Nothing.

* Does it trigger the websocket?

Dunno :-)

[melvincarvalho]

You could have servers that don't wish to support PATCH because of SPARQL

Not in solid you cant, it's part of the spec. See

https://github.com/solid/solid-spec/blob/master/api-rest.md#alternative-using-sparql-1

Is the proposal to remove this from the spec?

[kjetilk]

Yeah, I know, and no, I don't want to remove it. I'm just saying that POST to do RDF Merge is a "90% solution" that would simplify DevX, and could accomodate for those that cannot do a full implementation.

[melvincarvalho]

We dont run a full SPARQL engine, we just strip out the initial INSERT. Maybe that has lead to some confusion.

My initial concerns

• There doesnt seem to be a use case articulated yet (which is not a show stopper)
• We can do this already in solid

I think this proposal, probably belongs in LDP next?

[kjetilk]

Perhaps it should go in LDP Next, but I think the question, in the interest of DevX, needs to be reversed: What is the use case for using SPARQL, if RDF Merge can do the job?

Ah, BTW, found something, there is something about this in the RDF Graph Store. Lots of stuff in SPARQL is defined in terms of RDF merges.

To answer my own question, PATCH is used to do actual edits, i.e. both deletes and inserts, and we want to be able to extend what the PATCH method can do, right? But still, I think it is important of how the simplest operations are perceived by devs.

[melvincarvalho]

What is the use case for using SPARQL, if RDF Merge can do the job?

Delete?

We are open to extending patch in future, but right now it's just simple insert and delete (I think!).

As long as I can remember POST is up to the implementer to decide what to do with. We only define POST for LDPC's.

What about improving the devx be part of an easy to use library?

What would it do?

• add the INSERT {} around the payload
• set the content type to application/sparql-update
• set the VERB to PATCH

A better route?

[kjetilk]

Yeah, I made that edit about delete right there before your comment. Obviously :-)

Libraries are fine. We can do it in libraries, I just don't see why you would want the extra complexity for something this simple. INSERT DATA {} is doing an RDF merge behind the scenes, it is just extra complexity. That extra complexity needs to be justified. Obviously it can be justified, I just don't see why you should have everyone deal with the extra complexity.

[melvincarvalho]

I've added the tag enhancement to this. Because it's not really an issue in the spec, it's a feature request.

So, I think the next step is to turn this into a proposal.

What strikes me is that the proposal covers half or PATCH (insert and not delete) and is inferior due to lack of extensibility.

All solid servers can do this already, and this is not wanted outside of solid servers. So no new functionality.

It seems the main justification is some syntactic sugar around INSERT DATA {} which comes at the cost of possibly even confusing developers with two ways to do something.

There doesnt seem to be a use case behind it, right now, so I'm not optimistic for this propsoal's chances. Interesting food for thought, tho!

[kjetilk]

It seems the main justification is some syntactic sugar around INSERT DATA {} which comes at the cost of possibly even confusing developers with two ways to do something.

No, no, it is the reverse! INSERT DATA {} is syntactic sugar around this! Just read the SPARQL spec, it is even defined that way. Now, Solid's use of SPARQL isn't compliant with the SPARQL spec, but if it was, it would have to implement RDF merge to implement INSERT DATA {}, and then, implementing the POST as suggested would be 2 lines of code, whereas implementing INSERT DATA {} would use that code after stripping the SPARQL from the RDF, which would require some extra work (not a lot, admittedly)

Simple things should be easy, that should be the main guiding principle. Devs are familiar with the idea that POST adds stuff, PUT replaces it, DELETE deletes it. That intuition should take them 78% of the way. At least :-)

Then, they could move to the next level, where editing requires rudimentary understanding of SPARQL. Some devs my become scared at that point, and not be willing to go there, but those that do might be motivated if they had already been able to do stuff with simple HTTP operations.

[kjetilk]

One may add, the stuff between the {} in INSERT DATA {} are the exact triples that you would just POST, which also illustrates that INSERT DATA {} is extra complexity, and only extra complexity, if your goal is to add triples.

[melvincarvalho]

Got it! It's certainly interesting.

Some Meta Comments

So, we need a process to manage such proposals, and I suggest we chat about that out of band.

Typically with early specs, you can change them, but as solid is maturing now, we need to be more cautious, and create more of a process.

Fast track changes such as typos or the wrong path.

Proposals with wider implications, such as changing the sense of an HTTP verb (like this one).

With some gray areas in between.

I think we can loosely base it on W3C / IETF work flows such as raising issues, and then then ensuring commenters are satisfied.

I find the following doc great guidance in this respect, in case you may not have seen it

https://tools.ietf.org/html/rfc7282

ends meta

[acoburn]

One concern I would have about this is that, with this proposal, POST on an LDP-C would create a new resource while POST on an LDP-RS would update the target resource. Given that an LDP-C is a specialized type of LDP-RS, it would require clients to first check the resource type before issuing a POST. It also makes the semantics of POST inconsistent across different resource types.

What about LDPatch? This is a much lighter-weight "update" mechanism than SPARQL-Update, and it can be used with PATCH operations. The LDP-RS would advertise support for this via: Accept-Patch: text/ldpatch.

[kjetilk]

Given that an LDP-C is a specialized type of LDP-RS, it would require clients to first check the resource type before issuing a POST. It also makes the semantics of POST inconsistent across different resource types.

Right. Then, I suppose you are right, this is not something that is easily doable with LDP.

But you know, you gave me a good argument to say that my hypermedia-approach to this problem is better, because it tells the client what it can do as a part of the metadata of the resource. Now, Tim didn't like the idea of mixing in metadata, and I can see that point, but it reinforces my skepticism towards LDP, it requires too much up-front, unintuitive, out-of-band knowledge.

Anyway, now we have LDP as the foundation, and we need to see where it takes us for now. So, just leave it here as a proposal.