shape languages and validation features

[phtyson]

Is it within scope of the WG to add shape language feature instances and description of validation endpoints? Would also affect sparql-protocol document.

[rubensworks]

I suspect this won't be in-scope for this WG.
This might be a better place to add this suggestion: https://github.com/w3c/sparql-dev

[pfps]

I view this as out of scope.

[pchampin]

This was discussed during the rdf-star meeting on 26 September 2024.

View the transcript

Un-star operation to support RDF Dataset Canonicalization? 1

niklasl: I tried to summarize the two options on the table: unstar based on named graphs, or base on classical reification

<william_vw> present_

niklasl: also the question whether it is targetting canonicalization alone, or more general
… if c14n was defined on RDF 1.2 with triple terms, unstar would not be necessary.

pfps: as far as I'm concerned, this group does not need to do anything about c14n.
… We could be nice, but not spend to much effort about this.
… We could say "RDF-CANON should be extended to RDF 1.2. In the mean time, use an unstar mapping that essentially uses reification."

<pfps> This should be specified a bit more precisely.

tl: I agree that we should provide a reification-based unstar mapping, that does not require named graphs.
… Several variants are described in the github issue, I think the reification-based is the less controversial.

niklasl: we need to know what the type of triple terms is.

gkellogg_: although the unstar is necessary for c14n, there are probably other cases that require it.
… I think round-tripping is important.
… We must consider SPARQL as well, being able to run it on an RDF 1.1 database.

<niklasl> +1 to "unstar a query" too (to put annotation in existing graph stores and use it in production)

gkellogg_: It would also be interesting to be able to turn standard reification into triple terms.

<niklasl> (noting that I have no problem "unstarring queries" manually)

ora: could be an issue if there is a mix of old-style and new-style.

gkellogg_; we need to decide if that's a problem.

<niklasl> +1 to that to (is the target 1.2 basic or 1.1)

<pfps> In my opinion an unstar mapping is only to be used as an interim solution. It does not have to support round-tripping. It does not need to preserve non-isomorphism for RDF graphs that are not "good" RDF 1.2 graphs (misusing rdf:reifies, misusing triple terms, not well-formed if we still have this).

AndyS: we need to decide if we are turning RDF 1.2 Full into RDF 1.2 Classic or into RDF 1.1. RDF 1.2 has text direction, RDF 1.1 does not. The algorithm would not be the same.

gkellogg_: I claim that base direction would not impact c14n.
… In the sense that it can easily be integrated in the existing algorithm.

pfps: given that there is more than c14n does not handle, I say we don't do anything.

ora: who's gonna get hurt if we don't do anything?

gkellogg_: the c14n algorithm is not so complicated, but the proof that it's correct are.
… It is not likely that a new group is going to be chartered to do a new algorithm.
… If we don't provide an unstar mapping, the RCH group would probably provide one.
… We do have the Full and Basic profiles.

pchampin: I simpathise with pfps position, but agree that if we don't do it someone else will.
… I believe there are other use cases for un-star.
… This provides a useful way to go between profiles.

<tl> I think we should do it (backwards compatibility, and illustrate the meaning of triple terms), and re @andys its target should be RDF 1.1

AndyS: I think we should do something, especially since the CG report already mentions an unstar mapping.

<niklasl> This issue has mutated a bit, and should perhaps be retitled again, to e.g. "Define an unstarred form into RDF 1.1(?)" (to cater for everything specified and/or deployed, including C14N and reasoners, that will not upgrade to RDF 1.2 overnight)?

AndyS: does not have to be a big thing, can be non-normative.

ora: if there are other use-cases for this than c14n, we run the risk that other people do it differently.
… We are in the best position to do it.
… What are our use-cases? Is it someone who wants to use RDF 1.2 with their RDF 1.1 implementation?

<Zakim> pfps, you wanted to point out that https://www.w3.org/TR/rdf-canon/ has flas

ora: Other question is round-tripping.

pfps: the RDF-CANON has a big problem, it is unclear about what its input is.
… The input is an n-quads documents, but in other places it talks about the input dataset.
… I don't want us to get involved in this.
… It is not up to us to fix that problem.

gkellogg_: you seem to be asserting that it is a flawed recommendation.

<pfps> From RDF canonicalization "This document outlines an algorithm for generating a canonical serialization of an RDF dataset given an RDF dataset as input."

