Define SHACL constraints

[retog]

SHACL constraints would complement the ontology defined as per #33

[msporny]

I think we should define the SHACL constraints, but should not make it a blocking work item. We also need to produce JSON Schema as well for the non-RDF folks (and I'd argue that's a higher priority than SHACL).

[gkellogg]

AFAIK, SHACL works over RDF Graphs, and not Datasets. VC uses Datasets (default and named graphs for credentials/claims). There is some work in the ShEx CG to extend support to Dataset shape patterns.

Currently, when expressed as JSON-LD, where the named graphs can be hidden using the context, JSON Schema may be the best bet, but there should be a way to accomplish this in the RDF model.

[stonematt]

should we label this as a "privacy" issue?

[gkellogg]

As discussed on the call, we may want to have some concept of "publishing profile" that ties a constraint to some particular vocabulary terms and relationships to insure interoperability across that profile.

[gkellogg]

Just an update, working with @ericprud on an extension to ShEx to support named graphs and to work out how to identify a shape to match within that graph. At this point, both SHACL and ShEx work only on a graph, and the VC data model uses a dataset. I expect ShEx to support our use case within our timeframe, but still working the issue.

[burnburn]

Without input from @gkellogg this is unlikely to make progress. @retog if you are willing to help make progress here please respond. Marking as deferred until we hear otherwise.

[gkellogg]

I don't expect progress on ShEx anytime soon, and can't comment on SHACL. Due to my long absence, and growing obligations elsewhere, I'm taking myself off of this issue.

[burnburn]

Thanks Gregg.

…

On Tue, Jul 17, 2018 at 12:31 PM, Gregg Kellogg ***@***.***> wrote: I don't expect progress on ShEx anytime soon, and can't comment on SHACL. Due to my long absence, and growing obligations elsewhere, I'm taking myself off of this issue. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#76 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABHeUwFTojwdfzemHWD-okj4dbuv8waMks5uHhF-gaJpZM4P8ZrZ> .

[ericprud]

This depends on graph continuity outlined in json-ld-api issue 26.

Edit: this ended with wontfix tag.

[iherman]

The issue was discussed in a meeting on 2021-06-14

• no resolutions were taken

View the transcript

3.1. Define SHACL constraints

See github issue #76.

Manu Sporny: suggestion to defer Issue #76

Ivan Herman: I have found some problems recently on the RDF aspect of the model, and there are some problems on how the data models are expressed - SHACL would reflect those - more to the topic than just editorial

Manu Sporny: I will add defer-v2

Brent Zundel: suggestion for new label, other than "deferred" for issues like @issue 76 - "deferv2"

[OR13]

I'm in favor of considering the a broader family of data definition langauges, including SHACL, CDDL and JSON Schema

[iherman]

The issue was discussed in a meeting on 2022-08-10

• no resolutions were taken

View the transcript

4.1. Define v2 context (issue vc-data-model#76)

See github issue vc-data-model#76.

Kristina Yasuda: This is about SHACL constraints..
… Some conversation going on in that issue..

Manu Sporny: It was a suggestion that nobody really followed up on. Some people could write SHACL constraints. But until somebody actually puts in a PR, I don't feel we need to keep this open. Maybe we close until someone comes up with a PR..

Ivan Herman: I did that for the DID model, which is simpler than this one. We can close it and I look at it later. I don't know yet whether I will have the time..
… It would also be good to have JSON schema, but I'm less familiar with that..
… It's good to keep but with low priority..

Orie Steele: We looked at the same issue with DIDs. We looked at JSON Schema, CDDL, SHACL. Machine-parsable structured format for the data model is helpful. Having 3 of them is maybe even more helpful. But takes a lot of WG contributions to make it high quality..
… I would like to have at least 1 of these types of languages. Each has their own trade off. I don't think we should limit it to just one language..

Kristina Yasuda: Preference to keep issue open with low priority..

[SmithSamuelM]

JSON Schema has some very nice composition operators (anyOf, oneOf) features that allow us to support graduated disclosure and contractually protected disclosure in ACDCs. JSON Schema also have a fairly expressive rules engine for arbitrary composition. If one uses composed JSON Schema then Schema can be immutable (all the allowed variants in a presentation exchange are already committed to in the composition. This locks down the intent of the Issuer and simplifies presentation exhange protocols. Immutable schema then make it much easier to manage VCs from a security perspective because a content addressable identifier can be attached to the schema and any registry or cache of schema can provide a verifiable (integrity) copy of the schema so indentified. Finally one can use JSON Schema as the capture base for other semantic tools such as the ToIP OCA specification which for those that are unfamiliar is a layered schema approach that enables data shaping for the capture base.

Something generic like JSON Schema can be used with other data models like those based on Property Graphs which can be implemented in not merely PG specific databases like Neo4J or Open Cypher or the emerging ISO GQL but existing SQl databases can be repurposed to support PGs. This means that instead of one set of tooling (JavaScript JSON-LD) or RDF we have at our disposal the full suite of tooling widely used by everyone else.

[iherman]

In my view, this issue could be closed.

• We had a discussion about JSON schema usage at the F2F, and there is now a separate issue on this (Define JSON Schemas for all objects in the VCDM #934)
• Neither SHACL nor Shex is prepared to constrain Datasets (ie, named graphs) as opposed to single RDF graphs. Named Graphs are essential in the VC model, we cannot bypass them, and we should not use any sort of experimental extensions to SHACL/Shex; it is not our job.

Propose closing, thus.

[TallTed]

@iherman -- I agree about avoiding experimental extensions in VCDM, but it seems worth logging this as an issue against SHACL-now toward a SHACL-next (or whatever bikeshed name eventually gets settled on).

[brentzundel]

Marking as pending close. Will close in 30 days if a concrete SHACL representation is not proposed.

[iherman]

Alternatively, we could also mark it as "deferred" (this label does not exist yet, though) if we believe SHACL will be extended by another WG to include Datasets.

[brentzundel]

If SHACL end up extended, we can re-open this issue, closing for now.