RDF-star WG biweekly meeting

16 November 2023


AndyS, AZ, doerthe, Dominik_T, eBremer, Enrico, gkellogg, gtw, niklasl, ora, pchampin, Souri, Souri_, TallTed, Tpt
AndyS, gkellogg, Tpt

Meeting minutes

<Souri_> only on irc

<AZ> As Gregg, I remembered that this would be a 1 hour meeting, but not an hour spent on administrative stuff

<AZ> https://github.com/w3c/rdf-star-wg/blob/main/docs/scribes.md

<AZ> There is a link to it from the Github wiki

<AZ> Actually, the scribe list was not updated since May 2023

ora: Intro
… Questions and Observations slide
… not required to "rubber stamp" the CG work

ora: set of decisions to make - not independent
… challenge is to come up with the consistent set of choices
… how much do we extend RDF semantics

ora: timescale
… now, and for work after this WG

<ora> It was always clear that we were not going to “rubber-stamp” the work of the CG, because we have a different group of participants now

gkellogg: Need to get abstract syntax right.

<ora> We have a set of decisions to make, many of which depend on one another (and are informed/influenced by use cases). Can we make a consistent selection of solutions/answers to these questions?

<ora> Can we finish our work in a finite amount of time? Can we reach consensus for an approach where we limit ourselves to some (“simple”) solution now, but make it possible for us (or others) to continue the work after this WG is done?

gkellogg: either reification or graphs
… concrete syntax can be different ways
… somewhat different work to be done
… "do the least harm" - start with changes to RDF concepts

fsasaki: charter scope is implement quoted triples
… what is the implication of this on process?

pchampin: all work falls under the charter
… the CG work is input not final
… graph terms is unclear as to whether in/out
… triple terms may imply graphs by some reading
… we would need to inform the members we are interpreting the charter in a particular way

tl: Reification and statement id is quite different
… makes it a big difference

niklasl: my approach is conservative conceptually with liberal concrete syntax
… want simple as possible that does not upset the wider communities
… inc those using RDF-star already
… charter has "quoted" which I think implies opacity
… in named graphs, there is no way to control the union default graph

ora: nebulous community
… in original spec work, reification was introduced very early in the text
… there is probably a community that relies on reification
… why was it called "quoted"? lisp analogy - no interpretation.
… so my interpretation is that it implies "not asserted"

niklasl: something about tokens - describes a triple, not asserts it
… named graphs have this capacity to quote
… multiple interpretations
… power in named graphs
… problem is that want to use RDF 1.1 implementations

<Zakim> gkellogg, you wanted to note how similar reification is to collections, which are also unpopular

ora: different interpretations by different communities

gkellogg: there is a problem with changing URI named graphs - more usage
… blank node can only refer to the graph

gkellogg: c.f. RDF collections (lists) -- unpopular
… similar dilemma to if we wanted list as first class concepts
… similar to quoted triples as reifications

ora: lists were from closed collections in OWL.

tl: lists got syntactic sugar.
… quotation - embedded triples were asserted and this changed in the CG to support unasserted statements
… requirement - unasserted triples is orthogonal to annotated statements
… graph literals cover this
… can use concrete syntax for different use cases

niklasl: my POV is that unasserted statements and annotated statements are close together
… trusted and untrusted graphs

tl: graph literals - queryable
… need a marker to distinguish the two cases

ora: interesting discussion
… Q for today - is it possible to work on proposal 2 (CG work??)
… which that the work on graphs can build on that
… I think that is the way to go

<doerthe> Can someone remind us, what option 2 was? :)

AndyS: There are two technical fundamental issues from option 2: we're much clearer on types vs tokens.
… Any option will have to have both working within them.
… It was always in the background that we might want to talk about graphs, and it's now become the "genie you can't put back in the bottle".
… But, I don't think moving from quoted triples to quoted graphs is really that big a step; I don't see how it really changes the problem.


niklasl: I think that "option 2" distracts from the right thing to do.
… quoted triples as types are a problem - can be misused

niklasl: name the graph vs name the occurrence
… option 2 will not help the important cases

pchampin: quoted graphs are more complicated because need to look inside graphs to answer questions
… to niklasl on numbers - seem to be counter to the fact numbers occur once in a graph
… types can be useful

<Tpt> AndyS: when we talk talk about option 2, what are we refering to

<Tpt> ora: I was referring to gregg's email

<pchampin> gregg's email: https://www.w3.org/mid/30203E2A-6941-44D2-92A1-9A9FD9E40C27@greggkellogg.net

