Re: Why is the RDF-star working group standardising RDF 1.2 and SPARQL 1.2?

My $0.02:

It is clear to me that we have to clarify exactly what it is that we are doing (hoping to do) and why. The way I look at it, there are two documents that we need to consider very seriously: The charter of the RDF-star WG and the final report of the RDF-star CG. The charter sets the “boundaries” for our work, the CG report represents a large body of work I am hoping we do not have to redo (but can, if we absolutely want to).

Regarding the charter, it does say that we are to publish RDF 1.2 and SPARQL 1.2, but I now realize that various people have differing interpretations of the charter. The big question, in my mind wrt. how to interpret the charter, is whether the “RDF-star features” are an add-on that people later can sort of take or leave. What we need (irrespective of version numbers) is to spell out “RDF-conformance” and “RDF-star conformance”. The new specifications will spell out what, exactly, was added. I am thinking that then future implementors could choose whether to support these added features or not; I very sincerely hope that most implementors do choose to support them, of course.

We are talking about evolution of RDF, not a disruptive revolution. To me it is unacceptable that “old” RDF documents would become invalid, would change vis-à-vis their semantics, etc. Backwards compatibility should be a given, unless there are details where someone can convincingly argue that we have to forego it.

The charter does spell out what is “out of scope”, but also makes it possible for us to decide to bring in work that is already “in flight” in the RDF community. The way I look at this, the priority is to get the “RDF-star” features done, but we can discuss what else we want to do.

Having said all this, I think the really important discussion to have should be about conformance and how implementations communicate exactly what it is that they conform to (i.e., what they support). But for now, let’s not get hung up on names (“1.2” vs. “-star”, etc.), let’s focus on the substance of the new specs instead.

Ora

--
Dr. Ora Lassila
Principal Technologist, Amazon Neptune



From: Pierre-Antoine Champin <pierre-antoine@w3.org>
Date: Friday, January 27, 2023 at 12:25 PM
To: Antoine Zimmermann <antoine.zimmermann@emse.fr>, <public-rdf-star-wg@w3.org>
Subject: RE: [EXTERNAL]Why is the RDF-star working group standardising RDF 1.2 and SPARQL 1.2?
Resent-From: <public-rdf-star-wg@w3.org>
Resent-Date: Fri, 27 Jan 2023 17:24:27 +0000


Antoine,

a few reactions to some of the points you make
On 27/01/2023 11:49, Antoine Zimmermann wrote:
This is an email I have been wanting to write for a long time.
The subject is a rhetorical question, please do not answer it out of the context of this email.

RDF-star is undeniably a success in terms of adoption by companies and various implementers. It is, for sure, improving the data management in triplestores. A community group crystallised the specification so that it could go to standardisation.

But instead of standardising RDF-star and SPARQL-star as new standards on top of RDF and SPARQL, it is trying to squeeze it into RDF and SPARQL core. I will not talk much about SPARQL-star and concentrate on the RDF part.

Now, for me, RDF-star should play a role similar to what RDF datasets are playing.
And yet, datasets were not introduced as "a new standard on top of RDF", they were added to RDF 1.1 as an integral part of it.
RDF datasets exist for better data management and query features. They do not interfere with the way RDF works, nor with any technologies that go on top of RDF. However, if RDF-star becomes the new RDF, it very explicitly interferes with everything on top of RDF.
I agree that we need to figure out a way to design RDF 1.2 with minimal impact on everything that currently exist. And yes, this will probably be more tricky than the addition of datasets in RDF 1.1.

Every implementation that relies on RDF processing would have to be updated, lest they fail to be interoperable any more. I know, from the RDF 1.1 working group, that there are implementations that require the assumption that there will be only blank nodes or IRIs in subject position. There are vendors who consider that adding support for a new type of things in subject position would have dramatic cost. These companies would need to be convinced they'll get a lot of money from RDF-star in order to accept to pay the cost.

Then there are standards, or community specifications that rely on RDF. RDFa, SHACL, SWRL, N3, RIF, R2RML, etc. What is a Web Ontology Language for RDF-star? If OWL can be used together with embedded triples, it opens a lot of possibilities, causes a lot of consequences, and brings a lot of questions. The RDF-star semantics is not well crystallised. There are people even in the community group itself that do not like the final version of it. Me first. There isn't a consensus on how to fix it. An RDF-star community consensus is, I expect, possible to reach within the duration of this WG. However, we've open the RDF 1.2 working group, albeit in disguise.

