# Solid Interoperability Panel
July 14th, 2020

# Attendees

* Justin B
* Josh C
* Jackson M
* Sarven C
* Eric P
* e Pavlik
* Dmitri Z

# Agenda

* Ecosystem - Data Registration and Data Authorization

# Minutes

## Data Registration and Data Auth

Update on work in progress / marriage of data registration and data authorization

Draft of data registration: https://github.com/solid/data-interoperability-panel/pull/57

- Justin: This Draft just needs some clean up and I'll turn it in PR.
- Justin: It's important to keep in mind how access is organized in data registration when we look at data authorization.
- Pavlik: If NeverNote creates notes and notebooks, it can create new instances.
- ...: Figure 19, suggests that NeverNote can edit registration directly to add new instances.
- Justin: Yes, NeverNote can write to registration. Regisration knows that you will register shapetrees. One shape tree says that it is data registration. Another one says that there will be specific type of data stored there.
- Dmitri: I wanted to step back and ask about the use cases. What are those data registries for, what are they doing for the user?
- Justin: The purpose of data registry gives user a way to register, organize and manage data inside of it. Let's say you have a pod from your health care system gives you for your health data, another one for your wearables and another one at home. When you work with applications you want to effectively traverse those boundries. If aplication wants access to data stored in two different places, you shouldn't need two workflows. User doesn't need to think about complex hierarchies. If notebooks use notes, there is adjacent registration for notes.
- Dmitri: Are they ment to drive authorization screens? Eg. NeverNote wants to access this types of data.
- Justin: Application Profile Document will include what they need to access, which expresses what kind of data they need to access.
- Sarven: If uses does a POST, what is expected from a server given there is data registration or there isn't one.
- Justin: You can follow your nose from user's identity document. Apps will know how to follow their nose.
- Sarven: What is the relation between container and `#registration`. So we attach it to container and it's not a separate resource.
- Justin: To me it is key attribute to how it is organized. Data registration is a container, instance of registration is in a container.
- Sarven: I try to understand relationship between auxiliary resources. Why in some cases we store descriptions in the resource itself, and when we store it in auxiliary resource.
- Justin: Information that we validate resource with given shape is and auxiliary information.
- Sarven: What is target of shape validation resource?
- Justin: Right now there is no server side support for shape trees.
- Justin: We have a Postman collection which sets up the whole structure. We have to store some metadata which should go into auxiliary resource in the resource itself. We have dispute how `describedBy` should be used.
- Sarven: Who in particular?
- Justin: When we talk about configuration resource, you should use `describedBy`.
- Sarven: Dmitri Does NSS allow RDFSource to be described by another RDFSource?
- Dmitri: It does but it doesn't do anything specific about it.
- Justin: I think it only does it for containers.
- Sarven: NSS sets describedBy for any resource.
- Justin: In the example you will see temporary situation where we put auxiliary data in resources itself.
- Sarven: I don't see it as "follow your nose". I don't see relation between container and registration.
- ...: