14:53:08 <RRSAgent> RRSAgent has joined #lws
14:53:12 <RRSAgent> logging to https://www.w3.org/2025/11/03-lws-irc
14:53:12 <Zakim> Zakim has joined #lws
14:53:15 <TallTed> meeting: Linked Web Storage WG
14:53:19 <RazaN> RazaN has joined #lws
14:53:38 <TallTed> TallTed has changed the topic to: Linked Web Storage - agenda 2025-11-03: https://www.w3.org/events/meetings/a19ab7dc-1753-433d-bac5-64e3ad8c0a43/20251103T100000/
14:53:45 <TallTed> agenda: https://www.w3.org/events/meetings/a19ab7dc-1753-433d-bac5-64e3ad8c0a43/20251103T100000/
14:53:45 <agendabot> clear agenda
14:53:45 <agendabot> agenda+ Introductions & announcements
14:53:45 <agendabot> agenda+ Server-managed vs user-managed metadata
14:53:45 <agendabot> agenda+ Metadata format(s)
14:53:45 <agendabot> agenda+ HTTP management of metadata
14:54:02 <RRSAgent> I have made the request to generate https://www.w3.org/2025/11/03-lws-minutes.html TallTed
14:54:38 <TallTed> previous meeting: https://www.w3.org/2025/10/27-lws-minutes.html
14:54:38 <TallTed> next meeting: https://www.w3.org/2025/11/10-lws-minutes.html
14:55:23 <TallTed> present+
14:55:37 <RRSAgent> I have made the request to generate https://www.w3.org/2025/11/03-lws-minutes.html TallTed
14:56:15 <TallTed> RRSAgent, make logs public
14:58:19 <ericP> present+
14:58:54 <jeswr> jeswr has joined #lws
14:58:59 <jeswr> present+
14:59:37 <eBremer> eBremer has joined #lws
15:00:02 <acoburn> present+
15:00:51 <RazaN2> RazaN2 has joined #lws
15:01:23 <RazaN2> RazaN2 has left #lws
15:01:32 <acoburn> Scribe list https://github.com/w3c/lws-protocol/wiki/Scribe-list
15:01:51 <ericP> chair: ericP
15:01:53 <eBremer> present+
15:02:05 <RRSAgent> I have made the request to generate https://www.w3.org/2025/11/03-lws-minutes.html TallTed
15:02:11 <RazaN> RazaN has joined #lws
15:02:18 <RazaN> present+
15:03:42 <acoburn> chair: acoburn
15:03:52 <ericP> scribe: ericP
15:03:55 <acoburn> RRSAgent, draft minutes
15:03:56 <RRSAgent> I have made the request to generate https://www.w3.org/2025/11/03-lws-minutes.html acoburn
15:04:21 <ryey> ryey has joined #lws
15:04:40 <acoburn> zakim, open agendum 1
15:04:40 <Zakim> agendum 1 -- Introductions & announcements -- taken up [from agendabot]
15:05:20 <ericP> acoburn: today will be part II of the metadata conversation
15:06:03 <ericP> ... goal: establish consensus so we can start drafting text (which will neccessitate more consensus)
15:06:45 <acoburn> zakim, open agendum 2
15:06:45 <Zakim> agendum 2 -- Server-managed vs user-managed metadata -- taken up [from agendabot]
15:06:51 <ryey> present+
15:07:25 <ericP> acoburn: we're continuing from last week's metadata conversation
15:08:21 <ericP> ... we have user-managed stuff we wlll need to accomodate in specs
15:08:55 <ericP> ... the "extensions" section is stuff we won't intend to specify
15:09:14 <RRSAgent> I have made the request to generate https://www.w3.org/2025/11/03-lws-minutes.html TallTed
15:09:27 <ericP> RazaN: why is "data integrity" out of scope?
15:10:17 <ericP> acoburn: the stuff we're specifying supports data integrity but we're not specifying it directly
15:11:22 <ericP> s/RazaN: why is "data integrity" out of scope?/benG: why is "data integrity" out of scope?/
15:11:31 <bengo> bengo has joined #lws
15:11:46 <ericP> s/benG/bengo/
15:12:26 <ericP> acoburn: we have these user-managed and server-managed types...
15:12:42 <ericP> ... we can partition this list into those groups
15:12:57 <ericP> ... or we can let impls decide
15:12:57 <TallTed> q+
15:13:04 <acoburn> ack next
15:13:42 <ericP> TallTed: i see mod time in server-managed
15:14:22 <ericP> ... also think the "user-manmaged types" should go away
15:15:09 <bengo> if the user signs over a timestamp (and they should), the server can't change it
15:15:23 <ericP> ... user has no control over e.g. created time. managed by the server
15:16:13 <bengo> We should perhaps distinguish between wall 'clock time' and causal/relative 'tick time'
15:16:17 <ericP> ... for the most part, the server is managing while the user is requesting
15:16:38 <ericP> acoburn: how about "Last-modified" is server-managed
15:16:47 <ryey> q+ on relation between customized metadata and server-managed metadata
15:16:55 <acoburn> ack next
15:16:56 <Zakim> ryey, you wanted to comment on relation between customized metadata and server-managed metadata
15:17:00 <ericP> s/how about "Last-modified" is server-managed/how about "Last-modified" is server-managed?/
15:17:10 <ericP> ryey: i agree
15:17:43 <ericP> ... re relation between user- and server-managed metadata, is it allowed for the user-managed to include some same predicates?
15:17:53 <ericP> ... if so, overrides? extends?
15:17:56 <bengo> In POSIX the modified time is managed by the user, not the kernel (iiuc) so this would be pretty different.
15:18:23 <ericP> acoburn: i was imagin we have two link rels, one each for server- and user-managed metadata
15:19:46 <ericP> ... if the user want's to e.g. define a container as something else, it will be clear which came from the server
15:20:26 <ericP> bengo: this implies that the "one" server (potentially zillions of machines) agree on time
15:20:48 <ericP> acoburn: one option for mod-time is to simply leave it up to HTTP
15:21:07 <bengo> +1
15:21:31 <bengo> q+ to mention the thing on modfied time frequently being user-modifiable not only system-decided
15:21:57 <ericP> [acoburn strikes out ModificationTime item]
15:22:40 <ericP> TallTed: just as HTTP handles mod-time, it also handles media-type
15:24:10 <bengo> q- dont need to belabor modified time dicsussion
15:24:12 <ericP> acoburn: i think these are different types. there's a Content-type header with a media type value, and there's a Link with rel="type"
15:24:13 <bengo> q-
15:24:44 <bengo> q+ what does it mean to be 'server managed'? Does that just mean it's persisting the type a client tells it?
15:25:04 <bengo> q+ to ask what it means for content-type to be 'server managed' if the client sets it in requests
15:25:46 <bengo> 'managed' is often ambiguous. is there a better word?
15:25:53 <dmitriz> dmitriz has joined #lws
15:25:56 <ericP> TallTed: the user sets the media-type but the server manages it
15:26:27 <acoburn> ack next
15:26:28 <Zakim> bengo, you wanted to ask what it means for content-type to be 'server managed' if the client sets it in requests
15:27:17 <ericP> eBremer: [example of zip called a jpeg]
15:27:44 <ericP> q+
15:28:00 <ericP> bengo: why would we call this server managed if the user is the locus of authority
15:28:22 <dmitriz> +1, agree with @bengo
15:28:22 <gb> https://github.com/bengo -> @bengo
15:28:51 <acoburn> ack next
15:29:13 <dmitriz> q+
15:29:22 <acoburn> q+ to describe meaning of server managed
15:30:08 <ericP> ericP: if our litmus for user-managed is what can the server change, we would have no user-managed because the server can always changes stuff
15:31:39 <ericP> bengo: if the media type includes the media type, the server changing it would break the media type
15:31:59 <acoburn> ack next
15:32:59 <ericP> dmitriz: this argument seems odd, if we s/server/filesystem/, we'd not ask whether the filesystem would change content type
15:33:04 <acoburn> ack next
15:33:05 <Zakim> acoburn, you wanted to describe meaning of server managed
15:33:06 <bengo> server provides the property of durability etc, but it is confusing to say it 'manages' it without more precise language
15:34:03 <ericP> acoburn: "server-managed" is probably the wrong term. i think it came from Fedora. I was tying to get at the notion of "server-managed" the idea of data that the server should reproduce without changing
15:34:10 <dmitriz> @acoburn - yes, I believe so. there's some metadata that is specifically set by the storage server, that user cannot directly alter
15:34:10 <gb> https://github.com/acoburn -> @acoburn
15:34:39 <ericP> ... a client can PUT with a new media type
15:35:26 <ericP> ... if you replace a five-byte file with a ten-byte file, that was managed by the client
15:35:54 <TallTed> q+
15:36:08 <acoburn> ack next
15:36:12 <ericP> ... if i have an ACL at /1 and a client wants to move it to /2, should it be allowed?
15:36:33 <dmitriz> in terms of server-managed, the server records (and the client cannot change _directly_):
15:36:38 <dmitriz> in terms of server-managed, the server records (and the client cannot change _directly_):
15:36:46 <ericP> TallTed: we're rehashing an argument that's been going on since the dawn of time
15:37:31 <ericP> ... LDP forbids the client from overwriting metadata
15:37:49 <bengo> are we obliged to obey LDP? no right?
15:37:55 <bengo> esp wrt 'the server is in charge'
15:38:02 <ericP> ... even with a PUT, the server is in control. at least in theory it can't change the content, but that's debatable
15:38:07 <dmitriz> @TallTed - I think there's a difference between 'persits' and 'manages'
15:38:07 <gb> https://github.com/TallTed -> @TallTed
15:38:40 <acoburn> bengo: no we are not depending on LDP (at least Solid does not require it today)
15:39:13 <ericP> ... if the resource is RDFa, the server must understand the RDFA stuck in any version of HTML
15:39:44 <bengo> the server never has to edit a file, it only has to maintain an operational history of changes
15:40:04 <ericP> ... so if you're trying to change the relations in RDFA, the server has to understand it
15:40:06 <dmitriz> no, we are not inheriting LDP
15:40:25 <bengo> q+
15:40:32 <bengo> q-
15:41:02 <ericP> ... if we're going to rehash these arguements, the WG won't finish
15:41:57 <ericP> acoburn: let's skip over this user-/server-managed metadata issue by simply saying there's a set of data that a server is responsible for persisting [for the user]
15:42:39 <ericP> acoburn: Solid curerntly has a described-by link header (used in but not specific to LDP)
15:43:17 <ericP> ... there's not specification of what the described-by data is, what format it's in, what authority it has...
15:43:30 <bengo> with wallet.storage we have also been using application/linkset (RFC 6924)
15:43:43 <ericP> ... eBremer has been working on linksets
15:44:16 <ericP> ... once you have a linkset resource, you can update it without changing the file it describes
15:44:45 <eBremer> @bengo isnt linkset rfc9264?
15:44:45 <gb> https://github.com/bengo -> @bengo
15:44:55 <bengo> eBremer oy yes, sry typo. thanks
15:45:19 <ericP> eBremer: HTTP link headers are nice but can result in header bloat
15:45:39 <ericP> ... linksets avoid this bloat
15:46:06 <bengo> +1 to all this. it has worked really well. using linkset+json
15:46:17 <ericP> ... you can also consider it JSON-LD
15:46:43 <bengo> q+
15:46:49 <acoburn> ack next
15:47:00 <ericP> acoburn: specifically, the link header turns into link headers
15:47:15 <ericP> bengo: i've been using this for a few months and it's been working well
15:47:35 <ericP> ... some folks get upset when you stick "@context" in JSON
15:47:35 <gb> https://github.com/context -> @context
15:48:19 <ericP> ... one link header use case is adding contexts without shoving it in peoples' faces
15:48:50 <ericP> acoburn: it's a lot easier to write a client to parse/update this JSON rather than any type of serialization
15:50:07 <bengo> Also wroth noting that ActivityStreams2 defines RDF for 'Link' and 'Collection' which is kinda like a LinkSet
15:50:11 <ericP> ... we have options for how to divy user and server data can be managed by saying that all data has to be in Link headers, which is very constraining
15:50:30 <dmitriz> q+
15:50:35 <acoburn> ack next
15:50:44 <bengo> q+ to share about how dmitri and i got to this
15:50:51 <ericP> q+
15:50:53 <acoburn> ack next
15:50:54 <Zakim> bengo, you wanted to share about how dmitri and i got to this
15:51:04 <ericP> ... do we want to say that that there are explicit user-managed metadata resources?
15:51:22 <ericP> dmitriz: we can start with just the linkset?
15:52:03 <ericP> bengo: we might want more types of metadata resources
15:52:31 <bengo> if you have linksets, you dont necessarily need 'metadata resources' because any resourced linked to can be thought of as 'metadata resource'. it's just a linked resource.
15:52:32 <ericP> ... so we'd want to use linksets to give us that flexibility
15:53:01 <bengo> https://www.rfc-editor.org/rfc/rfc9264.html
15:53:24 <acoburn> PROPOSAL: LWS will make use of linksets [RFC 9264] to describe metadata resources
15:53:36 <ericP> +1
15:53:40 <dmitriz> +1
15:53:51 <bengo> +1
15:54:38 <acoburn> +1
15:54:47 <ericP> TallTed: does this mean everyone has to user linksets?
15:54:49 <TallTed> -0.5
15:54:57 <ericP> acoburn: that would be a minimal requirement
15:55:05 <TallTed> s/user linksets/use linksets/
15:55:09 <eBremer> +1
15:55:41 <RazaN> +1
15:55:57 <ericP> acoburn: is there some change to this proposal that would change your -.5?
15:56:13 <ryey> +0
15:56:24 <ericP> TallTed: i don't think we've implemented it. will need to see how difficult it is to implement
15:56:42 <ericP> acoburn: i see general support, we'll revisit this later
15:56:45 <RRSAgent> I have made the request to generate https://www.w3.org/2025/11/03-lws-minutes.html TallTed
15:56:51 <ryey> ryey has joined #lws
15:57:04 <ryey> +0.5
15:57:39 <ericP> ... next week, i want to move on the storage metadata, and contrast that against the metadata for a specific data resource
15:58:03 <ericP> RRSAgent, draft minutes
15:58:04 <RRSAgent> I have made the request to generate https://www.w3.org/2025/11/03-lws-minutes.html ericP
16:33:43 <TallTed> Zakim, end meeting
16:33:43 <Zakim> As of this point the attendees have been TallTed, ericP, jeswr, acoburn, eBremer, RazaN, ryey
16:33:45 <Zakim> RRSAgent, please draft minutes
16:33:47 <RRSAgent> I have made the request to generate https://www.w3.org/2025/11/03-lws-minutes.html Zakim
16:33:52 <Zakim> I am happy to have been of service, TallTed; please remember to excuse RRSAgent.  Goodbye
16:33:53 <Zakim> Zakim has left #lws
16:33:56 <TallTed> RRSAgent, bye
16:33:56 <RRSAgent> I see no action items