15:00:31 <RRSAgent> RRSAgent has joined #lws
15:00:35 <RRSAgent> logging to https://www.w3.org/2026/02/02-lws-irc
15:00:43 <acoburn> rrsagent, make minutes
15:00:44 <RRSAgent> I have made the request to generate https://www.w3.org/2026/02/02-lws-minutes.html acoburn
15:01:20 <gibsonf1> gibsonf1 has joined #lws
15:01:26 <gibsonf1> present+
15:01:28 <AZ> AZ has joined #lws
15:02:37 <RazaN> RazaN has joined #lws
15:02:43 <TallTed> RRSAgent, make logs public
15:02:46 <pchampin> RRSAgent, make logs public
15:02:51 <AZ> present+
15:03:09 <pchampin> meeting: Linked Web Storage Working Group
15:03:30 <uvdsl> uvdsl has joined #lws
15:03:33 <Luke> Luke has joined #lws
15:03:49 <laurens> chair: laurens
15:04:07 <uvdsl> present+
15:04:44 <acoburn> rrsagent, make minutes
15:04:45 <RRSAgent> I have made the request to generate https://www.w3.org/2026/02/02-lws-minutes.html acoburn
15:04:51 <RazaN> present+
15:04:59 <gibsonf1> scribe+
15:05:02 <laurens> scribe: gibsonf1
15:05:11 <acoburn> present+
15:05:20 <acoburn> present+ laurens
15:05:27 <acoburn> present+ pchampin
15:05:33 <ryey> ryey has joined #lws
15:05:42 <gibsonf1> laurens: Introductions and Announcements
15:05:45 <ryey> present+
15:05:56 <bendm> bendm has joined #lws
15:06:19 <bendm> present+
15:06:21 <gibsonf1> ...Issue Triage
15:07:09 <gibsonf1> ...Agent Identification #57 - how to proceed?
15:07:09 <gb> https://github.com/w3c/lws-protocol/issues/57 -> Issue 57 Agent Identification (by uvdsl)
15:07:14 <laurens> https://github.com/w3c/lws-protocol/issues/57
15:07:15 <gb> https://github.com/w3c/lws-protocol/issues/57 -> Issue 57 Agent Identification (by uvdsl)
15:07:29 <uvdsl> q+
15:07:37 <laurens> ack uvdsl
15:07:52 <jeswr> jeswr has joined #lws
15:07:56 <jeswr> present+
15:08:00 <gibsonf1> uvdsl:  Stated a proposal in the issue itself, not sure how process works
15:08:35 <gibsonf1> laurens:  added needs-discussion so can discuss later
15:08:55 <gibsonf1> acoburn: If this is a work-item, how does it fit in?  what needs to be dropped?
15:09:15 <gibsonf1> laurens: https://github.com/w3c/lws-protocol/issues/64
15:09:15 <gb> https://github.com/w3c/lws-protocol/issues/64 -> Issue 64 Controller discovery should be in the document, not Link headers (by melvincarvalho)
15:09:43 <gibsonf1> acoburn: Not sure I agree - maybe just add needs-discussion
15:09:54 <gibsonf1> laurens: https://github.com/w3c/lws-protocol/issues/65
15:09:55 <gb> https://github.com/w3c/lws-protocol/issues/65 -> Issue 65 Container Requirements Problem (by gibsonf1)
15:10:08 <gibsonf1> ...probably need-discussion as well
15:10:25 <gibsonf1> ...https://github.com/w3c/lws-protocol/issues/67
15:10:26 <gb> https://github.com/w3c/lws-protocol/issues/67 -> Issue 67 Generalized notion of auxiliary resources (by damooo)
15:10:51 <gibsonf1> acoburn:  was discussed in some degree - but maybe needs-discussion to clarify
15:11:02 <gibsonf1> laurens: https://github.com/w3c/lws-protocol/issues/68
15:11:03 <gb> https://github.com/w3c/lws-protocol/issues/68 -> Issue 68 Ability to have general metadata (by damooo)
15:11:17 <gibsonf1> ...maybe needs discussion, potential duplciate?
15:11:29 <gibsonf1> acoburn:  leave duplicate off and can clarify issue later
15:11:46 <gibsonf1> laurens: https://github.com/w3c/lws-protocol/issues/24
15:11:46 <gb> https://github.com/w3c/lws-protocol/issues/24 -> Issue 24 Reasons for separate rest bindings (by jeswr)
15:12:03 <gibsonf1> ...unsure whether ready to close?  Christoph?
15:12:06 <uvdsl> q+
15:12:31 <gibsonf1> jeswr:  Was in the poll
15:12:33 <uvdsl> q-
15:12:42 <gibsonf1> laurens: Anyone willing to take on issue?
15:13:10 <gibsonf1> acoburn:  Summary: there are pros and cons and basically an editorial decision - would be my take
15:13:12 <uvdsl> q+
15:13:33 <laurens> ack uvdsl
15:13:34 <gibsonf1> ...Couple items have proposed close - not sure additional
15:14:00 <gibsonf1> uvdsl: Aaron - like your approach and would like to document outcome of discussion
15:14:22 <gibsonf1> laurens: https://github.com/w3c/lws-protocol/issues/18
15:14:23 <gb> https://github.com/w3c/lws-protocol/issues/18 -> Issue 18 Prior Art Collection (by jeswr) [propose-close]
15:14:33 <bendm> +1 for close
15:14:48 <gibsonf1> +1 for close
15:15:00 <gibsonf1> ... propose close
15:15:16 <gibsonf1> ...https://github.com/w3c/lws-protocol/issues/38
15:15:17 <gb> https://github.com/w3c/lws-protocol/issues/38 -> Issue 38 Consider draft-parecki-oauth-client-id-metadata-document for input (by jeswr) [propose-close]
15:15:31 <gibsonf1> ...propose close?  ok, closed
15:15:57 <acoburn> rrsagent, make minutes
15:15:58 <RRSAgent> I have made the request to generate https://www.w3.org/2026/02/02-lws-minutes.html acoburn
15:16:05 <elf-pavlik> elf-pavlik has joined #lws
15:16:08 <gibsonf1> ...please look at need-discussion items for next week
15:16:14 <laurens> https://docs.google.com/document/d/1vY-tlbM96Vuf0_SVH1Xy1NzCaZ_MnlOOm-lvr1EHgt8/edit?usp=sharing
15:16:24 <gibsonf1> ...next up Container discussion
15:16:25 <acoburn> zakim, open agendum 3
15:16:25 <Zakim> agendum 3 -- Discussion: Containers -- taken up [from agendabot]
15:17:41 <gibsonf1> ...Removing resources from containers - how to approach semantics?
15:17:56 <acoburn> q+ to ask about removing resources and relationship to multiple containment
15:18:20 <gibsonf1> ...what happens when resource removes from last container, do we delete?  move? retain container? etc.
15:19:00 <gibsonf1> ...Looking at Solid, this issue pops up less.
15:19:05 <laurens> ack acoburn
15:19:05 <Zakim> acoburn, you wanted to ask about removing resources and relationship to multiple containment
15:19:17 <gibsonf1> q+ on multiple containment
15:19:54 <uvdsl> q+ on the "action": removing a resource or removing a containment relation
15:20:07 <gibsonf1> aaron:  worried when more than one way to do things.  Best to have one way.  If server does not support multiple containment, it just doesnt respond?
15:20:29 <gibsonf1> laurens:  If you can remove one, can you remove all, would that be illegal operation?
15:20:48 <gibsonf1> acoburn: Maybe have dedicated section on multiple containment?
15:21:26 <TallTed> "multiple containment" akin to "hard links" in Unix-like world? vs "aliases" or soft links?
15:21:42 <TallTed> q+
15:22:00 <gibsonf1> laurens: Second convenience enables by update link relations, to move resources between containers.
15:22:25 <laurens> ack gibsonf
15:22:25 <Zakim> gibsonf, you wanted to comment on multiple containment
15:22:30 <laurens> scribe+
15:22:48 <laurens> gibsonf: What is the argument for multiple containment? Are there any implementers interested?
15:23:00 <laurens> ... I agree it should be easy to move resources between containers.
15:23:03 <laurens> scribe-
15:23:53 <gibsonf1> laurens: Multiple containment came from F2F meeting.  Its starting to look pretty complicated to implement, but semantic complexity etc.
15:24:01 <acoburn> q+ to suggest indicating multiple containment as "at risk"
15:24:07 <laurens> ack uvdsl
15:24:07 <Zakim> uvdsl, you wanted to comment on the "action": removing a resource or removing a containment relation
15:24:44 <gibsonf1> uvdsl:  Maybe differentiating between location of resource in container vs deleting resource
15:24:46 <laurens> ack TallTed
15:28:17 <gibsonf1> tallted: Managing containment is left to the server in LDP and Solid and think it should stay that way.  What does containment mean?  Thats a challenge.  Intention: Unix like storage in web-friendly way.  Soft links, aliases, hard links multiple containment.  Soft links can use redirects, hard-links it actually exists in multiple places.  Master
15:28:17 <gibsonf1> resource gets the change no matter hard or soft link. Implementation left up in air - we talk about output, not how the input gets to the output - we shouldn't specify implementation.
15:28:29 <laurens> ack acoburn
15:28:29 <Zakim> acoburn, you wanted to suggest indicating multiple containment as "at risk"
15:28:33 <gibsonf1> laurens:  I think its mainly operational but see your point
15:29:21 <gibsonf1> acoburn: I suspect we won't have as much agreement with multiple-containment as other areas so think maybe to mark at-risk.  Lets focus on where majority agree
15:30:26 <uvdsl> q+
15:30:33 <bendm> q+ to ask about bulk operations
15:30:38 <gibsonf1> laurens:  Maybe splitting into to PRs to cover multiple-containment.   Lastly deleting containers, operational semantics, should cascading/recursive deletes be supported?  The wording needs more detail.
15:30:42 <laurens> ack uvdsl
15:31:29 <gibsonf1> uvdsl: We should point out that operation should be atomic.  Without permission, whole operation should not be executed.
15:31:57 <gibsonf1> laurens:  Haven't covered authorization on container delete yet
15:32:07 <gibsonf1> acoburn: authorization spec assumes things are atomic
15:32:17 <laurens> ack bendm
15:32:17 <Zakim> bendm, you wanted to ask about bulk operations
15:33:07 <gibsonf1> bendm: Bulk operations - delete multiple in one atomic in multiple containers, moving things, etc.  Is that in scope?
15:34:00 <gibsonf1> laurens:  Has not come up yet, but if use cases cover that we could support that - but brings in some complications.  Unsure we can easily support this.
15:34:08 <TallTed> atomicity suggests ACID, all of which is desirable, but difficult to deliver, particularly at scale
15:34:37 <gibsonf1> bendm:  I bring it up since we are talking recursion in a single container might be same spec/complexity
15:34:57 <gibsonf1> q+ on bulk
15:35:09 <laurens> ack gibsonf
15:35:09 <Zakim> gibsonf, you wanted to comment on bulk
15:35:45 <laurens> gibsonf1: It could be simple to do, if you're request is about a resource URI, you could list a bunch of resources and specify what operations to perform.
15:36:41 <gibsonf1> laurens: Depends on what a resource is.  Don't see how that would work if resource is natively in a storage.
15:37:19 <TallTed> "prepare deletion" is when the services check permissions, etc. This can be parallelized.
15:37:20 <TallTed> "execute deletion" is when they get deleted, all at once, as an atomic action -- all succeed or none do.
15:39:09 <acoburn> q+ to mention prior art with webdav
15:39:12 <gibsonf1> laurens:  Right now as the draft sits, assumption that there is a resource with a URI path within the storage.  Resource URI is just a URI in the storage.  I'm not sure how you would move URI outside of that storage, not sure how.
15:39:16 <laurens> ack acoburn
15:39:16 <Zakim> acoburn, you wanted to mention prior art with webdav
15:39:35 <gibsonf1> laurens: that makes sense if its all in the same storage
15:40:01 <bendm> oeh I love that idea
15:40:04 <gibsonf1> acoburn: We should look at prior-art with webdav - maybe we don't have to define it ourselves
15:40:12 <gibsonf1> laurens: agree with that suggestion
15:40:30 <acoburn> q+
15:40:35 <gibsonf1> ...moving on to Container Media Type
15:40:36 <laurens> ack acoburn
15:42:47 <uvdsl> https://github.com/w3c/lws-protocol/issues/61
15:42:48 <gb> https://github.com/w3c/lws-protocol/issues/61 -> Issue 61 LWS Container Media Type (by acoburn) [needs-discussion]
15:42:54 <gibsonf1> acoburn: Brought this up at json-ld meeting last week (to get good advice).  If we do json-ld profile, run into CORs issues, maybe say its equivalent applicion/lws  or application/lws-json .   CORs is a key issue.  Advice to use application/lws+json (no profile)  or (I'll pull up the document)
15:43:14 <acoburn> As with Web Annotations
15:43:14 <acoburn> Content-Type: application/ld+json; profile="https://www.w3.org/ns/lws/v1"
15:43:14 <acoburn> As with Activity Streams
15:43:14 <acoburn> Content-Type: application/ld+json; profile="https://www.w3.org/ns/lws/v1"
15:43:15 <acoburn> -OR-
15:43:16 <acoburn> Content-Type: application/lws+json
15:43:18 <acoburn> As with CID / VC
15:43:20 <acoburn> Content-Type: application/lws
15:44:31 <uvdsl> q+ to suggest alternatives outlined in https://github.com/w3c/lws-protocol/issues/61#issuecomment-3813015541
15:44:43 <acoburn> q+
15:44:49 <laurens> ack uvdsl
15:44:49 <Zakim> uvdsl, you wanted to suggest alternatives outlined in https://github.com/w3c/lws-protocol/issues/61#issuecomment-3813015541
15:44:50 <gibsonf1> laurens:  I'm concerned with application/lws interfering with other defined types
15:45:12 <laurens> s/with other defined types/with existing JSON based clients in frameworks./
15:45:47 <gibsonf1> uvdsl: an additional alternative: Server defines resources - depending on what client requests, response will be what it is per spec.  Content-type headers adapted to request
15:46:18 <gibsonf1> laurens:  I don't think spec prohibits that.  Do we want that required?  Not strong opinion
15:46:34 <gibsonf1> uvdsl:  Proposal not to invent the wheel again - when general solution works fine.
15:46:38 <laurens> ack acoburn
15:48:31 <gibsonf1> acoburn: I agree with uvdsl, other specs clarify in definition how to use general solution.  Forgot to mention , one advantage with application/lws - allows us to define a file extension.  Gives potential leeway into downloading containers etc might work.
15:49:55 <gibsonf1> laurens: Json-ld context and framing.  Context warrants separate discussion, do we want single context for most things or do we want to split it out, versioning, etc.  Need separate agenda time to discuss
15:50:17 <acoburn> q+ to talk about json-ld / vocabulary
15:50:23 <laurens> ack acoburn
15:50:23 <Zakim> acoburn, you wanted to talk about json-ld / vocabulary
15:50:56 <gibsonf1> acoburn:  Would leave it as now as normative, can create canonical discussion later.
15:51:04 <gibsonf1> q+ on example json-ld
15:51:23 <acoburn> s/as normative/as informative
15:51:35 <gibsonf1> laurens: normative json-ld frame.
15:51:53 <gibsonf1> acoburn: I didn't define anything in the spec yet.  As we clarify we can define in one go.
15:51:56 <laurens> ack gibsonf1
15:52:05 <laurens> scribe+
15:52:46 <laurens> gibsonf1: The example JSON-LD context refers to paging here. It should be discussed separately.
15:53:46 <acoburn> q+ to talk about requirements and scope for paging
15:54:11 <TallTed> see: scrollable cursors, in DBMS world
15:54:30 <laurens> gibsonf1: The concept of a page is problematic here.
15:54:41 <laurens> ... Industry standard is to have a start and offset.
15:54:48 <TallTed> the cursor window varies (number of records, number of fields per record, etc.)
15:54:58 <laurens> ... The server shouldn't know about the pages.
15:55:00 <gibsonf1> laurens: Might make sense to go back to paging discussion.  I think you want to see this go with query string?
15:55:46 <TallTed> where the window falls (offset) also varies
15:55:47 <laurens> ack acoburn
15:55:47 <Zakim> acoburn, you wanted to talk about requirements and scope for paging
15:55:54 <pchampin> +1 that the current proposal does not prevent gibsonf1's proposal
15:56:14 <laurens> scribe-
15:56:17 <pchampin> -1 to the claim that this is what everyone™ is doing
15:56:54 <TallTed> also, again, remember that HTTP paging is byte based,
15:57:02 <laurens> q?
15:57:03 <gibsonf1> acoburn: I think we should talke about this next week and work out the details
15:57:09 <laurens> ack gibsonf
15:57:09 <Zakim> gibsonf, you wanted to comment on example json-ld
15:57:18 <gibsonf1> laurens:  Yes, lets discuss paging next week
15:58:00 <uvdsl> Quick question, is there already some information about the next face-to-face meeting?
15:58:03 <gibsonf1> ...also look into webdav has done and can use it in this proposal
15:58:21 <TallTed> LWS > Solid > LDP > WebDAV > basicHTTP
15:58:25 <gibsonf1> ...there is some information on f2f, Jesse?
15:58:46 <uvdsl> alright, I'll stay tuned :)
15:58:56 <gibsonf1> jesswr: April 29th?
15:59:02 <acoburn> rrsagent, make minutes
15:59:03 <RRSAgent> I have made the request to generate https://www.w3.org/2026/02/02-lws-minutes.html acoburn