RDF-star WG biweekly long meeting

Discussion on Andy's updated post

Enrico: Yes, and the meaning of the triple terms themselves is hard to understand. And the meaning in terms of as resources can be bizarre.

Andy: That's one of the most important points. What happens if we put occurrences into the data model instead?
… Instead of triple terms and associate these with a relationship.
… So I rewrote this in terms of occurrences. But how do we get from the occurrence to the triple itself? What's the subject, property, object of the occurrence?
… In theory you could scan the graph. But it doesn't help if the triple isn't asserted?

Ora: does this imply that it becomes brittle?

Andy: Not brittle, but harder.

Enrico: Just like with unstar, the solution can be to add an invisible relationship (rdf:occurrenceOf).
… to optimize like with standard SPARQL

Andy: would it be three triples?

Enrico. With only named occurrences in the syntax, that's equally expressive as triple terms in the object position, but disallow writing that explicitly.
… with an automatic syntactic restriction

Andy: If the name is a URI can you get the resource information (the triple)?

<Souri> Would this work? => select ?s ?p ?o { ?n :start 1885 . ?s ?p ?o | ?n }

Enrico: yes the triple can be found via the rdf:occurrenceOf

Andy: the thing in the object position can be a list of three things. But not a triple term

Peter: This is close to standard reification. But these extra triples was the problem.
… I don't see a need for this. To get the occurrence, put variables to find them.
… It's clunky, but this proposal is not less clunky.

<pfps> If you want to get at the parts of a triple occurerence, just query for << :r | ?v1 ?v2 ?v3 >> ?v4 ?v5 .

Andy: With the three operations on graphs: add, delete, find; if we have an abstraction here, the change is bigger to get the equivalent find operation.

Peter: We're trying to get around clunkiness by other other clunkiness.
… there's no way of hiding anything in SPARQL. So with Enrico's proposal you can't hide anything.

<pfps> The other problem with treating triple occurrence is that SPARQL will be able to see them using variables.

Enrico: My suggestion would be to have Andy's syntax, and allow querying with variables. With named occurrence syntax, the unstar operation is systematically applied, and this is what is queried.
… you can never get back the rdf:occurrenceOf or the reification parts (??)

Ora: are we moving to a case where triples are invisible in the query results? Or left to implementation detail?

<AndyS> SELECT(count(*) AS ?c) { ?s ?p ?o }

Enrico: the surface syntax never shows the unstar parts. The internal impl. will use them.

Gregg: We're sort of back to triple terms as types except they're restricted. They're a bit like literals but queryable.
… I'm not comfortable with a magic thing, invisible in syntax, but you can query around it...
… Better to go back to a triple term. The semantics are tricky, but we've never solved that. Also the question of what the identifier identifies -- a unique occurrence? But inference prevents that.
… Seems very muddy.

Enrico: It looks muddy, but it's a misunderstanding. The elements of a triple are accessible, it is not a literal. The triple is a named occurrence, with no semantics in itself. Can only appear in the object position.
… If we modify the syntax to only allow triple terms in the object position, we can query their parts.
… I'm neutral wrt this proposal and the original one.

niklas: Like gkellogg, can't see how "internal only" works out.
… we don't have "ill-formed" reifications eg. two subjects
… no material difference to consolidation v1 (with triple terms)
… unstar brings along the same consequences as the old reification

Andy: Are we saying that there's no use case for making statements about triple terms?

<draggett> A test case for my understanding: << :JohnWilkesBooth :assassinated :AbrahamLincoln >> dc:date "1865-04-14"^^xsd:date .

Andy: But if that's wrong we have to change how we approach the problem space.
… it doesn't have the property explosion issue. It's a structural list of s,p,o.

<enrico> query: << ?v0 | ?v1 ?v2 ?v3 >> ?v4 ?v5 . This corresponds somehow to query: ?v0 rdf:occurrenceOf << ?v1 ?v2 ?v3 >>

Enrico: written in IRC how to access it without writing the relationship.
… the TC of Dave, it is not an exact test case for triple terms.

<pfps> that looks just like what I typed above.

Enrico: the UC of Dave, it is not an exact test case for triple terms.

In natural language you have to identify the reference of a description.

Enrico: In natural language you have to identify the reference of a description.
… Any wedding, any president. But the proposition does not have a time. It's a truth bearer. It's not a truth maker.
… You need to name the proposition to describe it. The term itself can appear in this discourse. But we have no use cases for this.
… A proposition does not have a date, etc.
… If a triple term denotes a resource you need a bijection. Thuth makers are occurrences (in philosophy).

