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

I would be happy with Antoine's proposal as well! Regarding the naming ("RDF 1.2 Full Conformance" vs
>> "RDF 1.2 Weak Conformance" as suggested by Antoine or "RDF conformance" vs "RDF-star conformance" as mentioned by Ora), I don't have a strong opinion.

Olaf

Feb 1, 2023 17:52:12 Pierre-Antoine Champin <pierre-antoine@w3.org>:

> 
> On 01/02/2023 15:22, Antoine Zimmermann wrote:
>> 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)
> 
> I can definitely live with that, and prefer that phrasing at what Ora wrote in his mail ("RDF conformance vs. RDF-star conformance"). It hints better at the preference, also expressed by Ora, for people including the quoted-triples feature in their implementations.
> 
>> 
>> 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).
> 
> As a matter of fact, there is a point that I was meaning to bring up in the group :
> 
> the Dataset Exchange WG has a work item that has not received much love recently :
> 
>     Content Negotiation by Profile
>     https://www.w3.org/TR/dx-prof-conneg/
> 
> but which addresses exactly the kind of problems that we are going to face.
> 
> Mind you, I am not suggesting that we add this specification to our plate (on which we have more than enough!). But to liaise with the DXWG to provide them with our feedback and requirements on the matter. It so happens that I am staff contact of both groups, so I can play that role.
> 
> (but yes, of course, SPARQL Service Description are also a way to do that, at least for SPARQL endpoints)
> 
>   pa
> 
>> 
>> 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.
>>> 
>>

Received on Wednesday, 1 February 2023 23:43:08 UTC