# W3C Solid Community Group: Data Interoperability Panel

* Date: 2021-11-02T14: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

- Justin B
- e Pavlik
- Eric P
- Angel A
- Jamie F

---

## 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

- Justin B

## Agenda

### Action Items from Last Week

- Justin to raise application profile specification at next protocol editor meeting.
- Pavlik to raise application profile specification at next authentication panel meeting
- Pavlik to create PR for Authz Agent share notification (#107)

### PRs and Issues

#### Recap on Authn Panel / Client ID Document

* Pavlik: Believe i misinterpreted document that we could rely on content negotiation
* ...: Aaron clarified that static JSON-LD would be OK so you can't rely on content negotiation
* ...: This could be problematic because we can't rely on turtle representation
* ...: At least we agree agree that these specs will rely on the same document and we need to coordinate
* ...: Maybe have a separate mini-spec for defining these profiles that all specs can rely on
* ...: Should work on making solid storage broadly accessible / available - have it as minimum
requirement that one could always put this document in a solid storage. Could be a common denominator
so that whenever we have a hestitation about publishing something we always put it into solid storage. If the current JSON-LD and turtle for RDF sources are satisfactory then we rely on that. If we go with same requirement then we ensure that server provides both representations and client can conneg for that. As we have it in solid-oidc, the client would need to be able to parse the JSON-LD because the aim is that its usually the compacted JSON-LD (could be used as pure JSON).

* EricP: Does that in turn mean you have to be able to put back JSON-LD? (e.g. if editing).

* Pavlik: If we have solid storage assumption then you could parse in JSON-LD and put it back as turtle. In many cases these profiles use static storage and probably don't need to think as much about editing in solid-oidc, more about how it is published as a readable resource.

* Justin: Okay with static hosting

* Pavlik: What about solid storages being broadly available? Just publish in solid storage

* Justin: I'm not against it. My guess is that specifically with ID documents they would be statically hosted. Saying that it needs to be solid storage is limiting. We have to determine is that the right requirement given some of those considerations. Or maybe we have different requirements for something that is read only.

* Pavlik: Was also some discussion about assumption of webids being public and implicit trust. If webid and oidc issues share same domain than do you need to double-check (?). Also discussed putting delegation in HTTP link header. Could still be exposed in a link header. Need to review assumption of whether the social agent webid document should be public? Probably some things would break if they are not public?

* Justin: In DID, isn't there assumption that document is public? I think it is.

* Pavlik: Related issue https://github.com/solid/solid-oidc/issues/51#issuecomment-951935639
...: https://www.w3.org/2005/Incubator/webid/spec/identity/#privacy

* Pavlik: Need to resolve issues with format, as well as public / non-private. And need to say what happens if something is not accessible. JB +1

#### [Use agent registration discovery after receiving access receipt](https://github.com/solid/data-interoperability-panel/pull/212)

* Justin: Let's say I sent receipt to you and said it was from Eric. You would look up Eric's AA, do discovery and probably find nothing. It's not really that much of security problem. You could say it's a DoS vector.

* Eric: This one could saturate your 'go check it out queue'.

* Pavlik: Should consider recommendation that any public inbox uses some special and dedicated storage that's setup more for high transaction volume and some measure of spam

* Justin: Looks good overall - will give it a line-by-line later today

* Pavlik: Will create issue to track delegation scenario. In cases where Alice is a Trusted Agent for Acme, and she delegates to Bob, which Agent Registry should it go in? Trinpod has also been bringing up some organizational pod use cases.

#### [Updated shape tree terminology](https://github.com/shapetrees/specification/pull/71)

* Justin: Eric and I were discussing terminology. Some terms could be more intuitive. This PR is addressing it. The other thing was similar refactoring on decorators as we did here.

* Eric: It's kind of A/B testing, we explained it over and over and used terminology which was had the most success.

* Justin: Metadata resource gives information about which shapetree is assigned to the resource.

* Eric: It could be used for other purposes.

* Justin: Shapetree locator was renamed to shape tree manager. Link relation was just URI of shapetree locator. In response of consideration to use LDP constrainedBy, we defined managedBy. We didn't use constrainedBy to not to go LDP heavy. Especially that solid moves more and more in direction of having less dependency on LDP. We also made it bi-directional.

* ...: Previously what we called shapetree location, is called shapetree assignment. We optimized some properties within assignment.

* ...: We also added `st:viaPredicate` as well as examples.

* ...: We now also include snippets.

* Eric: this also makes validating snippets easier.

* Pavlik: We should automate validation.

* Eric: In ShEx Primer we have some extra metadata to help with validation.

* ...: ??? from Ghent actually wrote paper on first iteration of ShapeTrees. They could appreciate changes in current version.

## Action Items

- Pavlik to create issue to track delegation scenario on access share
- Justin to raise application profile specification at next protocol editor meeting.
- Justin to follow up on mailing list usage, including automated digest