work with antoine and others to come up with a proposal for weak and strong compliance

[ghurlbot]

due 16 Feb 2023

[TallTed]

We might consider conformance levels like were in SQL-92 (Entry, subset of Intermediate, subset of Full), or be more like SQL-99 and later (a long feature list, with a Core subset of these required for conformance, and all the others being optional)...

[Antoine-Zimmermann]

I can imagine two ways of dealing with this:

1. Define 2 ways of conforming to the RDF 1.2 spec (weak vs full)
2. Define explicitly a subprofile of RDF 1.2 (e.g., "RDF 1.2 no-star")

In case of 1., we define a single data model, RDF 1.2, and its query language SPARQL 1.2, that comprises embedded triples and all. Then, identify two ways of conforming: full conformance and weak conformance. Weak conformance does not mandate supporting embedded triples. Only test cases that do not make use of embedded triples have to be passed for weak conformance. Specifications that are built on top of RDF 1.2 can be weakly conformant by extending only the part of RDF 1.2 that does not use embedded triples. If RDF 1.2 minimally extends RDF 1.1, then it is possible to make RDFa 1.1, OWL 2 and SHACL weakly conformant specs over RDF 1.2 without change.

In case of 2., conformance is defined similarly to OWL 2 EL, QL, RL. That is, there is no "weak" conformance, simply implementations of RDF 1.2 no-star along with implementations of complete RDF 1.2 (same for SPARQ 1.2 vs SPARQL 1.2 no-star). RDFa 1.1, OWL 2, SHACL would be compatible with RDF 1.2 no-star, if RDF 1.2 no-star is backward and forward compatible with RDF 1.1.

[pfps]

Are weak conformance and RDF 1.2 no-star going to be any different from RDF 1.1?

[rdfguy]

I hope not. Why would it be?

[pfps]

No reason that I can see, as the whole idea of the working group is to add embedded triples.

I can perhaps see some minor changes to fix errata, but I hope that these are all things that are already being done.

[Antoine-Zimmermann]

RDF 1.2 no-star should be almost the same as RDF 1.1, but it is possible that we introduce minimal backward and forward-compatible changes (e.g., by addressing the errata) that require minor updates on conformant implementations. E.g., assume we standardise the datatype rdf:HTML.

[pchampin]

FTR: part of the conversation happened on the mailing list: https://lists.w3.org/Archives/Public/public-rdf-star-wg/2023Feb/0092.html

Personally, I like the terms "classic"/"full"

[TallTed]

I'm OK with "classic" and "full". I think I prefer "extended" for the latter.

"1.1.1" and "1.2" might make sense, if we were going to publish a full raft of 1.1.1 docs along with a full raft of 1.2 ... but I think this would be out of reach.

[afs]

"classic"/"full" is OK for now and seems the most robust naming to separate "with" and "without" quoted-triples.

We'll probably only be able to finally decide when all errata and their changes are seen.

[Antoine-Zimmermann]

To be clear, what does "classic" designate? I see 3 possibilities:

