Meeting minutes
Scribe: Alexiev, Vladimir (alternate: Taelman, Ruben)
Approval of last week's minutes: 1
ktk: Any comments on last week's minutes?
pchampin: I discovered that I closed the conversation when I left last week.
… There is also a wrong GH link. Only the link by the scribe-bot is wrong.
ktk: Should we use the full links instead?
https://
TallTed: Is there a correct link near the wrong one?
pchampin: The scribe script link is wrong, and I can fix that. The other bot's one seems to be wrong as well, and Gregg put in the correct link. I can fix this mess.
<ktk> PROPOSAL: Approve last week's minutes
<ktk> +1
+1
<TallTed> +1 upon PAC's fix
<gtw> +1
+1
<AndyS> +1
RESOLUTION: Approve last week's minutes
<TallTed> ack
Querying nested quoted triples at an unknown depth 2
rubensworks: in SPARQL-star, it is possible to have top-down access to quoted triples
… do we want to allow bottom-up access to quoted triples, to be able to query quoted triples of unknown depth?
… This is not about adding specific syntactical support to SPARQL,
… more about asking to the group: do we need this? do we want to somehow support it?
AndyS: the problem might be more complex than what's in the issue (which uses the same predicate at all depths)
… you might also want to match not down to the end.
rubensworks: agree with first point: my first proposal is inspired by property paths,
… but further down in the issue, I describe a more genetic possible solution (QUOTED keyword),
… where you don't necessarily to specify the path to the quoted triple
TallTed: I like the initial concept of this being an extension of property paths;
… feels more intuitive to me than the analogy with GRAPH.
… But it is a deep issue, requiring significant math-heads.
… (aside: it is a shame that some people from early RDF are not part of this group)
ktk: [question about the proposal in the issue]
TallTed: there is a strong wish in the community to get all the intermediaries of property paths
… There was a proposal in the early proposal of property paths, to specify an arbitrary depth,
… it is implemented in Virtuoso, but I don't know what happened to it in the spec.
AndyS: does the charter allows us to make this kind of change?
… not an errata, definitely a new feature, requires to change the SPARQL data model.
<Souri> I had presented a paper at the KGC 2022 conference related to this and it is being, in principle, discussed for inclusion in the SQL/PGQ standard's next version: https://
AndyS: Is it possible? yes. But in scope?....
… If we take on this feature, other features will be required as well.
… The reason it was rejected was a formal objection from some university, it adds much complexity.
AndyS: [disussion about living standard, that needs to reflect the position of the wider community]
ktk: any of the implementers on the call want to comment?
Souri: I call this neighbourhood-aware path, see link to paper above
… this was not included in PGQ because of complexity issue, but is much discussed at the moment
… there is a big need for this, and SPARQL property paths is simple and does not provide this
… it would be nice to have it, if time allows
<TallTed> Is there a link to any SQL/PGQ documentation? I know it will be put behind a paywall when finalized, but maybe there's a draft available?
Souri: I work with veteran standard people in SQL and PG, they acknowledge that it is a really nice to have
Tpt: I agree this is something we want to think about, but that's complex.
… Should probably not be a priority at this point, and consider it later if we have time.
<AndyS> https://
rubensworks: implementation-wise, we experimented with a number of indexing approaches,
… the second proposal in the issue (QUOTED keyword) is easy to support in an index,
… as an extension to existing triple stores.
TallTed: could Souri please share a link to this work on PGQ?
gtw: concur with what has been said: should not be a priority and probably out of scope;
… but happy to see experiments on this in the SPARQL-dev CG.
pchampin: Wondering if we have a label for future work?
<TallTed> `deferred` is common
ktk: I propose everyone to write down what Greggory said in the issue, and link to it in sparql-dev.
<pchampin> the label "ms:futurework" looks like a good match
AndyS: Ruben, will you write this down in sparql-dev?
rubensworks: yes.
<AndyS> Issues at w3c/
ktk: Ruben will post the issue.
Review of open actions, available at 3
pchampin: The renaming to sparql-dev has been done. The old URLs of the CG and GH repo redirect.
… The public mailinglist already existed, so we created public-sparql-dev-cg instead.
AndyS: The other one is where all Cfps go.
pchampin: And other spam.
ktk: Remaining work is to update all text.
pchampin: We did some renaming already.
pchampin: Remaining issues are long-standing issues still to be solved.
Review of pull requests, available at 4
pchampin: We decided to shift the mobile PR from making it mobile-friendly, to just fixing his concrete problems. So I think we can close this PR, but let's wait for Dominik to be present.
ktk: He said would provide screenshots.
AndyS: What about the problem with echidna in sparql-update
https://
pchampin: There is probably a validation issue.
pchampin: Pointy brackets around an URL.
pchampin: I noticed last week a credentials issue, but it seems to be resolved.
AndyS: It's intermittent.
Any Other Business (AOB), time permitting
ktk: Next week I'm not here.
AndyS: How many people will go to TPAC in person?
ktk: I booked a hotel; yes.
<pchampin> I will be present in person
ktk: Ora is confident he will go.
<TallTed> sadly, insufficient travel budget
AndyS: Gregg might not be able to.
<Souri> Where is the TPAC being held? When?
ktk: Not cheap for those coming from the US.
https://
AndyS: It will be hybrid.
… Our slot is on Tuesday.
https://
<Souri> Which helps because that way I don't miss any meetings here! :-)
<ktk> rubensworks: thanks for scribing!
<AndyS> pchampin? Got a minute?
<AndyS> I'm not seeing an error locall (well, I use the usual 1E/1W about included documents)
<AndyS> Ack
<AndyS> Where?
<pchampin> s/<pchampin> +1/<pchampin> <pchampin> +1/