solid / data-interoperability-panel

Repository for the Solid Data Interoperability Panel
MIT License
51 stars 19 forks source link

Relying on shapes from a common repository #25

Closed elf-pavlik closed 3 years ago

elf-pavlik commented 5 years ago

I'd like to follow up on out conversation yesterday about using shapes for validation. Thinking further about common repository of shapes, used as shared knowledge between solid storage instances and apps. I see possibility that shape used for validation (and or discovery) would not stay colocated with resources that use it as a constraint, but it would just stay referenced by IRI in that common repository. Let's imagine shape denoted by https://w3id.org/solid/shapes/comment, resource on ACME's pod would use it through a statement

@prefix ldp: <http://www.w3.org/ns/ldp#> .
@prefix shapes: <http://w3id.org/solid/shapes/> .
@prefix acme: <https://acme.example/> .

acme:ld00cuc/ck17xaflb000001o1dgvx6vgt ldp:constrainedBy shapes:comment .

In this case, only maintainers of https://w3id.org/solid/shapes/ can modify the actual shapes, or even keep them immutable and create new versions https://w3id.org/solid/shapes/comment/v1 etc. Also maintainers of ACME's storage would only have access to modify references between resources and shapes, possibly using some storage administration app which allows applying shapes from common repositories to resources in storage. Most users posting comments on ACME's discussion board, would use apps of their choice, each one producing data conforming to selected shapes (from https://w3id.org/solid/shapes/ repository) but those apps would not even have any functionality to modify shape references, even less modifying any shapes themselves.

RubenVerborgh commented 5 years ago

Thinking further about common repository of shapes, used as shared knowledge between solid storage instances and apps.

We have to be careful about centralization there though; is there an inherent need to put them in one specific place?

elf-pavlik commented 5 years ago

I don't think they have to stay located in one place like https://schema.org , but for app developers I would see need for at least some aggregator like https://lov.linkeddata.es

I'll write very specific use case of discussion boards, which would pretty much work around https://www.discourse.org/customers BTW we also use discourse on https://forum.solidproject.org/

I think administrators of solid storage instances and developers of apps need a very straight forward way to:

While they could use compatible shapes, in many cases neither storage admins or app developers don't want to create shapes just reuse existing common ones. App developers probably would also appreciate tool like https://search.google.com/structured-data/testing-tool to check if their app will work with commonly deployed discussion board workspaces.

justinwb commented 5 years ago

We have to be careful about centralization there though; is there an inherent need to put them in one specific place?

Agree - and I don't think we actually need to publish them to a centralized location to have a place that developers can go to search for shapes they may want to use, see what people are using, and collaborate around the same.

elf-pavlik commented 4 years ago

During today's call I did mention that on app authorization consent screen, when app asks to access data conforming to some shapes (calendar events, discussion board posts etc.), people need an easy way to verify what does shapes actually match. I don't think any average person will look at some representation of shape. Most likely they will just rely on the label of the shape and what source the shape definition comes from. It can't really come from the app itself, since we want to use it to restrict access of that app. In that case trusted repositories of shapes may come into play again.

I would compare it to package sources on linux distributions. Many people just install something like Ubuntu and never modify package sources, advanced users may add/remove sources as they wish. Another way to look at it may come from comparing to TLS certificate authorities, technically one can use self-signed certificates, or use custom certificate authorities. Still most average people want to get default list of authorities they trust and never deal with more advanced options.