Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We use this convention on all of the auxiliary resources that have a 1:1 relationship with the resource they have been associated with. Essentially its just a way to have a bi-directional association, specifically:

Resource A -> Shape Validation V
Shape Validation V -> Resource A

Note that the shape validation resource is not meant to actually link straight to the shape itself, but to an RDF document that will point to the shape(s), contain some other helpful metadata like type of shape(s), enforcement level - (warn, fail), etc.

Now that aux. resource section is wrapping I plan to start documenting that one, so there should be more detail soon.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note that the shape validation resource is not meant to actually link straight to the shape itself, but to an RDF document that will point to the shape(s), contain some other helpful metadata like type of shape(s), enforcement level - (warn, fail), etc.

Why isn't the shape resource self-describing ie. including both the shape and anything else that's relevant?

The name of the property signals "shape", the resource is called "shape resource".. but when the client gets there, they are directed to another resource which is the actual shape?

Too many meta layers for my taste.

We have rel=acl, describedby,.. targeting the most essential resource. How is the metadata (eg. enforcement level) about the shape resource (ie. the target of rel=shape) is of use to the client?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why isn't the shape resource self-describing ie. including both the shape and anything else that's relevant?

The shape resource is public and doesn't know anything about the context in which you are applying it. For example, you may only want to warn when the validation fails. That a decision you make in how to apply the validation, not the author of the shape.

The name of the property signals "shape", the resource is called "shape resource"..

Agree that the property name is misleading - it might be best to change it to something else like "constraint" or "validation". Also there's nowhere in this document that the words "shape resource" are used?

but when the client gets there, they are directed to another resource which is the actual shape?

The purpose of this auxiliary resource is to illustrate one or more validation constraints set on that resource. It's not limited only to the shape itself, but also other parameters related to how that validation should be evaluated / applied.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The purpose of this auxiliary resource is to illustrate one or more validation constraints set on that resource. It's not limited only to the shape itself, but also other parameters related to how that validation should be evaluated / applied.

That's fine but I don't see a reason why that's not all (including all constraints as well as any other related information) be stated in the auxiliary shape resource.

A resource representation whose shape is constrained by a given ShEx schema that links to an auxiliary resource defining that schema.

Sounds closer to what I'm saying than what you're saying but perhaps I'm misinterpreting.

In any case, I can't draw the underlying rationale from the text or arguments. I'm suspecting two reasons for having an intermediary (auxiliary) resource:

• the lifecycle of the shape (constraints) information shouldn't depend on the lifecycle of the primary resource, so the auxiliary resource hop is a way to let the shapes live on. On deleting primary resource, auxiliary resource can get deleted without touching the shapes (which happen to be elsewhere and possibly used by other resources).

• there are multiple approaches to shape validation (SHACL/ShEx) so instead of picking one to associate resources with, we have the intermediary auxiliary resource to point at them.

The first seems reasonable.

The second less so - after all, no particular reason why there can't be specific link relations point at shacl or shex resources. On that note, at least one of these things needs to be required in order to have minimum level of interop.