Using shape expressions to become interoperable just got a whole lot easier

I wrote a new tool called shex-codegen with which you can generate the code to query and mutate shapes. It can generate shape objects that have methods through which it is very easy to read, create or modify nodes of a certain shape.

If we would want to create a solid profile e.g. with this shape expression:

PREFIX srs: <>
PREFIX foaf: <>
PREFIX schem: <>
PREFIX vcard: <>
PREFIX rdfs: <>
PREFIX xsd: <>

srs:SolidProfileShape EXTRA a {
  a [ schem:Person ]
    // rdfs:comment  "Declares the node to be a Person" ;
  a [ foaf:Person ]
    // rdfs:comment  "Declares the node to be a FOAF Person" ;
  vcard:hasPhoto IRI ?
    // rdfs:comment  "A link to the person's photo" ;
  foaf:name xsd:string ?
    // rdfs:comment  "An alternate way to define a person's name" ;

And with this config:

schema: "solidProfile.shex"
    - typescript
    - typescript-methods

In this example the codegen will try to read the shex file and generate a new file to node_modules/@generated/shex.ts with roughly this content:

import { NamedNode, Literal } from "rdflib";
import { Shape } from "shex-methods";

export type SolidProfileShape = {
  id: string;
  hasPhoto?: string | NamedNode; // A link to the person's photo
  name?: string | Literal; // An alternate way to define a person's name
} & {
  type: (
    | SolidProfileShapeType.SchemPerson
    | SolidProfileShapeType.FoafPerson
  )[]; // Defines the node as a Person

export enum SolidProfileShapeType {
  SchemPerson = "",
  FoafPerson = "",

export enum SolidProfileShapeContext {
  "type" = "rdf:type",
  "name" = "foaf:name",
  "hasPhoto" = "vcard:hasPhoto",

export const solidProfile = new Shape<SolidProfileShape>({
  id: "",
  shape: solidProfileShex,
  context: SolidProfileShapeContext,
  type: SolidProfileShapeType,

You can then use the generated solidProfile instance to create a new node that fits the shape expression:

import { solidProfile } from "@generated/shex"
const newProfile = await solidProfile.create({
  doc: webIdDoc,
  data: {
    id: webId,
    type: [SolidProfileShapeType.SchemPerson],
    name: "Ludwig",
    hasPhoto: "",
const { data, errors } = newProfile;

Authenticating can be done by updating the ._fetch method of the fetcher of a shape object. E.g. with solid-node-client:

const client = new SolidNodeClient();
await client.login(config);
solidProfile.fetcher._fetch = client.fetch.bind(client);

Feel free to try it and leave some feedback or check out the repo if you want to learn more.

Now developers just have to agree on the underlying shape expression/schema and then the cost to become interoperable goes really low :smiley:


Looks very promising. Can I use it to read objects from an rdflib store?

Yes for finding all nodes of a certain shape you can use the findAll() method or findOne() to read a specific node. For now it is implemented to fetch the doc that is passed as an arg, but i plan to also implement options for “local” or no-fetch operations.

At the moment it is also implemented in a way that it looks for nodes that match the rdf:type of the shape expression. So, to use findAll() without ids is only possible for shapes that have a specified type. I am currently still thinking of how to do it more generally because some shapes also use wdt:p31 (instance of - Wikidata) and others don’t have any type to pre-match on and validating all nodes is expensive at scale.

1 Like

Nice project. One small thing… the package.json says it is GPL-3.0. Might be best to make that explicit with a LICENSE file.

1 Like


1 Like

Interesting project, this looks like thrift generating ts code from IDL file, or graphql generate server code from gql file?

1 Like

Correct, it is a bit similar to graphql-codegen (the config, and typegen), but the generated operations are more modeled with prisma as an inspiration. I have worked with it before and liked the way the interface works.

However, the bulk of the functionality of prisma, I won’t yet implement/is hard to implement in the Solid Ecosystem. I think the filtering and aggregation that prisma allows is a bit more difficult to do with federated data sources. Could imagine to use sparql / comunica for that in the future, when more pods have sparql endpoints.