<Tpt> AndyS: I am afraid you lost me about type. I did not quite followed. If you say we write the same pointy bracket syntax in different places of the graph and it means different terms, we have changed RDF fondamentally

tl: idea - literal as the type
… the problems Peter described and pchampin mentioned, subgraph containment.

niklasl: I am not sure you understood me. I used 5 as an example because the use of it in a piece of paper is an occurence of 5

niklasl: If we say X is born in 1902 and somebody else too, those 2 occurences are what I am talking about

niklasl: I don't think we should go all that way to graph terms, it's out of the charter

niklasl: Named graphs being pairs of any term and a graph is very fine and the way it should be

niklasl: what the graph is is application specific, it can be a file or just the graph itself

niklasl: I like RDF-star triples for annotations (what is the source...)

doerthe: niklasl: do you affirm we don't need graph terms at all?

doerthe: We can do quoted triples with literals, but we still want to query that, have a mechanism to query that.

doerthe: I don't think the logical consequence of the graph is a logician problem, in SPARQL we implement entailment and it affects results

AndyS: I want to make an example. There are two occurences, they are triples about the same subject. You need to have a look inside of them.

AndyS: To niklasl, other than your concern of working with RDF 1.1, would having query statement like "the node having an occurence of X" works for you?

<AndyS> niklasl: "yes" to rdf:occurenceOf example

niklasl: I have no need for graph/triple term type, I would like to have more use cases. The proposal I made covers all the use cases I have seen

tl: The problem with type is that it's early optimization.

tl: As soon as you have two facts "bob said X on monday", you need an identifier

tl: as soon as you get into metamodeling it creates problem

pchampin: reaction to tl: in the CG the choice to make quoted triples type is not an optimization but as you pointed out forcing that all triples have an identifier is standard reification

pchampin: if RDF-star has been so popular is because of its simplicity

pchampin: but we are not bounded by the CG

pchampin: to niklasl you consider term in subject and object position to work differently. I have an issue with that. I don't avocate to change that. But the semantic does not care about this distrinction. Am I wrong that you make this strong distinction?

niklasl: Yes and no, I uses inverse all the time, there is no real difference between subject and object. Literals are fine to have them as subject but it's quite easy to missuse as subject. You would end up with JSON in RDF

niklasl: One of my problem with triple terms is that they change the semantics. I have to see if the value of adding them outweights the complexity

niklasl: The usecase is the measurement I have used to know this more confidently

niklasl: It's easy to do wrong when we have them

AndyS: I thought we were going to do something difference. I want to hear about the proposal and what they are going to change.

AndyS: We need to get a little bit more working on what the core principals are and spend time discussing how we move forward. I don't feel we have moved forward in any way

ora: Rather than saying what is the proposal you support we might answer instead to what are we willing to live with

ora: I am not entierly sure how to make progress

ora: do we need to be more clear about what the possible way forward are?

<doerthe> I will also have to leave

ora: Do we need to check at compatibility to see what people can live with

<doerthe> Bye

niklasl: We were talking about proposal 2 and I wanted to know how many people can live without triple terms

gkellogg: The minimum we can do is to do nothing, we do not harm

gkellogg: But we push the problem into the realm of syntax. I believe it's what peter was higlighting. We leverage the concepts we have and we do thing at the syntax level

gkellogg: For example, it works with list even if they are a pain to query

gkellogg: I don't think we need to go that if we bridge the gap about what a graph name means in subject and object

tl: Our problem is very complicated: metamodeling in RDF. RDF-star puts a lot of strings on users.

<Zakim> pchampin, you wanted to suggest to rephrase "can live without triple terms" into "cal live without extending the abstract syntax"

tl: I made a proposal that changes a very few things but I think it brings a lot. I would appreciate feedback and comments

pchampin: I was wondering if the spirit is more about living without triple terms in the abstract syntax rather leaving it untouched. Then there are the option of having graph and triple terms

niklasl: That's a good point. I don't think triple terms are possible without type. It's why I am suggesting annotation only.

AndyS: I cannot square we are not changing the abstract syntax if we are introducing occurences as a first class object

AndyS: It opens a question about replacement of blank node by uris

niklasl: every example I use serialize as nquads and the denotation is the same

AndyS: In this case, what about you write a document that describes how to do annotations in RDF 1.1

TallTed: niklasl: in terms of teaching RDF, you are teaching language, grammar. When teaching RDF concepts it does not matter that subject is restricted to not a literal, it's refinement

