08 Jan 2021


gkellogg, pchampin, thomas, TallTed, AndyS, pfps
gatemezing, olaf
andys, pchampin, pfps


<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

New people on the call introduce themselves

Intro mielvds

Interests --KG, provenance, rights

Review pending actions

<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

sections on "triples vs occurences"

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

Annotation syntax

<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

open-ended discussions

<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

new semantics (open discussion)

<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*

Summary of Action Items

[NEW] ACTION: AndyS to gather in one place the proposals about the annotation syntax
[NEW] ACTION: thomas submit an issue about the link to the 1999 spec about reification

Summary of Resolutions

    [End of minutes]

    Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version (CVS log)