W3C

– DRAFT –
RDF-star Working Group focused meeting

16 May 2024

Attendees

Present
AndyS, AZ, doerthe, Dominik_T, eBremer, enrico, fsasaki, gkellogg, gtw, ktk, niklasl, olaf, ora, pchampin, pfps, rubensworks, Souri, TallTed, thomas, tl
Regrets
fsasaki
Chair
ora
Scribe
pchampin

Meeting minutes

Feedback KG Conference

ora: the KGC keeps improving.
… There was a panel on graph standards.
… I gave a short overview of what's going on in our WG. There seemed to be a lot of interest in that.
… There was also a lot of interest in RDF-LPG alignment.
… People expressed interest in reasoning for LPG, shapes for LPG.
… Another topic was the use of LLMs wth KGs.
… Souri, you were here as well. Anything to add?

Souri: Alister mentioned the simplicity of the LPG model (e.g. property values limited to scalars).
… It is important that we provide a way to align RDF with LPGs. People who don't need it don't have to use it.

ora: we are definitely not working in a vacuum. People are observing and following.
… Now the GQL is out -- provided you pay a few 100$ for access.

Discuss Profiles 1 2 and possibly Singleton Properties 3

enrico: to summarize the state of the "profile" business
… we have two profiles with largely overlaping syntax.
… implementers can decide to implement one, or the other, or both.

<enrico> https://github.com/w3c/rdf-star-wg/wiki/RDF%E2%80%90star-examples-of-profiles

enrico: we need to decide if "both" is possible, and if so to decide on a syntactic marker to distinguish which is intended.
… Niklas wrote a number of examples. (link above)

gtw: my understanding of the two profiles was in the use of different predicates.

<niklasl> (Enrico wrote the examples, I mostly reformatted.)

gtw: My concern is that the syntactic sugar is defined in a way that favors one of the profiles.
… But looking at Enrico's examples, I am not sure. Both of them seem to use the same syntax.

enrico: the opaque triple terms have a quote around, but that's just a proposal. A nice one, in my opinion.

<niklasl> Another form thrown around uses <' s p o '> instead of <<'s p o'>>

enrico: it would be fine as it does not conflict with the IRI syntax.
… I'm not too concerned about syntax.
… We are not concerned about the predicate, but about the ability to distinguish the opaque profile from the transparent profile.

gtw: do you see this as a possibility that implementors implement both?

enrico: I have no crystal ball, but I expect everyone would implement both. I don't see a reason to implement only one.

gtw: it sounds like it would be possible to implement both; two predicates seems an important aspect of this design.

Souri: rdf:refies could be used in triple terms, like :a rdf:reifies << :b rdf::reifies << :c :d :e >> >> .
… Is there any demand for being able to do that? My sense is that it would be very low.
… If that is to be included in the standard, I would prefer it to be a SHOULD than a MUST.
… Implementations would like to not support it for performance.

enrico: the current abstract syntax forbids it. We can change that, but I don't think it would make much sense.

pfps: a couple of points should be made.
… 1. People talk of these as profiles, but they are different from OWL profiles (different proposals, vs. parts of a bigger language).

<niklasl> One example would be for reifying a data event where something other was reified.

pfps: 2. Transparent and opaque don't matter much with rdf:reifies. It tends to make transparent things behave much like opaque things.

ora: can you elaborate?

pfps: with a reifier, you don't get the kind of inferences you would get with a regular triple.
… With transparency, if two triples have the same denotation, you can mix and match their components.
… But this does not apply to reifiers.

enrico: that's fine. Different reifiers of the same triple can denote different things (a triple, an event).

ora: a question, just to clarify:
… in enrico's definition, a tuple with rdf:reifies in the predicate position is not defined as a triple, right?

enrico: yes

ora: in a SPARQL query, are those tuples invisible to SPARQL triple patterns?

enrico: you can consider that we have two kinds of triples: legacy-triples, and reifies-triples. But they are all triples.
… But all should be visible to SPARQL.

ora: I started wondering whether the association between the reifier and the triple term is really part of the graph, or if this is merely part of our book-keeping.

enrico: if we want to exclude reifies-triples, then they are more like "declarations", but there were arguments against separating declarations from statements.

doerthe: we got here (transparent / opaque profile) because we wanted to avoid having a reifier reifying multiple triples.
… ora, as you were concerned about this, would the opaque profile address your profile?

ora: I do believe it helps us.

<niklasl> My impression has been that the transparency version does not work with LPGs due to it's many-to-many nature; but that the distinct opaque version makes it clearer "a priori" which graphs are "LPG-compliant"?

ora: I'm extremely happy that the WG has indulged us in this regard.
… I understand both sides of the argument. The way I look at it there are multiple dimensions to it.

pchampin: what are we trying to achieve by preventing reifies-triples from being triple terms?
… Granted this is a corner case, but I would prefer a more regular model.

