Thanks Danny. atomgraph.com should be back up now.
BTW this is probably a better link in hindsight:
https://jena.apache.org/documentation/fuseki2/fuseki-data-access-control.html
It seems to overlap with the shiro functionality, but has more features.
On Sat, Oct 2, 2021 at 7:27 PM Danny Ayers w
> Overall, it whether the WHERE answer is 16*26*2636 rows (all one BGP) or
> 16+26+2636 rows (union).
Yes, I understand better now, thanks!
Do you think there might be some optimization at some point for that
case? I suspect this is very common in SPARQL queries out there...
Best,
--
Elie
On 07/10/2021 12:30, Élie Roux wrote:
if you take this expression
WHERE
{
{
bdr:MW23703_1183 ?instp ?insto . # 200ms alone
} union {
bdr:MW23703_1183 :hasTitle ?t . ?t ?tp ?to . #245ms alone
} union {
bdr:MW23703_1183 :partOf+ ?ancestor . ?ancestor :hasPart
?ancestorPart . #
When there are different parts of pattern going to make up different
parts of the CONSTRUCT template, splitting it up into UNION makes sense.
It is using the fact that in a CONSTRUCT template, if variables are
unbound, the triple pattern isn't substantiated but the rest of the
triples from the
> if you take this expression
>
> WHERE
> {
> {
> bdr:MW23703_1183 ?instp ?insto . # 200ms alone
> } union {
> bdr:MW23703_1183 :hasTitle ?t . ?t ?tp ?to . #245ms alone
> } union {
> bdr:MW23703_1183 :partOf+ ?ancestor . ?ancestor :hasPart
> ?ancestorPart . # 200ms alone
> }
> }
>
> se
Thanks a lot for your very informative answer Richard, it's really
helpful to know when writing queries!
It seems this is a case where some optimizations might be implemented?
(I'm afraid this isn't something I could contribute though, sorry)
Best,
--
Elie
Queries of the form
CONSTRUCT {...} WHERE {...}
are evaluated with a three-stage pipeline. First, the query
SELECT * WHERE {...}
is executed. Second, the CONSTRUCT template is applied to each result row
(producing no triple for any triple pattern that has a variable without value
in t
