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://
<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.
scribe=
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://
<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://
<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