<Zakim> AndyS, you wanted to respond to draggett

Enrico: We could have it, but it would be *very* powerful. And people would not understand the difference. And a bijection introduced here would be complicating(??)

Andy: Enrico covered it. Are there any cases where it *must* be a type?

<Souri> +1 I agree

Dave: Can we explain our ideas simply? For the property graphs people?

<AndyS> +1 to needing a simple explanation of what we add.

Souri: What are the requirements? Any annotations allowed only on the occurrences? Or on the types too?

Ora: Related to PGs that Dave mentioned, people who use PGs treat the graphs as a data structure, and invent their own semantics.
… We don't do that in RDF. We have to explain this, but there are apples&oranges differences here.

niklas: I agree with Ora
… PG edges has a use/meaning that makes duplicates possible.
… we can aim to represent the same information as a LPG

Souri: I agree with a lot of that. We have experiences with PG users. RDF is all about triples; conceptual relationships. Does a relation *exist* or not. In PGs, it's "just edges".
… In PGs, every edge has an ID (that's how it's managed).
… The way the data is (re?)presented, every edge has an ID. We do need to tackle edges. Jesus Barassa had a paper(??) about that.
… Occurrences are all about edges.
… RDF triples from 1.1 and we add occurrences for those, as edges, and we can describe these further. PGs can only add values, not relationships. But we can do that in RDF.
… In my last email I wrote about RDF triples, and edges. The connection between them *is* the s,p,o. If they share these, the edge is an occurrence of the triple.
… My point is: we need to support occurrences. We could call them edges, vs. the conceptual distinction to triples.
… But do we need to support annotations about triple types? If not, everything is easier.

Enrico: I don't share the pessimism of not being able to represent PGs.
… Look at GraphQL (GQL).

<ora> GraphQL != GQL

Enrico: The mismatch of multiset or set is not it. The semantics (??) ... We have to find instances of properties to correspond to edges (??). I can repeat relationships in UML, etc. Internally, the edges are distinct. Different in space.

<draggett> For GQL, see: https://www.gqlstandards.org

Enrico: the multiedge problem does not exist in standard RDF
… but we need RDF-star to attach properties to them
… we have to reify them, to attach properties to occurrences

Ora: What would the PG schema proposal look like in RDF? PG schema defines types, but those are not visible to the graph itself. Labels are not types.
… It is confusing to explain these to the PG and RDF camps respectively.
… What RDF has now is a separate type system for the edges.

Olaf: I see it differently from Enrico. There is a difference between edges in PGs and triples in RDF. The PG-edge has an identity. It is not only the label of the arc. It has 3 elements plus identity. In RDF, the triple identity *is* the 3 elements.

<Souri> +1 to what Olaf said about PG having an edge identitiy -- a fourth element

Olaf: This is the core of the differences for multiedges, identifiers for occurrences.

Gregg: This is reconciled by the identifier on the triple occurrence.
… The identifier is what you can annotate. In my mind that is a unique identifier. Anything inferred on that is an other occurrence (perhaps automatically identified).
… In PGs, I take it that edges have unique identifiers.
… In a concrete syntax, the use of the occurrence syntax has the effect of create an occurrence. It should not be illegal to construct a triple term from that, but discouraged; like
… a bnode only used once.

Ora: I have also seen PG use establish a vocabulary that essentially looks like RDF schema.
… This looks like the PG being used essentially as RDF

<AZ> Erich is mentioned as scribe

Enrico: posted in zoom, an illustration

Olaf: that's essentially singleton properties

<Zakim> draggett, you wanted to ask about relevancy of the semantics of who said what, in which every statement is asserted by someone/something

draggett: saying something doesn't mean it's true, just soemone assuming it is.

ora: that was the purpose of reification, but the semantics where never quite figured out

andy: occurrences

niklas: claims as opposed to assertions

<enrico> BTW, our occurrences are called in philosophy "relators" or (worse) truth-makers.

andy: rrdf 1.1 discussions - a reification is just a claim. only when it goes into your graph you assert it

andy: similar in datasets: the default graph is the one that you assume is true

ora: assserting something means you think it is true. another possibility would be a language that differentiates between claims and what you endorse. but would like to not get there with this WG

ora: just add edge properties

<Zakim> Souri, you wanted to ask again about the requirements: Is it sufficient to support annotations only for occurrences (or "edges")? Or, Do we need to support annotations for regular RDF (type) triples as well?