Souri: yes, for completeness, we may want to allow it, but in practice people would not need that.
… From an implementation point of view, I would make it more difficult for us to support that.

<gtw> +1 on this being an issue for efficient implementation

Souri: I'm not saying it should not be part of the standard, but if it is, the standard should allow vendors like us to not implement it.

ora: I can't even think of a use-case for those.

<gtw> obvious use case would be data provenance: "when did Ora insert this rdf:reifies triple?"

thomas: why not get rid of the abstract triple term as well, and define 4 elements in a triple (s p o id)?

enrico: you still need to define the relation between the triple term and the id.

thomas: then we need two kinds of quads. So what?

enrico: I read a lot of LinkedIn posts on this topic. You can see two camps: those who want transparent, and those who want opaque.
… So we need both.
… I wanted to give examples of how we can encode LPG in RDF, making them richer.

<niklasl> Very much a corner case, but e.g.: <record/version-2> rdf:reifies <<( <publication> rdf:reifies <<( <book> :publisher <org> )>> )>> . # in version 1 the <publication> "reifier" just reified another triple (the publishedAt date).

pchampin: I don't have a use case for reifying reifies-triples, but I am concerned that ensuring this restriction will be a hassle
… You would need to check every triple before turning it into a triple-term.

AndyS: To add to that: this would happen quickly with SPARQL CONSTRUCT.
… With variable you need to check it at runtime. It would create runtime errors, which would create usability problems.

ora: is this an argument for letting all flowers bloom, or for turning them into declarations?

AndyS: I don't know how it would look as a declaration.

Souri: reacting to what Thomas said about having 4 terms.

<AndyS> Also - rdf:refies in property paths

Souri: I'm ok with having rdf:reifies. But if we wanted 4 components, there would be a way to distinguish opaque vs. transparent.
… But I'm not pushing for the 4-components solutions.

enrico: if we used declarations instead of reifies-triples, we would be unable to query this.
… That's why at this point I don't think we should go for declarations.
… I suspect the regularity would not create too much implementation problems, but that's not my field.

<niklasl> (this would be named triples)

<enrico> :-)

pchampin: to AndyS' point about irregularity: we already have that with literals as subject with SPARQL CONSTRUCT
… we are ignoring it. Could we do the same with rdf:reifies in triple terms?
… (playing the devil's advocate, I prefer regularity :->)

AndyS: this would be more confusing

Souri: and a SPARQL CONSTRUCT could end up putting triple-terms in the subject position

AndyS: yes, or bnodes in predicate position

Souri: to pchampin's point, we could handle rdf:reifies in triple terms like we are currently treating those other irregularities

niklasl: question about the LPG case and transparency.
… If you migrate an LPG to RDF, you will and up with a lot of opaque stuff that you might not want to be opaque.
… It seems to me that the opaque profile came from the need to restrict the cardinality of rdf:reifies, not from a wish from LPG people to have only opaque.

enrico: cf. pchampin's counter-example with symmetric properties and transparent triple-terms.
… We need opaque for a one-to-one correspondance.
… If we want to talk about what these things mean (which LPGs don't do at all), you expand with transparent triple-terms.

ora: that's a good point. In many ways, LPG people (if there is such a group) don't understand when we talk about semantics.
… For them the semantics is only in their head.

enrico: there is a Property Graph Schema Language WG
… apparently, they consider that once a PG has a schema, they can reason with it.

ora: this is a new thing for their group.
… The have use-cases for validating PGs, which is a valid.

pchampin: my belief is that a one-size-fit-all tansformation will never be entirely satisfying.
… more accurate transformation will require a kind of "context", similiar to JSON-LD.

niklasl: we seem to represent the lack of known semantics with opaque triples.
… any syntax suffers from this lack, unless they are designed as concrete syntaxes for RDF.
… If you have to edit your data once you realize you needed RDF, to change triple-terms from opaque to transparent, that might be an issue.

ora: we are over-time, sorry thomas, we could not talk about singleton properties
… thanks everyone, good conversation. See you next week.

enrico: there will be a Semantics TF meeting tomorrow.

Minutes manually created (not a transcript), formatted by scribe.perl version 221 (Fri Jul 21 14:01:30 2023 UTC).

Diagnostics

Succeeded: s/LDP/LPG/

Succeeded: s/LGP/LPG/

Succeeded: s/p+//

Succeeded: s/an example/examples/

Succeeded: s/topic: report of the Knowledge Graph Conference/

No scribenick or scribe found. Guessed: pchampin

All speakers: AndyS, doerthe, enrico, gtw, niklasl, ora, pchampin, pfps, Souri, thomas

Active on IRC: AndyS, AZ, doerthe, Dominik_T, eBremer, enrico, fsasaki, gkellogg, gtw, ktk, niklasl, olaf, ora, pchampin, pfps, Souri, TallTed, thomas