# 2021-08-17 Solid Interoperability

https://meet.jit.si/solid-data-interoperability

## Agenda

* [Remove References List and use ShapePath PR#147](https://github.com/solid/data-interoperability-panel/pull/147)
* [Specification Project Board](https://github.com/solid/data-interoperability-panel/projects/1)

## Present

* elf Pavlik
* Justin B
* ajp
* Barath R
* Jamie F

## Minutes

### [Remove References List and use ShapePath PR#147](https://github.com/solid/data-interoperability-panel/pull/147)

* Justin: we should enable externalizing the relationships again, while using shapepath
* Pavlik: who makes decision which pattern is being used, I think this should be defined at shapetree level
* Justin: I think application could decide
* Pavlik: IMO applications should be consider as tools people use at given time to work with their data and they shouldn't make persistent decisions.
* Pavlik: we should prioritize establishing the pattern
* Justin: we can create issue and add it to the board
* Pavlik: Considering splitting the primer into application context and authorization agent context
* Justin: +1 - but think the spec should stay combined
* Pavlik: +1 on spec combining, but ensure it's clear where one may need to conform in one of the two contexts

### Interoperability library dependency on shape tree library

JB: Question about how much a given interop library (e.g. sai.js) should depend on a shape tree client library for:
- initializing data registries, registry sets, data registrations, application registrations, etc - all will require planting (plus unplanting in cases where adjustment is required after the fact)
- Creating data (send proper link headers for target shape tree / focus node) - would apply to data instances, grants, receipts, etc.
- Updating and deleting doesn’t really need much by way of special attention from shape tree library
- Iterating shape tree references for a given shape tree instance
- Accessing shape tree decorators

EP: we need to make sure we don't include any code that will not be used. Given that it will be used by applications running in a web browser we need to be mindful about [Performance budgets](https://developer.mozilla.org/en-US/docs/Web/Performance/Performance_budgets). At minimum we should use ES modules which bundlers should handle well when tree shaking. Later we can look into using dynamic imports for features loading of which we can defer until they get used.

### [Specification Project Board](https://github.com/solid/data-interoperability-panel/projects/1)

* Justin: I'm currently finishing filling up the To dos. Some of them are mega issues and should be broken up further. At the end spec will full reflect what goes in the primer as well as open TS implementation [sai-js](https://github.com/janeirodigital/sai-js). The vast majority is related to refactoring Access Grants and Data Grants. Spec also will be more compact, currently big part of the spec are the operations. We will follow JSON-LD spec and separate the operations into dedicated document. JSON-LD has syntax and API specifications, syntax just links to algorithms in the API spec. We may keep intro which links to them, maybe a table.
* Justin: In various places in the spec we require UUID for resource names. Now they will not be a hard requirements. We may require unique names, or names that are not descriptive.
* Justin: Primer uses bikeshed includes to embed code from separate files. Specification will now also use the same approach.
* Pavlik: We can also validate the snippets which IMO we have to do.
* Justin: We will add discovery mechanism for Authorization Agent, similar to `solid:oidcIssuer` in [Solid-OIDC](https://solid.github.io/solid-oidc/)
* Justin: We will also review the vocab, shapes and shapetrees.
* Pavlik: We should create gh labels
* Justin: Probably we will do vocab first and later update shapes, but also just evaluate shapes if they can be improved. With latest update to Shape Trees spec we will also need to update our shapetrees eg. remove `st:AllowAll` and `st:AllowNone`.
* Justin: Adding `iriPrefix` to Data Registration will allow more flat IRI spaces.
* Justin: When it comes to Access Grant Access Receipt refactoring. We remove Remote Data Grants and Remote Data Registrations. Instead we will use Delegated Data Grants.
* Pavlik: Those now will only repeat or also narrow regular (Source) Data Grants. In lines with delagation chains in [Authorization Capabilities for Linked Data](https://w3c-ccg.github.io/zcap-ld/)
* Justin: We also remove all the Referenced*
* ...: Access Receipt previously was including copy of all Data Grants from Access Grant. Now each Data Grant will be a separate resource which can be referenced from Access Grant and Access Receipt.
* ...: Data Grants will be defined as immutable.
* ...: We will provide more specific shapes for each scope of data grant.
* ...: We need to clarify how to use shape trees references for InheritInstances scope.
* Pavlik: *Explanation of InheritInstances scope* - Conditional access to child instances of a given parent data instance
* Justin: We need a way to verify that Access Receipt is coming from the agent it claims it is from.
* Pavlik: If we use same discovery path applications are using we can have confidence that grants were issued by specific agent.

## Actions

* Create issue for: Establish pattern to externalize shape tree references - EP