RDF-star WG weekly meeting

Scribe: Haudebourg, Timothée (alternate: Patel-Schneider, Peter)

Approval of 2023-08-31 and 2023-09-12 minutes: 1

Previous weekly meeting was 31 August, not 31 September

Minutes at https://www.w3.org/2023/08/31-rdf-star-minutes.html

ora: any comments on minutes from 31 August

<ora> proposal: Approve 2023-08-31 minutes

<gkellogg> +1

<ora> +1

<pfps> +1

<pchampin> +1

<niklasl> +1

<Dominik_T> +1

<rubensworks> +1

<olaf> +1

<Tpt> +1

<gtw> +1

<TallTed> +1

RESOLUTION: Approve 2023-08-31 minutes

<pfps> TPAC minutes at https://www.w3.org/2023/09/12-rdf-star-minutes.html

<pfps> There are several problems with the minutes - missing section headings

<pfps> - quoted triples vs (named) graphs

<pfps> - use cases

<pfps> - CSS

gkellog: there was discussion of JSON values

tallted: there are some @ bits that don't correctly link

pchampin: I'll fix the @ links

pchampin: I'll add a line that there was discussion

ACTION: pfps to email where section headings should go

<gb> Created action #92

ACTION: pchampin to clean TPAC minutes: remove spurious at-user mentions, add mention of the value space discussion for rdf:json

<gb> Created action #93

ora: defer approval of TPAC minutes to next week

TPAC Feedback

ora: I would like feedback about how TPAC went

gkellog: the F2F was productive - we should consider having more

niklasl: it was productive even though most people were on Zoom

andys: I thought the meeting went well. We could consider more special-purpose meetings.

<TallTed> +1 periodic or regular topic-specific sessions are good; occasional 2 or 3 hour sessions, depending on the topic

ora: we could have longer meetings (longer than one hour, not longer than the TPAC meeting)

<niklasl> +1 for some longer meetings, and topic-specific meetings

pchampin: we could alternative between regular (process) meetings and special-purpose meetings

<pchampin> to be fair, we've been hearing that comment all along, from various people

ora: it seemed to me that tbl thinks that RDF-star (and historically RDF itself) is going in the wrong direction (and this may be the genesis of N3)

tallted: the comment that I heard from TBL is that there should be inclusion of graphs, not (just) triples

andys: there was early work on N3 in the data access working group

andys: doerthe had comments at the TPAC that quoted triples are different from quoted graphs (particularly with respect to transparency)

gkellog: N3 had a version of quoted triples, but to support reasoning

gkellog: the transparency issue has to do with blank node namespaces

andys: transparency covers more than blank nodes

niklasl: my understanding is that included graphs in N3 don't share blank nodes

niklasl: there are lots of differences between N3 and RDF, including variables

niklasl: there may be differences between even RDF 1.1 and N3

niklasl: Pat Hayes's presentation on RDF surfaces is relevant

<niklasl> https://www.slideshare.net/PatHayes/blogic-iswc-2009-invited-talk

<TallTed> https://w3c-cg.github.io/rdfsurfaces/ BLOGIC

<gkellogg> http://videolectures.net/iswc09_hayes_blogic/

tallted: there was some pushback against RDF surfaces because it was too complicated

pchampin: some ideas from RDF surfaces may have made it into RDF 1.1

niklasl: it would be nice to ask Pat about his thoughts

niklasl: there is information about the type/token distinction in the BLOGIC presentation

andys: one of the reasons to keep the charter of this WG small was that something big would not get through the approval process - has there been a change?

gkellogg: process aside, the WG should do something right, not something expedient

andys: syntax is important - complex syntax tricks have problems

<TallTed> note -- verifiable claims became verifiable credentials some time ago

andys: cwm appears to use bnodes

ora: is the WG supposed to adhere closely to the CG result or should it do something else

ora: my preference is to not go too far

andys: there is a definite problem turning proposals into recommendations

ora: changing a bit of recommendation often requires changing lots of the recommendation

ora: this WG should get something done

blank graphs

niklasl: I wrote a proposal to add included graphs

niklasl: recursive quoted triples open up a lot of issues

The proposal is at https://gist.github.com/niklasl/4f52c32ef2d888c172c8584e36c24610

niklasl: I am concerned that a recursive syntax construct does not fit well into RDF

niklasl: Originally quoted triples were to be a better way of doing reification

niklasl: I have issues with the CG version of quoted triples.

niklasl: I tried to give a treatment of blank graphs that supports the current use cases.

niklasl: Blank graphs can be used for the same purposes as quoted triples, and can be just syntactic sugar.

niklasl: Blank graphs can be used in other areas.

niklasl: JSON-LD has blank graphs and is widely used.

niklasl: Can we build on these existing notions.

niklasl: If there is the expectation that quoted triples are occurences, then making them types is problematic.

can someone scribe - I have to go in 2 minutes

pchampin: have to be careful not to take over named graphs, but maybe blank graphs suffice

<pchampin> seems like we already adopted the "1 week specific topic / 1 week process" mode :-)

ora: time's up

<niklasl> _:ex2 rdf:type { <p1> :birthDate "1902" }

<niklasl> _:ex2 a { <p1> :birthDate "1902" } .

<niklasl> >>> set() == set()

<niklasl> True

<niklasl> >>> set() is set()

<niklasl> False