# W3C Solid Community Group: Data Interoperability Panel

* Date: 2021-12-21T15:00:00Z
* Call: https://meet.jit.si/solid-data-interoperability
* Chat: https://gitter.im/solid/data-interoperability-panel
* Repository: https://github.com/solid/data-interoperability-panel

## Present
* Hannes
* Justin
* Eric
* Angel
* Pavlik

## Regrets
*

---

## Announcements

### Meeting Recordings and Transcripts
* No audio or video recording, or automated transcripts without consent. Meetings are transcribed and made public. If consent is withheld by anyone, recording/retention must not occur.
* Use panel chat and repository. Queue in call to talk.

### Participation and Code of Conduct
* [Join the W3C Solid Community Group](https://www.w3.org/community/solid/join), [W3C Account Request](http://www.w3.org/accounts/request), [W3C Community Contributor License Agreement](https://www.w3.org/community/about/agreements/cla/)
* [Solid Code of Conduct](https://github.com/solid/process/blob/master/code-of-conduct.md), [Positive Work Environment at W3C: Code of Ethics and Professional Conduct](https://github.com/solid/process/blob/master/code-of-conduct.md)
* If this is your first time, welcome! please introduce yourself.

### Scribe Selection

*

## Agenda

### Next week meeting

* Pavlik: should we cancel?
* Justin: I think we should

RESOLUTION: Next week meeting will not happen, next meeting in January

### Shapetree Java to TS port

Java: https://github.com/janeirodigital/shapetrees-java
Typescript: https://github.com/janeirodigital/shapetrees-js

* Eric: I took Java parser and ported it to TS. I arranged files in predictable matter.
* ...: I'm at 180 errors remaining and I need to figure out how to port the tests.
* Eric: there was shapetrees.js repo but it needs to be removed
* Justin: I just opened shapetrees-java under MIT license in recent weeks.
* Eric: It may not count as independent implementations since TS was ported from Java.
* Eric: I still have bunch of TODOs, some TS nuances like dealing with nulls.
* ...: As I update TS i try to also change Java accordingly
* ...: Worried about merge since i touched a lot of files.
* Justin: TS version is going to go into CSS which will provide server side shapetree validation.

### sai-java overview

https://github.com/janeirodigital/sai-java/

* Justin: sai-java is meant to be companion implementation to sai-js (TS), they should have feature parity. TS version is well ahead since Pavlik has been working on it for couple of months.
* ...: I focused on implementing fundamental resources (Readable, CRUD, Immutable). This part is working and I'm adding test coverage, currently around 75%
* ...: We deal with Jena Model and Resource.
* ...: I added bunch of helpers to work with RDF
* ...: When anything gets merged into main JavaDocs gets published
* ...: Next I will add client side validation as option.
* Pavlik: I didn't implement client-side shape tree validation so it's interesting to see how you go about it
* Justin: Shapetree Java client side validation interface is pretty opinionated. It's all done using interceptors. I'm adjusting it that it can be hooked in and be transparent.
* Pavlik: Will it behave the same if validation is server side or client side?
* Justin: If you do validation client side it's hooking in the core logic and client is using HTTP to look up resources. Server would use local access to get those resources.

### Authorization Agent Service requirements

https://github.com/janeirodigital/sai-js/issues/26

### Solid-OIDC plans to add UMA Authorization Server

https://github.com/solid/solid-oidc/pull/18

* Pavlik: *walking through diagram at URL above*
... authorization server would understand data grants, and that would be the party that does the translation to ACP. Solid-OIDC will define some reqs on the authorization server. Some authorization related spec could implement the solid-oidc parts, acp, and data grants, and handle the delegation chains that we discussed. PR doesn't have rendering - but the primer has the relevant parts of the request flow.