<AndyS> Hi all
<thomas> thomas+
<AndyS> meeting: #rdf-star telecon / 2020-12-11
<gkellogg> scribe: gkellogg
<pchampin> scribe: gkellogg
pchampin: No call on December 25th or January 1st.
<gatemezing> +1
<olaf> +1
pchampin: are people okay for next week?
<pchampin> +1
+1
<ora> +1
<TallTed> +1
<doerthe> +1
<pavel> +1
<rivettp> +1
<AndyS> December 25 / January 1
<AndyS> +1
<thomas> +1
scribe: Last call of the year next week.
ora: I’m a member of the Amazon graph DB team. Ora Lassa.
<ora> Correct spelling: Ora Lassila
TallTed: I’m with OpenLink Software, maker of Virtuoso and many other things, and I've been on many W3 groups since about 2000.
<olaf> Welcome Ora and Ted!!
<pchampin> https://github.com/w3c/rdf-star/issues?q=is%3Aopen+is%3Aissue+label%3Aaction
pchampin: Two actions, one about creating a test suite. Andy has created Turtle* syntax tests.
... I’ve created a skelleton for SPARQL*
... I think we can close the action, although the test suites aren’t (and may never by) complete.
... I’d like to suggest … The tests are very abstract, and based on my understanding on RDF*.
... pfps has suggested that it may be premature.
... I’d like to ask people that have run the test cases to translate examples into test cases.
... It may help to make a link from practical issues without loosing track of what people have proposed.
<pavel> SPARQL* test cases?
<gatemezing> Is there a way to map those UCs using the manifest file?
<pchampin> scribe: pchampin
gkellogg: syntax tests are not about interpretation
... we need to set a line where N-Triple* is, so that we can write syntax tests with their *meaning*
... I'm concern that people think that annotations and pointy brackets are different things
<gkellogg> AndyS: I put some notes in the annotation discussion about that. N-Triples* is a key to understanding this.
<scribe> scribe: gkellogg
UNKNOWN_SPEAKER: Jos’ EYE has been reporting trnslations, and I’d like to create evaluation tests based on those.
<Jerven> (sorry I am late and can only stay a bit)
pchampin: I agree with the need for N-Triples*, and things are held up on that.
TallTed: I’m seeing a lot of bluring in whats being discussed to date. I’ve been out of date for the last year.
<AndyS> AndyS: Offer to write some evaluation tests starting with the EYE translation.
TallTed: Much of what’s been discussed is focusing on Quads and not talking about N-Triples. The “Star” has got to go. If it’s an evolution of RDF it needs to be treated as such.
... We can’t use RDF+ or RDF#, because they’re used. Punctuation naming breaks things.
<pchampin> ack: gkellogg
<pchampin> scribe: pchampin
gkellogg: same problem with the JSON-LD WG, when working on JSON-LD 1.1
... should we go as WHATWG? I don't think so for RDF*
<TallTed> "RDF Annotation task force" would put it under the umbrella, without using a version that might be overrun by another group
gkellogg: it is more than RDF, a proposal for what a future WG might do
<gkellogg> scribe: gkellogg
pchampin: We’re drifting off the action list. I’d like to keep a slot at the end of the meeting for open issues.
... I agree that it might be important for outreach, but we can make progress in parallel.
olaf: I copied over definitions from some old papers into the spec to define query standards.
... What needs to be adjusted is recursion.
... I don’t think there’s anything suprising. I’ve defined it assuming “SA” mode.
... If we have a nested triple and a pattern that my match it, it would not be a match unless the embedded triple is also asserted.
pavel: I was reading through evaluation semantics. I’m not quite sure how it works with SA mode. If you can’t match an embedded pattern against a database.
olaf: We changed it in the sense that in the original papers, the BIND could match something that was embedded, but that would not be a triple itself in the graph.
... That was possible in the original definitions, but now the triple needs to be explicitly in the graph.
pavel: If you have BIND and an embedded pattern with variables that iss not in the graph, you can’t use BIND to create embedded triples.
<pavel> bind(<< :a :p :b >> as ?var) <-- no match here
olaf: This is a separate issue to be discussed. I’ve created another issue to address differences between SA and PG mode, as it’s different.
... You can’t create new triples that aren’t in the graph.
... AndyS suggested renaming BIND to FIND accordingly. But, it’s still open if it matches triples in the graph or embedded triples.
... Issue #6. We’re not talking about issue #8.
... We can discuss #6 next week.
AndyS: Using BIND in this way also … If triples are terms they can also be used in expressions.
... You might need to replicate the expression with and without to handle both modes.
... You should be able to ask what the subject of the value of a variable is
olaf: Are you talking about additional builtin functions?
AndyS: By deciding one particular way, we might end up blocking that.
olaf: Getting to issue #6, I like renaming BIND to FIND.
AndyS: I just wanted to make clear that there are other consequnces of the decision.
<pavel> fwiw, Stardog does provide additional builtin functions e.g. subject(), to decompose embedded triples
pchampin: We need to put issue #6 on the agenda for next time.
<gatemezing> Happy also to use another keyword like FIND
olaf: Can we have a straw poll?
<AndyS> FWIW so does Jena including construction triple-terms
<pchampin> PROPOSED: close issue #8, the current state of section 4 SPARQL* is satisfying
<pchampin> +1
<pfps> 0
<pavel> +1
<rivettp> 0
<olaf> +1
<TallTed> It is helpful to make clear the PRs relevant to an Issue
<AndyS> +1
+1
<gatemezing> +1
<thomas> 0
<ora> 0 ("enthaltung" ;-)
<doerthe> +1
AndyS: We’re creating quite a lot of material. Just because we agree, doesn’t mean they can’t become discussion items later
<olaf> TallTed, next time -- I did not put this one through a PR
<james> 0
<TallTed> (and rather than just making commits directly, to go through the PR mechanism)
<olaf> Sorry!
<TallTed> +0
RESOLUTION: close issue #8, the current state of section 4 SPARQL* is satisfying
pchampin: As AndyS said, just because we’ve resolved an issue, doesn’t mean we can’t come back to discuss it. We’re not a WG, but we’re mimmicking the process.
<TallTed> trying to extend *all* of RDF, Turtle, N3, N4, SPARQL, TriG, etc. in one whack is a rather large undertaking, given that each of those has had its own WG for updates
<pchampin> https://github.com/w3c/rdf-star/pull/58
<olaf> Preview with diff: https://pr-preview.s3.amazonaws.com/w3c/rdf-star/58/2160503...7479002.html#turtle-star-grammar
pchampin: This is an extension of Turtle* that’s been discussed for a while. Some people use it in discussions, but it’s not properly documented. It would be useful to have in the document.
... It’s not just about the syntax, but can help us to move forward on SA vs. PG.
... The question is if an embedded triple is also asserted. There have been different interpretations of << … >>. The idea is to have two different syntaxes, one which asserts, and one which doesn’t That way, we don’t need different modes.
... I think getting rid of SA and PG modes would help discussions.
... That’s why I added a non-normative paragraph to explain the history.
<pchampin> scribe: pchampin
gkellogg: I have implemented it, it is straighforward
... I think we should get rid of PG mode
... a provisional N-Triple* would not have the annotation syntax, only the poiny bracket syntax
... thus you would need to explicitly assert a triple that is also embedded
<AndyS> +1 to gkellogg -- "one line, one triple"-ish.
<gkellogg> scribe: gkellogg
<thomas> so only Turtle* would get the sytactic sugar of PG mode?
pchampin: Is anyone unhappy with the notion of having an annotation syntax?
... To answer thomas, not just Turtle*, but perhaps TriG*, SPARQL*.
... But, N-Triples and N-Quads want to keep one asserted triple per line, which is why they wouldn’t have an annotation syntax.
<thomas> okay, thanks. +1 to that
pchampin: Basically, one “asserted” triple per line.
<TallTed> I'm not sure I see a strong utility of the annotation syntax, but I don't (yet) see a strong argument against allowing it. Implementation may be problematic, but I can't speak to that at this point.
james: This may be a minority view, but as implicit in my use case, I’m opposed to anything that changes the elementary syntax. It runs against the general intent of RDF.
... I believe this should be a consequence of iinterpretation and not of encoding.
... I don’t think there should be two different encodings.
<ora> Clarify "encoding"
pchampin: The standard does specify how you interpret the syntax.
james: N-Triples encodes triples, which are all in graphs. Anything else is going out on thin ice. I can’t see a purpose to ratifying different interpretation of the syntax.
pchampin: Are you saying you just want PG mode?
james: I don’t want a mode at all.
<pfps> I'm confused. It seems to me that this proposal is requiring that :a :b "<a b c>" requires that the triple (a, b, c) be in the graph.
<Jerven> Sorry for the noise, I need to go already
TallTed: I think you’re saying that the interpretation is modal, because you want to have one interpretation for embedded triples, and wheither it’s treated as its own term or another triples.
james: I’m not asserting that there are modes, or there may be three modes, but it should be after the fact and not as a consequence of the encoding.
<AndyS> Isn't this like entailment? Specifically D-entailment -- entailment being an external mechanism.
james: It could be that SA and PG are the interpretations, but I don’t want to presume them.
pchampin: I agree with AndyS, perhaps this relates more to entailment?
james: That would be a way to frame it.
pchampin: I see that SA mode is less committing of the two modes.
james: The eproblem of saying SA mode is that there is no PG mode. I’d like to avoid that.
... My feeling is that both have reasonable use cases.
pchampin: The idea is that the need for PG mode was a problem of redundancy, because SA mode is more redundant.
... Maybe, in other cases, it could be a matter of inferrence.
TallTed: I want to be able to say “Mary said Bob is stupid”, but I don’t want to say “Bob is stupid”.
... They can interpret my notation as if it’s asserting it, because it may come around to say something I didn’t mean to say.
pchampin: To be clear, is the annotation syntax a problem?
TallTed: I don’t see a problem with the syntax, but it may not be easy to implement.
AndyS: To james, the problem is that “mode” puts things as either/or, which was useful at the time, but if we have a system where we have a fundamental rule to unify them…
james: The concern I have with mode is that it is exclusive.
<pchampin> scribe: pchampin
gkellogg: my interpretation of this discussion is to get rid of the notion of mode
... everyone would interpret the syntax the same way
... the notion of modes was useful before, because we didn't have the appropriate syntax
... any further matter of interpretation may be a matter of entailment
<gkellogg> scribe: gkellogg
<pchampin> STRAWPOLL: do you agree to merge PR58 Annotation syntax
+1
<olaf> +1
<pchampin> +1
<TallTed> +1 (I did add one more tweak to the language a few minutes ago)
<pavel> +1
<AndyS> +1
<thomas> +1
pchampin: I think the discussion of modes is hindering our discussions, and I’d like to get this out of the way.
<doerthe> +1
<gatemezing> +1
<ora> 0
<james> 0
<gatemezing> Question: Based on the james' comments, could we add an issue on merging modes?
<pfps> 0
pchampin: I think we have a use case which is a point of discussion, but if James thinks it’s necessary,, please feel free to create a new issue.
<gatemezing> Thanks pchampin !
<rivettp> 0
<pchampin> PROPOSED: merge PR58 Annotation syntax
+1
<thomas> +1
<TallTed> +1
<gatemezing> +1
<pchampin> +1
<doerthe> +1
<pfps> 0
<olaf> +1 (including TallTed's tweak from a few mins ago ;)
<james> 0
<rivettp> 0
RESOLUTION: merge PR58 Annotation syntax
<ora> 0
pchampin: Of course, any other changes would be editorial and aren’t an issue.
<gatemezing> Thanks all!
<thomas> bye