TallTed: RDF is at base a system of describing anything in statements of triples

TallTed: When the 4th column was added it was named "context" and not given a definition

TallTed: because people had different ideas of how to names them

TallTed: lots of people are using it as other than a named graph even if it's the most common usage

TallTed: Using it as named graph with a firm definition, we are going ahead of ourselves

<gkellogg> https://www.w3.org/TR/rdf11-concepts/#section-dataset

<gkellogg> An RDF dataset is a collection of RDF graphs, and comprises:

<gkellogg> Exactly one default graph, being an RDF graph. The default graph does not have a name and may be empty.

<gkellogg> Zero or more named graphs. Each named graph is a pair consisting of an IRI or a blank node (the graph name), and an RDF graph. Graph names are unique within an RDF dataset.

TallTed: our challenge is to make our changes as small as possible while still achieving what we need

TallTed: Something that does not exactly exists. Quad are not necessary, they are a sugar that disrupt the purity of the triples

TallTed: Getting all of this stuff to work right requires that we satisfy not only the new use cases but the old one

<pchampin> gkellogg, I think what TallTed is saying is that people are putting more "meaning" in the term "named graph" than what the spec says

TallTed: and apply on the existing systems

TallTed: I am afraid of the logical purity will distrupt people who use RDF today

TallTed: We have competing goals. There was a paper that people liked that was about bridging RDF and property graph

<gkellogg> pchampin, yes, I agree. My thought in 1.2 is that we should be able to talk about named graphs, or rather the graphs which are named by that pair.

TallTed: It turned out what we wanted is something to annotate and quote

TallTed: The annotation is talking about something asserted and quoting is about something not asserted

TallTed: Describing bridges between RDF and property graph is more important than building them

TallTed: We can't make veryone happy but we can deliver an improvement

TallTed: RDF built-in reification is ugly and nobody thinks that way

<pchampin> +1 to making most people mostly happy; hence the importance of "can you live with it?" questions

niklasl: I agree with that. Reification is explicitely talking about the token. The thing I propose uses only what is in RDF

AndyS: I heard TallTed say to respect what is already out there and using named graph in a specific way is not respecting what is out there

<pchampin> niklasl you are implying a specific relation between the graph and its name

AndyS: Currently we have a pair (graph, graph name) that has no defined relation between them

AndyS: I have asked on all proposal how they work on the abstract syntax level. I have not had answers.

tl: I have made a lot of work in my semantic proposal such that it does not interract to much with existing named graphs

tl: ...usages. You can nest named graph in some totally application specific named graphs

ora: I would need a lot of thinking on who to move forward

ora: to tl I need to understand about how his proposal interacts with SPARQL

ora: I agree with TallTed, the situation is exactly as you describe

ora: We need to answer what are the question we are trying to answer and find a consistent set of answers

ora: And leave things such that things that people argue are outside the charter can still be possible

ora: such that we don't close doors

ora: I urge people to think about the things they can and they can not live with

<pchampin> +1 to that :)

ora: I think it would be worthwile for everyone to think about what TallTed said

ora: I propose we are adjourned.

ora: we decided no meeting next week because of Thanksgiving

pchampin: next meeting will be a short meeting

ora: ...in two weeks

ora: I urge people to continue talking on the mailing list

ora: Happy thanksgiving, I feel very grateful for this group

Minutes manually created (not a transcript), formatted by scribe.perl version 222 (Sat Jul 22 21:57:07 2023 UTC).


Succeeded: s/grapohs/graphs/

Succeeded: s/quote/quoted/

Succeeded: s/ThomasL:/tl:/

Succeeded: s/gaph/graph

Succeeded: s/built on reification is hugly and nobody things/built-in reification is ugly and nobody thinks/

Succeeded: s/archiving what we need/achieving what we need/

Succeeded: s/requires to satisfy/requires that we satisfy/

Succeeded: s/people that people liked that was about briding RDF/paper that people liked that was about bridging RDF/

Succeeded: s/more important than solving them/more important than building them/

Succeeded: i/ora: Intro/scribe: andys/

Maybe present: fsasaki, tl

All speakers: AndyS, doerthe, fsasaki, gkellogg, niklasl, ora, pchampin, TallTed, tl

Active on IRC: AndyS, AZ, doerthe, Dominik_T, Enrico, fsasaki, gkellogg, gtw, niklasl, ora, pchampin, pfps, Souri, Souri_, TallTed, tl, Tpt