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