2020-01-06 Data Interoperability Panel

# 2020-01-06 Data Interoperability Panel ## Present * @justinwb * @jaxoncreed * @jamiefiedler * @elf-pavlik * @ericproud * @kjetilk ## Issues - Justin: Main agenda: discuss updates to the PR (https://github.com/solid/data-interoperability-panel/pull/32). I went through every issue I could find that was resource metadata related and included them. But I'd like to give a bit of background to the changes that were made. - ...: I think we should do a couple of updates. 1 from eric and the footprint work. Then Jackson will give a quick overview of some thinking he's been doing on interop. And he created an issue we can dive in offline. ## Footprints - Eric: Not a lot of progress from last time because of vacation. - ...: I added shex validation so that we can prove shapes. And the github app is now just one of my github repos. We also got around the architectural issues where if it was an organization it would be its own pod. - ...: I'm in the process of stripping some stuff out and simplifying it. I could probably make it public and share it in the next few days. And since it's working, I can write up how it works in the spec. We could incorporate it in the main spec or not depending on what people think. - ...: Work left is taking RDF manipulation and saying "You posted me this" I'll find this spot and this place. I want to port it so Jamie can integrate it into the node solid server implementation. That would take a week beccause NSS is all async and we need to re-architect it a bit for that. - Justin: That was good updates. Sounds like people can expect to start seeing some stuff. I think spec and primer is going to go a long way to provide feedback on the approach. Then we can iterate on the approach based on feedback - Eric: I was thinking to concentrate mostly on the primer and in the spec if there's an algorithm or something complex, I'd throw that in the spec document which wouldn't be as complete as the primer. ## Hair brain scheme - Jackson: Main problem is that there are a few different ways to handle discovery and access control being proposed - Adding shapes in order to cover a use case not covered by fs-based access control. Other proposals (like tags) have also been proposed - Not one of them encapsulates every kind of use case - Could see a problem with futureproofing - In the future this could lead to complexity if we need to support too many divergent ways - Maybe it would be a good idea to have one flexible way to do access control and discovery - Requirement - all other ways could boil down to this one way - don't worry about ui friendliness or efficiency - SPARQL construct queries could be one way these all boil to - construct queries define abstract subgraph without knowing what's available - will write an example with enough time - translate ShEx shapes or fs into CONSTRUCT queries - every request has to include a CONSTRUCT query, or some other format on top of that, but must always implement this - other points - detail more about how we would need to change the query structure for it - ericP: what does the CONSTRUCT pattern would look like? - Jackson: query itself would describe a graph which would need to be satisfed. Eg. triples from specific graph (or sub graph). All tripples associated with node with `rdf:type` eg. chat. - ericP: CONSTRUCT x WHERE y, would would the x look like? - Jackson: x would stay what triples we would expect - ericP: I might have tried something similar a while ago, including translating between vocabularies. For acls I would have pretty much CONSTRUCT x WHEre x . - Jackson: We could restrict x to simple `{s, p, o, g}` - Justin: Examples in the issue would come very helpful. Also authorization needs to be something regular people can understand - what kind of access they authorize. We need to keep UX in mind when we design it. - Jackson: One could have very flexible ways to do UIs based on this low level flexible approach. - ericP: an example: https://www.w3.org/2009/Talks/0504-swobjects-ep/acls#(5) - Jackson: Maybe we could just constrain it to WHERE clause - ericP: in that case we would pretty much get shape validation - Jackson: you could do other thigns, like chats from specific person etc. ## Resource Metadata https://github.com/solid/data-interoperability-panel/pull/32 - Justin: We use this PR pretty much like google doc for inline comments. - ...: - Elf: how can the server create a reference to a metadata resource on another server? - ... i can see how clients could do that. - Justin: suppose you were setting up shape validation on some Resource. - ... the server doesn't decide the server. The client stipulates the metadata (e.g. shapes in this exampe.) - Elf: There's no way to modify what's going in the Link header. - Justin: agreed. "The server needs to maintain a working knowledge... appropriate validation and sanity checks to make sure it is valid." - ... If the server knows the server knows that a document is validated by some shape, the schema could be on some other server. - Elf: should the link be directly to the resource? - Justin: are you saying that any resource metadata should live on the server? - Elf: if the client controls the Link headers, there's no way for the server to get the headers into the resources. - Justin: you're saying you need an interface for the client to e.g. assign a shape validation to a resource? - Elf: possibly. could leave it up to the server. - ... if we want to give clients control over the link headers, we need to provide an interface for client control. - Justin: I believe we do that already because when we look up a resource, the server gives you the metadata resources by API.... - ... your point the is that the server would say "here's where you'll write the e.g. shapes" - ... but the server could still be configured - ericP: in my prototyping of footrpints, i have link header that points to the footpring possibly pointing to another server, it could get cached locally but still it references external footprint. - Elf: how does this relation (going i Link header) gets created? - ericP: ... operation where client does POST which has Link rel=footprint in the request. Server fetches that footprint and responds with something that tells client where to post data. In some cases client could stomp more than one footprint. - Justin: In ericP's example, the footprint metadata resource would be a local resource that would point elsewhere. - ericP: ahh, so I was talking about POSTing to create local resources which are described by external footprints; you're talking about managing non-local resources... - Elf: I only recall Link method proposal: https://tools.ietf.org/html/draft-snell-link-method-12 but haven't seen using Link header in request to create link relations. - Kjetil: we can have several iterations. if we're not going for external resources now, we still have the Link header to add it later. - Justin: do you think that "a give resource MAY link to metadata on another server" should say? - Kjetil: leave it in. - Justin: "metadata resources on the same solid server MUST follow the LDPR interaction model". - Kjetil: TimBL didn't consider LDP to be a very important part of Solid, but it's very clear that we reuse things in the LDP spec. But we don't use e.g. the hierarchy of interaction models. - ... We specifically don't require the client to say what interaction model it uses. - ... We haven't decided if the client MUST say e.g. LDPC or LDPR. - Justin: I think the bigger point is that metadata resources MUST follow the same interaction model as the other resources. - ... Are we making the statement that they are resources in their own right? - Kjetil: are these resources ldp:contained? - Justin: the server makes a decision about where to ldp:contain them. - Kjetil: do we have a Container with ldp:contains triples? - Justin: you could have a container that has all of the ACL resourses inside of it. - ... it's an implementation detail. - Kjetil: that's a departure from how things work now but I can see the point. - ... it could be an IndirectContainer which predicates saying "these are ACL resources" - Elf: I think the issue about behaving like ldp:Resources and containment, we have to define DELETE, etc. - ... a server could keep that stuff in a container. - ... we have to figure out where to have the control over those relations (ldp Resource vs. Link header API) - Kjetil: Tim thinks of Solid more as unix flesystem than LDP. I consider acls not being contained as bad design. If we add shapes, footprints and etc. we get even more metadata resources. - Justin: we interact with ACLs/shapes pretty much the same way we do with other resources, modulo some special rules. - ... the server knows which resources are metadata. - ericP: We can do it either way, do PUT an acl and even block myself from changing it in the future. We can ask if its more intuitive, mostly to developers, if it behaves like a resource or not. We need to balance what comes friendly for developers and what we can do in reasonable time. - Justin: part of this was informed by looking a different positions. There are references to some of Ruben's issues at the bottom. - ... The server knows what's metadata and is in a position to handle special rules to e.g. edit an ACL. - ... You leave it up to implementation rather than try to solve it in the spec. - ... This question came up in pretty much every issue so we need to answer it. - Kjetil: "Resource" is everything, but ldp:Resource is much more constrained that rdf Resource or REST Resource. - ... we should find something close to what we already have. if we add Link headers to find ACLs, that can be re-used by some WG. - ... we'd ahve to re-define the who inheritance mechanism if we departed too far from what we have. - ... we can always think about the next iteration. - Elf: Do we want access rules for all the metadata resources or via Link headers? - ... addressing those issues would help us see if metadata resources behave like normal resources. - Justin: this is premised on the notion that the server knows if something is an e.g. ACL or not. - ... it determines the described/controled data object by something server-specificl. - ... What we have today is NSS, which is basically being retired. - ... Even NSS uses link headers, even though it always happens to be in the same place. - ... I don't think this proposal breaks what we are doing now. - ericP: NSS in principle uses Link header but in practice it always puts acl in predictable location. - Elf: clients have to do discovery using that link heade and not assume any specific location of acls - Justin: can we all agree that discovery through the Link header is appropriate? - ... I think what we're trying to figure out is what special treatment to metadata resources get? - Kjetil: +1 to Link header. - Justin: [quoted "ACL is found by link header, not by any other means"] - ...: https://github.com/solid/data-interoperability-panel/pull/32#issuecomment-569957952 > Given the URL of a resource, a client can discover the metadata resources by issuing a GET (or HEAD) request and inspecting the Link headers in the response. The [rel= attribute](https://tools.ietf.org/html/rfc8288) will define the relationship to the target URL. - Justin: metadata resources work like normal resources but server knows based on link relation to treat the as special metadata resources. client interacts with them like with normal resources. - ...: I hoped that content of that PR would be after resource access section in the spec - Justin: Resource Description would get used for general purpose description. For example for binary resources like images. In NSS we used it for `.meta` only for containers. - Elf: I think that container extra tripples come as a special case in NSS where client doesn't interact directly with that resource. - Elf: We may need to consider adding explicit way to assigning access control rules to specific metadata resources. - Justin: Shape Validation, I like idea of having that metadata resource local to the server. - ...: Server Managed: For example who and when wrote the resource, clients could discover it but not be able to modify it. Pretty much read only for any client. - ericP: What do we get from having them visible? - Justin: For every resource which get created server could sign that write and make that available to users to read. - ...: We may need other kinds of metadata, like configuration metadata. For example to enable memento time travel. - Justin: I extracted those sections from various issues referenced at the bottom of PR.