<scribe> scribe: @gatemezing
<pchampin1> https://github.com/w3c/rdf-star/issues?q=is%3Aopen+is%3Aissue+label%3Aaction
pchampin1: we have to discuss on the pending actions
... on more work on SPARQL* and s/rdf*/rdf-star
... missing to do the same for the use case documents. We also have to rename them in the UC docs
pchampin: AndyS can you work on those changes?
<AndyS> AndyS: yes
pchampin: will assign an action to AndyS to help for the record
pchampin: Next topic - discussing the semantics
<scribe> chair: pchampin
pchampin: We have to solve some concerns regarding the semantics and if it can be added in the public draft
... Great summary by pfps on the mailing list on the current state of the affairs. see pfps message
<pchampin> https://lists.w3.org/Archives/Public/public-rdf-star/2021Feb/0039.html
pchampin: asking pfps if he can summarize his points for non technical people here
pfps: Tried to find out the differences in the current proposals in the maling list and PRs on github
... only 3 of the 4 seem more important.
... A difference is one you generate RDF graph, do you do something special?
... The other importance is whether you use a hidden vocabulary o can't be assess except by using RDF-star
... If a scheme depends on the embedded semantics, there might be some issues..
... Differences can occur when merging before/after two RDF-star graphs
... The question is whether an embedded triple with illed form litteral is clearly stated or not?
pchampin: I agree that special datatype is a detail, and it could be done without..
... Also agree that cornor case can be adapted in the proposal
<pchampin> SELECT * { ?x rdf:subject ?y }
pchampin: Do we expect RDF-star to retrieve embedded triples for that query?
<pfps> If the RDF* vocabulary is not hidden, then the SPARQL(*) query above will return something in the presence of embedded triples.
AndyS: There are specific rdf terms...
<AndyS> And "SELECT * { ?s ?p ?o }" and similarly count queries.
olaf: The hidden vocab will allow systems to be more flexible
<gkellogg> Ruby RDF also uses a special term for an RDF triple (RDF::Statement).
olaf: I'm in favour of hidden vocabularies and not see any convincing arguments to introduce specific URIs.
... Are they any arguments for that introduction?
pfps: It is to come up with variations of RDF-star and transparent embedded triples
... even though RDF-star are mostly (semi) transparent
<pchampin> SELECT * { ?s ?p ?o }
<pfps> Ah, yes, that's an issue.
pchampin: Maybe have 2 levels of compliance
<pfps> I'm not in favour of "splitting" implementation.
pchampin: implementations that can operate also at level of interoperability/exchange
james: There's no reason that an implementation would have to create it separetly
... if you have a syntatic distinction, then you can do that. But if it's on the term, then it's more complicated
<Zakim> AndyS, you wanted to note a consequence of triples with real vocab.
AndyS: One of the consequence, it's that it could be partial...
... one of the possibility is to define a mapping from RDF triple terms into say reification
... adding an extra term was not an easy way of going
pchampin: I saw that pfps is not in favor of splitting the implementations
... The goal is to give flexibility to get things done in one way or another
<AndyS> AndyS: A new RDF term was not as problematic as dealing with reification quads (which can be partial AKA broken).
<pchampin> STRAWPOLL: 2 levels of compliance
<olaf> -1
pchampin: What about having 2 levels of compliance
<pfps> -0.7
<gkellogg> -1
<AndyS> 0 (not sure I fully grok the details)
<pchampin> +0
<twomas> 42
+0
<TallTed> -0.5 (also not sure I fully grok, but to the extent I do, it doesn't seem a good path)
olaf: It would introduce for mapping from RDF to RDF-star graph? IMHO, I don't think so
... If we really consider as a mean to define semantics, we need to avoid complications by having 2 compliance levels
<pfps> But aren't all RDF* and SPARQL* implementations non-conformant to every published description of RDF* and SPARQL*?
james: understanding RDF-star is not really 2 level of compliance
pchampin: There is no much tractions for the idea
<AndyS> pfps - Blazegraph?
pfps: The original semantics of SPARQL-star was a mapping to RDF?
<pfps> The original paper has two semantics, and they diverge. Implementations appear to implement the direct semantics, not the indirect one.
pchampin: We have discussed a lot the hidden vocabulary, but not if we want to keep the abstract syntax and define a mapping ?
pfps: yes. Remember it was an answer to different ways to create RDF-star
... we should have to figure out this thing is supposed to work
... it seems like we don't have a common understanding how RDF-star should work.
pchampin: we really need a huge rework of everything including SPARQL-star...
... the abstract syntax is something we did not argue a lot here
... I would like to hear others
olaf: I agree with pierre.
... I would claim for implementers to give them a big picture of what should come out when querying RDF-star
pchampin: Are we ready to deal without abstract semantics?
... seem no strong opinion
james: I do agree with olaf that the semantics should be based on the abstract syntax.
... it should not prevent the editors to stop the publication
pchampin: put something in the doc so that people can respond
<pchampin> PROPOSAL: include PR88 in the first public draftbefore publishing, with a link to an issue summarizing Peter's email about the altnatives
<pfps> +1
<twomas> +1
<pchampin> +1
+1
<TallTed> +1
<james> +1
<olaf> +1
<gkellogg> +1
<AndyS> +1
<pfps> I'll create an issue.
RESOLUTION: include PR88 in before publishing, with a link to an issue summarizing Peter's email about the altnatives
<olaf> Given that we have a few mins left, can we do a strawpoll on the question of whether we want to keep the abstract syntax?
pchampin: I found no way to make links to previous draft
... having the links in the header generated by respec. It seems to work for WG.
gkellogg: It is manually done
pchampin: We have 5 minutes left. What are the best way to have more attractions?
... We have something in the community blog
... Any other ideas?
... The semantic web mailing list as well
gkellogg: Also something in the CG, the RDF list and pchampin to give a talk
... in the next month or so...
+1 to also present a summary in some events by the chairs
gkellogg: We are finishing the work in the JSON-LD CG in one or 2 weeks
pchampin: anyhing else?
Zamik, who is present?
<gkellogg> https://json-ld.github.io/json-ld-star/
pchampin: thank you very much. We made some progress and congrats for the next coming first public draft
olaf: I would like to add the contributions in the draft
pchampin: how do we suggest we proceed?
olaf: create an issue and ask everybody. It should be a short term without delaying the draft
pchampin: It should be a short term without delaying the draft
bye
<olaf> bye