Please advertise the UC&R work to your networks and ask them to add to https://github.com/w3c/rdf-star/issues/. Don't worry about duplication - better to get more input and sort out later.
<scribe> scribe: AndyS
<pchampin> Meeting: RDF*
<pchampin> Chair: pchampin
<pchampin> Agenda: https://lists.w3.org/Archives/Public/public-rdf-star/2020Nov/0031.html
<pchampin> https://github.com/w3c/rdf-star/issues/22
pchampin: issue 22: "Do you need referential opacity?"
<scribe> ... done some testing existing implementations
pfps: Several choices here - impls seem to be doing what was easiest at the time.
<pfps> I think it is unlikely that there are implementations of the partial opacity that is not specific to blank nodes.
pchampin: Can a system replace one ground term by another if they know the terms entail.
... do blank nodes work like they do outside <<>>
<pchampin> << :s :p :o >> :p2 :o2.
<pchampin> ASK { << _:x :p :o >> :p2 :o2. }
andys: people find it difficult to engage in this discussion
... what would be good is to have a set of test cases
<pavel> +1 to test cases
<pfps> test cases might help, but you have to be very careful to not pull in intended semantics of the terms used
<gatemezing> +1 also to have test cases, hopefully we can agree on the different test case
AndyS: Blank nodes in SPARQL(*) will be variable-like.
<pfps> yes, one has to be very careful when using SPARQL(*) for this because of the status of blank nodes in queries
<pfps> asking entailment queries gives better answers (as long as the RDF store supports entailment questions)
gkellogg: Rerential f opacity : my impl does not do entailment
... regimes. Don't understand what the implications are for the abstract syntax level.
pchampin: need a semantics for the abstract syntax.
gkellogg: RDF semantics does not speak to owl:sameAs.
pchampin: literals are the similar
... D-entailment
<pchampin> "01"^^xsd:integer and "1"^^xsd:integer
pchampin: so two URIs will not be deduced to denote the same thing in RDF (only).
gkellogg: different terms (different lexical form). Causes two triples. Some places in SPARQL take account of values [ed: expressions]
pchampin: some systems store the value rather than the different lexical forms.
... like test cases idea.
AndyS: tests to define the decisions we have to make.
Blake_Regalia: javascript implementation
<pavel> graphy
<gatemezing> Graphy by Blake_Regalia
Blake_Regalia: how does ref opaque relate to RDF* is "just" syntactic sugar and what are the combinations of choices.
pchampin: hard to answer the other questions before answering this for encoding RDF* in RDF.
... if we decide it is not opaque then it may be possible to use reification.
... (superman example)
<pchampin> _:x rdf:subject :superam; :superman owl:same :clark |= _:x rdf:subject :clark
<pfps> it is entirely possible to have an opaque semantics using RDF reification
<pchampin> << :lifeUniverseAndEverything :anwser "042"^^xsd:integer >> :accordingTo :deepThought.
<pchampin> AndyS: can we in parallel make progress for RDF* in the no-entailment case
<pfps> a simple way to have a very strong notion of referential opacity is simply to use a fresh IRI for each occurrence of a triple
<pchampin> << :lifeUniverseAndEverything :anwser "042"^^xsd:integer >> :accordingTo :deepThought.
<pchampin> ASK { << :lifeUniverseAndEverything :anwser "42"^^xsd:integer >> :accordingTo :deepThought. }
Data: :lifeUniverseAndEverything :anwser "042"^^xsd:integer and ASK { :lifeUniverseAndEverything :anwser "42"^^xsd:integer }
AndyS: Why would it be different to what the system does outside RDF*?
<pavel> it wouldn't. normally systems deal with this via some sort of literal canonicalisation
gkellogg: If we are using an abstract syntax where embedded triples are treated different, need an extended D-entailment.
+1 to pavel
Doerthe: collect examples of how we want is use RDF*
... work on N3 and RDF* - theoretical interest.
gkellogg: Gets back to original motivation. PG mode - graph includes triples. Can refer to that triple.
... would expect that entailment happens as it does to triple.
... could allow for different semantics and extend to work over entailed triples.
Olaf: original intention was use of RDF* to make statements about triples in a provenance sense => opaque
... query semantics more important to me.
... test case: voting on result may lead to inconsistent/un-consensus outcomes
pchampin: may be we focus on query
... how would it work under simple entailment and also other entail regimes.
<gatemezing> Are we talking about this document https://www.w3.org/TR/sparql11-entailment/#DEntRegime when referencing D-Entailment?
Olaf: under simple entailment none of these show up?
<pfps> but simple entailment isn't useful - even SPARQL does more than simple entailment
<pfps> ooh, my mistake then
AndyS: SPARQL triple matching is simple-entailment with values in expressions only.
gkellogg: Use graph isomorphism for tests so not SPARQL dependent
pchampin: I will start the setup for a test suite
<pchampin> ACTION: pchampin to start a test suite, similar to the rdf-mt suite
<pchampin> ACTION: Olaf to write a first draft of the query semantics in the report
Olaf: offer to put draft of query semantic into the spec. There is a GH issue.
<Olaf> https://github.com/w3c/rdf-star/issues/8
<rivettp> FYI next Friday is Thanksgiving weekend in the US and I will not be able to attend the call
<Olaf> Who can be here next week?
<pchampin> +1
<Olaf> +1
<gkellogg> +1
<gatemezing> +1
<thomas> +1
<blake> +1
<pavel> +1
<james> +1
+1
<pchampin> ok, let's keep next week call
<gatemezing> thanks all! bye
<Doerthe> thank you pierre-antoine :)
<pchampin> and thanks to AndyS for scribing