14:53:06 <RRSAgent> RRSAgent has joined #lws
14:53:11 <RRSAgent> logging to https://www.w3.org/2026/03/02-lws-irc
14:53:21 <acoburn> zakim, start meeting
14:53:21 <Zakim> RRSAgent, make logs Public
14:53:23 <Zakim> please title this meeting ("meeting: ..."), acoburn
14:53:36 <acoburn> meeting: Linked Web Storage WG
14:54:00 <acoburn> agenda: https://www.w3.org/events/meetings/a19ab7dc-1753-433d-bac5-64e3ad8c0a43/20260302T100000/#agenda
14:54:01 <agendabot> clear agenda
14:54:01 <agendabot> agenda+ Introductions & announcements
14:54:01 <agendabot> agenda+ Issue triage
14:54:01 <agendabot> agenda+ Containers -> core PR https://github.com/w3c/lws-protocol/pull/81
14:54:01 <agendabot> agenda+ Containers -> paging PR https://github.com/w3c/lws-protocol/pull/82
14:54:04 <agendabot> agenda+ Other -> open PRs https://github.com/w3c/lws-protocol/pulls
14:54:30 <acoburn> RRSAgent, make minutes
14:54:31 <RRSAgent> I have made the request to generate https://www.w3.org/2026/03/02-lws-minutes.html acoburn
14:59:12 <uvdsl> uvdsl has joined #lws
15:00:44 <TallTed> present+
15:00:53 <acoburn> present+
15:00:58 <acoburn> chair: acoburn
15:01:17 <laurens> laurens has joined #lws
15:01:21 <laurens> present+
15:01:51 <gibsonf1> gibsonf1 has joined #lws
15:01:56 <gibsonf1> present+
15:02:16 <TallTed> previous meeting: https://www.w3.org/2026/02/23-lws-minutes.html
15:02:16 <TallTed> next meeting: https://www.w3.org/2026/03/09-lws-minutes.html
15:02:23 <RRSAgent> I have made the request to generate https://www.w3.org/2026/03/02-lws-minutes.html TallTed
15:03:23 <bendm> bendm has joined #lws
15:03:26 <bendm> present+
15:03:42 <acoburn> zakim, open agendum 1
15:03:42 <Zakim> agendum 1 -- Introductions & announcements -- taken up [from agendabot]
15:04:15 <acoburn> scribenick bendm
15:04:43 <acoburn> s/scribenick bendm/scribenick: bendm/
15:04:55 <acoburn> rrsagent, make minutes
15:04:56 <RRSAgent> I have made the request to generate https://www.w3.org/2026/03/02-lws-minutes.html acoburn
15:05:02 <bendm> q+ to ask for announcements: LWS WG is 27-28/4 in vicinity of Solid Symposium, everything else is to be decided?
15:05:26 <bendm> acoburn: most of today will be about containers
15:05:39 <bendm> ... any introductions or announcements?
15:06:02 <pchampin> present+
15:06:02 <elf-pavlik> elf-pavlik has joined #lws
15:06:02 <bendm> acoburn: reminder: end of april, we hope to have another F2F meeting in London
15:06:09 <bendm> ... at the ODI (downtown London)
15:06:14 <bendm> q-
15:06:20 <laurens> q+
15:06:27 <bendm> ... all, check your travel options
15:06:42 <bendm> laurens: also, there's daylight savings time coming up?
15:07:01 <bendm> ... from next week, for three weeks, there will be a time difference
15:07:09 <TallTed> use your electronic calendars! don't try to keep up with timezone shifts in your head!
15:07:15 <pchampin> check https://www.w3.org/groups/wg/lws/calendar/ :)
15:07:30 <bendm> ... for non-US residents, this means a shift
15:07:55 <acoburn> zakim, open agendum 2
15:07:55 <Zakim> agendum 2 -- Issue triage -- taken up [from agendabot]
15:08:12 <uvdsl> present+
15:08:37 <bendm> acoburn: 3 new ones
15:08:48 <bendm> ... some are follow-ups on the container discussion
15:09:06 <bendm> laurens: about #87, we need more discussion
15:09:07 <gb> https://github.com/w3c/lws-protocol/issues/87 -> Issue 87 Handling of the case where a resource is created in a non-existent container (by laurensdeb)
15:09:09 <bendm> ... wrt to error handling
15:09:26 <bendm> ... about #88, this is additional elaboration about recursion from deletion
15:09:27 <gb> https://github.com/w3c/lws-protocol/issues/88 -> Issue 88 Containers: specify behavior on deleting non-empty containers (by bjdmeest)
15:10:14 <bendm> laurens: for #88, it's ready for PR, mostly clarifying text
15:10:33 <bendm> ... for #87, it's more work
15:10:39 <bendm> ... e.g. error codes are bit all over the place
15:10:59 <bendm> ... for now, we can do needs-discussion label
15:11:11 <bendm> acoburn: for #86, this is needs-discussion
15:11:12 <gb> https://github.com/w3c/lws-protocol/issues/86 -> Issue 86 Have separate auxiliary resource for containment index (by damooo)
15:11:31 <bendm> ... this issue describes a very different approach to manage containment
15:11:58 <bendm> ... we need to discuss whether are in a position to follow this different approach
15:12:15 <bendm> s/whether are/whether we are/
15:12:20 <acoburn> zakim, open agendum 3
15:12:20 <Zakim> agendum 3 -- Containers -> core PR https://github.com/w3c/lws-protocol/pull/81 -- taken up [from agendabot]
15:12:54 <bendm> acoburn: this first pr is about the core work of containers
15:13:19 <bendm> ... laurens, what are the things that need to be discussed, to vote today?
15:13:30 <bendm> ... I think we should move to vote on this today
15:13:46 <bendm> laurens: this is the base PR, #81
15:13:47 <gb> https://github.com/w3c/lws-protocol/pull/81 -> Pull Request 81 Introducing support for Containers in the LWS protocol (by laurensdeb)
15:14:11 <bendm> ... I believe most comments have been resolved
15:14:55 <bendm> ... first comment is about minimal set of link relations to be defined
15:15:56 <bendm> ... I suggest 2 issues: requirements on link relations, and issue on slug header
15:17:23 <bendm> bendm: fine for me to discuss in new issues
15:17:28 <bendm> laurens: OK
15:18:00 <bendm> ... going to next issues, these are covered in #87 and #88, so OK
15:18:01 <gb> https://github.com/w3c/lws-protocol/issues/87 -> Issue 87 Handling of the case where a resource is created in a non-existent container (by laurensdeb) [needs-discussion]
15:18:01 <gb> https://github.com/w3c/lws-protocol/issues/88 -> Issue 88 Containers: specify behavior on deleting non-empty containers (by bjdmeest) [ready-for-pr]
15:18:54 <bendm> laurens: then, going to metadata types
15:19:23 <bendm> ... 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
15:19:58 <bendm> ... then about distinguishing container and dataresource metadata: to be refined
15:20:15 <bendm> ... so separate issue
15:21:01 <bendm> laurens: going to REST binding
15:21:17 <laurens> q?
15:21:29 <bendm> ... we need to discuss conneg
15:21:42 <bendm> pchampin: yes, I'm fine to discuss in a separate issue
15:22:13 <bendm> laurens: wrt Container representation
15:22:25 <bendm> ... there is a section on container media types and representation of containers
15:22:28 <bendm> ... there is quite some overlap
15:22:36 <bendm> ... also a section on storage description resources
15:23:02 <bendm> ... probably 2 things should happen: lws media type should be merged on container representation text
15:23:10 <bendm> ... should also include storage description resource
15:23:15 <Luke> Luke has joined #lws
15:23:28 <bendm> ... second thing: also put this under a broader auxiliary resource description
15:23:34 <pchampin> q+
15:23:42 <bendm> ack
15:23:42 <acoburn> ack next
15:24:09 <laurens> https://github.com/w3c/lws-protocol/issues/67
15:24:09 <gb> https://github.com/w3c/lws-protocol/issues/67 -> Issue 67 Generalized notion of auxiliary resources (by damooo) [needs-discussion]
15:24:21 <bendm> pchampin: we should reuse #67
15:24:22 <gb> https://github.com/w3c/lws-protocol/issues/67 -> Issue 67 Generalized notion of auxiliary resources (by damooo) [needs-discussion]
15:25:01 <bendm> laurens: yes, done
15:25:14 <bendm> ... next discussion: description of mediatype
15:25:20 <bendm> ... currently, there is a high-level description
15:26:10 <gibsonf1> gibsonf1 has joined #lws
15:26:10 <bendm> ... e.g. what to do when resources may have alternative media representations
15:26:22 <gibsonf1> q+
15:26:33 <bendm> ... we could fallback to a default/main/original mediatype
15:26:33 <laurens> ack pchampin
15:26:42 <bendm> ... or put an array of media types
15:26:57 <bendm> pchampin: I don't consider this as blocking
15:27:10 <bendm> ... this is a more general issue. We should clarify how data resources work
15:27:22 <bendm> ... they have a 'native' mediatype, during creation or update
15:27:43 <laurens> ack gibsonf
15:28:06 <bendm> gibsonf: on mediatype, it would make more sense to use the way solid does it now, i.e., having 'type' instead of mediatype
15:28:08 <uvdsl> (need to run in 3 min, apologies.)
15:28:20 <bendm> ... not everything is a file
15:28:56 <bendm> ... could a data resource be a non-file?
15:28:57 <pchampin> q+
15:29:06 <bendm> laurens: it can be any data-bearing resource
15:29:32 <bendm> gibsonf: I have an issue with describing this as a file, then we're just doing a file system
15:29:42 <acoburn> q+ to talk about data resources
15:30:16 <ryey> ryey has joined #lws
15:30:19 <ryey> present+
15:30:24 <bendm> laurens: feel free to create an issue to update this glossary
15:31:20 <bendm> gibsonf: some of my comments are at the bottom, not inline
15:31:33 <laurens> q?
15:31:33 <bendm> ... why differentiate between media type and type?
15:31:37 <laurens> ack pchampin
15:32:23 <bendm> pchampin: one clarification: when talking about file: the text doesn't care how that's implemented
15:32:43 <bendm> ... what it says, is from the client's perspective, that's a resource that has a media type
15:33:07 <bendm> ... that could be a limitation, but the core of LWS is a resource where you store content
15:33:21 <bendm> ... yes it looks like some kind of file, it does not prescript it to implement as such
15:33:49 <bendm> gibsonf: if I have pure triples: is there a media type for retrieving that?
15:34:23 <bendm> pchampin: as far as I understand: you should request a media type that is triple-bearing (e.g. text/turtle, rdf/xml, json-ld, ...)
15:35:00 <bendm> ... some implementations could have better understanding of triples and do content negotiation, just like other implementations could have better understanding of images
15:35:28 <bendm> gibsonf: so, dynamically requesting another mediatype...?
15:35:34 <bendm> pchampin: that could be optional behavior
15:35:45 <acoburn> ack next
15:35:46 <Zakim> acoburn, you wanted to talk about data resources
15:36:10 <bendm> acoburn: cfr conflating type and mediatype: I suggest to be very careful about that
15:36:21 <bendm> ... type: dataResource/container is a property of the resource
15:36:23 <gibsonf1> q+
15:36:28 <bendm> ... mediatype: property of the data
15:36:34 <bendm> ... conflating them would be a bad idea
15:36:37 <laurens> ack gibsonf
15:37:04 <bendm> gibsonf1: in our implementation, we have containers that are both: containers can also be data resources
15:37:23 <bendm> ... why do we need a hard line?
15:38:06 <bendm> acoburn: I don't think it's prohibited that containers can also be dataresource
15:38:32 <bendm> ... it's about representation vs resource type
15:38:43 <bendm> gibsonf1: I agree, everything has a media type
15:39:03 <gb> https://github.com/w3c/lws-protocol/issues/39 -> CLOSED Issue 39 Cool URIs for the Semantic Web: 303 URIs forwarding to Different Documents (by elf-pavlik)
15:39:03 <bendm> ... so keep the media type as separate property
15:39:22 <bendm> laurens: I will create a separate issue
15:39:43 <bendm> ... there is nothing explicitly prohibiting a data resource to be a container resource except
15:39:47 <bendm> ... maybe in the glossary
15:40:10 <Luke> q+
15:40:18 <laurens> ack Luke
15:40:24 <bendm> ... gifsonf1: could you raise an issue for that specific data resource AND/OR container resource?
15:40:40 <bendm> Luke: LWS should have some native capability to provide linkage
15:40:56 <bendm> ... that should differentiate it from a glorified filesystem
15:41:02 <bendm> ... to have more robust linking
15:41:10 <acoburn> q+ to talk about linking mechanisms
15:41:24 <ryey> q+ about linking
15:41:37 <ryey> q- about linking
15:41:38 <bendm> laurens: there's already the notion about metadata, which allows linking
15:41:44 <gibsonf1> q+ to respond to Luke
15:41:59 <bendm> ... also, the text that talks about multiple containment also allows more dynamic linking
15:42:10 <laurens> ack gibsonf
15:42:10 <Zakim> gibsonf, you wanted to respond to Luke
15:42:12 <ryey> q+  to talk about linking (if not covered by acoburn)
15:42:36 <bendm> gibsonf1: one of the glossary definitions talks about exactly one root container
15:42:45 <bendm> ... I suggest 1 or more root containers
15:42:51 <bendm> ... to have multiple hierarchies
15:43:15 <bendm> q+ about multiple root containers: how would you discover that, don't you need a root root?
15:43:37 <laurens> ack acoburn
15:43:37 <Zakim> acoburn, you wanted to talk about linking mechanisms
15:43:55 <bendm> acoburn: there are a number of mechanisms to link one resource to another
15:44:13 <bendm> ... link headers: client can add link headers: from one resource to multiple other resources
15:44:47 <bendm> ... additional linkages supports at higher levels: in metadata content you can have established relationships (in RDF,JSON,XML,...)
15:45:16 <laurens> ack ryey
15:45:16 <Zakim> ryey, you wanted to talk about linking (if not covered by acoburn)
15:45:26 <gibsonf1> q+ to ask on linked header - its a representation, not a resource?
15:46:21 <bendm> 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
15:46:55 <bendm> laurens: conclusion of Ghent F2F: we need to balance the reliance on RDF, so far focus has been on link-relationship based metadata RFC
15:47:37 <bendm> ... there are benefits in using RDF in a normative sense, but some initiative is needed from the community
15:47:51 <laurens> q?
15:47:52 <bendm> ... we haven't delved into the governance wrt the content of the dataresources
15:47:56 <laurens> ack gibsonf
15:47:56 <Zakim> gibsonf, you wanted to ask on linked header - its a representation, not a resource?
15:48:08 <bendm> gibsonf1: on linksets: aren't those representations called separate resources?
15:48:33 <bendm> laurens: introduction of linksets are a separate PR: an 'auxiliary' resource
15:48:42 <bendm> ... we have an open issue #67
15:48:43 <gb> https://github.com/w3c/lws-protocol/issues/67 -> Issue 67 Generalized notion of auxiliary resources (by damooo) [needs-discussion]
15:49:01 <bendm> gibsonf1: but auxiliary resources are resources
15:49:01 <acoburn> q+
15:49:09 <pchampin> q+
15:49:20 <bendm> ... we would never make metadata about metadata
15:49:21 <laurens> ack acoburn
15:49:25 <pchampin> q-
15:49:30 <acoburn> q-
15:49:38 <bendm> acoburn: linksets are important for LWS, but I would like to focus on containers
15:49:44 <bendm> ... today
15:49:57 <bendm> laurens: going to logical resource organization
15:50:31 <bendm> ... glossary: I did not go into depth of having multiple root containers
15:50:53 <bendm> ... at some level, there needs to be root container that does not have a parent
15:50:58 <gibsonf1> q+ to ask isnt LWS storage the root container?
15:51:04 <laurens> ack gibsonf
15:51:04 <Zakim> gibsonf, you wanted to ask isnt LWS storage the root container?
15:51:15 <acoburn> q+
15:51:25 <bendm> gibsonf1: isnt LWS storage the root container?
15:51:35 <bendm> laurens: in section 6.1, we could introduce multiple root contains
15:51:46 <laurens> ack acoburn
15:51:46 <bendm> acoburn: yes, exactly
15:51:46 <acoburn> q-
15:52:24 <bendm> gifsonf1: currently, the glossary describes the root container?
15:52:44 <bendm> lauresn: we can change the description to 'a root container' to not preclude a single root container
15:52:59 <bendm> s/lauresn:/laurens:/
15:53:19 <bendm> laurens: we will defer to #67
15:53:20 <gb> https://github.com/w3c/lws-protocol/issues/67 -> Issue 67 Generalized notion of auxiliary resources (by damooo) [needs-discussion]
15:53:51 <bendm> ... wrt logical resource organization
15:53:58 <bendm> ... wrt to single containment:
15:54:17 <bendm> ... should we leave this section out now, defer to multiple containment, or loosen the wording?
15:54:23 <gibsonf1> q+ to ask on linkset in this pr
15:54:24 <bendm> q+
15:54:31 <laurens> ack gibsonf1
15:54:51 <acoburn> q+ to talk about linksets
15:54:52 <bendm> gibsonf1: on linkset: is a separate resource associated with every lws resource
15:55:13 <bendm> ... that's a representation
15:55:51 <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
15:55:54 <bendm> laurens: that was a previous definition I moved, I suggest to create a separate issue about that, I'm open to change
15:55:59 <laurens> q?
15:56:01 <laurens> ack gibsonf
15:56:01 <Zakim> gibsonf, you wanted to ask on linkset in this pr
15:56:23 <bendm> acoburn: we should discuss this in a different call
15:56:25 <laurens> ack bendm
15:56:28 <acoburn> q-
15:56:51 <acoburn> q+ to agree with ben about single containment
15:57:03 <bendm> bendm: back to single containment: I suggest to remove that section
15:57:03 <acoburn> q-
15:57:09 <bendm> ... and put into a separate PR
15:57:12 <bendm> acoburn: I agree
15:57:21 <bendm> laurens: yes, moving to a separate PR
15:57:50 <bendm> ... now, how does the group stand for this PR?
15:58:15 <gibsonf1> q+ to ask, also have an issue with listing resources in container user has no rights to see
15:58:23 <acoburn> PROPOSAL: to accept the pull request #81 as proposed, subject to the open issues
15:58:23 <laurens> ack gibson
15:58:23 <Zakim> gibsonf, you wanted to ask, also have an issue with listing resources in container user has no rights to see
15:58:24 <gb> https://github.com/w3c/lws-protocol/pull/81 -> Pull Request 81 Introducing support for Containers in the LWS protocol (by laurensdeb)
15:58:40 <bendm> gibsonf1: I have an issue with listing resources in container user has no rights to see
15:58:59 <bendm> laurens: there is wording that it should include identifiers, but could include filtering
15:59:15 <bendm> ... that's moved to a MAY
15:59:37 <bendm> gibsonf1: can we leave the implementation-specific note out?
15:59:49 <bendm> laurens: If have no issues with that
16:00:05 <bendm> gibsonf1: and it's within spec that a container only shows the resources the user has access to?
16:00:08 <acoburn> +1 to leave out the implementation note if that brings us to consensus
16:00:11 <bendm> laurens: yes, additional is may
16:00:43 <acoburn> PROPOSAL: to accept the pull request #81 as proposed
16:00:45 <laurens> +1
16:00:46 <pchampin> +1
16:00:48 <acoburn> +1
16:00:59 <gibsonf1> +1 (assuming we can still revise definitions etc)
16:01:05 <Luke> +1
16:01:09 <bendm> +1
16:01:12 <TallTed> +1
16:01:26 <acoburn> RESOLVED: to accept the pull request #81 as proposed
16:01:27 <gb> https://github.com/w3c/lws-protocol/pull/81 -> Pull Request 81 Introducing support for Containers in the LWS protocol (by laurensdeb)
16:01:35 <ryey> +1 (generally fine; will need to carefully consider implications)
16:01:37 <bendm> acoburn: resolved!
16:01:42 <bendm> ... see you next week!
16:01:47 <acoburn> RRSAgent, make minutes
16:01:49 <RRSAgent> I have made the request to generate https://www.w3.org/2026/03/02-lws-minutes.html acoburn
16:01:55 <pchampin> RRSAgent, make minutes
16:01:56 <RRSAgent> I have made the request to generate https://www.w3.org/2026/03/02-lws-minutes.html pchampin
16:02:19 <acoburn> present+ Luke
16:02:35 <acoburn> present+ gibsonf
16:02:43 <acoburn> RRSAgent, make minutes
16:02:45 <RRSAgent> I have made the request to generate https://www.w3.org/2026/03/02-lws-minutes.html acoburn
16:03:09 <acoburn> acoburn has left #lws