# On datashapes as a complement to vocab

**URL:** <https://forum.solidproject.org/t/on-datashapes-as-a-complement-to-vocab/1298>\
**Category:** Solid App Development FAQs\
**Created:** [February 18, 2019, 8:38pm UTC](https://forum.solidproject.org/t/on-datashapes-as-a-complement-to-vocab/1298 "2019-02-18T20:38:11Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![SimonShapiro](https://dub1.discourse-cdn.com/flex017/user_avatar/forum.solidproject.org/simonshapiro/32/477_2.png) [@SimonShapiro](https://forum.solidproject.org/u/SimonShapiro)\
**Post date:** [February 18, 2019, 8:38pm UTC](https://forum.solidproject.org/t/on-datashapes-as-a-complement-to-vocab/1298/1 "2019-02-18T20:38:11Z")

</div>

There have been some discussions about vocabularies in the Gitter channels the past few hours. So I thought I would jot some of my thoughts down in the forum.

For interoperability we need to re-use data shapes or at the very least resolve them through some sort of equivalence process. To illustrate, I will use one of my bookmarks that was created with the Markbook application. Here it is:

```auto
@prefix : <#>.
@prefix terms: <http://purl.org/dc/terms/>.
@prefix bookm: <http://www.w3.org/2002/01/bookmark#>.
@prefix XML: <http://www.w3.org/2001/XMLSchema#>.
@prefix n0: <http://xmlns.com/foaf/0.1/>.
@prefix c: </profile/card#>.

<#0.08765609738909719>
    a bookm:Bookmark;
    terms:created "2019-02-12T07:32:50.643Z"^^XML:dateTime;
    terms:title "Style sheets in code";
    bookm:recalls n1:constructable-stylesheets;
    n0:maker c:me.

```

I first noticed that it suggested that it was `a bookm:Bookmark`, yet the example Bookmark used different properties other than `bookm:recalls`. So I decided to describe it from scratch in SHACL.

```auto
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix schema: <http://schema.org/> .
@prefix sh: <http://www.w3.org/ns/shacl#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix sol: <http://solid.org/shapes/> .
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
@prefix terms: <http://purl.org/dc/terms/>.
@prefix XML: <http://www.w3.org/2001/XMLSchema#>.
@prefix bookm: <http://www.w3.org/2002/01/bookmark#>.

sol:BookmarkShape
    rdf:type rdfs:Class;
    rdf:type sh:NodeShape;
    rdfs:comment "A bookmark refering to a website."^^rdf:HTML;
    rdfs:label "Bookmark";
    sh:targetClass sol:Bookmark;
    owl:equivalentClass <http://www.w3.org/2002/01/bookmark#Bookmark>;
    sh:property [
        sh:path foaf:maker;
        sh:description "Person creating the bookmark";
        sh:name "Created By";
        sh:nodeKind sh:IRI;
    ];
    sh:property [
        sh:path terms:created;
        sh:name "Date Created";
        sh:description "The date the bookmark was created";
        sh:datatype XML:dateTime;
    ];
    sh:property [
        sh:path terms:title;
        sh:name "Title";
        sh:description "The title of the bookmark";
        sh:datatype xsd:string;
    ];
sh:property [
        sh:path bookm:recalls;
        sh:name "Web Site";
        sh:description "The URL of the web site";
        sh:nodeKind sh:IRI;
    ].

```

The example bookmark would not validate against this shape and needed to have the type set to `a sol:Bookmark` where the prefix sol is `@prefix sol: <http://solid.org/shapes/> .`

I feel this is more accurate than `a bookm:Bookmark` as it contains the wider range of properties.

But it also highlights that just knowing the vocab is not sufficient for inter-operability. Rather we should also publish the data shape so that we can have apps decide how to cater for differences between the shapes in different apps.

Further, to facilitate a ‘follow your nose’ approach, I think we need to decide on a standard way of discovering the data shape. In this case, for example, we could include it in the typeIndex. So you could go from settings–\>prefs–\>public typeIndex–\>Bookmark where you find a triple to lets you know which data shape has been used.

I also feel, we should curate common data shapes in the same way that [schema.org](http://schema.org) curates them for json-ld.

I am interested in any feedback you care to give.

---

<div class="post-metadata">

**Author:** ![happybeing](https://dub1.discourse-cdn.com/flex017/user_avatar/forum.solidproject.org/happybeing/32/59_2.png) [@happybeing](https://forum.solidproject.org/u/happybeing)\
**Post date:** [February 25, 2019, 12:05pm UTC](https://forum.solidproject.org/t/on-datashapes-as-a-complement-to-vocab/1298/2 "2019-02-25T12:05:41Z")

</div>

No feedback on the content, but want to say that even having not looked into shapes/shacl yet, it was clear and helpful. Thanks.

---

<div class="post-metadata">

**Author:** ![linonetwo](https://dub1.discourse-cdn.com/flex017/user_avatar/forum.solidproject.org/linonetwo/32/4039_2.png) [@linonetwo](https://forum.solidproject.org/u/linonetwo)\
**Post date:** [February 27, 2019, 2:52pm UTC](https://forum.solidproject.org/t/on-datashapes-as-a-complement-to-vocab/1298/3 "2019-02-27T14:52:58Z")

</div>

I think an alternative is share RDF manipulating code to npm, so apps dealing with similar business can use same Typescript schema (inside that package)