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

Dear Ora,


This is the kind of answer I was hoping for, thank you!

If I follow well what you say, there could be two kinds of conformances 
in RDF 1.2:
  1)  RDF 1.2 Full Conformance (implementing all of RDF-star)
  2)  RDF 1.2 Weak Conformance (not implementing stuff that relates to 
embedded triples)

And we will specify the mechanisms that allow an implementation to 
clearly declare which conformance it satisfies (e.g., via SPARQL Service 
Description or similar).

If this is the case, then it would be easy (easier) to ensure that the 
upper stack of the standards is not disturbed much by what this group is 
building. We can update RDF such that the current versions of OWL, 
SHACL, RDFa, etc. will be part of the RDF 1.2 Weakly conformant stack.

Is this something that the members of this group would be willing to 
accept?  I can live with that.

With that said, I still consider that the amount of work is quite 
daunting, and the path towards a consensual semantics is strewn with 
pitfalls.


--AZ


Le 01/02/2023 à 14:56, Lassila, Ora a écrit :
> 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.
> 

-- 
Antoine Zimmermann
École des Mines de Saint-Étienne
158 cours Fauriel
CS 62362
42023 Saint-Étienne Cedex 2
France
Tél:+33(0)4 77 49 97 02
http://www.emse.fr/~zimmermann/

Received on Wednesday, 1 February 2023 14:24:29 UTC