-
Notifications
You must be signed in to change notification settings - Fork 19
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
1 changed file
with
128 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,128 @@ | ||
| # Meeting #9 - 2020-01-07 | ||
| ## Solid Data Interoperability Panel | ||
|
|
||
| ## Connection Info | ||
| __Connect with your computer, tablet, or smartphone:__ | ||
| https://global.gotomeeting.com/join/620786365 | ||
|
|
||
| __Dial in:__ | ||
| United States (Toll Free): 1 866 899 4679 | ||
| Belgium (Toll Free): 0 800 78881 | ||
| Costa Rica (Toll Free): 0800 542 5404 | ||
| Denmark (Toll Free): 8025 3112 | ||
| France (Toll Free): 0 805 541 052 | ||
| Germany (Toll Free): 0 800 723 5274 | ||
| Ireland (Toll Free): 1 800 818 263 | ||
| Netherlands (Toll Free): 0 800 023 1954 | ||
| New Zealand (Toll Free): 0 800 47 0051 | ||
| Norway (Toll Free): 800 33 083 | ||
| United Kingdom (Toll Free): 0 800 031 4727 | ||
|
|
||
| __Access Code:__ 620-786-365 | ||
|
|
||
| # 2020-01-13 Solid Data Interoperability | ||
|
|
||
| ## Present | ||
| - Elf | ||
| - Justin | ||
| - Eric | ||
| - Jackson | ||
| - Kjetil | ||
| - Jamie | ||
| - Ruben Verborgh | ||
|
|
||
| ## Agenda | ||
|
|
||
| 2 latest draft of Resource Metadata | ||
| - should be close to moving it to Respec and submitting as a candidate proposal | ||
| 1 ericP gives status on Footprints | ||
| 3 Jackson added an example use case to the SPARQL CONSTRUCT proposal | ||
|
|
||
| ## Footprints | ||
|
|
||
| - created a [tests repo](https://github.com/janeirodigital/footprint-tests) | ||
|
|
||
| - started a [primer](https://janeirodigital.github.io/footprint-tests/primer) | ||
| - Eric: MultiCal could have one solid calendar format and other ones for example google calendar. | ||
|
|
||
| ## Resource Metadata | ||
|
|
||
| - Justin: wrt the data-interop PR#32 | ||
| - ... .. server metadata and configuration metadata were incomplete | ||
| - ... .. clarified interaction model: "should conform to the same interaction model as other solid resources" (avoids saying whether Solid is LDP) | ||
| - ... we talk about "direct association"; added a defn | ||
| - ... so if i have a link header for foo.ttl, and the Link header says that rel="acl" href="foo.ttl.acl", then foo.ttl.acl is *directly associated* with foo.ttl | ||
| - ericP: are MUSTs server or client obligations? | ||
| - justin: server, except in "Discovery" | ||
| - ACTION Justin: specify client or server explicitly where applicable in resource metadata doc | ||
| - Justin: [re direct or indirect link to shape] You can have extra parms configuring how the validation is performed, e.g. advise or reject on failures. | ||
| - ... | ||
| - changing `solid:server` to `solid:server-managed` | ||
| - Elf: for each type of metadata resource, it will be 1:1 to the resource. | ||
| - Justin: i think we can do that if we go type-by-type | ||
| - Jackson: I would prefer not to limit it to 1:1, can we think of cases where metadata would reside on another server. For example one very complex group of agents which someone would want to reuse. | ||
| - Justin: resource MAY link to metadata on different server, we don't even require it to be a solid storage. | ||
| - Jackson: where would the link between the resource and e.g. a remote ACL be stored. | ||
| - Justin: the server has to know and tell people in the Link: headers | ||
| - Elf: we have no controls allowing the client to manage them. | ||
| - Jackson: so it would make sense to say that when you delete the resources, the *link* is deleted. | ||
| - Eric: For cases where one would like to reuse existing acl for multiple resources. Do we want to enable clients to have control over which acl gets used? | ||
| - Justin: I agree with the 1:1, but I'd want to do it type-by-type. | ||
| - Elf: if there's more than one, the client doesn't know which one to manipulate. | ||
| - Elf: for group definitions, i was thinking about re-using ACLs. | ||
| - ... but if you're editing a shared ACL, you run the risk of unexpected consequences. | ||
| - ... it's doable to have re-usable parts but each resources would have it's own e.g. ACL | ||
| - Eric: each type of metadata would have ways to reuse external resources | ||
| - Justin: we can work within the scope of each metadata type because we can't predict what we'd want to introduce for new metadata types. | ||
| - Kjetil: the [WAC impl notes](https://github.com/solid/web-access-control-spec/blob/master/README.md#group-listings---implementation-notes) talks about ACLs residing on different servers. can get you into an infinte loop. | ||
| - ... this seems like it (infinite loops) could be an issue for anything reference e.g. ACL resources. | ||
| - Justin: when the server is authoritative, it has a chance to prevent/resolve inconsistency | ||
| - ... where it's not authoritative, you have to be really thoughtful. | ||
| - Kjetil: we should decide what happens if we get into loops. | ||
| - Justin: i could see the pubsub events service allowing servers to resolve these issues -- will require a lot of thought. | ||
| - ... moral: if you're relying on data you don't control, you're inviting problems | ||
| - Elf: when we verify access for groups, we define what happens if the group defn isn't available (access, server down). | ||
| - ... can do same for shapes. | ||
| - Justin: we had a conversation about local caching of e.g. shapes. | ||
| - ... that can protect you against the resoure disappearing | ||
| - ... of course, it creates other issues you have to deal with e.g. shape gets updated | ||
| - ... [Configuration metdata] if you want to store Mementos, you could do that in conf metadata | ||
| - ... for conf metadata, i thought it appropriate that the client have ACLs over the resource | ||
| - ... so if you have a solid server which supports memento, and there are resources in your POD that get updated every second, you may want to configure which resources get memento-ized. | ||
| - ... users' apps should be able to configure which resources get what granularity, so the client needs controls. | ||
| - Kjetil: I think that the Link: headers is sound, but if it's a Container, it seems like an impl detail, but you still have a rel="type" href="ldp:Resource" header. | ||
| - Justin: NSS stores metadata 'next to' file or 'inside of' container. This resource seems to stay responsible of storing all the metadata which doesn't sound practical. | ||
| - Kjetil: [this section](https://github.com/solid/solid-spec/blob/master/content-representation.md#metadata) doesn't say anything about updating this resource. | ||
| - Eric: Everybody has different notion about what metadata is. | ||
| - Justin: I would see good implementations keeping all metadata resources in some other container deticated to them. | ||
| - ...: Going over example of adding description of an image. Client would create image and then could do HEAD on URI of that image to discover location of resource description. | ||
| - Kjetil: I think of scenario where in NSS one would modify content of `.meta` file by interacting directly with resource URI. | ||
|
|
||
| ## [Create a Generalizable baseline for interop #34](https://github.com/solid/data-interoperability-panel/issues/34#issuecomment-573741883) | ||
|
|
||
| - Eric: why `accessTo` stays optional? | ||
| - Jackson: ACL rules express to who access get granted, what kind of access and to which data | ||
| - Eric: example would have `accessTo: <./chat1.ttl>` | ||
| - Jackson: `constructQueries` would provide common bottom line while in paralel higher level rules could be used. | ||
| - Eric: why not to use ASK queries? | ||
| - Jackson: 'cause otherwise you have to customize your SPARQL impl to keep the visited triples. | ||
| - ... not using the `CONSTRUCT { ?s ?p ?o } WHERE`, just the rule body. | ||
| - Jackson: does ShEx has way to do anything algorytmic? | ||
| - Eric: You have two objectives, 1. having user configurable set of triples 2. if somebody uses different system they could use this as minimal common ground to interoperate | ||
| - Jackson: If we can do 1. but if not 2. we just add to the problem. | ||
| - Justin: I find WAC very simple which I see as benefit. I think that footprints can provide a way to define clear data boundries. One could than apply authorization rules to those data boundries defined this way. | ||
| - Jackson: I search for assembly equivalent for access control rules. | ||
| - Jackson: Any references to papers on arbitrary depth queries in SPARQL? | ||
| - ...: I wonder if we need turing complete language to implement degree of flexibility we find in our use cases. | ||
| - Eric: It depends on use cases. I think we should search for sweet spots in the middle. | ||
| - Ruben: I don't understand exactly which problem we try to solve. | ||
| - Eric: I want to give someone access to my medications but not psychiatric medications. This would require more involved rules. | ||
| - Jackson: I see that various forms of access control and data discovery come up to satisfy slightly different use cases. I fear that we will add many different ways of doing it to the spec to satisfy all those use cases. | ||
| - Ruben: I really miss clear problem statement. Exacly what cases do we try to solve, so that we can define boundries of the problem. | ||
| - ...: I think I understand access control, not sure about discovery since that can happen in so many different ways. | ||
| - Eric: We can have a lot options in terms of selection and access. We need to look for practical solution which gives us broad enough coverage of use cases but without to much of expressivity. | ||
| - Justin: I appreciate forethought proposed by Jackson of having some low level instructions set. At the same time I don't see to many ways of describing access rules. I see more issues with having something that average user can manage in responsible way way to define clear data boundries. | ||
| - ...: Working with footprints we always get back to authorization, how person can manage access. Davi made point that once you expose something on the web, you can't really unexpose it any more. | ||
| - Jackson: I see need to have common way to define any possible access rule. | ||
| - Ruben: I would separate functional and non functional requirements. | ||
| - Jackson: I agree with approach of building something simple first. In mean time we can keep thinking about the problem. |