- Justin Bingham
- ericP
- Jackson Morgan
- elf Pavlik
- Josh Collins
- Panel format and focus
- Renaming footprints
- Footprint primer and Spec
- Justin: It started with a question "If I have a shape, where do I write it?".
- ...: We need shared understanding of data, intuitive boundries. Often we work with data conforming to more than one shape which stay in the same data boundary.
- ...: We need something that intersects graph and resources. Our "footprints" attempt to do it.
- ...: After discussing it with Tim and Ruben they had something very specific in mind, so we are going to name ours something else.
- ericP: You can just modify URL and put your own name there to preview it: http://uu3.org/checkouts/janeirodigital/footprintlib.js/footprints/primer?blueprint,imprint,imprint
- Justin: I like constelation since some people working with graphs have resent to trees.
- Jackson: ShEx allows you to define trees. I find constelation not sounding intuitive.
- Justin: We also look at using it for telling app what access you want give it to it.
- Elf: I understand the need to have a name, but maybe we can focus on how exactly it should work, so we have a better ground to name it.
- Eric: I think how it works is secondary to the problem it solves.
- Justin: We've evolved a lot since the panel began, and we have a better understanding of the goals we're aiming to tackle, so the panel repository needs some updating to reflect this.
- The problems and goals that we covered in last weeks session covers the full bredth of what this panel should be aiming to solve: "Create an interoperable, safe application ecosystem in solid without changing Solid's fundementals"
- The way that the panel was structured, we broke things out into individual projects and we had things like "data validation", "portability" in vacuums. But, they're all part of the bigger problem that we're aiming to solve.
- I'd like to propose how to organize it:
- People agree with the problems
- A set of requirements that are needed to satisfy the problems and goals organized in two parts
- A skeleton use case for an end to end application
- A set of work based on that that's needed to fulfill the goals
- I'd like to propose through pulls some updated structure and focus for the panel between now and next week's session. And the aim is going to be to get us to iterate on some real meat that fulfills the stated problems and goals for an interoperable ecosystem.
- Justin: I think the problem we have is just "interoperability" rather than "data interoperability". Would be be open to renaming the panel to interoperability.
- Eric: Shapes give you data interoperability, but footprints don't. They give you application interoperability.
- Justin: We're also going to be talking about organizing information in the pod to provide interoperability. But also the paterns that are employed in the pod to find and discover it.
- Elf: I recall the conversations on the community call last year, and was thinking that we shouldn't have all these repos and focus our work. So, I think we shouldn't try to drive the scope. I would see footprints as hypermedia controls.
- Eric: If you could figure out a way to add that to the primer, that would be good in the intro
- Justin: Another example would be how applications can register in someones pod.
- Jackson: Currently we have footprint proposal. How do we expand it to more global exosystem. I think of query federaton, indexes etc.
- Justin: We decided to leave out querying mechanism since that should be able to evolve over time and there should always be different options.
-
Justin: Spec should give you enough to write tooling for developers and other advanced software.
-
Jackson:
-
ericP: If you have shapes interop, two different applications relying on the same shape, we have 90% of our job there. Now if we have a photo album which can have images or image refs. Footprints pretty much does it.
-
Jackson: Footprints can apply to resource and container?
-
Justin: For resources it just defines shape or media type for the resource.
-
...: With github example, if I create new repo, issues container will get automatically created.
-
Jackson: I had idea before that all developers should come to dynamic consensus on shapes. But now it seems that preferably developers will come to consensus on footprints.
-
...: How do we handle footprnts which somehow ovelap?
-
Justin: We want people to be able to store things in their stores. Where things get stored will impact how you grant access to those things.
-
Jackson: Footprints sounds like single inheritance system.
-
ericP: In situation you describe footprints would help to surface your modelng choices.
-
Justin: Once somethng gets stored in the storage, you shouldn't need to move it around based on how you want to classify it. You also shouldn't need to move it around to give someone specific access to it.
-
Justin: looking at the github example footprint, it has very complex footprint, we probably wouldn't reccomend modeling it this way.
-
...: Footprint can use other footprints. For example evernote has notebooks and notes.
-
Jackson: It sounds like each resource is a thing. We wouldn't put bunch of stuff in one resource.
-
Jackson: It sounds like turning RDF into property graph.
-
Justin: I think it allows you to turn each resource into property graph.
-
Elf:...
-
ericP: I tried to use indrect contaner to point to something not nested in it.
-
...: We could easily address relationships between resources.
| template | instance | verb | |
|---|---|---|---|
| footprint | footprint instance | stomp | primer |
| blueprint | imprint | imprint | primer |
| constellation | constellation instance | instantiate | primer |
| seed | shrub | plant | primer |
| shape tree | instance | plant | primer |