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
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
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:
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