Blog post: Shaping Linked Data apps


#1

Hi all.

In my latest blog post, I explain the role that Linked Data shapes might play in Solid apps.

In addition, I am introducing the concepts of forms and footprints that we will need as a complement to shapes.

Warning: it’s quite a long read, but you can just pick the sections that are interesting to you. I recommend reading the individual shapes / forms / footprints parts, and if you’re really curious, also possible future use cases.

Your feedback is most welcome!

Ruben


Focus: A Solid Task Manager
#2

This is a great read, thanks Ruben! One of my questions since I first learned of Solid was about how we can maintain a data-model cross-application, and shapes certainly seem like the way.

We’ve added ShEx shape support into the SDK and I think that’s a good first step, soon we will be adding something more like footprint support as well. But I think overall the work we’re doing aligns with what you’ve written (at least in broad strokes).


#3

Hi @RubenVerborgh,
For a project, my app loads this schema / shape : https://holacratie.solid.community/public/Schema/tension.ttl, construct form from it and submit it to a POD, this is the interpretation I made of the same need, I think.

And here another work from a friend of mind generate forms for Semantic Web https://github.com/jmvanel/semantic_forms


#4

This was a great read and very informative. One question I had while reading was related to your statement:

“…data can be stored or created in one shape but retrieved in another shape.

Could you elaborate on this or point me to more info about how this is accomplished? I may be mistaken, but wouldn’t the shape dictate how the data is mapped, and therefore dictate how that data would need to be queried?

Thanks!


#5

After readthrough, I’ still confuse how I will use Shape in my app.

Is there any JS example that I would use in the future in my app? I used to believe that Shape is only for Client side form creation https://github.com/solid/solid/issues/259

But in you blog post, seems it is also live in Server side, act as something like GraphQL Schema. Which defined the GraphQL Query the Client can perform, and what GraphQL Mutation Client can send.


#6

Could you comment on how this relates to the type registry?

It seems the type registry provides the footprint as long as you know what type you’re looking for, and instead of specifying a shape explicitly, it specifies the root node or container for the shape?
So in future the type registry would be replaced or augmented by expressing shapes and footprints with their own vocabularies?
Or would the type registry be replaced by something completely different?


#7

“…data can be stored or created in one shape but retrieved in another shape.

Could you elaborate on this or point me to more info about how this is accomplished?

I’m thinking here about profile-based content negotiation, where a client says “hey server, can you give me this thing in Turtle or JSON-LD, represented according to either this or that shape?”

wouldn’t the shape dictate how the data is mapped, and therefore dictate how that data would need to be queried?

But data could be reshaped on the fly, either by the server or the client. Even if data is shaped, it still contains semantics, and those semantics aid with reshaping.


#8

After readthrough, I’ still confuse how I will use Shape in my app.

Is there any JS example that I would use in the future in my app?

Hold on, the future is still being built :slightly_smiling_face:
This blog post represents a vision, but many pieces still need to be created. It’s just so you know what is on the roadmap, and how we plan to tackle certain interoperability issues.

But in you blog post, seems it is also live in Server side, act as something like GraphQL Schema.

In all of my work, I assume that code can be moved between clients or servers. So yes, if the server supports shapes, all the better for the client. But we shouldn’t mandate server-side support, because that can be complex/expensive; clients should be able to provide a fallback.


#9

Could you comment on how this relates to the type registry?

The type registry would be one kind of index that can be maintained through footprints. There can be more.

I was never a big fan of the type index, because I found it too hard-coded for a highly specific purpose. Footprints allow for more flexibility there.

So in future the type registry would be replaced or augmented by expressing shapes and footprints with their own vocabularies?

A pod could indicate compliance to a certain shape, which would allow clients to know exactly what to find where.

Or would the type registry be replaced by something completely different?

Footprints would be able to provide a more generic indexing mechanism. Not just by type but, for example, people by last name and photos by GPS location.


#10

Ruben already commented on this, but we have some examples now in the SDK of how shapes can help drive the UI. It started before the footprint concept had been solidified, but it’s not too far off, and future versions will incorporate more of the UI ontologies and so on to make them more interoperable.

That said, the vision I see for shapes is a reusable library of shapes, to help applications maintain consistent vocabularies and predicates cross-application. In other words, a simple example might be an instant message - there could be many different vocabs and predicates used by IM applications, but if they could use an InstantMessage shape, then it’s a lot easier to maintain interoperability, so IMs from one app can seamlessly get used in another app.