souri: annotations only to occurrences, or to regular rdf type triples?

andy: argues for a simple base line, check if it's sufficient, and expandable

<Zakim> enrico, you wanted to answer that we don't have use cases for annotating triple terms

<Souri> +1 fully agree to Andy

enrico: see no use cases for annotating triple terms (only very niche ones for linguists)

enrico: named occurrences are transparent, but can be used to introduces various levels of opacity, emulating modal logics, superman use case etc

<gkellogg> +1 triple terms are opaque, occurrences are transparent and imply the existence of a corresponding triple term.

enrico: so we can say that my belief is different from your belief, including what IRIs we use etc. that could open the door to named graphs

enrico: named graphs would need some form of opacity

ora: propose to have that discussion about named graphs and opacity in the semantics tf

ora: and modalities

niklas: some open problems, eg naming different triples with the same name

niklas: one can always declare an occurrence to refer to the type

ora: we need one concrete proposal to make progress. how do we get to that proposal?

ora: maybe form a subgroup?

<niklasl> +1 for a focused subgroup

<enrico> +1 for a focused subgroup

ora: proposal needs to be concrete so that the WG has something to discuss not as abstract as teh questions we often discuss

ora: broadly what this thing should look like (e.g. not necessarily all syntactic detail)

ora: "the big things"

andy: so probably you mean the introductory paragraph, impact on data model, syntax, outline of the semantics, consequences on sparql, but fairly concisely (no explanations, but definitions)

ora: agree, but de-emphasize the importance of syntax

<Zakim> enrico, you wanted to say that the answer ro niklas on naming different triples with the same name is: yes, we should allow that

enrico: same uri for different triple terms should be allowed

enrico: abstract syntax in my document in the wiki, could be a starting point for subgroup, maybe extend with an unstar mapping

<AndyS> Enrico's wiki page: https://github.com/w3c/rdf-star-wg/wiki/Semantics:-Andy's-proposal

gregg: we need to understand effects on rdf concepts, implications on semantics, sparql. rather not have another Note

gregg: triple term as part of abstract syntax might be necessary, even when going for occurrences

souri: we need to understand what are the requirements. what is the base line, what are niche cases? must be simple for RDF and LPG users

souri: one uri for multiple triples is important to model graphs

niklas: refers to enricos email about the same id for multiple triples (functional restriction)

<niklasl> tl: the same IRI for two triples either is impyling sameAs, *or* graphs

tl: danger of not defining graphs right away: people will find workarounds like using the same IRI to name multiple triples (versus infering those as owl:sameAs). we will not be able to reconcile those deviations later, leading to another lost opportunity to define graphs with sound semantics in RDF (and we have run out of brackets already)

andy: but adds more dimensions, more decisions to be made

andy: requirements and use cases should be responisbility of the whole WG, not some subgroup

<Souri> +1 to starting with smaller set of requirements ... once we get that done, we look at what more could be done without complicating the baseline too much

<Souri> +1 to requiring the whole group to agree on the baseline requirements

niklas: focus on triples should make things easier

enrico: triple equality vs functional relation - will have to be discussed in sem TF

andy: semTF slot to be used for a small group to come up with a concise proposal: occurrences, preserve RDF 1.1 semantics (merge)

AndyS: nail out process

<Souri> what's the time for the semantics slot?

<enrico> 4pm cet

enrico: we can use the semTF slot for that subgroup

<Souri> 10am EST (4pm CET) works for me ... Could someone please send me the invitation?

<TallTed> it's at https://www.w3.org/events/meetings/6d0cd306-0be8-4267-865a-6272cc8d9da4/ ... updating that event triggers email to the TF, but not to the WG as a whole

<enrico> https://www.w3.org/groups/tf/rdf-star-semantics/participants/

ora: will notify mailing list about new subgroup

<niklasl> https://www.w3.org/groups/tf/rdf-star-semantics/calendar/

<ktk> calendar would be here https://www.w3.org/gtoups/tf/rdf-star-semantics/calendar/

<Souri> I just need a link "Join ..." similar to what I see in Adrian's invitations

<ora> https://www.w3.org/events/meetings/6d0cd306-0be8-4267-865a-6272cc8d9da4/20240105T100000/

<TallTed> corrected event link: https://www.w3.org/events/meetings/6d0cd306-0be8-4267-865a-6272cc8d9da4/20240105T100000/

<TallTed> zoom links (especially including passwords) are still best kept out of publicly posted things (like minutes and IRC logs)