<scribe> scribe: gatemezing
<scribe> chair: pchampin
<AndyS> Do we need a rota? (from next meeting)
pchampin: Agenda: https://lists.w3.org/Archives/Public/public-rdf-star/2021Feb/0061.html
pchampin: we don't have new people today
<pchampin> https://github.com/w3c/rdf-star/issues?q=is%3Aopen+is%3Aissue+label%3Aaction
pchampin: RDF* was substituted to rdf-star. Time to close the related issue
... Next ACTION: we need it open
AndyS: how best to use the GH tools for a workflow that is minimal overhead for both reviewer and editor.
pchampin: opinions? james ?
james: Joined for the grammar's discussion
pchampin: The discussion was to use the same tools than the one use by the SPARQL group
... so that to generate full grammar more efficiently
... so that we reuse those existing tools
james: Having a complete grammar is useful
pchampin: james can you create an issue for that?
james: Will create an issue
olaf: can it be based on sections? issues?
... the same as we do for PR?
AndyS: Probably yes.
olaf: We need to figure out the issue
gkellogg: In the case of JSON-LD CG, single issue from a receiver's comment so that to construct a PR ...
... based on the comments received. We can't require people to have access to access - git features of Github
... We need to accept feedback from email lists
AndyS: We don't have an email address in the FPCG's draft
<james> grammar https://github.com/w3c/rdf-star/issues/104
AndyS: we need to find a way to figure it out
pchampin: The list to the mailing-list is not visible in the first draft
... agree with gkellogg to have one issue by income email's comment
olaf: Sounds good!
<AndyS> JSON-LD : The mailing list is in the Status section
pchampin: gkellogg could you make a PR? - Agreed by gkellogg
<pchampin> https://github.com/w3c/rdf-star/pull/98
pchampin: We have a PR at https://github.com/w3c/rdf-star/pull/98
olaf: This PR puts the content in Section 5 of the document
... splitted in two parts - overview and features and second part with definition part
... Now, this version is basically easier than a PG mode
pchampin: the introduction is very nice. Any comments from the work?
... We can merge this PR
<pchampin> PROPOSAL: merge PR 98 about SPARQL-star Update
<pchampin> +1
<gkellogg> +1
<olaf> +1
+1
<AndyS> +1
<james> +1
<thomas> 0
<pfps> +0
<TallTed> +0
RESOLUTION: merge PR 98 about SPARQL-star Update
pchampin: We can now merge this section - thanks @olaf!
... Any implementations already exist?
olaf: Ontotext GraphDB
gkellogg: We have to solve the issue of the annotation syntax in the query part
<pchampin> https://github.com/w3c/rdf-star/pull/65
olaf: And then come back to this issue
pchampin: olaf could you remind us what it is about?
olaf: This PR #65 is about annotation syntax for SPARQL* that I proposed some times ago
<james> please explain again why this is undesirable.
pchampin: james which details do you expect?
james: I don't understand what can be a problem
olaf: a property with a concatenation of two predicates
... Sometimes is difficult to figure out which path we are considering - in the case of a simple example like :ASK { s :p/:q :o {| :a :b |} }
pchampin: See this example ASK { ?x :p* ?y {| :a :b |} } - so nothing to annotate
<AndyS> ASK { ?s :p :o }
AndyS: there is no path in SPARQL - there are just syntax
james: I don't see an error in the syntax but to be interpret in the semantics
AndyS: We are talking about path, so not obvious -
gkellogg: There is no ways in the embedded syntax like the annotation - embedded triples are in the BGP
olaf: The expansion in the query side needs rewriting in the syntax level
gkellogg: maybe we need a section with the expansion part
olaf: There is a rule for the expansion in my PRs
pchampin: If we choose to forbid annotations on patterns that are not triple part, could that be rejected by the grammar?
AndyS: it does not make a difference in terms of evaluation
<olaf> ;-)
AndyS: paths work by calculating BGP...
pchampin: Is this created by the annotation syntax issue?
AndyS: Yes, the issue brings it up.
pchampin: My expectation was to expand by adding more constraints not necessarily in the grammar ...
olaf: That is exactly what we have in the PR.
AndyS: pfps brought the issue of the semantics
... so the ones with hidden triples
... There is a section on extended matching that will be affected
<pfps> I view the ability to see the reification triples as a feature, not a bug.
pfps: RDF-star would be more useful if tied with other things...
pchampin: you mean in particular reification when mentioning by the "rest of RDF"
<pfps> For example, it is very useful to be able to have different versions of "embedded triples" that are more or less transparent.
olaf: I'd not expect such results in the simple entailment regime
AndyS: I agree with olaf.
... I'd very nice to define an entailment regime where we can see the mapping
<olaf> Exactly!
<pfps> Well that depends on what a "triple" is?
pfps: how many triples in the embedded triple?
<pchampin> with RDF*, we have to be clear about "asserted triples" and "embedded triples"
<pfps> How many formulae are there in p & q? Not one, but three!
<pfps> How many triples are in << a b c>> d e. Two! One asserted triple and one embedded triple.
<james> +1 -> rdf-star entailment routine as integral to the final report
olaf: SPARQL-star query is to query RDF-star graph not the mapping
<pfps> So, contratrary to previous statements, SPARQL is not based on simple entailment.
Can we create an issue?
or send an email to continue the discussion?
<AndyS> https://www.w3.org/TR/sparql11-query/#BasicGraphPattern
<thomas> I'd like to ask 2 more things: 1) will the draft be announced on semantic-web@w3.org? and 2) can we put a discussion about the relation between N3 and RDF* on the agenda for next friday?
pchampin: thanks everyone
<pfps> I'm not sure whether SPARQL BGP matching is or can be defined in terms of simple entailment.