# W3C Solid Community Group: Data Interoperability Panel

* Date: 2021-09-28T14: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
* Michal
* Barath
* Pavlik
* Juliette
* Hannes
* Eric P

---

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

### Introductions
* Michal: (mrkvon) typescript developer - has been doing some work developing solid apps for 1-2 years. more intensively in the last couple of months. Getting involved in open hospitality network. Would like to see Solid used in decentralized hospitality exchange and collaboration in general. How can people find each other in decentralized systems? Worked on https://trustroots.org now contributing to https://openhospitality.network

---

## Agenda

### Action from last week

Justin: I still need to follow up on actions from last week, re-adding them to the bottom.

### Public repository of commonly used shape trees (and shapes)
[shapetrees.pub](https://github.com/shapetrees/shapetrees.pub)

PAVLIK: People shouldn't have to start defining their own method for where to put shapes and shape trees if they don't want to.

PAVLIK: Should get going with shapetrees.pub / shapes.pub to get some experience on workflow to maintain and change these types.

PAVLIK: Tim mentioned that we should start with contact, fitness, etc.

HANNES: +1 Happy to help and common shapes like that are of interest

PAVLIK: Which shapes / shape trees are required?

HANNES
: How do you establish contacts with people in pods so a family can watch something together. How can you build up your media profile for people to come together, express common interest, and provide them recommendations. How do we express permissions of what and how people have shared media profile? Media profile is how do you bring together media consumptions across multiple diff services into one format so you as a user can control what you want.

PAVLIK: contacts is a bit of a special case

JC: what makes contacts complicated beyond name, webid

PAVLIK: need to be careful when you share because of the social graph. are some requirements that when you receive access from someone you know you may want to check if its someone you know (e.g. your contacts). webid has historic connection to foaf but wac uses vcard. just need to take some of this into account

JC: Have been doing some work on building these up, user journeys, etc. Happy to share thoughts on that.

JB: +1 agree we should get this going

JB: shapes.pub and shapetrees.pub already has basic PR workflow, where main branch is auto deployed. It's more defining the workflow for how PRs get reviewed and merged. What are the criteria of review, one side is something like schema.org where all data is curated together. Other side is allowing people to submit whatever they want, even if it duplicates other shapes/trees.

ERIC: At w3 the namespace policy is you have a chicken / egg phase where you're making a spec and want to have a namespace, but you don't want to commit to anything yet. typically we have a status that says something is unstable. don't be surprised when tomorrow we break everything. Per w3 process when something reaches candidate recommendation it is stable. that's a way of doing it. might be useful to have something analagous. don't have a notion of iterating on working drafts for data.

JB: Is that status of unstable just part of metadata or it would be reflected in URI. Does transition between states change URI?

ERIC: No changes to URI. Could do something where we have stability written into metadata of resource.

PAVLIK: Thinking about it being a recommended common repo for app develoeprs to ensure that developers interoperate on the same data - would lean more towards schema.org (in that there's a barrier for entry). Don't want to have apps that don't interoperate over data. Would rather have something like a template repo (you can fork it if you want to publish your own). Especially if we want to dedicate some work and well-curate it, we should avoid duplication unless there's good reason.

JB +1 I think we can do both, if there is good reason for divergence we can allow it and keep an eye on it.

ERIC: I'm into heavy duty curation but we run the risk of people claiming unfairness. Could do something more like npm where it's automated.

PAVLIK: Make it clear somewhere in the purpose for this repo that the more divergence we have the less interop.

JB: we can deal with issues as they come up if they come up, and we'll provide ability to fork repo and stand up their own to support full DIY freedom. I agree that the messier we start the messier we may end up.

ERIC: For some insulation / protection - figure out something that would work in a general purpose registry - so essentially ensure that our structure can be used generally. JB +1

ERIC: In healthcare in particular, there are places where things talk about the same information in different ways (e.g. FHIR) which describe general purpose observations which can include blood pressures, vs. other data models that talk about them specifically. Different structures that cover the same domain. Could decide not to do that but could also decide to include some metadata to help differentiate and migrate from one to the other.

PAVLIK: Also need to think about how we migrate from one shapetree to a later version of another. Need to avoid changing the URIs, and essentially allow the data registration to be migrated. Need to think about how in the spec we can handle migrating forward to adjust trajectory as we evolve.

ERIC: Thought about this a bit at the beginning, and thought that apps could elect to choose which one they're ready to migrate to.

### Update on Consent / Grant Scope Definitions (#155)
https://github.com/solid/data-interoperability-panel/issues/155

JB: We worked out the set of scopes during last sessions. Access Consent section has section Data Access Scopes, it shows which are appropriate for grants and/or consents. Each scope has links to consent and/or grant shape which validates it.
We have examples of Data Consent and (Delegated) Data Grants created based on that consent.
...: Originally I was also putting inheritance in but it was getting to confusing, I will explain it in dedicated section for `Inherit` scope.
JB: I would like to rearrange the resource hierarchy table to use less space
eP: We may want to look at how we can provide some test suite using the snippets we have.
JB: In shapetree java implementation mocking was a bit of pain, we could look at putting together something that would simplify testing.
JB: I plan to finish this section sometime today and make PR.

### Next issues for 1.0

JB: We need to discuss revocation and superseeding of data grants
JB: Shapes and shapetrees, we may want to put them through process of publishing them to shapetrees.pub
eP: I think they are special case and may be hosted together with the spec on solidproject.org regular apps would not use them directly.

### Dependencies / UCRs for Notification Panel

---

PROPOSAL: text
* name: +1,0,-1
*

ACTION: Create issue for viaPredicate on Shape Tree Spec
ACTION: Create issue for labeling shape tree instances on Shape Tree Spec
ACTION: Create issue for migrating to later versions of shape trees and shapes
ACTION: Create an issue to activate shapetrees.pub / shapes.pub for public use and utility