Aklakan commented on issue #1557:
URL: https://github.com/apache/jena/issues/1557#issuecomment-1263317360
> Specifically to dynamic datasets: it records the original dataset
description so all query information is available.
Yes, maybe you haven't seen it, but I changed the PR to only make the
private "projected" (original) dataset accessible.
That's this only piece of information I am missing I need in order not
having to bother you with this issue anymore.
DynamicDataset is also in ARQ - this way Fuseki doesn't have to be touched
at all.
I can change the issue/PR titles because now they are misleading.
> Any query can be transformed in Fuseki. Add a custom operation
implementation and handle the incoming request.
That's technical dept on our side:
- It's not a good solution because the rewriting is only an ARQ-level
operation which shouldn't escalate to/depend on the server. Checking for
whether a Dataset is dynamic is also independent from Fuseki because
fortunately DynamicDataset is in ARQ.
Conversely, ARQ plugin don't need checks for whether a Dataset originates
specifically from Fuseki.
- With the way ACL is implemented in Fuseki, our rewriting based on
DynamicDataset would (coincidentally) still work. Conversely, we don't want the
prospect of potentially having to subclass every possible servlet when the task
at hand is unrelated to them.
- Right now, we have an ARQ plugin bundle which we just copy into the Fuseki
extra folder. If we touched the servlets we'd need a Fuseki-plugin bundle (or
would we even have to maintain our own Fuseki fork?).
> Virtuoso [...]
Let's leave it out because it adds nothing to the discussion.
> Where is it coming from?
Apparently I am biased, but among my peers it's a common design pattern to
have some form of query (template) catalogs that reference the target graph
with FROM (typically a single one).
For example, there is a process where initially a query uses `FROM
<latestEvents>` which gets then transformed into `FROM <events2022-09-30>`.
Furthermore, multiple version of the same query (FROM vs GRAPH) is not
acceptable because it becomes unmanageable quickly so there must be automatic
transformations whenever possible! Within the processing pipelines the FROM
clause can then be easily remapped to the final locations - much easier than
GRAPH (in the worst case this could even be a regex hack).
And this leads to the issue of slower requests in Fuseki+TDB2 due to
DynamicDataset wrapping.
- On solution for that is to (hard) code a specific rule that prevents the
DynamicDataset wrapping when there is just one FROM clause (and no named graphs
and whatever other corner cases need to be considered). If you want to add
specific code for that case then that would help us too:
If I am not mistaken, then under certain conditions FROM and GRAPH are
equivalent (w.r.t. to a given context; active graph and such), such as this:
```sparql
SELECT (COUNT(*) AS ?c) FROM <x> { ?s ?p ?o }
SELECT (COUNT(*) AS ?c) { GRAPH <x> { ?s ?p ?o }
```
- The other solution - the one that I favor - is to have a general way to
rewrite queries with FROMs that originate from Fuseki with ARQ plugins *without
having to touch Fusek*. This way I can experiment with FROM-to-GRAPH rewriting
*independently and without commitment* but still have the opportunity to put
into an ARQ plugin bundle that (in the future) works with vanilla Fuseki. If it
turns out to be of general community interest then we can still have a
discussion at a later stage. Yes, it would also allow one to experiment with
FROM expansions but this is not a relevant discussion now.
As it stands, it seems to me that making the projected dataset in
DynamicDataset accessible would be the best solution.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
