<pchampin> pchampin: this is a test
<pchampin> ... this is a continuation
<pchampin> scribe: pavel
pchampin: explains to pavel how to scribe
... any new folks here?
<pchampin> https://github.com/w3c/rdf-star/issues?q=is%3Aopen+is%3Aissue+label%3Aaction
pchampin: starting with the test cases
<pchampin> https://github.com/w3c/rdf-star/issues/46
pchampin: that one is done, yaya
<pchampin> https://github.com/w3c/rdf-star/issues/45
pchampin: next issue, embedded quads
... there was discussion
<rivettp> I'm not hearing anything (did when I first joined) will rejoin the call
blake_: this was about opening a discussion, not advocating for anything, just to have it on the table
... do we need t consider embedded quads? what does it mean?
pchampin: we will have some time for open discussion at the end, we can have it then if we want
<pchampin> https://github.com/w3c/rdf-star/issues/40
pchampin: README included in the HTML output
... empty sceleton for SPARQL* test suite is there, so more progress!
... still need more tests. please open PRs with manifest entries, test data. expected results, etc.
<pchampin> https://github.com/w3c/rdf-star/issues/8
pchampin: next action on Olaf, semantics of BGP* and BIND/FIND
pavel: i looked, seems fine
Olaf: let's keep it on the agenda for the next time
pchampin: let's add tests for it, even if they don't pass yet
Olaf: shall we split the tests on query answering and parsing?
pchampin: there're subsets already
Olaf: it's parsing vs execution, not answering
<pchampin> ACTION: pchampin to put the discussion on action #8 in the next agenda
AndyS: can we have a syntax test suite for Turtle*
<pchampin> action andys to add a test-suite for Turtle*
<AndyS> ACTION: andys to add a test-suite for Turtle*
pchampin: last time we stopped there ^^
... at the moment this is how the definitions in the Olaf's paper define RDF*
... and also how it's implemented right now
... embedded triples are one and the same thing as long as all SPO components are the same
... there was a concern about that (in the mailing list)
... could make it difficult to address some use cases, eg. Wikidata
... where we need to represent diff occurrences of the same statement
... since same statement can be said by different people and then they could be different
... some PG databases can have multi-edges and different attributes
... it's a known limitation, my position is these complicate things (though not impossible)
<pfps> It's not just the Wikidata use case. The examples related to provenance point to having multiple embedded triples with the same s,p,o.
pchampin: extending RDF* to more complex examples would require to distinguish occurrences of the same triple
gkellogg: are 2 triples in different NGs, are they the same?
pchampin: yeah
<pfps> And it's not just the provenance examples - belief is another place where one might want to distinguish between different embedded triples with the same s,p.o.
gkellogg: if a triple exists in multiple NGs, does it exist only in the NG where it's stated?
pchampin: the meaning of the named graph isn't formalised
... so it's not easy
gkellogg: Wikidata semantics could be resolved ins ome interpretation of named graphs, no?
... at least it'd make sense to me
... it should allow you to speak differently depending on named graph
thomas: do we speak about triples as extensions or occurrences in graphs/document? i tried to discuss that in my long email
<pfps> I don't see how named graphs help in expressing Wikidata. WIkidata has one "ground" but that ground can have multiple statements with the same s,p.o.
thomas: if 2 people want to say different things about the same triple, you have to differentiate in the semantics
... but defining semantics about all triples of the same type(?) makes it impossible
pchampin: 2 embedde triples in 2 NGs represents the same thing
... but: i can describe some thing in a NG, e.g. rdf-star a :great-idea and in a different graph rdf-star a :broken
... i can do that, and the triple is still the same
... if someone merges the graphs then we get a contradiction. but they don't have to merge those graphs
thomas: i'd be interested in how it works
AndyS: what we should try is enabling the basic building blocks are there to solve use cases
... it might need something else
... you could have RDF* triples as defined in the papers and be able to make statements
... statings vs statements (the former being the action of making the statement)
... the triple term right now can be annotated itself
pfps: if we enable basic blocks then RDF reification works
AndyS: nope?
... agree with pfps that many UCs can be solved with reification
... but it's more on users than us
pfps: evidence that we have that users use RDF, ie those documents, and as i pointed out, those documents are in bad shape
... either someone needs to fix them up and provide good evidence
AndyS: there's absemce of evidence for the use of RDF reification
... i want to get to a point where we can make progress without boiling the ocean
pchampin: Jerven do you want to say anything about reification
jerven: yes. reification solves our problem (to talk about the triple)
... i.e. talking about a relationship, it works fine as-is.
... but it's soo ugly
... and blows up data
... and queries!
... lots of joins too. that's problematic on large scale data.
... semantics is fine. but join performance and verbosity are problematic
<pfps> I wonder whether embedded triples would help at all in SPARQL performance.
<thomas> so RDF* with the RDF reification semantics would be fine for you, Jerven?
pchampin: want to add what RDF* buys us re: reification, it adds atomicity
jerven: we'd like to have that
<pfps> It would be nice to have some experiments on how fast SPARQL* queries are over embedded triples.
jerven: then the question is: do we constraint the rdf reification to say that your RDF reification graphs must be complete
... if you want RDF* enabled, you cannot have invalid/incomplete reification statements
... at some point semantics faces the practicality issue
blake: to respond re: reification verbosity
... i don't think any of those issues are necessarily
... those can be implementation details
... stores can have special treatments for RDF reification triples
... constraints can be enforced
... performance gains with RDF* are not a given
<Olaf> Blake, Jena did have such special treatment but they took it out
<pfps> +1 to blake
AndyS: there was some experience with that
... experience wasn't very good
... first problem is partials
... a lot of low-level work needed to deal with reification
... maybe it's not such a big issues these days since hardware is better
<pchampin> scribe: pchampin
<pfps> And what is the burden of implementing triples as a new node type?
pavel: in theory, it is true that performance issues of reification can be optimized away,
... but in practice, it proved very hard
... It is difficult to not leak those ugly reification triples to the user.
<AndyS> Work by Kevin Wilkinson and others: https://www2.cs.uic.edu/~ifc/SWDB/papers/Wilkinson_etal.pdf
<scribe> scribe: pavel
thomas: i don't know anyone saying that we should keep the standard reification. but its semantics is fine.
... i think we should keep that semantics, if RDF* would conform that'd be great
pchampin: the syntax of Turtle* and SPARQL* would make it hard
... one could imagine that every occurrence in <<>> identifies a new occurrence..
... but it'd make it very complex
... lots of practical issues will arise
thomas: by default i'd suggest that an annotation refers to the triple in the same named graph (?)
... others may have totally different opinions
pchampin: so you'd not object to the test as written?
thomas: no idea :)
pchampin: ok, we need to make progress in one way or another
... but the more we agree on, the better
blake: re: reification, it sounds like everyone is not against RDF* being syntactic sugar
... maybe with a better syntax and query patterns
<pfps> +1 for blake's comment that implementing embedded triples is hard too
<pchampin> [] rdf:subject :a, :b.
blake: all the points re: implementation, they're muted because the same would be required when embedded statements are first-class citizens
... so we can get away with syntactic sugar
jerven: in Uniprot we generate statement IDs which aren't quite valid in RDF/XML, so each statement gets an ID when we reify it
... and that works fine
... so we never have to generate reification quads again
<Zakim> AndyS, you wanted to suggest a strawpoll
jerven: i feel RDF* should be compatible with reification but we don't have to require it being as expressive
AndyS: what does everyone think?
pchampin: same idea
<AndyS> +1 to Jerven
pfps: still don't know what RDF* is supposed to be good for. how can i approve any test then?
<thomas> +1 to Jerven
pchampin: agree, good question. strawpoll here
<pchampin> STRAWPOLL: would you be happy with RDF* being syntactic sugar for standard reification (possibly with more constraints)?
<blake> +1
<thomas> +1
<jerven> +1
<pfps> +1
<rivettp> +1
<gkellogg> -0
<pchampin> -0
<AndyS> +1 "with more constraints"
<james> +0
<jerven> +1 "with more constraints"
<Doerthe> -0
<Olaf> Do you mean in terms of semantics?
0 (cannot answer)
+1 to AndyS!
<pfps> There are lots of sins that can be covered by syntactic sugar.
AndyS: it depends on what we mean by syntactic sugar (and pavel agrees)
<Olaf> +1
pchampin: i mean that Turtle* docs can be rewritten into reification and that'd make no difference
<thomas> I interpreted "syntactic sugar for RDF reofication" as keeping the RDF refication semantics
<pchampin> scribe: pchampin
pavel: I couldn't answer the strawpoll.
<pfps> I'm generally in favour of the syntactic sugar solution, particularly as it allows for other kinds of reification.
pavel: should the system return the reification triples? that would not be good
<pavel> scribe: pavel
blake: sugar should not disallow synthetic URIs or triples
<pfps> But the problem is if you have mixed syntax - some [[...]] and some rdf:subject.
blake: that could be another form of syntactic sugar?
+1 to pfps
pchampin: this needs to be explored, let's see if we have a ticket on it. but there seems to be no strong opposition so it's a serious option
<pfps> But there is no gain without pain, and it is completely unclear to me as to even the magnitude of the pains for the various approaches.
pchampin: but not there are some different expectations from syntactic sugar
... gotta think till next week
... thanks everyone, no formal decision for now, but feels like progress nonetheless
... bye
<pfps> One pain would be to allow embedded triples to be incomplete and transform rdf:subject etc into embedded triples.
<jerven> Thank you all.