<pfps> present*
<pchampin> ora, do you have problem connecting your audio?
<ora> Yep, hold on...
<pchampin> no problem
<ora> Now works!
<AndyS> Achievement unlocked.
<ora> :-)
<pfps> I'll scribe if I can get someone to scribe for the bits I will be involved in.
<AndyS> We can tag team.
<pchampin> scribe: andys
<pfps> I guess Andy and I could cover scribe duties
Intro mielvds
Interests --KG, provenance, rights
<pchampin> https://github.com/w3c/rdf-star/issues?q=is%3Aopen+is%3Aissue+label%3Aaction
<pchampin> scribe: pchampin
AndyS: syntax test suites for Turtle* and Sparql* have good coverage
... easy to amend based on future changes
... Did some cleanup to make it easier for other to work on the test suite.
... Conversion btw TTL and JSON-LD manifests.
... There are also some evaluation tests for Turtle*, mapping TTL files to NT files.
... Needs for tests.
<scribe> scribe: AndyS
<scribe> scribe: AndyS
gkellogg: passes all the tests at the moment
<TallTed> Create a test suite -- https://github.com/w3c/rdf-star/issues/40
gkellogg: and add SPARQL syntax if missing forms
Tidied up material
pchampin: Tidied up material
thomas: Changed the example not text referring to example.
... not enough about occurrences vs types.
... reification applies to the triple type
<TallTed> Add material in the spec about the triple-occurrence distinction -- https://github.com/w3c/rdf-star/pull/75
thomas: reference to reification is 1999 spec not RDF 1.0 (2004), RDF 1.1 (2013)
<pchampin> https://github.com/w3c/rdf-star/pull/75
pchampin: agenda has bad link: should be https://github.com/w3c/rdf-star/pull/75
... intro is intended to be high level and concise, not all detail
... about reification is indeed to 1999 REC.
<pchampin> ACTION: thomas submit an issue about the link to the 1999 spec about reification
<pchampin> ack: gkellogg
<ora> Hmm... I wrote the original 1999 part, oh goodness...
gkellogg: RDF 1.1 WG downplayed reification
... as were RDF containers
<ora> There were earlier discussions with references to modal logics as well...
gkellogg: issues about transformation to base RDF for reification
... vs single blank node for all uses
pchampin: Intention is one blank node per triple term --- not on agenda today to give time for people to read it
<pchampin> scribe: pfps
<TallTed> annotation syntax for SPARQL* -- https://github.com/w3c/rdf-star/pull/65
AndyS: proposal for annotations - as in property graphs - asserting the statement and also decorating it
... some proposals clash with other parts of RDF syntax
<pchampin> current syntax: :s :p :o {| :q1 :r1; :q2 :r2 |}
AndyS: {| was as popular as any other, but the stuff inside the curly braces is not triples, but property values
mielvds: there should be a real discussion about the syntax - maybe not now
<AndyS> Also mentioned :s :p :o @{ .... }
mielvds: should this stay within the triple structure
... is this what is pretty or what is most usable
AndyS: there have been comments by others
... no particular rush, I can try out various versions quite easily as I have an easy-to-change Turtle* parse
... to have annotations inside annotations there needs to be a trailing delimiter
mielvds: < vs { is an issue
AndyS: yes, but they do do different things
... someone suggested using << >> but this may not work
... the annotation syntax is for convenience so maybe nesting is not needed
pchampin: there is no rush, the item is on the agenda because of the recent activity
... another issue is the position of the annotation - after object or after pedicate
<james> "dropping down" would be nice, except that, andy, is it not the intent, that are not interchangable?
<TallTed> not exactly meaning to put a rush on this, but without at least a well-considered proposed notation, we can't discuss things well through email or github or much else... and significant changes later in the process are only likely to increase confusion in an already confusing topic
pchampin: after predicate is close to property graphs and Neo4J
... after object appears to work better in Turtle
AndyS: there are also complications in N3 with after predicate and certain delimiters
<gkellogg> Perhaps “before the object”, rather than “after the predicate”, which allows for “,”
pchampin: two separate issues - bracket style and position
... after the object works better in Turtle
pfps: nesting is allowed everywhere else so non-nesting annotations is a significant new thing
AndyS: yes, and the grammar will be complicated a lot
<AndyS> pfps: there was proposal (mention) to have no nesting in annotation
<pchampin> sf
gkellogg: there should be a test for nested annotations
... using "before the object" will allow for more uses than "after the predicate"
... yarspg might be a nicer syntax - it's more like what PG users might expect
mielvds: maybe annotations are not so useful in Turtle but more useful in SPARQL
AndyS: these parts of the syntax are very similar in Turtle and SPARQL
thomas: ...
... embedded triples are whole triples so it seems better to have the annotation after the object
pchampin: but in shorthands the entire triple is not beforehand
... no rush, but can we reach some agreement now
mielvds: annotations after the embedded triples looks like quads
AndyS: all this is for Turtle, so there are no quads
<TallTed> "annotation of a triple" is roughly "description of a triple", which seems more applicable to inscription (e.g., Turtle) than query (e.g., SPARQL).
<TallTed> Also, in RDF(-plain), Turtle and SPARQL graph patterns have been built to be copy-pasteable
mielvds: should the syntax go outside the triple syntax - annotations in both styles do this
AndyS: annotation syntax does not add anything
pchampin: I concur
AndyS: the Turtle* syntax examples show annotations, please take a look
mielvds: the question is whether Turtle* should go outside triple syntax
AndyS: shall we just let this lie for now?
pchampin: sounds like a plan
<pchampin> ACTION: AndyS to gather in one place the proposals about the annotation syntax
AndyS: picking the best answer may be difficult
<AndyS> BTW -- Good point to leave open possibility of n-ary syntax in some future
<AndyS> scribe:AndyS
<pfps> pfps: it would be useful to have some rationale for the proposal for the proposed semantics
<pfps> pfps: I'm having problems figuring out why the semantics is the way it is so I can't figure out why it is good or not
<ora> I have to drop, sorry.
pchampin: Use current RDF semantic by mapping RDF* to abstract RDF and hence leverage semantics.
... has been an idea embedded triples are literal-like (self-denote in every interpretation)
pfps: rdf:S* -- why not rdf:subject? (Similarly for P* and O*)
... RDF* has every URI/bnode/literal as a node in the RDF* graph (scribe: ????)
... no rationale why it is this way
... could have used existing reification vocabulary
pchampin: will think it through
<TallTed> perhaps instead of `<< :s :p :o >>` as a new object type, we might should consider `" :s :p :o "^^rdfstar:embed` as a new typed literal
<pfps> I had a proposal for using RDF reification plus a couple of other properties that appears to capture the intended meaning of RDF*