Re: Shapes Repository

I’ve only opened a couple of shapes from the repository. My suggestion is to include an explicit “version” property, similar to how you work with API life management – easier for developers and the ecosystem (e.g. mappings to/from RDF to JSON will lose a lot of the information).

 

___________________________________

Joshua Cornejo

marketdata

smart authorisation management for the AI-era

 

From: Jesse Wright <jesse.wright@theodi.org>
Date: Tuesday, 31 March 2026 at 11:05
To: <public-solid@w3.org>
Cc: Tanya Gray <tanya.gray@theodi.org>, Samu Lang <samu.lang@theodi.org>
Subject: Shapes Repository
Resent-From: <public-solid@w3.org>
Resent-Date: Tue, 31 Mar 2026 10:04:49 +0000

 

Dear Solid Community,

We would like to share a new repository - https://github.com/solid/shapes - aimed at supporting interoperability in the Solid ecosystem.

We’d really welcome your feedback on this and the role it could play for the community!

Primarily, this repository is designed to:

1.    Provide a space for the community to converge on the data models used across applications – declared using SHACL shapes

2.    Build up a collection of well-understood, reusable shape patterns

3.    Enable a collaborative review process where shapes can be compared and discussed transparently

4.    Support artefact generation from shapes, including object abstractions in Javascript, data validators (using SHACL engines), and forms.

5.    Offer visibility into existing shapes to encourage reuse, reduce duplication, contributor recognition, and help new participants get started more easily

We have documented an initial contribution process in the repository. In addition, there is an important human consensus step that we are still refining and would welcome feedback on.

We have pre-filled this repository with shapes that we know are already used within the ecosystem – including shapes based on the data models used by SolidOS. We would now like to invite you to contribute shapes, representing the data that your Solid applications read and write - please refer to the guidelines on contributing.

Note: The goal of this repository is to achieve interoperability through social consensus rather than technical complexity, such as inference or mappings. As the Solid ecosystem scales beyond its current size, we may eventually deprecate this repository in favor of other mechanisms. We also expect that this repository will, in time, evolve beyond the use of SHACL alone – ways we imagine this could happen include:

·  Ontology-Driven Approach: Moving toward a set of recommended ontologies based on actual usage. Shapes would still document how applications read/write data, with automated checks to ensure they conform to these recommended ontologies.

·  Consistency Checks: Ensuring the consistency of recommended ontologies (though this may be too academic for practical implementation).

·  Foundational Ontology: Introducing a foundational ontology (e.g., UFO) that all other ontologies build upon (similarly, this may be too academic for our current needs).

These are subject to change based on feedback from the repository’s usage and other interoperability efforts.

If you have comments, we’d like to gather initial feedback asynchronously via GitHub discussions. If there’s interest in a deeper discussion, we can schedule a call or bring this to the Community Group agenda. 

Design decisions have been itemised on GitHub and we would encourage you to comment on individual design decisions there rather than via the email thread.

Looking forward to your thoughts!

Best,

-- 

Jesse Wright (he/him)

Project Lead, Solid

The Open Data Institute

4th Floor, Kings Place, 90 York Way, London, N1 9AG

Website: theodi.org

Book a meeting: https://calendar.app.google/hv63aFQyL6jgjiXG9

Tel: +44 7862381515

My work day may look different than yours. Please do not feel obligated to respond outside of your normal working hours.