naming RDF 1.2 without triple terms

[pfps]

There has been discussion in the working group on defining a version of the RDF that is produced by the working group with triple terms removed. I propose calling this version RDF 1.1bis. It would not be described as a profile of RDF 1.2 but instead as a minor update to RDF 1.1.

[domel]

Thank you for sharing the proposal for RDF 1.1bis. I wanted to ask if this direction is connected to the absence of profiles in RDF 1.2. Do I understand correctly that all new things will end up in RDF 1.2, and the RDF 1.1 specification will be slightly modified? Consequently, there will be no need to propose two profiles in RDF 1.2.

[pfps]

Yes. This would "remove" the requirement for profiles in RDF 1.2. Implementations that advertise RDF 1.2 compliance would have to support triple terms. Implementations that just want to fix/add some of the littler things (e.g., rdf:JSON) would advertise RDF 1.1bis. It's just a matter of branding, not any real change to what the working group is doing.

[pfps]

There would be no change to the RDF 1.1 recommendations, I think. They are not "living" specifications, at least as far as I know. Instead the RDF 1.2 recommendations would define what RDF 1.1bis is.

[afs]

What about initial text direction?

Would there be tests?

Having with normative or non-normative terminology (c.f. "generalized RDF", "symmetric RDF") may be useful. The "may" is because the WG has not determined whether "RDF 1.2 without triple terms" will have implementations. I'm a bit wary of introducing terminology if it has no practical adoption.

[domel]

Awesome. In my opinion, introducing profiles would unnecessarily complicate the ecosystem. I definitely support it.

[niklasl]

I think this could simplify matters (of assessing/adjusting existing implementations and hopefully of communication). But as @afs says, it depends on how it will practically aid such things. A dedicated set of tests would be useful.

I'd expect a fallback for initial text direction to be a part of this (e.g. lang+dir as special datatype).

Will there also be a need for explaining how to upgrade RDF 1.1bis-compliant data containing unstarred triple terms and/or lang+dir literals to RDF 1.2?

[pfps]

If there are no implementations of the triple-term-less variant of RDF 1.2, whatever it is called, then there is no reason to worry about it.

My suggestion would be to send a message out on an official W3C mailing list asking whether there is any interest in implementing the triple-term-less variant of RDF 1.2. If there is no interest, then don't define it. If there is interest then work on figuring out just what is in it and how to test for compliance.

[niklasl]

I believe one motivation is to have compatibility with existing RDF 1.1-based systems, who ideally would work with RDF 1.1bis-compliant data without alteration (unless they drop unrecognized terms in the RDF vocabulary). I added a wiki page about one way of doing such conversions.

[gkellogg]

I believe one motivation is to have compatibility with existing RDF 1.1-based systems, who ideally would work with RDF 1.1bis-compliant data without alteration (unless they drop unrecognized terms in the RDF vocabulary). I added a wiki page about one way of doing such conversions.

Note that the SPARQL does not work for embedded triple terms unless the query is repeated until the triple count becomes stable, or similar condition.

[niklasl]

Note that the SPARQL does not work for embedded triple terms unless the query is repeated until the triple count becomes stable, or similar condition.

Good point! Added that to the page in a note.

[kasei]

If we think it's important to allow some systems to support new features without supporting triple terms, I don't think an RDF1.1bis is a good idea. That might work in the short term, but the next version of RDF and/or SPARQL to introduce updates (1.3, or maybe 2.0) would very likely just build on 1.2. At that point, what happens to the systems that don't support triple terms? Either they're forced into supporting triple terms to conform to the new standard, or perhaps the WG is forced to continue updating 1.1 beyond 1.1bis?

In my opinion, it all boils down to how serious we are about letting systems avoid supporting triple terms. If there's a reason to do that, it should be as part of 1.2.

[afs]

@kasei has a good point about the long term implications of bis. It's permanent and sets an expection for future versions. Same for profiles.

Keeping it specific to the features rather than "bis" would be better -- e.g. "RDF 1.2 with unstar", "RDF 1.2 transition", "RDF 1.2 for 1.1".

There are possible variations: accept triple term syntax at the boundary, applying unstar on ingestion - the user/application of the data (application) is not aware of triple terms but the system accepts RDF 1.2.

[Antoine-Zimmermann]

There has been discussion in the working group on defining a version of the RDF that is produced by the working group with triple terms removed. I propose calling this version RDF 1.1bis. It would not be described as a profile of RDF 1.2 but instead as a minor update to RDF 1.1.

This was already resolved a year ago: RESOLUTION: Adopt all 3 proposal from AZ.

The "3 proposals from AZ" are those found in my comment on 5 October 2023 to #19.

Was this resolution overridden by further discussions? If yes, can you provide a reference to them?