-
Notifications
You must be signed in to change notification settings - Fork 46
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Level of SPARQL Update support #125
Comments
Couple of quick points from my side:
None. As it stands, there is no notion of a SPARQL endpoint, in the sense of the SPARQL procotol (which would use Rather, we are using the patch format with its MIME type
Additional question: And what should happen when clients go outside of that subset?
No, not by default as the minimal interface, given that:
Other question:
|
Right, a flaw in my mental model. Thanks for pointing that out.
👍
Ah, but I think you misunderstood my point there. I'm not talking about HTTP verbs in relation to SPARQL Protocol, I'm talking about them in relation to Solid, like in the proposal to introduce HTTP Verb
Yeah, it is a pain. I would like to add some more sophistication in SPARQL at this point, but it would take quite an effort to argue for that, I think. Meanwhile, I would like to see the queries that are used, especially if the |
Since one of the most urgent decisions that we need from this is the minimal SPARQL Update requirement, I started to look into what could inform this decision. The TL;DR is: "Is it sufficient for a Solid server to support I'd like to hear the input of @RubenVerborgh and @rubensworks , as it can be informed by the LDFlex work. I also looked into rdflib, and found that it seems to look to see if a statement has a blank node, and therefore interpretes that as a quad pattern, and so uses a |
Currently, LDflex can also produce I do however think that it may be possible to disallow |
I don't think so; the semaphore functionality is important to many Solid apps. See #139 |
But isn't that orthogonal to the semaphore issue? I just saw you restarted discussion in solid/solid-spec#193 , I'll go over there. |
The current semaphore mechanism relies on |
I have made a loose proposal to the SPARQL 1.2 CG mailing list, which I think would address the semaphore problem as well as the confidentiality problem: I suggest that further discussion is held in a query-panel repository (solid/process#186) or in the SPARQL 1.2 CG as appropriate. |
Note: we might (or might not) want to move issues such as this one over there. |
Yeah, actually, my idea, which is codified in solid/process#182 is that this is exactly the kind of overarching issue that should live in the spec repo for the editors to track, and for the panel to report progress on, to move it along the editors project board, but the panel will create issues like "what permissions are required for different operations" will be opened in the panel repo board, and each of them isn't the editors task to track. |
A new Query Panel has been formed, and the issues from here have been detailed as individual issues there. There's also a gitter channel. Further detailed discussion should happen there. This will now serve as the birds-eye view issue that serves as a contact point between the Query Panel and the Editors. |
The Solid Editors Meeting today, with @timbl , @csarven and @kjetilk present resolved:
We didn't come to consensus on discovery, access control and #220 . The latter can be decided separately, access control is something we can decide in drafting phase and I would like to hear more experience on discovery. Thus, I advance this issue to rough consensus. |
I just touched that proposal page to fix the link to an HTML-ized RFC. Feel free to edit that proposal and the associated yacker. If you want to keep the orig grammar around for posterity, you can save the edited grammar under a new name. One way to decide whether to duplicate is whether someone somewhere would want to instantiate that proposal without |
Because it's important to keep things clear, ad wiki pages should always be considered moving targets, and future wiki edits might change the SPARQL UPDATE subset on that page... Subset page as resolved for adoption -- https://www.w3.org/2001/sw/wiki/index.php?title=SparqlPatch&oldid=4800 Today's tweaked page (which did not change the SPARQL UPDATE subset) -- https://www.w3.org/2001/sw/wiki/index.php?title=SparqlPatch&oldid=5335 |
This issue has been nominated for drafting phase for the next milestone. |
I have started work on the draft, and for the first iteration, I have attempted to produce a BNF, but yacker was down now, so I couldn't use that. Also, it is the first time I'm writing a BNF, and I have some confusion around the differences between the variations of BNF. I tried to stay close to SPARQL-patch, but made some changes and also introduced no less than 10 new rules to accommodate for
|
Where is TripleData defined? |
ooops, good catch, I'll update :-) |
The BNF itselfs looks correct to me at first glance. For reference, it does not cover quad support. Perhaps we want to await the resolution of #291 before this issue here is pushed forward? |
Great!
No, that is deliberate, this is what we need for defining 1.0. Quad support will need to be after 1.0. :-) |
One thing I came to think of was that it doesn't seem that @ericprud 's subset supports Any comment on that, @ericprud ? I wonder if we could/should support that by making a simple adjustment to |
One question that just arose, should we have more than one query in a single HTTP request? |
Just not yet, please 🙂 Another question from me: do we want a (sub-) MIME type or a profile for this? |
👍 Just wondered if that was in the wild :-)
I think that can be a post-0.9 question? |
Unfortunately it is, as I realized again in #322 (comment) NSS supports what rdflib.js supports; which seems to be a sequence of two queries |
Solid Editors decided in meeting https://github.com/solid/specification/blob/main/meetings/2021-11-03.md#level-of-sparql-update-support with @justinwb , @RubenVerborgh , @dmitrizagidulin , @csarven and @kjetilk present to define N3 Patch #332 for 0.9, and put the current SPARQL PATCH behaviour at risk, but to come back to it for 1.0. |
A certain level of SPARQL Update support is expected in Solid, to be used with the
PATCH
method (#85). This discussion has begun, and this issue is to discuss some details that we need to decide upon.The main questions are:
A short overview of SPARQL Update
SPARQL Update has three operations that are of relevance to us,
INSERT DATA
,DELETE DATA
, andINSERT
/DELETE
. SPARQL always operates over quads and quad patterns, whether they are quads that are passed directly as data to the two former operations, or used with the keywordsWITH
andUSING
to theINSERT
/DELETE
operation. In the context of Solid, each resource is represented with triples, and since the graph part is optional, we can safely ignore it for now.INSERT DATA
takes triples in their curly brackets, and RDF merges the triples into the resource.DELETE DATA
deletes exactly the triples that it has in curly brackets if they exist. It is important to note that there are no variables with these two operations, so no pattern matching is going on. They are the simplest forms of SPARQL Update.If pattern matching is required, i.e. you need variables, then those variables goes in a
WHERE
clause, and thus, the more advancedINSERT
/DELETE
operation must be used.Minimal SPARQL Update requirement
Quite clearly, the two operations
INSERT DATA
andDELETE DATA
has some interesting properties, as supporting them does not require a query engine, it only requires that the RDF library can parse the queries, which are trivial since it is just triples, no patterns, and that it can perform an RDF Merge operation, and delete triples. TheDELETE DATA
operation can't contained blank nodes, which also simplify. Moreover, since both operations can be performed in a single HTTP request, it can be implemented as an atomic operation with relative ease.Once a
WHERE
clause is added, for the more complexINSERT
/DELETE
operation, pretty much a full SPARQL engine with an almost complete larger parser and query planner is required.Thus, a requirement to support
INSERT DATA
andDELETE DATA
in a single HTTP PATCH request seems like an attractive option.WAC as applied to Minimal SPARQL Update
INSERT DATA
seems clearly anacl:Append
operation, andDELETE DATA
is clearly aacl:Write
operation.The question is if
acl:Read
should also be required. Imagine a malicious user "Mallory": Mallory is authorized to write, but not to read, and does not particularly care if he destroys things, he just wants to check if certain triples were there. In that case, he can send the queryThe fear now would be that Mallory can figure out from the response that Alice was in fact 14 years old. With SPARQL as defined, this will have no effect, so it shouldn't be a problem. However, we have challenged this behaviour, so this may be a problem with Solid, that may be solved by requiring
acl:Read
to be able to perform aDELETE DATA
operation.The risk may be so remote that it isn't a real concern, but I think we need to discuss it.
WAC applied to SPARQL as a whole
Some implementations may have a full SPARQL Engine available and will wish to use it. For them, we need to define how WAC applies. As above,
INSERT
is clearly anacl:Append
operation,DELETE
is clearly anacl:Write
operation, but with the caveat above, it may also be anacl:Read
operation. Whenever theWHERE
clause is added,acl:Read
would also be required. There is a long-term possibility that data could participate in the query without being exposed to the user, but lets only be concerned with the permission modes we currently have for now. Then, obviously, all the SPARQL read queries requireacl:Read
.SPARQL Endpoint
Historically, SPARQL has been queried through a server-wide SPARQL Endpoint, but the
PATCH
use case typically makes every resource its own endpoint, and will only query data from that resource. This is a useful simplification, because it removes the need to use graph naming. This assumption may be relaxed in the future, but for now, I suggest we keep it that way.Other SPARQL Update operations
SPARQL Update also defines operations
LOAD
,CLEAR
,CREATE
,DROP
,COPY
,MOVE
andADD
. We might need a brief note on what to do with them.COPY
andMOVE
operationsThe COPY use case has been proposed in #19 , and a possible solution could be to use the SPARQL Update
COPY
operation instead of a protocol verb. Similar withMOVE
.Forbidden SPARQL Update operations?
Most of the other operations maps trivially to HTTP methods as defined in Solid through LDP. It may be problematic to support them, as WAC must be applied in a consistent manner, and failure to do so may cause leaks. OTOH, those who have a full SPARQL engine may find it bothersome if they cannot use them. We need to define the behaviour.
The text was updated successfully, but these errors were encountered: