- From: Thomas Lörtsch <tl@rat.io>
- Date: Tue, 24 Jan 2023 16:35:13 +0100
- To: Pierre-Antoine Champin <pierre-antoine@w3.org>
- Cc: Franconi Enrico <franconi@inf.unibz.it>, RDF-star WG <public-rdf-star-wg@w3.org>
Pierre-Antoine, > On 17. Jan 2023, at 14:35, Pierre-Antoine Champin <pierre-antoine@w3.org> wrote: > > Dear Enrico, all, > following the discussion we had during the last call [1], I would like to give a more detail overview of our rationale when designing the RDF-star semantics in the CG report [2], and defuse a few misunderstandings. > > 1. It was not the intention to make RDF-star a modal logic > > I know that examples such that ":alice :belives << :s :p :o >>." strongly point in the direction of modal logic, and that such examples have been largely used to "sell" RDF-star. I agree that such examples are misleading, and we actually tried to avoid such examples in the CG report. It was foremostly the provenance use case that you called regrettable and misguided - which led to the seminal example being demoted to an error and historic relic [0]. > The intention was to make RDF-star quoted triples opaque, and providing as little inferences as possible The intention of the RDF-star semantics was never to help bridge the gap to LPGs or at least support RDF* as a more concise syntax to address the popular provenance use case. That all was considered semantically much too dangerous. But the chance was seen to shoehorn N3 formulas into quoted triples. That the consequence would be that 99% of users have to jump through crazy hoops to implement their middle of the road use cases in semantically sound ways was and is until today ignored [1][2]. > -- leaving it open for semantic extensions to provide more inferences. Those semantic extensions however were only referred to handwavingly as being "easy" to implement, until I pressed hard for at least a proof of concept. The result was a proposal to define transparency-enabling properties (TEP) per graph, per property [3]. I have never seen this proposal been mentioned, let alone applied outside the CG report (very understandably so, IMO). That is a problem. At least it shows that nobody respects the proposed semantics, if it doesn’t fit his/her niche use case anyways [4]. What does that mean for interoperability, for standardizing a semantics in the first place? That it is a failure, that it provides no assurance whatsoever that triples from an unknown source follow the standardized semantics. What does such a semantics buy us, except even more confusion about meta modelling and even more ressentment against the effort required by formal semantics? In the worst case it could even lead to referential opacity creeping into regular RDF. Thomas [0] https://w3c.github.io/rdf-star/cg-spec/2021-12-17.html#the-seminal-example [1] https://lists.w3.org/Archives/Public/public-rdf-star/2021May/0023.html [2] https://lists.w3.org/Archives/Public/public-rdf-star/2021May/0040.html [3] https://w3c.github.io/rdf-star/cg-spec/2021-12-17.html#selective-ref-transparency [4] I’ve seen only two applications ever abide by the proposed semantics: PAs "superman" example in the Lotico-talk and a poster at ESWC 2022, which used quoted triples for verification credentials. Both applications needed to hack quoted graphs by listing quoted triples to get their job done. > 2. Ground quoted triples are similar to literals > > Our initial attempt was to define from scratch a model theoretic semantics of RDF-star, where ground quoted triples (i.e. quoted triples containing no blank node) were constrained to denoted themselves. In other words, we consider that RDF(-star) triples (as defined by the specification) are conceptual objects that exist in the world (in the same way that graphs, classes and properties exist), and that ground quoted triples did denote exactly them. > > In that sense, ground quoted triples are very much like literals (except that they are allowed in the subject position). > > > 3. Blank node rain on our parade (as they usually do) > > Of course, things get tricky when we take blank nodes into account. > > Just like the RDF1.1 Semantics, our proposal was built in two steps : > - define the semantics of ground RFD-star graphs (following the rationale described above) > - deal with blank node > > The second step was quite complicated, and it raised some questions about whether this brand new semantics was sound. An alternative way was therefore proposed, to rely on the battle-tested RDF semantics. And that's where we are now. > > Honestly, I would rather give another try at adapting the current RDF semantics to take into account quoted graphs, than keeping the layered approach that we currently have. > > pa > > > [1] https://www.w3.org/2023/01/12-rdf-star-minutes.html#t03 > [2] https://www.w3.org/2021/12/rdf-star.html#rdf-star-semantics > > <OpenPGP_0x9D1EDAEEEF98D438.asc>
Received on Tuesday, 24 January 2023 15:35:37 UTC