gkellogg_: It uses n-quads as an input to leverage the blank node labels.

<pfps> From the docuemnt "input dataset

<pfps> The abstract RDF dataset that is provided as input to the algorithm."

gkellogg_: It was reviewed and I think it is an adequate recommdnation.

<pchampin> s/recommndnation/recommendation

<pfps> The algorithm, however, starts with an N-quads document.

niklasl: I think the argument about migrating from RDF 1.1 is a good one.

<tl> +1 to niklasl

pchampin: I think we should use RDF 1.2 Classic as the baseline, not RDF 1.1.

niklasl: I sympathise with this position.

<william_vw> I assume RDF 1.2 classic means without triple terms?

niklasl: There are ways in JSON-LD 1.1 to encode base direction in RDF 1.1, but there are two options, none of them ideal.

ora: what would it require to deal with base direction in RDF 1.1?

<tl> @william_vw yes

<william_vw> @TL thanks

gkellogg_: we would probably go with one of the JSON-LD options, probably the i18n datatype.

<niklasl> I'd agree on i18n datatype version of lang-literals-with-dir.

ora: I don't like the idea to deem this somebody else's problem
… Depends how much work we want to put into it, pieces of solution already exist.

pchampin: I agree that we need to do something. But, let's be clear on what we're trying to solve.
… I'm worried about using RDF 1.1 as a baseline.
… It's also useful for the "inter-profile" operation.
… If we agree that this is the scope, I can take it into account in my PR.

ora: it would solve the c14n "for free". Ultimately RDF-CANON has to be adapted to RDF 1.2, but we know it may take time.

<ora> STRAWPOLL: Should we include an un-star algorithm in the 1.2 spec? (some questions remain...)

<pfps> -1

<niklasl> +1

<gkellogg_> +1

<tl> +1

<ora> +1

<william_vw> +1

<MacTed> +1

<olaf> +1

<pchampin> +1

<AndyS> +1

<Dominik_T> -0.5

gtw: what would normative mean? not all implementations need the unstar mapping?

pchampin: it needs to be normative if other specs want to normatively refer to it.

gkellogg_: implementations can be compliant without passing all the tests

<gtw> +1

gtw: the manifest vocabulary allows us to flag tests as requiring certain features

tl: it seems like a straightforward implementation, not putting unreasonable burden on implementations, so let's make it normative

<niklasl> I like this direction (not requiring 1.2 implementations to have an unstar operation plus adding a new set of tests for this feature (usable to opt-in for those who support it)).

ora: if we didn't make it normative, that would nudge the RCH group to do the work properly

AndyS: the more tests we put, the more work that is, and the less likely it is that implementations migrate

ora: I don't know the answer to this normative/non-normative thing. If we make a non-normative section, then people will hopefully not make their own.
… If some days the RCH group makes a 1.2, this is an interim solution.

pchampin: in the interest of time, I suggest we defer the nonrmative/non-normative question until we have a PR to discuss on

<gb> Issue 114 Un-star operation to support RDF Dataset Canonicalization? (by niklasl) [needs discussion] [discuss-f2f]

<gb> Issue 26 shape languages and validation features (by phtyson) [discuss-f2f] [needs discussion]

<gb> Issue 127 Material about `rdf:ReificationProperty` (by afs) [needs discussion] [discuss-f2f]

<gb> Issue 156 Addressing SPARQL EXISTS errata (by afs) [discuss-f2f] [needs discussion]

<niklasl> I see no big risk in just making it informative. (Famous last words; but... In practice, for "reasons", lots of implementations aren't 1:1 with what's normative.)

<gb> Issue 49 Define an interpretation of Triple Terms (by niklasl) [discuss-f2f] [needs discussion]

<niklasl> I see no *big* risk in just making it informative. (Famous last words; but... In practice, for "reasons", lots of implementations aren't 1:1 with what's normative.)

---

[pchampin]

This was discussed during the rdf-star meeting on 26 September 2024.

View the transcript

Shape languages and validation features 2

<ora> PROPOSAL: Mark as out-of-scope and close

<gkellogg_> +1

<pchampin> +1

<tl> +1

<ora> +1

<gtw> +1

<doerthe> +1

<niklasl> +1

<TallTed> +1

<eBremer> +1

<Dominik_T> +0.5

<AndyS> +1

RESOLUTION: Mark as out-of-scope and close

---