# 2021-08-24 Solid Interoperability https://meet.jit.si/solid-data-interoperability ## Agenda * [Define usage of Shape Path for Data Grant with InheritInstances scope #131](https://github.com/solid/data-interoperability-panel/issues/131) * Review additional items added to [1.0 specification milestone](https://github.com/solid/data-interoperability-panel/projects/1) ## Present * Justin B * Jamie F * Hannes * e Pavlik * Barath * Ángel A ## Minutes ### [Define usage of Shape Path for Data Grant with InheritInstances scope #131](https://github.com/solid/data-interoperability-panel/issues/131) PAVLIK: Came out of implementation work on sai.js. Found it quite convenient that if you want to create a child data instance (e.g. task. for a project) - on the child data instance you can call a new child data instance method and it give you a ready data instance bootstrapped with relation to the parent. Since it is InheritInstances scope, when you create the new instance it automatically adds the relationship to the parent first (otherwise you wouldn't be allowed to create it). If we have a simple binary relation (e.g. project has task) we can do that quite easily. Think its convenient for the app developer to have the library do that. When we have a shape path its a bit more tricky because we have a more indirect relationship, might require the application to handle creating those. ERICP: If we have a straightforward example where a project has issues, and it's a repeated property, we could easily follow the shape path. The problem I think you're talking about is a many to many table, and don't want to model the many to many as being part of the series of things we're crerating shape paths for. PAVLIK: Not sure we're on same page (going to share example) - demonstrates that the library might not be smart enough to add links to the parent resource, and the intermediate resource ERICP: There are some ways to evaluate the schemas for the library to determine if it can handle it. PAVLIK: Are cases where a simple predicate link are all that's needed. In those cases don't need to load to ### Review additional items added to [1.0 specification milestone](https://github.com/solid/data-interoperability-panel/projects/1) JUSTIN: Reviewing items added to the spec target. Reducing surface area of the text by a lot, but maintaining all flexibility and capabilities. * Removing Registry Sets as intermediate pointers * Moving Application Registry to Agent Registry * Optimized out Application Receipt Registry * Access Grant Registry -> Consent Registry ## Actions * Add "viaPredicate" to the shape tree specification (+1 JB, +1 ERICP) * Add issue - question on adding whether a reference is reverse or not (possibly coupled with next bullet) * Add issue - question on where to look for the shape tree reference (parent resource, child resource, external 'bridge' resource)