Shapes

[calummackervoy]

There are two main languages for shapes on the semantic web, SHACL and ShEx

It's like SQL constraints for data, but at the application layer rather than the database layer

Why not ontologies?

Good (long) reference on Shapes can be found here: https://ruben.verborgh.org/blog/2019/06/17/shaping-linked-data-apps/

I'll try and summarise it a bit below

Whereas vocabularies provide a list of possible attributes, shapes mandate a specific structure for data

In theory, data modeled with one vocabulary can be accessed seamlessly using another through mechanisms such as reasoning. In practice, reasoning is seldom available on the client or server, so data access patterns would need to match storage patterns exactly

Shapes allow applications to see data through specific lenses, regardless of what the underlying structure of the data might be.

Crucially, data can be stored or created in one shape but retrieved in another shape. So unlike some other technologies, shapes primarily matter dynamically during interactions and exchanges, instead of acting as permanent upfront contracts. Different apps can interact with the same resources through different data shapes.

In my work on #3 I needed to do a little reasoning on RDF type. I was surprised to see that even reasoning the transitive property required some manual referencing to ontologies. I opened #14 which details an issue using custom ontologies and how to automatically traverse it in this situation

Ruben summarises the issue we could face with these kinds of overlapping ontologies:

For instance, suppose a pod internally stores data as:

<#me> a schema:Person;
      schema:name "Ruben Verborgh"@en;
      foaf:mbox <mailto:ruben@verborgh.org>;
      dbo:birthDate "1987-02-28"^^xsd:date.

Then an app should be able to request that data as this shape:

<#me> vcard:fn "Ruben Verborgh"@en;
      vcard:hasEmail [
        vcard:value <mailto:ruben@verborgh.org>
      ];
      vcard:bday "1987"^^xsd:gYear.

Note how the structure and field names are different, while the information contained in the second is a subset of the first.

Using just ontologies, we'd need to have a custom reasoning to bridge the gap between them, which actually for common vocabularies like VCARD and FOAF we have been

Shapes may become the generic solution which we need to get around ontology inconsistencies

In the end, we don't want to be writing code with assumptions about what properties are in the data at all: https://ruben.verborgh.org/blog/2019/06/17/shaping-linked-data-apps/#shapes-apps

[calummackervoy]

Footprints may also be useful for writing data to Pods, something which has also been coming up thanks to #3

[calummackervoy]

In the (relatively) short-term we could use Shapes to validate the data being saved to a dataset, e.g. that a Task is submitted with the necessary taskImplements property which is the responsibility of the TaskActor developer

[calummackervoy]

https://forum.solidproject.org/t/using-shape-expressions-to-become-interoperable-just-got-a-whole-lot-easier/4223