I resent the implication. Read the charter<https://www.w3.org/2022/08/rdf-star-wg-charter/> again. There are many things in it that leave no doubt, in my opinion, on the fact that the goal was to update the RDF and SPARQL recommendations (if only the list of deliverables, all starting with "RDF 1.2 ..." and "SPARQL 1.2 ...").

One reason to keep the name "RDF-star" for the group was to insist on the fact that other new features were, for the moment, out of scope. In hindsight, that was probably a bad move, creating wrong expectations on the scope of the group.

And there comes a big issue. With an RDF-star WG that is implicitly an RDF 1.2 WG (and SPARQL 1.2 WG), we must accept the RDF community at large to join the discussion.
Yes, indeed!
Enrico, for instance, was not in the CG and he genuinely wants to understand how things are supposed to work with quoted triples. The CG report is not clear about it, as it provides explanatory text that suggests something, while the formal semantics suggests otherwise. Of course, I understand Ted's frustration as the CG has indeed talked about the semantic issues ad nauseam. But if you want to standardise RDF 1.2, you have to get people from outside the CG. And you can't just expect that they read the 1,000 pages of discussions and listen to hours of audio recording of the calls (recordings that don't exist, by the way).

I don't think that is what Ted implied either.

In my view, everything that is in the CG report is open for discussion. But the efforts that the CG has put in it should not be neglected either.

Ora, in one of the earlier meetings, said he wished the work be done in one year. This is, I suppose, doable if the RDF-star group standardises RDF-star. However, 2 years at least are certainly needed to standardise RDF 1.2 and SPARQL 1.2, no matter how limited the charter is. And in this case, I have the impression that some people underestimate how big the charter is. There seems to be people thinking that the CG report is the specification that simply needs to get a stamp of approval. But even if there was a consensus on it, this specification has a lot of consequences on everything on top of RDF, especially semantically. There are open questions that are to be addressed by research, not by W3C WGs.

For instance, RDF-star introduces a whole new set of entailment regimes. Is there expertise in the group about how this is going to be handled in the SPARQL 1.2 Entailment Regime spec? How does SPARQL-star with OWL 2 RDF-star-based semantics regime work?
(I have ideas about that as well, but I'll keep them for a discussion focused on semantics rather than the scope of this group)

There is also the issue of the education and teaching. I teach a Semantic Web course. Imagine I introduce RDF 1.2, with embedded triples. Then I talk about ontologies, SHACL, and more, and there aren't embedded triples anymore!

How do you deal, today, with the fact that SPARQL and OWL are based on RDF 1.0, then? And have this strange notion of "plain literal" that does not exist in RDF 1.1? Also, RDF 1.1 has datasets (as part of the core model, I insist), and yet OWL can only reason about a single graphs...

My point is: the situation today is already messy, but we deal with it. We can't evolve the whole semantic web stack in one go. We have to start somewhere.
I'd rather introduce RDF (1.1), SPARQL, OWL, SHACL, then introduce the extension, RDF-star and SPARQL-star, if I want to get deeper in the data management part.

Here is what I would like to see:
 - RDF-star, a data exchange model for RDF data management. It's not replacing RDF, it is complementary to it.
 - SPARQL-star, a query language for RDF-star and RDF-star datasets.
 - As far as the semantics of RDF-star is concerned, make it critically minimal. Just interpret embedded triples as arbitrary resources.(*) If someone wants to do more reasoning, they can just invent a semantic extension.
This way, just like RDF datasets define a data model on top of RDF without replacing it, with SPARQL a query language for this model, we would have RDF-star as a data model on top of RDF with a query language for it, mainly for data management purposes, but which does not preclude other usages, just like RDF datasets can be used for many things beyond partitioning graphs. Then there would be no discrepancy between SHACL and RDF, OWL and RDF, RDFa and RDF, and no need to define SPARQL-star entailment regimes. SPARQL Service description could be updated to be able to mention that a system supports SPARQL-star.


Now, I am conscious that this does not help at all going forward in the direction of the charter, but I needed to say it, and I'd better say it early.

On the contrary, I think your concerns, about making the transition painless for existing system, are very valid and must be taken into account.

  pa


(*) RDF-star basic semantics would be defined on any RDF-entailment regime by adding a mapping IT from embedded triples to the set of resources IR. Under this basic semantics, embedded triples simply act as distinct names, as if they were IRIs. This does not preclude extensions where the internal structure of the embedded triples makes a difference.