---
tags: Solid
---
# W3C Solid CG: Data Interoperability Panel 2021-09-21

* Date: 2021-09-21T14: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
* Angel A
* Jamie F
* Barath
* 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
* Eric
* Pavlik

### Introductions
* N/A
*

---

### Re-evaluate naming and meaning of scopes used in Data Consent and Data Grant
[Issue#155](https://github.com/solid/data-interoperability-panel/issues/155)

Justin: We refactored various sections including Access Grants. Now we have Access Consents and registry for them.
... Delegated Data Grants replaced need for Remote Data Registry. ... Access Consents are being stored in Access Consent Registry.
... Access Grants and (Delegated) Data Grants are derived from consents.
... Delegated Data Grants replaces need for a remote data registry.
... BTW wherever we had resource hierarchy section we also had permissions section. Now we just have comments in hierarchy section.
... Wherever you have embedded snippet, we have *view* link to see the full snippet. We also link to those full snippets from resource hierarchy tables.
Eric: With embedding we don't need to include bunch of snippets in the examples, but in full snippet we still have them available.
Justin: Back to issue 155. As we refactor consents and grants we can take a good look at scopes.
... Pavlik suggested that a given registry have only one type of registration.
... There are `inheritFromX`. I believe that covers the use case.
Pavlik: I've neen implementing that. I confirm that the form `allFromX` is useful.
... I suspect that we can have one `inhertFrom` rather than typed `inheritFromX` predicates.
Justin: so five predicates?
Pavlik: yes. let's start with that; optimize later.
Justin Bingham @justinwb [gitter] 16:19:
* AllInstances
* AllFromAgent
* AllFromRegistry
* SelectedFromRegistry
* Inherited

... `AllInstances` would grant to all of the owner's data of that type plus all data shared with the owner across registries.
Pavlik: I would remove "instance" because it's too specific.
... if we decide that a registry should have one registration for a given ShapeTree... @@1
Justin: it seemed more intuitive to say "All from this Data Registry" and "All from my Agent Registry" where this type of data was shared.
... Downside: it's not a great pointer 'cause you're pointing to the whole registry. If it were `AllFromRegistration`, you have to do less work.
... So which is more useful if you want to include delegated grants as well as your down data?
Pavlik: I think we have to tell a consistent story about what's been presented on the user's consent screen.
Justin: I feel like we can better abstract registries for the user; i.e. "this area where you keep your data".
Pavlik: I agree that the registry scope is more useful.
... Even though `FromRegistry` will point to a registration, i +1 it.
Justin: can you have two scopes?
... can you share "data that Bob has shared with me" vs. "projects that Bob has shared with me"
Pavlik: I think we want to have control over sharing which of the ShapeTrees that Bob has shared
... I think we should tie shares to a ShapeTree. [ericP +1]
Eric: It won't be a burden for a user 'per shape tree' control. When they make this decision they will be already
thinking about type of data they are sharing.
Pavlik: on a grants, the ShapeTree should be required. Also data owner (except for `All` scope).
Justin: do any of these decision affect the above list of scopes? (i.e. can we accomplish our use cases withthose 5?)

Pavlik: All 5 scopes are used for data consents, only AllFromRegistry, SelectedFromRegistry, and Inherited apply to data grants. Bottom three must have reference to a data registration.

JB: Will also include shapes in the PR
Justin: added `hasDataResource` property (instead of `hasDataRegistration`).
... We might want to subclass them or have a unique scope. Neither seems to be required.
Pavlik: prefer to finalize after we implement it.
... might want subclasses or refs from data grant with different property.
... we shouldn't expect to finalize until implementation.
Justin: alternative to `hasDataGrant` could be `hasTrustedGraph`. allows you to keep the same linking properties.
Pavlik: let's add a note saying that we'll after implementation.

---

### Generic predicate to assign labels for Data Instances, needed when selecting instances on consent screen
[Issue#186](https://github.com/solid/data-interoperability-panel/issues/186)

* Pavlik: [introduction] quick topic; no proposal.
* ... we talk about `selectedFromRegistry` for a scope.
* ... we need to label, either by an e.g. rdfs:label, or something in the ShapeTree. don't see how to generate consent screen without them.
* Justin: +1
* ... both would work. Gut reaction went with rdfs:label.
* ... Prob is that rdfs:label is used pretty liberally. could mislead.
* ... so leaning towards Shapes and ShapeTrees
* Pavlik: currently, we put lots of responsibility on @@2
* ... could be in some domain-specific data
* ... Apps would have to manage potential duplications.
* ... The AuthAgent knows the ShapeTree.
* Justin: the ShapeTree modeller typically has a better model.
* ... By next session, shoot for updates for 155 and 186.
* Justin: Let's say authorization agent doesn't know anything about medical domain
* Pavlik: it will not know
* Justin: How does the authorization agent know how to present each prescription to the user?
* ...: it seems in jurisdiction of the shape tree to tell which predicate should be used.
* Eric: I would be inclined to add generic predicate to shape tree vocab
* ... `st:label rdfs:subPropertyOf rdfs:label .`
* Justin: Where would that shapeTreeLabel go?
* Eric: I think this would be only in schema/shape
* Eric: actually we have shape tree decorators, we can stick it there

---

### Interop requirements for Notifications Panel

* name: text

---

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

ACTION: text