<pchampin> scribe: ora
<pchampin> https://github.com/w3c/rdf-star/issues?q=is%3Aopen+is%3Aissue+label%3Aaction
phampin: Test suites
andys: work in progress
... we can close the action, for now
<pchampin> https://github.com/w3c/rdf-star/pull/114
gkellogg: test suites can be difficult
pchampin: outstanding pull requests and issues
phampin: (not too controversial, mostly)
<pchampin> Subtopic: annotation syntax
<pchampin> https://github.com/w3c/rdf-star/pull/106
pchampin: annotation syntax
<olaf> https://pr-preview.s3.amazonaws.com/w3c/rdf-star/pull/106.html#sparql-star-grammar
olaf: propose not to extend the grammar
... put a note in the spec, call it a restriction
... counterexample (example 5)
<pchampin> https://pr-preview.s3.amazonaws.com/w3c/rdf-star/pull/106.html#example-5
olaf: cleaned up the grammar a bit, ready to be merged
gkellogg: there is a specific class of illegal examples, will add
... changes rendering subtly
<pchampin> PROPOSED: merge PR 106 after gkellogg adds the specific class on example 5
<AndyS> The syntax test suite has an "bad syntax" test for the path ":p/:q" case.
<gkellogg> +1
<AndyS> +1
<olaf> +1
<pchampin> +1
<gatemezing> +1
+1
<james> +1
<thomas> +1
<TallTed> +1
<gkellogg> the class name is “illegal-exampleâ€. I added a change note to the PR.
RESOLUTION: merge PR 106 after gkellogg adds the specific class on example 5
<pchampin> SubTopic: allowing for triples in the VALUES clause
<pchampin> https://github.com/w3c/rdf-star/issues/108
olaf: VALUES clause allows to bind values to variables; should extend to cover triples
... can create a pull request for this
<AndyS> Good idea.
pchampin: should we have a formal vote once the pull request is there?
gkellogg: there should be a vote for every pull request, but that can be a burden
... we can merge some time after the pull request is there, that gives folks time to comment
olaf: post on mailing list, leave three days to comment
<pchampin> PROPOSED: olaf to implement the proposal in issue 108 into a PR, and merge its after 3 days if no objection
<gkellogg> +1
+1
<olaf> +1
<pchampin> +1
<thomas> +1
<TallTed> +1
<AndyS> +1
<gatemezing> +1
<james> 1+
<mielvds> +0
RESOLUTION: olaf to implement the proposal in issue 108 into a PR, and merge its after 3 days if no objection
ghislain: are we allowing the use of the shortcut 'a' in the grammar? (scribe did not understand)
<olaf> https://github.com/w3c/rdf-star/issues/108#issuecomment-782853946
olaf: these are the parts of the grammar we propose to change
<olaf> https://pr-preview.s3.amazonaws.com/w3c/rdf-star/pull/106.html#expand-syntax-forms
gatemezing: this is fine
<pchampin> SubTopic: build-in functions to (de-)construct triples
<pchampin> https://github.com/w3c/rdf-star/issues/109
<pchampin> https://github.com/w3c/rdf-star/issues/27
pchampin: duplicate issues
olaf: built-in functions to allow us to access the components of a triple, and to test whether a bound value is a triple
(thanks gatemezing)
olaf: these should be like any standard built-ins
pchampin: should using a specific namespace be cleaner?
(pchampin hears voices in his head ;-)
gkellogg: this is an unofficial extension, should not co-opt an existing namespace; maybe we need a RDF*/SPARQL* namespace?
andys: these are like keywords
<AndyS> https://www.w3.org/ns/sparql#
pchampin: symmetry argument can be made, makes sense
james: symmetry argument is paramount
... where will you ultimately put these, that's where they should go now
olaf: upper case or lower case? No clear pattern in the SPARQL spec
andys: they are case-insensitive
... except for "a", "true", and "false"
olaf: propose to create a pull request, leave it open for a couple of days for folks to comment
<pchampin> PROPOSED: olaf to implement the proposal in issue 109 into a PR, and merge its after 3 days if no objection
<pchampin> +1
+1
<olaf> +1
<thomas> +1
<gatemezing> +1
<james> 1+
<AndyS> +1
<james> 1+
<mielvds> +1
<TallTed> +1
RESOLUTION: olaf to implement the proposal in issue 109 into a PR, and merge its after 3 days if no objection
<pchampin> SubTopic: removing the old version of the BIND operator
<olaf> BIND(<<:bob ?p ?o>> AS ?t)
<AndyS> FYI-- 1.1 spec Grammar note 1 is about case-sensitivity
olaf: meaning of this is that every triple that matches has to be bound to ?t
... this is for matching, not for construction
... should this be called something else, since the standard BIND can construct
<olaf> :bob ?p ?o . BIND(<<:bob ?p ?o>> AS ?t)
olaf: this would be a way to construct
... proposal is to remove this from the spec
pchampin: asserted triples only?
olaf: no, any triples
... in the draft, it is now only for asserted triples, unlike in the original version
... original draft assumed PG mode
gkellogg: this is much more complex than I thought
olaf: implementation complexity: agreed, it can be used in both directions (find or construct)
pchampin: the symmetry made it counter-intuitive
olaf: propose to remove it from the draft
<olaf> https://github.com/w3c/rdf-star/issues/6#issuecomment-783305045
gkellogg: it would be nice to capture related use cases
andys: consequence of this is that we do not need the bracket syntax (?)
<pchampin> bob ?p ?o . BIND(Triple(:bob, ?p, ?o) AS ?t)
<olaf> +1
andys: that would be preferable
<olaf> bob ?p ?o . BIND(Triple(:bob, ?p, LANG(?o)) AS ?t)
andys: bracket syntax may be convenient, but not necessary
<pchampin> BIND(<<:bob a :Person>> AS ?t)
pchampin: strange
... embedded triples are just terms
andys: this is an expression
... variables would be required to be bound
... could add it as a special case to BIND syntax, or it could be an expression that could be used anywhere
<AndyS> BIND(SUBJEC(<<:bob a :Person>>) AS ?t)
<AndyS> BIND(SUBJECT(<<:bob a :Person>>) AS ?t)
<AndyS> BIND(<<?s a :Person>> AS ?t)
<pchampin> BIND("a"^^?dt AS ?t)
andys: move to issues
<pchampin> PROPOSED: remove the old BIND (a.k.a. FIND) construct from SPARQL-star
<olaf> +1
<pchampin> +1
<james> +1
<gkellogg> +1
<gatemezing> +1
<AndyS> +1
0
<TallTed> +1
<thomas> 0
<mielvds> +0
RESOLUTION: remove the old BIND (a.k.a. FIND) construct from SPARQL-star
<AndyS> ACTION: AndyS Raise new issue for the BIND(<<:bob a :Person>> AS ?t) discussions
pchampin: the new BIND needs some more discussion
thomas: Notation3 has formulae
<mielvds> +q
thomas: embedded triples would be similar?
... blank nodes?
pchampin: Notation3 scopes bnodes within the formula
<mielvds> I was just going to say
<mielvds> that i'' comment on this later, because I can't typ that fast
<mielvds> anyway, the people really involved are not on the call
<mielvds> N3 semantics hasn't been decided, but atm I would say thomas's interpretation is correct with the addition of the blank node thing
<mielvds> yes yes, I know, but the deep semantics people
<mielvds> the chairs I mean
<mielvds> but nesting in RDFstar is different from citing a graph
thomas: it is possible to have different IRIs for the same thing
... this is what formulae enable
pchampin: co-reference is not part of "core RDF"
thomas: "unique name assumption"
<mielvds> can we open a ticket on the relation w. N3? (Sorry for the mic thing)
pchampin: let's open a ticket
<pchampin> ACTION: pchampin to open an issue on he relation btw N3 and RDF-star
thomas: this is not the appropriate semantics for embedded triples
... cf. occurrences
<mielvds> I see N3 as a strict superset of RDF-star, so whatever semantics RDF-star would influence those in N3 (IMHO)
pchampin: I may disagree
<mielvds> bye
bye, stay safe
<gatemezing> bye!
<olaf> Thanks me if I have implemented them ;-)
<AndyS> bye all
<AndyS> rssagent, please leave