Skip to content

Latest commit

 

History

History
84 lines (75 loc) · 5.71 KB

2019-09-30.md

File metadata and controls

84 lines (75 loc) · 5.71 KB
Raw

Meeting #4 - 2019-09-30

Solid Data Interoperability Panel

Connection Info

Connect with your computer, tablet, or smartphone:
https://global.gotomeeting.com/join/620786365

Dial in:
United States (Toll Free): 1 866 899 4679
Belgium (Toll Free): 0 800 78881
Costa Rica (Toll Free): 0800 542 5404
Denmark (Toll Free): 8025 3112
France (Toll Free): 0 805 541 052
Germany (Toll Free): 0 800 723 5274
Ireland (Toll Free): 1 800 818 263
Netherlands (Toll Free): 0 800 023 1954
New Zealand (Toll Free): 0 800 47 0051
Norway (Toll Free): 800 33 083
United Kingdom (Toll Free): 0 800 031 4727

Access Code: 620-786-365

Agenda

  1. Data Validation
  • Discussion around how shape validation should be incorporated into the current Solid protocols.
  • Identify different areas of consideration that would need to be factored and addressed by any sound implementation.
  • Goal is to produce a hypothesis that can be leveraged by prototype implementation work.

Minutes

Discussing https://github.com/solid/data-interoperability-panel/blob/master/data-validation/use-cases.md

  • Justin: use cases that we've reviewd with the panel
  • ... use cases that arrise if you don't ahve validations.
  • ... enabling/modifying validation
  • ... haven't done mis-use-cases but please submit any ideass.
  • ... Use case: new app corrupts data
  • ... Use case: app asks for permission to update data (structures)
  • ... People won't understand details prompts
  • ... Validation on a Resource says that any data writted to the Resource MUST validate.
  • ... Validation based on pattern
  • ... systems keeps track of "first writer"
  • ... Disjunction on Container
  • Justin: I see Use Cases very similar to ones for Web Access Control, when someone tries to write you check if they have permissions to the resource. Here we need to verify that it conforms to specific shapes.
  • Dmitri: We need to decide what statements we use (etc. ldp:constrainedBy) and where we store it, in resource itself in .meta
  • Justin: I see it related to Data Portability
  • Dmitri: Side note, we should just tackle topics in the panel we stumble on them
  • Justin: We should decide how to apply shapes in recursive way, preferably it should follow WAC pattern
  • re ldp:constrainedBy, some relevant error codes: 417 Expectation Failed,
  • Dimitri: Verifiable Credentials ran into this problem.
  • ... they wanted to support ShEx, SHACL and another crypo-enforcable schema.
  • ericP: it's easy to consistently report that there was a failure but reporting why something failed is more of an art.
  • ... there are about 50 Million reasons to create rooted graphs for RDF.
  • Dimitri: I agree
  • ... Why can we use JSON Schema to validate Verifiable Credentials but ShEx and SHACL won't work?
  • ericP: because JSON Schema treats it as a tree, but the outside object in the nested graph has no predictable place in the nested graph.
  • Justin: does the association between nodes and shapes require special access control?
  • Dimitri: seems like a good place to start.
  • Elf: app may write data but not shapes.
  • Justin: the app has already stated what shapes it expects.
  • ericP: could have a registry of resource selectors to a list of shapes, each with a list of apps.
  • Justin: I don't know this should be in the data validation spec. It should say what you get when you violate a shape.
  • ... App Authorization should say what shapes an app is managing.
  • ericP: we should answer how we can have ecosystem of independently developed apps that interoperate
  • ... sometimes changes to schema would imply monotonic changes to schema, when you do that you would not know what app you would break
  • ... we need to know what apps get affected if we change schape for data
  • Justin: we could also say that once you set validation on something you can't modify it
  • ericP: If I write something into a schema, I can't add something later on that changes the meaning of it (explaining monotonic change)...
  • ericP: for changing shapes we could look for a way of all apps accessing the data consent to change to the shape
  • elf-pavlik: I think we should look how shapes play role in discovery and consider 3rd party shapes registry which apps would use for compatibility
  • ...: data spaces would also use those common shapes for validation to enable use of all the apps which produce data conforming to those shapes
  • ericP: Let's try to look at the cases where we think it might work
  • Justin: Let's nail down the 'normal' path and then deal with exeptions
  • Justin: registry can help to mitigate the problem but won't elimintate it
  • ericP: if everyone follows common shapes, would keeping track on associating shapes and apps will be excessive
  • Justin: Capturing from the call
    • we want to mirror WAC inheritance rules, as well as rules for accessing the resource containing shapes - note from chat

@DoctorBud: (from about 10min ago) Regarding the idea that Control is necessary to see the validators associated with a resource... If I have authorization to Write, but don't have Control or Read, I still think I should be able to see what kind of shapes I'm allowed to write. So requiring Control to see the validators seems like it would blind a writer to the valid shapes. ACL on the other hand, requires Control to see it.

  • Justin: there's a data leakage problem. OTOH, if you have write perms, you can write to everything and derive the shapes from error reports.
  • ... It would be a big blow to interop if you couldn't see the schema you failed.
  • ericP: we don't talk about it in general case, we talk about it only in case where someone explicitly in the ACL disallow read access to shapes
  • Justin: Let's start with the WAC convention and then possibly challenge that