1. A type of RDF 1.2 graphs. Compare this to "ground graph" to designate graphs that don't contain blank nodes. If you just support these types of graphs, you don't get special conformance validation.
2. A sublanguage, or "profile" of RDF 1.2. That is, it defines the language and specification that is syntactically based on a type of RDF 1.2 graphs as in 1. It can require specific conformance constraints and additional normative stuff. Compare this to OWL 2 profiles. They are not just types of ontologies (as one could also name other types that are not profiles, such as ontologies with acyclic TBox). If you implement this profile, you get the label "conformant to RDF 1.2 classic".
3. A weaker kind of conformance to RDF 1.2. Compare to an OWL 2 DL engine that does all of OWL 2 DL except key axioms. It rejects all OWL 2 ontologies that have this construct, but it respects everything else in terms of conformance. This could be the OWL 2 DL classic conformance (obviously, there is no such things, it's for illustrative purposes). Maybe this means that some "MUST"s of RDF 1.2 can be interpreted as "MAY"s and one still gets the label "classically conformant".

I believe by "RDF classic", people means item 2. however, issue #33 is asking for a name for 1.

[afs]

Note : PR w3c/rdf-concepts#32 insert text that relates to this issue.

[Antoine-Zimmermann]

With Ora, we discussed this a bit and came up with these 2 proposals:

PROPOSAL 1: Define two levels of conformance, namely "Full conformance" that supports graphs and datasets containing quoted triples (in parsing, processing, querying, or reasoning); and "classic conformance" that only supports graphs or datasets that do not contain quoted triples.

The second option could be:

PROPOSAL 2: Define two profiles for RDF 1.2, namely RDF 1.2 Full that describes the full language including quoted triples, and RDF 1.2 Classic that only includes graphs that do not have quoted triples. Implementations MAY support RDF 1.2 Classic without supporting RDF 1.2 Full.

(BTW, we need a name for the concept of "graphs that do not contain quoted triples")

[TallTed]

Another possible pairing — RDF 1.2 Basic and RDF 1.2 Complex

[afs]

I think we have to give a definition for RDF 1.2.

It would what text/turtle provides. Unless we are forking the data model, that would allow all possibilities - with quoted triples, text direction and errata.

To make the default a restricted subset will not help uptake.

RDF 1.2 and RDF 1.2 Basic perhaps.
There may be an informal qualifier of "Full" for RDF 1.2 to help when discussing the two together.

Thought experiment: Would there be a "RDF 1.3 Basic"? Or is this a migration helper at 1.2?

[rat10]

"RDF 1.2" and "RDF 1.2 Star".
Treat quoted triples as a semantic extension (but include that semantic extension in the RDF 1.2 specification suite, giving it high visibility).
Pave the way for more semantic extensions (i.e. incentivize them - "look, they can actually make it into the specification").
Semantic extensions are a quite natural way to implement a "living standard" while ensuring backwards compatibility.

Eventually specify RDF 2, integrating the most natural/successful extensions into a coherent, maybe not fully backwards compatible next version of RDF (e.g. postpone the question of competing and overlapping primitives like named graphs and quoted triples until then).

RDF-Star still has a lot of problems and there's little experience and shared understanding of the corner cases, where the simplistic idea of quoted triples breaks - especially with multiple instances, but also semantics, bnodes etc. It would be prudent to not fully integrate them into RDF Core just yet.

[afs]

Quoted triples are an integral part of the RDF data model.

[rat10]

Right, still an extension though. Since backwards compatibility will always be very important, also in a "living standard", it might still be an approach worth considering.

[afs]

"Extension" has many possible implications. It can imply "in addition to normal". It is an extension to RDF 1.1 (as would be initial text direction).

What is important to me is "What is RDF 1.2?". (OWL Full is not the same situation.)

If we make quoted triples an additional feature, we may be implying we expect general purpose toolkits and platforms to be treat it as an extra. We should be considering the whole technology pipeline.

Example: some system do not use blank nodes. They still use the commonly available RDF tools and systems.

[rat10]

"Extension" has many possible implications. It can imply "in addition to normal". It is an extension to RDF 1.1 (as would be initial text direction).

Making it an extension to 1.2 and justifying the bump to 1.2 exactly with the introduction of that extension would give RDF-Star a good deal of visibility and thrust and would still give us some flexibilityin the future to correct (or recover from) its shortcomings.

What is important to me is "What is RDF 1.2?". (OWL Full is not the same situation.)

You would like it to be "RDF-Star 1.2" because you think its good enough, and I wouldn't because I think its too bad - that's the issue. My proposal tries to balance those two assessments.

If we make quoted triples an additional feature, we may be implying we expect general purpose toolkits and platforms to be treat it as an extra. We should be considering the whole technology pipeline.

Bluntly: RDF-Star isn't well defined. Standardizing it in its current form will buy us nothing but trouble. I wouldn't want to make tool vendors think we expect them to implement it as if it was the real thing. We are not sure it is. We are struggling with important aspects. We are trying to force it out the door. We will fail. More below.

Example: some system do not use blank nodes. They still use the commonly available RDF tools and systems.

Let's not confuse users with implementors. IMO we should suggest implementors implement it, but honor and keep in mind the fact that it still has gaps and suffers from largely unexplored corner cases.

Let's face it: standardizing RDF-Star is premature. It was over-simplistic from the start, and the CG proposal either glossed over or even increased the resulting tensions. Central problems are not solved in a way that will survive in practice. The TEP is highly problematic. Maybe the semantics TF will be able to agree on a sound solution, but what if not? The need to model occurrences differently from types will lead to a lot of problems in practice, and very practical problems at that. The vaguely defined relation to named graphs might foster even more balkanization in modeling approaches (how much more attractive and sound would it be if we could offer a solution that healed the wounds of RDF 1.1 Datasets and provided one modelling primitive for all use cases).

The main initial thrust behind this standardization effort - the desire to bridge the gap between RDF and LPG, articulated in the W3C workshop in Berlin 2019 - has become a neglected nuisance in the CG report. Instead provenance, for which we really had named graphs already, is again front and center. A less ingenious design was hardly conceivable.

I would talk differently if the CG had been more welcoming to discuss and tackle these problems, but it hasn't, and this WG, chartered with only 2 years, does seem to be in a rush to largely rubberstamp the CG results and be done with it. At least I haven't experienced much support for my repeated attempts to resolve these issues. I made easy to implement proposals like "Let the shortcut syntax default to referentially transparent occurrences" - a compromise that IMO would stand a real chance to survive in practice, and wouldn't demand much from the position the CG settled on. Yet I didn't even get a response. In the absence of any such pragmatism and willingness to confront realities I can only reckon that RDF-Star will fail in practice, just like Named Graphs by Carroll et al 2005 failed: because it is too detached from practical needs and customs. The syntax will survive, but everybody will interpret it based on ad hoc intuitions. Nobody needs such a standard. The farther it is decoupled from RDF (Core), the better. I don't want to offend anybody, but that's my take on the current situation.

[pfps]

This issue is only about creating conformance levels for RDF 1.2. Any discussion of the relationship between quoted triples, named graphs, singleton graphs, etc., should happen in w3c/rdf-concepts#46

[Antoine-Zimmermann]

After considering all that has been said about this issue, I think we should formally and normatively define a subset of RDF 1.2 that I will call "RDF 1.2 Basic" following Andy's suggestion. What this implies in terms of edits to RDF 1.2 Concepts is something like this:

• The abstract of RDF 1.2 Concepts can mention that RDF 1.2 introduces quoted triples, but that it also defines a subset of RDF 1.2 called RDF 1.2 Basic [for instance] that excludes quoted triples as possible terms.
• Sec.1.3 that describes quoted triples can mention that RDF 1.2 Basic does not have this type of terms.
• In Sec.1.9 about RDF documents and syntaxes, it can be said that all syntaxes have production rules specific to quoted triples in their grammar, and these production rules can be ignored for tools that only deal with RDF 1.2 Basic.
• Sec.2 about conformance can mention 2 levels of conference (full RDF 1.2 conformance and RDF 1.2 Basic conformance). Full RDF 1.2 conformance implies that everything normatively defined here has to be implemented or assumed in specs that build on top of RDF 1.2. RDF 1.2 Basic conformance means that quoted triples may not be suppoted (in implementation) or that a spec reusing the concepts and terminology may be ignoring or may be undefined for quoted triples or graphs with quoted triples. A fully conformant RDF 1.2 implementation or specification may have features or functionalities that are specific to RDF 1.2 Basic.
• Sec.3.1, we could have a name like "simple RDF triple" for triples without quoted triple, and "complex RDF triple" when there is a quoted triple, and all simple and complex RDF triples are RDF triples. In RDF 1.2 Basic, only simple RDF triples exist.
• Sec.3.6 on graph comparison is currently incomplete. It does not define isomorphism of complex triples. RDF 1.2 Basic conformance does not require to do comparison of quoted triples.
• Sec.4.1 RDF Dataset Comparison similar to Sec.3.6
• Sec.7 Generalized RDF Triples, Graphs, and Datasets must be updated to include quoted triples as possible kind if terms, and Generalized RDF 1.2 Basic triples, etc. are just like in RDF 1.1

In RDF 1.2 Semantics, things can be built gradually, as they are already: define simple entailment on graphs without bnodes nor quoted triples; introduce bnode semantics; introduce datatype semantics; extend to RDF and RDFS vocabulary. Up to this point, point out that this is all valid in RDF 1.2 Basic. Then introduce quoted triples semantics and say that this does not need to be implemented nor considered to claim RDF 1.2 Basic conformance.

In SPARQL 1.2, it may be a little more difficult to manage. Should there be "SPARQL 1.2 Basic"? Then the specs must identify what parts can be ignored when aiming at Basic conformance.

Test cases should have a label when they are tests for RDF 1.2 Basic. Conformance to RDF 1.2 Basic can be claimed as soon as tests with the label are passed. It should not be forbidden to pass some of the other tests are still claim Basic conformance.

Note that I did not consult with @rdfguy to write this post.

[afs]

Should there be "SPARQL 1.2 Basic"?

Not unless there is a proven need. It seems to be more about whether the data is basic or not.

There could be an indicator in SPARQL Service Description as to whether the data is "Basic only".

There isn't a simple SPARQL Query level syntactic restriction. The SPARQL query or Graph Store Protocol request may not mention quoted triples yet if the data contains quoted triples, then results might might have quoted triples.

This can only be determined after seeing all the results. Given the HTTP status code goes out before any results, a requirement to return a status code for bad queries (4xx status code) means no streaming.

[Antoine-Zimmermann]

I agree that a "SPARQL 1.2 Basic" may not be needed but the existence of the Basic profile requires some text to be added to the SPARQL specs in relation to it. For instance, what about SPARQL CONSTRUCT? It may not need much content to add or edit, but I think the implications on the SPARQL spec are a little tricky to determine at this stage.

[hartig]

Regarding "SPARQL 1.2 Basic" or not, what about a SPARQL processor that supports only RDF 1.2 Basic? Should such system be able to parse nested triple patterns? Probably not. But then, don't we need a limited version of the SPARQL grammar for RDF 1.2 Basic?

[Antoine-Zimmermann]

I'll try to summarise some of the conclusions I can reach from the little discussion we had:

1. noone seems to be hostile to having a distinguish profile of RDF 1.2 that would not have quoted triples in its syntax.
2. since the name "RDF 1.2 Basic" have been proposed, noone suggested a counter proposal and people engaging in the conversation used this name after.
3. some people interpret "basic" as "you can discard new features of RDF 1.2", but from the beginning, I think the idea has been to exclude quoted triples only. The other new features (directional text in literals and erratas) are usually understood to be part of RDF 1.2 Basic (to be verified)
4. it is not clear yet if SPARQL should make explicit how it has to interact with systems that are built for RDF 1.2 Basic only.

I would propose to:

1. PROPOSAL: The RDF-star WG shall define a profile for RDF 1.2 where quoted triples are excluded from the syntax
2. PROPOSAL: The profile that excludes quoted triples shall be named "RDF 1.2 Basic"
3. PROPOSAL: The profile that excludes quoted triples shall retain every other aspects of RDF 1.2, including features that were not present in RDF 1.1, as long as they are unrelated to quoted triples

For serialisation syntaxes, I think we don't need to do much. Just have a note that explains which parts of the grammar are not be considered by RDF 1.2 Basic processors.
There are obviously other decisions that should be made regarding documents like RDF 1.2 Semantics, and SPARQL.

For RDF 1.2 Semantics, I think that the semantics should be defined in steps:

1. Define semantics for ground RDF 1.2 Basic graphs
2. Define semantics for RDF 1.2 Basic graphs that contain bnodes
3. Define semantics with datatype interepretations for RDF 1.2 Basic graphs
4. Define RDF/RDFS semantics for RDF 1.2 Basic graphs
5. Extend to all RDF 1.2 graphs

Other options, like introducing quoted triple semantics at 2., are possible, but this would be my favourite because it defines completely the semantics of RDF 1.2 Basic graphs before getting into quoted-triples territory.

[pfps]

I think that it is better for Semantics to define semantics for all of RDF 1.2. The semantics for Basic are then just that part of the entire semantics that does not mention quoted triples. To do otherwise just adds considerable repetition.

[niklasl]

Just to clarify: I think the proposals are good; I just hope we may be able to do step 2 in the semantics (maybe in conjunction with step 4) in such a way that step 5 might not be needed. If so there could still be "convenience" surface syntax building upon 2+4 only (and maybe that is all there is to the optional star profile).

(My worry in the other case is that any hard-to-overcome variance in the software landscape might work against adoption.)