# Solid Weekly Editorial Session January 31 2020 - (8AM-9AM EST / 2PM-2PM CEST) https://meet.jit.si/solid-specification ## Attendees - Kjetil Kjernsmo (Editor) - Sarven Capadisli(Editor) - Justin Bingham (Editor) - Mike Adams Agenda: - Footprint Update - Resource Metadata Update - [Issue #69](https://github.com/solid/specification/issues/69) Footprints - Proposed footprints to interoperability panel on Monday in a 2.5 hour session that went really well - Documentation is incomplete and needs some immediate attention to ensure people understand the direction - Structure of footprints is fairly well established now, but how you apply footprints to organization of data in the pod, and incorporate authorization around it needs to be defined in the docs - Justin, Eric Prud, and Jamie F are working to update the document ahead of next interop session at least with the right structure (possibly absent work-in-progress specifics on org and authz). Resource Metadata - After Sarven's latest review feedback is incorporated it will be ready to turn into respec and submitted as a candidate proposal to the specification Sarven: - General structure / discovery and characteristics are part of core - Which metadata types are part of the core? This should be open for discussion - DescribedBy should be part of core, but others should be referred to as optional - What's bubbling up in some issues are around things that aren't quite meta, but right now we're calling the whole thing resource metadata - Some use-cases aren't strictly about meta-data - Some of elf Pavlik's examples propose use cases we need to evaluate in terms of what should or shouldn't go into resource metadata - RDF data is self-describing - need a clear line between what should be meta or not - Is there a better way of framing this / using a better term than resource metadata (i.e. resource decoration?) Justin: - Reiterating Sarven's points - Open to using a different name than resource metadata Kjetil: - We give clients the option to add more data into representation of a resource, as well as different metadata mechanisms - Idea that we should have a hypermedia to declare that this resource is something you need control for, or that you need server managed - All of the metadata resource combine different aspects of this - We could formulate this in RDF by having certain types - In the short term having this as part of the spec with it as an extension mechanism makes sense - We need to find out where the gaps are now, and what points are left to get it into the spec Justin: - No big points of contention left, just need to finish incorporating sarven's review feedback - Hoping to be in a position to have a pull request next week for resource metadata into the spec document Sarven: - Need to describe the common behavior across the types - Can hit some of the structure and organization in editorial process - For the other specs, there's usually a section to allow extensibility. If we plan to add new notions (e.g. some new metadata type), it needs to conform to this same behavior / expectations of the other one. - Follow up in panel to start about concensus for which types to include as core and not core - We're probably going to have more of these types - Inbox is an example with a similar discovery - Seems reasonable or safe enough that it could work for the resource metadata types - Discovery mechanism for these types should be probably be common. - If someone comes up with a new type they can refer to same mechanism / system - If they need to do something different then it would just need to handled differently. ## Issue #69 Mike: - Here to join in the discussion. - Regarding index.html page - trying to follow the discussions and make sure he understands how evolution affects work in progress. - Why can't the document continue to be a standard html document? Why does it have to inject rdf? Kjetil: - Both a practical issue and deep philosophical issue - Are we going to use contents of index.html for representation of the container? Mike: - My issue is that you can't edit the contents of the container - (Sarven) You can Sarven: - This applies to any resource - There is a fallback rule that you don't use the same identifier for a different resource - In what cases will a cat change to a dog for html representation of a container but not anywhere else? Justin: - Proposal to use a configuration metadata parameter to control how index.html is handled for a given container Sarven: - Seems interesting but people have also been doing this in different ways already - Should it be modifiable by a client? - (Justin) The proposal would be set server-side by someone in control - Should we use server configuration for this? - There was a question earlier on - how did index.html get into the system to begin with? Justin: - I think that this all fits within the LDP resource model that we already have (plus metadata) - Implementations can and should differ in terms of how they implement it - Index.html is an LDPR like any other, and then how it is handled is left to configuration metadata on the container resource Kjetil: - Index.html representation is left to the user - Container representation is left to the server - What is the container representation? - Will always be containment triples and any server managed metadata - HTML representation is totally uncontrolled Sarven: - There's a whole server imposed constraints to catch Kjetil: - Unwilling to spend more time on this - Talked to timbl about how he thought this should be - Got an answer that was consistent and coherent - We have so many really important issues - this one is low priority relative to other pieces Mike: - Facts in an html document should speak for themselves and shouldn't rely on container to speak for it Sarven: - There's no expectation that representations are equivalent - If the agreement is that this is RDF bearing - If not, then HTML (or whatever) can do whatever they want Justin - Agree with Sarven - If it's RDF-bearing, and we want to exert control over the composition or content, this is where we get help from shapes and footprints - If it's LDP-NR (non-rdf), you should have freedom as you like - How to handle index.html should be done as a configuration parameter on the container.