Meeting minutes
Introductions & announcements
acoburn: most of today will be about containers
… any introductions or announcements?
acoburn: reminder: end of april, we hope to have another F2F meeting in London
… at the ODI (downtown London)
… all, check your travel options
laurens: also, there's daylight savings time coming up?
… from next week, for three weeks, there will be a time difference
<TallTed> use your electronic calendars! don't try to keep up with timezone shifts in your head!
<pchampin> check https://
laurens: for non-US residents, this means a shift
Issue triage
acoburn: 3 new ones
… some are follow-ups on the container discussion
laurens: about #87, we need more discussion
<gb> Issue 87 Handling of the case where a resource is created in a non-existent container (by laurensdeb)
laurens: wrt to error handling
… about #88, this is additional elaboration about recursion from deletion
<gb> Issue 88 Containers: specify behavior on deleting non-empty containers (by bjdmeest)
laurens: for #88, it's ready for PR, mostly clarifying text
… for #87, it's more work
… e.g. error codes are bit all over the place
… for now, we can do needs-discussion label
acoburn: for #86, this is needs-discussion
<gb> Issue 86 Have separate auxiliary resource for containment index (by damooo)
acoburn: this issue describes a very different approach to manage containment
… we need to discuss whether we are in a position to follow this different approach
Containers core PR
acoburn: this first pr is about the core work of containers
… laurens, what are the things that need to be discussed, to vote today?
… I think we should move to vote on this today
laurens: this is the base PR, #81
<gb> Pull Request 81 Introducing support for Containers in the LWS protocol (by laurensdeb)
laurens: I believe most comments have been resolved
… first comment is about minimal set of link relations to be defined
… I suggest 2 issues: requirements on link relations, and issue on slug header
bendm: fine for me to discuss in new issues
laurens: OK
… going to next issues, these are covered in #87 and #88, so OK
<gb> Issue 87 Handling of the case where a resource is created in a non-existent container (by laurensdeb) [needs-discussion]
<gb> Issue 88 Containers: specify behavior on deleting non-empty containers (by bjdmeest) [ready-for-pr]
laurens: then, going to metadata types
… issue is that these metadata aspects that are non-URI structures: these cannot be part of linksets, this is going to be a separate linkset
… then about distinguishing container and dataresource metadata: to be refined
… so separate issue
laurens: going to REST binding
… we need to discuss conneg
pchampin: yes, I'm fine to discuss in a separate issue
laurens: wrt Container representation
… there is a section on container media types and representation of containers
… there is quite some overlap
… also a section on storage description resources
… probably 2 things should happen: lws media type should be merged on container representation text
… should also include storage description resource
… second thing: also put this under a broader auxiliary resource description
ack
<laurens> w3c/
<gb> Issue 67 Generalized notion of auxiliary resources (by damooo) [needs-discussion]
pchampin: we should reuse #67
<gb> Issue 67 Generalized notion of auxiliary resources (by damooo) [needs-discussion]
laurens: yes, done
… next discussion: description of mediatype
… currently, there is a high-level description
… e.g. what to do when resources may have alternative media representations
… we could fallback to a default/main/original mediatype
… or put an array of media types
pchampin: I don't consider this as blocking
… this is a more general issue. We should clarify how data resources work
… they have a 'native' mediatype, during creation or update
gibsonf: on mediatype, it would make more sense to use the way solid does it now, i.e., having 'type' instead of mediatype
<uvdsl> (need to run in 3 min, apologies.)
gibsonf: not everything is a file
… could a data resource be a non-file?
laurens: it can be any data-bearing resource
gibsonf: I have an issue with describing this as a file, then we're just doing a file system
laurens: feel free to create an issue to update this glossary
gibsonf: some of my comments are at the bottom, not inline
… why differentiate between media type and type?
pchampin: one clarification: when talking about file: the text doesn't care how that's implemented
… what it says, is from the client's perspective, that's a resource that has a media type
… that could be a limitation, but the core of LWS is a resource where you store content
… yes it looks like some kind of file, it does not prescript it to implement as such
gibsonf: if I have pure triples: is there a media type for retrieving that?
pchampin: as far as I understand: you should request a media type that is triple-bearing (e.g. text/turtle, rdf/xml, json-ld, ...)
… some implementations could have better understanding of triples and do content negotiation, just like other implementations could have better understanding of images
gibsonf: so, dynamically requesting another mediatype...?
pchampin: that could be optional behavior
<Zakim> acoburn, you wanted to talk about data resources
acoburn: cfr conflating type and mediatype: I suggest to be very careful about that
… type: dataResource/container is a property of the resource
… mediatype: property of the data
… conflating them would be a bad idea
gibsonf1: in our implementation, we have containers that are both: containers can also be data resources
… why do we need a hard line?
acoburn: I don't think it's prohibited that containers can also be dataresource
… it's about representation vs resource type
gibsonf1: I agree, everything has a media type
<gb> CLOSED Issue 39 Cool URIs for the Semantic Web: 303 URIs forwarding to Different Documents (by elf-pavlik)
gibsonf1: so keep the media type as separate property
laurens: I will create a separate issue
… there is nothing explicitly prohibiting a data resource to be a container resource except
… maybe in the glossary
… gifsonf1: could you raise an issue for that specific data resource AND/OR container resource?
Luke: LWS should have some native capability to provide linkage
… that should differentiate it from a glorified filesystem
… to have more robust linking
laurens: there's already the notion about metadata, which allows linking
… also, the text that talks about multiple containment also allows more dynamic linking
<Zakim> gibsonf, you wanted to respond to Luke
gibsonf1: one of the glossary definitions talks about exactly one root container
… I suggest 1 or more root containers
… to have multiple hierarchies
<Zakim> acoburn, you wanted to talk about linking mechanisms
acoburn: there are a number of mechanisms to link one resource to another
… link headers: client can add link headers: from one resource to multiple other resources
… additional linkages supports at higher levels: in metadata content you can have established relationships (in RDF,JSON,XML,...)
<Zakim> ryey, you wanted to talk about linking (if not covered by acoburn)
ryey: linked web storage: the linking is in the link headers, the data resource can be interpreted as blobs. so it's a _linked_ web storage, not a _linked web_ storage
laurens: conclusion of Ghent F2F: we need to balance the reliance on RDF, so far focus has been on link-relationship based metadata RFC
… there are benefits in using RDF in a normative sense, but some initiative is needed from the community
… we haven't delved into the governance wrt the content of the dataresources
<Zakim> gibsonf, you wanted to ask on linked header - its a representation, not a resource?
gibsonf1: on linksets: aren't those representations called separate resources?
laurens: introduction of linksets are a separate PR: an 'auxiliary' resource
… we have an open issue #67
<gb> Issue 67 Generalized notion of auxiliary resources (by damooo) [needs-discussion]
gibsonf1: but auxiliary resources are resources
… we would never make metadata about metadata
acoburn: linksets are important for LWS, but I would like to focus on containers
… today
laurens: going to logical resource organization
… glossary: I did not go into depth of having multiple root containers
… at some level, there needs to be root container that does not have a parent
<Zakim> gibsonf, you wanted to ask isnt LWS storage the root container?
gibsonf1: isnt LWS storage the root container?
laurens: in section 6.1, we could introduce multiple root contains
acoburn: yes, exactly
gifsonf1: currently, the glossary describes the root container?
laurens: we can change the description to 'a root container' to not preclude a single root container
laurens: we will defer to #67
<gb> Issue 67 Generalized notion of auxiliary resources (by damooo) [needs-discussion]
laurens: wrt logical resource organization
… wrt to single containment:
… should we leave this section out now, defer to multiple containment, or loosen the wording?
gibsonf1: on linkset: is a separate resource associated with every lws resource
… that's a representation
<pchampin> FTR, I disagree that a linkset is just a representation of a resource; it is a resource of its own, with a separate URI, which one can GET or PUT
laurens: that was a previous definition I moved, I suggest to create a separate issue about that, I'm open to change
<Zakim> gibsonf, you wanted to ask on linkset in this pr
acoburn: we should discuss this in a different call
bendm: back to single containment: I suggest to remove that section
… and put into a separate PR
acoburn: I agree
laurens: yes, moving to a separate PR
… now, how does the group stand for this PR?
<acoburn> PROPOSAL: to accept the pull request #81 as proposed, subject to the open issues
<Zakim> gibsonf, you wanted to ask, also have an issue with listing resources in container user has no rights to see
<gb> Pull Request 81 Introducing support for Containers in the LWS protocol (by laurensdeb)
gibsonf1: I have an issue with listing resources in container user has no rights to see
laurens: there is wording that it should include identifiers, but could include filtering
… that's moved to a MAY
gibsonf1: can we leave the implementation-specific note out?
laurens: If have no issues with that
gibsonf1: and it's within spec that a container only shows the resources the user has access to?
<acoburn> +1 to leave out the implementation note if that brings us to consensus
laurens: yes, additional is may
<acoburn> PROPOSAL: to accept the pull request #81 as proposed
<laurens> +1
<pchampin> +1
<acoburn> +1
<gibsonf1> +1 (assuming we can still revise definitions etc)
<Luke> +1
<bendm> +1
<TallTed> +1
RESOLUTION: to accept the pull request #81 as proposed
<gb> Pull Request 81 Introducing support for Containers in the LWS protocol (by laurensdeb)
<ryey> +1 (generally fine; will need to carefully consider implications)
acoburn: resolved!
… see you next week!