For ActivityPods, we have a urgent need for this because we are finishing at the moment our full implementation of SAI, and so all our apps will need to point to shapes and shape trees, in order to be interoperable with each other. So we quickly created our own shape repository, based on Jesse’s previous work, except we use ShEx instead of SHACL-Compact, and we also host shape trees.
@jeswr suggested there may be enough interest (and importance) in that subject to propose a Special Topic Meeting, so that we can discuss it together. So here’s a poll to find a date when, hopefully, all concerned actors can be here. Please cast your vote now
Below I’m listing some of the requirements that I see for such a shape repository, but it’s of course open to discussion!
Requirements
ShEx + SHACL + SHACL-Compact negotiation for shapes
Turtle + JSON-LD + Quads negociation for shape trees
Predefined JSON-LD context to make JSON-LD more readable ?
The main idea was to have a bottom-up/crowdsourced way of publishing shapes (including shapes used by specific apps), and aggregating them into a larger shape of shapes. Easier way to preview relations that matter, and shape the missing ones with low entry barrier.
OTOH I still don’t get what’s good about shapetrees. If I understand them correctly, they feel a lot like an unnecessarily strict constraint on data organization within Pods. Specific folder structure for specific data — enforced hierarchy in the world of graphs. But perhaps that’s offtopic in this thread.
There has been a blog post published back in 2022 about hierarchy vs graph in Pods: Let’s talk about pods | Ruben Verborgh. It sparked wide enthousiasm (including mine), but also some pushback and unfortunately didn’t really make it into Solid mainstream.
The article must have been a product of deep understanding of the topic, and made a lot of intuitive sense to me. Perhaps LWS WG, with Ruben’s involvement, may revisit and bring back those ideas.
That’s exactly what I thought when I first read about shape trees: “they’re trying to put a square peg in a round hole!”. But then @elf-pavlik showed me that shape trees can also be used with a flat hierarchy. This is very well explained in the first part of the Application Interoperability Walkthrough that I recommend to watch (it’s a bit old, but it lays the foundation for the SAI spec).
The advantage of using a shapetree instead of a single shape is that you can link resources / shapes together, and give – for example – the rights to view a project, but also all linked issues. It may be something close to your idea of “shape of shapes”, but I’ll need to read your proposal.
I shared this enthusiasm when this article came out! But his proposal for “views” also seemed difficult to implement concretely, especially on filesystem-based Pod providers (we use a triplestore for ActivityPods so it’s possibly easier to achieve). IMHO SAI solves many problems that Ruben points out. It’s unfortunate that few Solid developers know about this spec! (it’s true I needed to read it several times to get into it)
