RDF*

<blake> p?

<gkellogg> Has Zakim arived?

<pchampin> gkellogg: yes

<AndyS> scribe: AndyS

Review pending actions

<pchampin> https://github.com/w3c/rdf-star/issues/40

pchampin: test suite ... SPARQL* "in-progress"

AndyS: Can start some SPARQL* syntax tests.

<pfps> successfully? you mean that you have all the desired results or that you have results for all of them?

gkellogg: Notes JSON-LD for one set of tests.
... have both kinds

Discuss the SPARQL* annotation syntax proposed by Olaf

Andy: Key piece of work was extending isomorphism to handle nested <<>>

<pchampin> https://github.com/w3c/rdf-star/pull/65

<gkellogg> AndyS notes that there are changes necessary for isomorphsim checks.

olaf: work ongoing for annotation with regard to SPARQL paths.

<gatemezing> +1 to postpone the resolution for this proposal

olaf: just copying over from Turtle has impacts wider than intended
... property paths e..g ":s :(:p|:q) ?o {| ... |}"

<pfps> +1 for annotating property path patterns :-)

Discuss the overview section proposed by Bob

<pchampin> https://github.com/w3c/rdf-star/pull/69

pchampin: bobdc has contributed an overview and introduction

pfps: current example needs to be changed
... suggests no ^^ use
... (datatype)

pchampin: document is not fixed by a PR. Can have later discussion.
... prefer to have some text rather than none.

<pchampin> ack: gkellogg

gkellogg: It is non-normative text.

<pfps> My initial complaint was that strings were used as dates, but using the date dataype brings in the irrelevant issue of which datatypes need to be supported.

gkellogg: need to motivate RDF*

<pchampin> scribe: pchampin

AndyS: this should not be just a blunt specification for implemters
... this should be accessible to anyone

<gkellogg> +1 to what Andy said

<AndyS> scribe: AndyS

<pchampin> PROPOSED: merge PR 69 after removing the xsd:date literals from the example

<gkellogg> +1

<pchampin> +1

+1

<pfps> 0

<gatemezing> +1

<olaf> +1

<ora> +1

<james> +0

<thomas> 0

RESOLUTION: merge PR 69 after removing the xsd:date literals from the example

pchampin: please continue to raise comments and issues on doc text
... continuous improvement

"unique triples"

<pchampin> https://github.com/w3c/rdf-star/issues/64

<pchampin> https://github.com/w3c/rdf-star/pull/69

<olaf> Isn't this PR https://github.com/w3c/rdf-star/pull/75?

pchampin: removed text about "type" (different meaning to computer science)
... tried to articulate common understanding (discussions, implementations)

pfps: people are sloppy in use of language but sometimes need to be exact.
... lots of levels : interpretations, models, abstract syntax, graphs, surface syntax.
... embedded triples are at several levels.
... e.g. replace "embedded triple" by "literal"and text should level-correct.
... unlike [] which is not the same term on each use in a Turtle file.
... We agree that <<>> are not like []
... section 2.1 - unclear about "embedded triple" - as surface syntax? as a term in a graph? as in model theory?

pchampin: I see the point here.

<gatemezing> Based on the previous discussion, are we going to clearly separate those three "context" of embedded triple?

pchampin: embedded triples in the abstract syntax denote themselves.
... occurrences of the same term.

<pfps> The point here is that the proposed addition of 2.1 needs to be clear as to what is what. If 2.1 is talking about abstract syntax it should do so throughout (and be very careful about using concrete syntax), as the mapping from concrete syntax to abstract syntax may create multiple triples that "share" something derived from one piece of the concrete syntax document.

<james> "occurrences of the same term" just that does not make sense

olaf: embedded triple - confusion from examples - for me, mathematical concept of 3 terms - like a literal

ora: clarifying question - embedded triple is a identifier - opaque to make statements about it ?

gkellogg: Q about Embedded triple and blank node.

<pchampin> << :s :p _:x >>

<pfps> Hmm. What about << :a :b [] >> in Turtle?

pchampin: several ways to consider it.
... blank node is like plain RDF
... existential variable

<ora> Does this go away if we replace each blank node with a new identifier?

pchampin: complex discussion
... SPARQL(*) bnodes are variables.

<pfps> Blank node labels are part of concrete syntaxes, and are not part of RDF graphs.

<pfps> A blank node is a blank node, not a variable.

pchampin: If a blank node is a variable, then embedded triple is no longer completely opaque.

<gatemezing> Why do we need blank nodes here? -

<pchampin> :alice :father [ :name "bob" {| :asserted :alice |} ].

<james> the statement would have to be in the context of a question

<pchampin> scribe: pchampin

<pfps> Well, there is nowhere the triple with subject :a, as triples can't have CURIES as subjects.

AndyS: difference btw blank node appearing only in an embedded triple

<ora> I assume <<:a :b []>> and <<:a :b []>> are not the "same" triple.

AndyS: and bnode appearing both inside and outside embedded triples

<pfps> GTGN

AndyS: the former may have a meaning, but not very useful

<gatemezing> +1 ora - they are different here

<ora> Hyvää joulua!

<AndyS> Next telecon: 2020-01-08

<gatemezing> Bye all! Happy end of year!