Ability to read and validate based on shapes

[james-martin-jd]

This is a bit of a pain point on one of my projects, the solid-react-sdk. We provide examples of how to do certain things, such as notification creation or file / game creation. In these cases we want to do two things:

1. Fetch "objects" or object-like structures as defined by a shape (in our case, shex)
2. Validate that these objects are what they say they are

Right now, these means a lot of common, repeated loops.

What we've done so far is create JSON structures representing a simple version of a shape. This isn't great practice, but you may see why we do this soon. We need to loop over something in order to create multiple ldflex expressions, one per property in the shape, then execute and combine together into one JS object.

These JSON structures are not good practice, since they are separate from the actual shapes, not used for validation, and are custom. That being said, it's more difficult to loop over ShEx or Shacl shapes and check each predicate name, for various reasons.

We also have to validate the data first - usually we do this with ShEx (though we have put together some Shacl experiments as well) and it's a bit of a pain as we have to fetch the data twice - the ShEx validator fetches once, as it takes a path as a param and does the fetch internally, and returns the valid paths, not the valid data. Then we use LDFlex to fetch the valid document URLs to build our objects as described above.

In a perfect world, I would like to be able to do something like

solid.data[subject].shape('<IRI to shape>') and have it return me a JS object contain the fields, or throw an error if it fails validation

In an even more perfect world I could do this with a list of subjects and get an array of JS objects that all pass validation :)

[RubenVerborgh]

Yes, shapes are the next frontier for LDflex: https://github.com/LDflex/LDflex/issues/15

Right now, we mimic JSON-LD contexts, which work on a per-property basis. In the future, this needs to become shapes.

As an example of what this will feel like, see the current LDflex activities: https://ruben.verborgh.org/blog/2018/12/28/designing-a-linked-data-developer-experience/#ldflex-future-p-3

[james-martin-jd]

Excellent! I wanted to make sure to throw my hat into the ring for discussion. I think shape integration (whether ShEx or Shacl or both - though I tend to prefer ShEx) will be critical for front end development moving forward. Fetching a property of a node at a time, and needing some code to "manage" how you get that data in each app, is certainly a code smell. Even though true "objects" don't exist in Solid, I think nodes are often used in that way (grouping of like-minded data) and it would be fantastic to start moving more towards that model with the development tools.

After all, we still need to transform the data into a view-ready state, regardless of how it's stored, and right now that's a pain. I tend to think of Shapes as surrogate Data Models or even View Models and if we can bridge that gap that's excellent.

What I've discovered wading into the shape world is so many people use them only for validation purposes that it's easy to forget they're ALSO object data models of sorts, and we need both of these things in the front end.

[RubenVerborgh]

Even though true "objects" don't exist in Solid, I think nodes are often used in that way (grouping of like-minded data)

Yes, and shapes can make them temporarily exist—that's why they are so crucial indeed.