14:36:23 <RRSAgent> RRSAgent has joined #lws
14:36:27 <RRSAgent> logging to https://www.w3.org/2025/11/17-lws-irc
14:36:27 <Zakim> Zakim has joined #lws
14:36:49 <TallTed> meeting: Linked Web Storage WG
14:36:49 <TallTed> agenda: https://www.w3.org/events/meetings/a19ab7dc-1753-433d-bac5-64e3ad8c0a43/20251117T100000/
14:36:49 <TallTed> rrsagent, draft minutes
14:36:51 <RRSAgent> I have made the request to generate https://www.w3.org/2025/11/17-lws-minutes.html TallTed
14:36:53 <TallTed> rrsagent, make logs public
14:36:54 <TallTed> present+
14:36:54 <agendabot> clear agenda
14:36:54 <agendabot> agenda+ Introductions and announcements
14:36:54 <agendabot> agenda+ Authentication proposal
14:36:54 <agendabot> agenda+ Containment discussion
14:37:20 <TallTed> previous meeting: https://www.w3.org/2025/11/10-lws-minutes.html
14:37:20 <TallTed> next meeting: https://www.w3.org/2025/11/24-lws-minutes.html
14:37:40 <RRSAgent> I have made the request to generate https://www.w3.org/2025/11/17-lws-minutes.html TallTed
14:50:59 <acoburn> acoburn has joined #lws
14:52:55 <acoburn> zakim, start meeting
14:52:55 <Zakim> RRSAgent, make logs Public
14:52:57 <Zakim> please title this meeting ("meeting: ..."), acoburn
14:53:04 <acoburn> meeting: Linked Web Storage
14:53:28 <acoburn> agenda: https://www.w3.org/events/meetings/a19ab7dc-1753-433d-bac5-64e3ad8c0a43/20251117T100000/#agenda
14:53:28 <agendabot> clear agenda
14:53:28 <agendabot> agenda+ Introductions and announcements
14:53:28 <agendabot> agenda+ Authentication proposal
14:53:28 <agendabot> agenda+ Containment discussion
14:53:44 <acoburn> rrsagent, make minutes
14:53:46 <RRSAgent> I have made the request to generate https://www.w3.org/2025/11/17-lws-minutes.html acoburn
14:55:06 <acoburn> scribenick: acoburn
14:55:24 <TallTed> present+ acoburn
14:55:36 <RRSAgent> I have made the request to generate https://www.w3.org/2025/11/17-lws-minutes.html TallTed
14:57:34 <eBremer> eBremer has joined #lws
14:58:21 <acoburn> zakim, open agendum 1
14:58:21 <Zakim> agendum 1 -- Introductions and announcements -- taken up [from agendabot]
15:00:36 <laurens> laurens has joined #lws
15:00:43 <laurens> present+
15:01:19 <eBremer> present+
15:01:39 <jeswr> jeswr has joined #lws
15:01:43 <jeswr> present+
15:01:54 <gibsonf14> gibsonf14 has joined #lws
15:02:24 <gibsonf1> gibsonf1 has joined #lws
15:02:30 <gibsonf1> present+
15:04:03 <ericP> ericP has joined #lws
15:04:12 <TallTed> chair: ericP
15:04:12 <acoburn> chair: ericP
15:04:16 <ericP> present+
15:04:22 <pchampin> present+
15:04:23 <ericP> agenda?
15:04:33 <ericP> next agendum
15:04:43 <acoburn> zakim, open agendum 1
15:04:43 <Zakim> agendum 1 -- Introductions and announcements -- taken up [from agendabot]
15:05:57 <gibsonf1> scribe+
15:06:15 <acoburn> pchampin: just back from TPAC. Nothing specifically related to LWS
15:06:40 <acoburn> ... a lot related to VC and DID, sorry, nothing off the top of my head about LWS
15:06:51 <acoburn> ... will sort notes and report back next week
15:07:08 <ericP> next agendum
15:07:16 <acoburn> zakim, open agendum 2
15:07:16 <Zakim> agendum 2 -- Authentication proposal -- taken up [from agendabot]
15:07:30 <ericP> scribe+
15:07:37 <acoburn> -> https://github.com/w3c/lws-protocol/pull/43 Authentication proposal
15:07:38 <gb> https://github.com/w3c/lws-protocol/pull/43 -> Pull Request 43 LWS Authentication (by acoburn)
15:08:06 <ericP> acoburn: at Gent F2F, we discussed aaa at a high level
15:08:22 <ericP> ... last week, jeswr and I met to realize this vision
15:08:34 <ericP> ... should have a PR for this today or tomorrow
15:08:58 <ericP> ... will require more attention but wanted it in front of people ASAP
15:08:59 <RRSAgent> I have made the request to generate https://www.w3.org/2025/11/17-lws-minutes.html TallTed
15:09:16 <ericP> ... please considier how it fits with authz
15:09:43 <ericP> ericP: you plan to write an authz draft as well so we can see them together?
15:10:04 <ericP> acoburn: yes, jeswr and i worked on both. will have authz in separate PR
15:10:31 <ericP> scribe-
15:10:38 <ericP> next agendum
15:10:38 <acoburn> zakim, open agendum 3
15:10:40 <Zakim> agendum 3 -- Containment discussion -- taken up [from agendabot]
15:10:59 <AZ> AZ has joined #lws
15:11:08 <AZ> present+
15:11:15 <acoburn> jeswr: (shares screen)
15:11:26 <TallTed> s/Gent/Ghent/
15:11:39 <acoburn> ... topics raised in Ghent related to containment
15:12:03 <acoburn> ... data in containers, semantics of data, container media type, paging for large containers
15:12:06 <jeswr> Data in containers
15:12:06 <jeswr> Is it server managed?
15:12:06 <jeswr> 	Can clients add data? or does client data go into metadata resources?
15:12:06 <jeswr> Semantics of data
15:12:07 <jeswr> Do we use LDP semantics?
15:12:07 <jeswr> 	What vocabularies? What terms do we define ourselves?
15:12:07 <jeswr> Container media type
15:12:08 <jeswr> 	RDF: JSON-LD and/or Turtle
15:12:08 <jeswr> Is Conneg required?
15:12:08 <jeswr> 	defined JSON-LD frame / JSON schema
15:12:09 <jeswr> 	to look up: can the response point to a json schema resource? (in json, link or well-known)
15:12:09 <jeswr> Paging for large containers
15:12:09 <jeswr> 	Mechanics
15:13:02 <jeswr> https://docs.google.com/document/d/1tHLQ2sylpP_J8JMlee4q3g-bx487qcgZ7Lbx6zIAzes/edit?usp=sharing
15:13:08 <bengo> bengo has joined #lws
15:13:23 <acoburn> -> https://docs.google.com/document/d/1tHLQ2sylpP_J8JMlee4q3g-bx487qcgZ7Lbx6zIAzes/edit?usp=sharing container discussion
15:13:59 <acoburn> jeswr: strawman proposal offers a JSON-LD container
15:14:07 <acoburn> ... in a particular frame
15:14:26 <acoburn> ... we would specify a schema for that frame, which would allow clients could treat that as pure json
15:14:51 <pchampin> q+ to ask about media-type for containers
15:14:52 <acoburn> ... we would also define an LWS context so that the object could be interpreted as RDF
15:15:24 <acoburn> ... first item is to discuss whether the JSON-LD is a MUST
15:15:36 <acoburn> pchampin: +1 to this proposal
15:16:00 <bengo> +1 JSON-LD be required. Is a particular *framing* required to be supported? (imho a good idea)
15:16:02 <acoburn> ... have a question whether you are considering a particular media type or served as just json-ld
15:16:51 <acoburn> jeswr: acoburn and I had some conversations about this
15:16:53 <bengo> "application/ld+json; profile={uri}"
15:16:53 <bengo> is what activitypub does
15:17:11 <acoburn> ... inclined to offer a custom content type, such as application/lws+json
15:17:24 <pchampin> q+
15:17:32 <acoburn> bengo: I like the requirement of json/json-ld
15:17:43 <acoburn> ... is there a particular framing required
15:18:02 <acoburn> ... it would be a good idea for the server to use a particular framing
15:18:13 <ericP> ack next
15:18:14 <Zakim> pchampin, you wanted to ask about media-type for containers and to
15:18:14 <acoburn> jeswr: that is my expectation: to have  a particular frame
15:18:34 <acoburn> pchampin: I do consider two uses of JSON-LD
15:18:46 <acoburn> ... one is generalized serialization (application/ld+json is best)
15:19:03 <acoburn> ... another is defining specific formats which can be used as plain json or as RDF
15:19:10 <ericP> +1 to pchampin's discrimination of the use cases for JSON-LD
15:19:15 <acoburn> ... for the second category a definite media type is appropriate
15:19:43 <acoburn> ... as to bengo's proposal with a profile, there are some problems with that, esp with CORS
15:20:00 <acoburn> ... not such a good choice from the web annotations spec
15:20:08 <bengo> I dont understand any CORS issues. haven't had any in ActivityPub using this to my knowledge
15:20:17 <acoburn> jeswr: is that an issue with the URL length?
15:20:34 <acoburn> pchampin: it's because the profile is a URI
15:20:56 <acoburn> ... maybe we could add a keyword profile for json-ld, but I'm not sure if there is a mechanism for that
15:21:02 <bengo> AP 3.2 " The client MUST specify an Accept header with the application/ld+json; profile="https://www.w3.org/ns/activitystreams" media type in order to retrieve the activity. "
15:21:05 <bengo> (conneg)
15:21:06 <acoburn> ... another problem is content negotiation
15:21:37 <ericP> q+
15:21:42 <acoburn> ... I would be nervous if there was a different profile using the same media type
15:22:11 <acoburn> bengo: unless one is very careful, the profile could drift to pure json-ld
15:22:19 <ericP> q+ to say that no algorithms describe matching on profile. that said, maybe somebody has to go there first
15:22:21 <pchampin> bengo, Verifiable Credentials has some language that we could reuse
15:22:46 <acoburn> jeswr: I've seen issues in JS ecosystem with media type parsing
15:23:13 <acoburn> bengo: there are debates about the processing of custom media types
15:23:14 <ericP> ack next
15:23:15 <Zakim> ericP, you wanted to say that no algorithms describe matching on profile. that said, maybe somebody has to go there first
15:23:48 <acoburn> ericP: no specs that describes how profiles are handled
15:24:01 <acoburn> ... this could be a forcing function for defining profiles
15:24:38 <acoburn> jeswr: next topic: do we require content negotiation within the RS spec?
15:25:16 <acoburn> ... personal opinion is that we should not require conneg (e.g., turtle), however, we provide a discovery mechanism for servers to advertise
15:25:28 <acoburn> ... that they can transform to another format
15:25:56 <pchampin> +1 to keep conneg optional
15:25:56 <bengo> btw the definition or the profile parameter on application/ld+json is elaborated in here https://www.iana.org/assignments/media-types/application/ld+json
15:26:04 <acoburn> ... are there other opinions on the requirement for conneg?
15:26:06 <pchampin> it could also be advertised with HTTP header "Vary: accept"
15:26:24 <bengo> I would like for the servers to not be required to serialize turtle, which I think is consistent with what jesse said.
15:26:39 <acoburn> jeswr: for JSON Schema, one option is to include a JSON-Schema in the representation
15:26:46 <acoburn> ... are there other topics related to the framing
15:27:02 <pchampin> q+
15:27:11 <acoburn> bengo: for JSON Schema, I don't know of any W3C specs that have normatively referenced JSON Schema
15:27:29 <acoburn> jeswr: I'm not a JSON schema expert so I'm not sure
15:27:52 <ericP> ack next
15:28:00 <acoburn> bengo: from CR to TR in other specs, we had to drop features (such as JSON schema) that were not stable
15:28:15 <pchampin> https://www.w3.org/TR/vc-json-schema/
15:28:16 <acoburn> pchampin: normatively citing JSON Schema has been problematic in the past
15:28:37 <acoburn> ... vc-json-schema normatively refers to JSON Schema
15:28:50 <bengo> (we had to drop 'json-ld signatures' but not json schema, but the rationale from the chair was that it was not a stable enough spec to normref. 5+ years later now we have https://w3c.github.io/vc-data-integrity/ )
15:29:12 <bengo> json-schema was never used in SocialWG
15:29:56 <acoburn> jeswr: next question on that front is how to reference the schema
15:30:05 <acoburn> ... one option is to reference the schema in the spec
15:30:17 <acoburn> ... another option is to include a link to the schema in the JSON document itself
15:30:36 <acoburn> ... not sure if this is a standard approach, esp. with JSON-LD objects
15:30:46 <pchampin> q+
15:30:54 <acoburn> ... are there opinions on how to reference such schemas
15:31:05 <ericP> ack next
15:31:36 <acoburn> pchampin: in reference to the schema key, there are several options: ignore or map the key to a particular URI
15:31:58 <acoburn> ... we have examples of specs where a JSON-LD context and also provide a hash
15:32:06 <acoburn> ... since the content on /ns is not normative
15:32:27 <bengo> I guess I have a question which is... is the json-schema going to be normative? is the JSON-LD frame context going to be normative (like in activitystreams)? what if they disagree or the schema languages are not equally expressive?
15:32:28 <acoburn> ... we should also insist that implementations are not required to dereference the referenced schema
15:33:00 <acoburn> ... we'll need to explain this better in the next version of the JSON-LD WG
15:33:25 <bengo> q+ do we need a normative json-schema if we have a normative json-ld frame?
15:33:38 <bengo> q+
15:33:43 <acoburn> jeswr: would be better to have some statement about this from the JSON-LD WG rather than define it ourselves
15:33:54 <ericP> ack next
15:34:01 <acoburn> pchampin: JSON-LD is currently being rechartered
15:34:14 <acoburn> ... the charter is already quite full
15:34:38 <acoburn> bengo: if both a frame and a schema are normatively referenced, what if they disagree?
15:35:02 <acoburn> ... if they do disagree, there will be no deterministic algorithm
15:35:16 <pchampin> I agree that the schema and the frame serve different categories of users
15:35:24 <ericP> q+
15:35:30 <ericP> ack next
15:35:31 <acoburn> ... I am more comfortable with a normative JSON-LD frame than normatively including a JSON Schema
15:35:38 <pchampin> and also that ensuring that both agree can be challenging
15:35:53 <acoburn> ericP: the benefit of making JSON devs happy shouldn't be understated
15:36:18 <acoburn> bengo: the schema doesn't help a server know how to serialize consistently
15:36:38 <acoburn> ... JSON-LD frame will be more specific/deterministic
15:37:00 <acoburn> jeswr: can we derive a JSON schema from a JSON-LD frame?
15:37:08 <acoburn> bengo: activitystreams would benefit from that
15:37:21 <pchampin> q+
15:37:26 <acoburn> bengo: we could dodge this by dropping json schema
15:37:30 <ericP> ack next
15:37:48 <acoburn> pchampin: I would really like to have a way to derive one from the other
15:38:07 <bengo> My biggest concern is that json-schema does not help produce JSON-LD in a deterministic way, whereas a normative json-ld frame does.
15:38:20 <acoburn> ... but I'm willing to standardize one and leave the other informative
15:38:44 <acoburn> ... or specify both and state that if there is conflict, one takes priority
15:39:00 <acoburn> jeswr: this object we're talking about is not especially complex
15:39:13 <acoburn> ... we should be able to normatively define the JSON-LD context
15:39:18 <ericP> +1
15:39:20 <acoburn> ... and informatively include the JSON schema
15:39:32 <acoburn> ... and be quite certain that they won't conflict
15:39:45 <AZ> AZ has joined #lws
15:40:08 <acoburn> jeswr: next up: semantics of the data
15:40:29 <acoburn> ... we need to define the data we want to describe and start defining a context
15:40:41 <acoburn> ... which involves defining the terms
15:41:35 <acoburn> ... strawman object of the kind of data to include
15:41:54 <acoburn> ... go through each field
15:42:07 <acoburn> ... first field "type: Container"
15:42:21 <acoburn> ... assume this is not controversial
15:42:32 <gibsonf1> q+ about paging
15:42:41 <acoburn> ... the "totalItems: N" field, seems like optional
15:44:47 <acoburn> ... for each child resource, "type: DataResource" seems like a required field
15:44:54 <gibsonf1> q+ about overall storage status vs. container
15:45:19 <ericP> ack next
15:45:55 <acoburn> gibsonf1: related to paging, there have been attempts to define how many items in a response
15:46:12 <acoburn> ... if we do paging, can we do this without intermediate items
15:46:53 <acoburn> ... would like apps to be able to define the number of items in a page
15:48:02 <acoburn> ... on containers, is it possible for the storage to contain containers but also perform a role as a container
15:48:24 <acoburn> ... for example, if there are URIs that are not in a container you can still refer to them
15:48:39 <bengo> I dont like the 'MUST include exactly ONE type'
15:49:35 <acoburn> jeswr: i.e. you want to restrict what goes into a resource, I can only put data describing the subject of the URL
15:49:51 <acoburn> gibsonf1: I'd like to treat the storage as a named graph
15:50:43 <pchampin> q+
15:51:08 <acoburn> jeswr: in Solid it was never a requirement that a subject must be in the resource where a subject is defined (i.e. at that url)
15:52:05 <pchampin> q-
15:52:24 <acoburn> jeswr: suggest that we discuss named graphs for a future discussion
15:53:26 <acoburn> ... related to types, are these the right types (DataResource, Container, MetadataResource)
15:53:38 <bengo> q+ on mediaType
15:53:43 <acoburn> ... should we include the media type?
15:53:58 <gibsonf1> q+ on container child type
15:54:15 <ericP> scribe+
15:54:42 <ericP> acoburn: for large containers with defined media type, you need to HEAD them all
15:55:06 <ericP> ... useful for things with a defined media type
15:55:14 <bengo> IMHO the notion of a resource having a single media type is confusing the nature of REST where a resource has many representations with many media types
15:55:32 <ericP> ack next
15:55:48 <ericP> ack next
15:55:49 <Zakim> bengo, you wanted to comment on mediaType
15:55:54 <acoburn> bengo: media type as a property is defined in activity streams and VC
15:55:58 <bengo> https://github.com/w3c/vc-data-model/issues/1408
15:55:59 <gb> https://github.com/w3c/vc-data-model/issues/1408 -> CLOSED Issue 1408 reconsider `@id` for `mediaType` term (by gobengo) [pr exists]
15:56:21 <ericP> scribe-
15:56:33 <acoburn> ... the bigger concern is that something with type: DataResource has a single media type
15:56:50 <acoburn> ... Representations have media types, Resources do not have a single media type
15:56:50 <jeswr> q+
15:57:07 <bengo> q-
15:57:10 <ericP> ack next
15:57:11 <Zakim> gibsonf, you wanted to comment on container child type
15:57:36 <acoburn> gibsonf: related to media type, we deliver enough so that the app can display a list of items
15:57:54 <acoburn> ... such as a type, which helps the app know what to do
15:58:40 <acoburn> ... for a media type, there is a URI for that
15:59:02 <ericP> ack next
15:59:03 <acoburn> ... our implementation has an algorithm to know which type to display
15:59:30 <acoburn> jeswr: I want to extend on bengo's point about there being multiple representations of a resource
15:59:51 <acoburn> ... would it be better to describe the "accepted" media types for a given resource?
15:59:59 <gibsonf1> <http://www.w3.org/ns/iana/media-types/image/>
16:00:32 <acoburn> ... for images, one may get a list of "image/jpeg" and "image/png"
16:01:02 <acoburn> ... or define which media type was the one used when the resource was originally written
16:01:29 <pchampin> +1 to all jeswr is saying
16:01:38 <acoburn> ... tbl has often opened issues related to the original form of the resource (e.g., to include comments from turtle document)
16:01:59 <acoburn> RRSAgent, make minutes
16:02:01 <RRSAgent> I have made the request to generate https://www.w3.org/2025/11/17-lws-minutes.html acoburn
16:02:07 <ericP> ADJOURNED
16:02:07 <bengo> what I've been playing with, and sort of works well, is just reifying the representations. ie a resource is serialized as { representation: [{ mediaType: 'application/json' }, { mediaType: 'image/jpg' }] }
16:02:12 <bengo> jeswr fyi
16:02:23 <bengo> as opposed to { mediaTypes: [] }
16:03:10 <bengo> curious what you think. leaves room for future per-representation props
16:03:33 <acoburn> present+ bengo
16:03:42 <acoburn> present+ gibsonf
16:03:55 <acoburn> RRSAgent, make minutes
16:03:57 <RRSAgent> I have made the request to generate https://www.w3.org/2025/11/17-lws-minutes.html acoburn
16:04:45 <acoburn> bengo: FYI, I'm very much in agreement with your concern about resource vs representation
16:05:59 <acoburn> acoburn has left #lws
16:38:57 <gb> gb has joined #lws
17:01:39 <TallTed> Zakim, end meeting
17:01:39 <Zakim> As of this point the attendees have been TallTed, acoburn, laurens, eBremer, jeswr, gibsonf, ericP, pchampin, AZ, bengo
17:01:41 <Zakim> RRSAgent, please draft minutes
17:01:43 <RRSAgent> I have made the request to generate https://www.w3.org/2025/11/17-lws-minutes.html Zakim
17:01:49 <Zakim> I am happy to have been of service, TallTed; please remember to excuse RRSAgent.  Goodbye
17:01:49 <TallTed> RRSAgent, bye
17:01:49 <RRSAgent> I see no action items
17:01:49 <Zakim> Zakim has left #lws