Converging on one standard for shapes in Solid

[jeswr]

First of all - great to see this repo exists!

I noticed in the README that the description allows for a range of "'shapes' in languages or expressions such as SHACL or SheX". I believe that it would be worthwhile converging on and using a single standard for shapes in this repository, and across Solid, in order to ensure consistency and limit the number of standards that clients/servers may need to implement in the future.

I would be (strongly) pushing for SHACL to be that standard as it has an official W3C Recommendation status and appears to have growing industry adoption (and it can be serialized in RDF so shapes can be stored in RDF Resources in Solid). That said, I also believe that agreeing to use one standard is more important than which standard is ultimately chosen.

[langsamu]

I'm an implementer of various products that are likely to use these shapes.

I very much agree with @jeswr's suggestion and reasons.

[csarven]

No objection. A couple of considerations:

• Any particular cases in which SheX may be preferable to SHACL for certain (kinds of) specification?
• Can everything in SheX be expressed in SHACL?

[ericprud]

• Can everything in SheX be expressed in SHACL?

No. The main reason ShEx and SHACL diverted was because it's basis in SPIN meant imposed semantics that precluded distributed reuse, which we needed for e.g. clinical data. Once you define a property in SHACL in one shape, you can't re-use that shape allowing for more instances of that property (our use case involved adding fhir:components).

We also needed cardinality constraints on groups, e.g. more than one fhir:input, fhir:output or fhir:result or an optional group like:
(fhir:duration xsd:decimal ; fhir:durationUnit @<#code>) ?
You can compile this into SHACL by recording all permissible combinations (a power set of the disjuncts obtained from a disjunctive normal form), but then you'd have an authoritative representation in ShEx compiled to SHACL.

There are a bunch of places where compiling ShEx to SHACL either can't be done or isn't as straightforward as you'd expect because SHACL doesn't do what you'd expect. For example, CLOSED shapes only work on simple lists of predicates. If you have ORs or ANDs, you have to compile in all of the permitted and not permitted predicates in each conjunction or disjunction.

The ShEx XOR operator ('|') doesn't map to the SHACL XOR:

(
   foaf:name xsd:string
 | foaf:givenName xsd:string ; foaf:familyName xsd:string
)

In ShEx that accepts any of:

• foaf:name "Alice Walker"
• foaf:givenName "Alice" ; foaf:familyName "Walker"

Writing that as a SHACL XOR permits those plus:

• foaf:name "Alice Walker"; foaf:givenName "Alice"
• foaf:name "Alice Walker" ; foaf:familyName "Walker"

• Any particular cases in which SheX may be preferable to SHACL for certain (kinds of) specification?

I would say the delta in the semantics isn't terrible apparent if you have a pure list of properties that no one's going to extend. Other than that, ShEx was designed to meet serious use cases; it was not designed to reuse a particular technology.

[jeswr]

Definitely interesting on the multiple property instances point - @HolgerKnublauch is there any way of achieving similar behavior with something like SHACL advanced features or qualified constraints?

[HolgerKnublauch]

In a comparison situation like this, it is of course possible to point at some very specific use cases and features that language X supports but the other doesn't. I could certainly make a large list of features that SHACL has but ShEx doesn't. Wide industry-strength tool support is probably the biggest differentiator - almost all RDF databases now natively support SHACL. Other benefits stem from the fact that SHACL is an official W3C standard, including the fact that more people are willing to invest their time. From what I can tell SHACL is far better integrated into the RDF stack, and it is natural to define shapes as part of ontologies alongside with labels, comments, and non-constraining properties that drive input forms and other ways of consuming a shape structure. I have not tracked ShEx for a long time, so I am honestly not sure where it stands.

I guess you need to enumerate what is important for your project and then look at which features you absolutely need. Are these requirements spelled out somewhere?

On specific scenarios that ShEx can express easier than SHACL, there is always the possibility of using SPARQL in SHACL as a fallback.

[csarven]

Thanks everyone.

(Where shapes are being used or considered was summarised in https://github.com/solid/specification/blob/main/meetings/2023-03-01.md#shapes-reuse .)

It seems to be that each specification will need to employ the most suitable shape language for itself. That incorporates the consensus and implementation experience on how various classes of products have been implemented.

Hence, this repository does not need to be limited to a particular shape language. This is also not the appropriate repository to set requirements pertaining to a shape language or its contents with respect to any specification. (Which shape language(s) to use has been raised before, e.g., solid/specification#44 (comment) .)

PROPOSAL: It can be strongly encouraged (or required) that a shape proposed for inclusion in this repository and published are serialised (or serialisable) to a concrete RDF syntax that is aligned with the Solid Protocol, i.e., Turtle or JSON-LD.

---

Having said that, not requiring one shape language potentially complicates implementations that wish to conform to multiple specifications which may require different shape languages.

It does not serve us well at this point in time to run proposals or vote on which shape language to require across Solid TRs.

Which brings me to leaning on https://www.w3.org/TR/design-principles/#priority-of-constituencies for some guidance, in particular:

User needs come before the needs of web page authors, which come before the needs of user agent implementors, which come before the needs of specification writers, which come before theoretical purity.

A close translation would mean that implementation experience can be used as preferred input, as mentioned earlier. As usual, open implementations play an important role towards these decisions as they can be publicly verified.

How does that sound to everyone?

---

If none of the above is acceptable and everyone strongly demands a solution now, then let's require SHACL.

[jeff-zucker]

A close translation would mean that implementation experience can be used as preferred input.

Another reading would be that it is to the great advantage of implementers not to have multiple conflicting options for every piece of Solid. ACL or ACP , SHEX or SHACL - what it comes down to for implementers is you have to learn all of everything and that completely sucks.

[jeswr]

PROPOSAL: It can be strongly encouraged (or required) that a shape proposed for inclusion in this repository and published are serialised (or serialisable) to a concrete RDF syntax that is aligned with the Solid Protocol, i.e., Turtle or JSON-LD.

Strongly agree with this (preferring required over encouraged) - my question is what shape specifications other than SHACL are serializable in an RDF syntax?

[ericprud]

ShEx schemas are expressed in ShExC (compact syntax), ShExJ (JSON), and ShExR (RDF)). See .shex, .json, and .ttl in the ShEx test suite schemas. The representations are losslessly roundtrip-able apart from comments (which can't be shoehorned into JSON anways). Some folks use YAML as well, but the mapping between JSON and YAML is straightfoward enough that there's not much point to add 33% more tests to an already large repo.

[langsamu]

Another consideration of interest to implementers is support in RDF libraries.

[csarven]

PR #3 is intended to resolve this issue. All welcome to review.