Meeting minutes
Introductions and announcements
acoburn: introductions....
jeswr: 1st, solid symposium 2026 has gone live with tickets
<jeswr> https://
jeswr: ODI having a hack-a-thon at beginning
<jeswr> https://
jeswr: I would like ODI to host LWS meeting at start of week
… ODI prepared to host one
… things going the whole week
acoburn: anyone a member of WG should pencil those dates in...
<jeswr> There is a “Solid Week” from April 27 - May 1, which includes:
<jeswr> - An application development tournament (April 27 - April 29)
<jeswr> - Likely a Linked Web Storage in-person meeting (April 27 - April 28)
<jeswr> - The Solid Symposium (April 30 - May 1)
acoburn: most likely will be
pchampin: TPAC - summary of informal discussion with people about the relavence of subsetting of LWS toa read-only part
… POD restricting write operations
… inform applications so that they do not break
… convo with Dan Brickley...having a POD be read-only
… which then LWS could use in a LWS way
<bendm> RSSAgent make minutes
pchampin: underlying concern Dan expressed, that any applciation broken when trying to write
… use case we should acknowledge
<TallTed> so, restoring the read-only (or read-mostly) environment of today's www, to the read-write-web toward which LWS (and Solid) is aiming?
pchampin: we talked about f2f, Darius Kazemi is one of the co-chairs of the social web wg
… missions to update and maintain activity pods
… LWS and social groups should be able to liaise on regular basis
… we should probably plan on attending their Dublin 2026 meeting
<TallTed> AuthN + AuthZ should be enough to deliver the protected data spaces being described, whether via WAC or other...
jeswr: had convo with Chris Riley
… plan their to use DTI connectioons to bridge data from services like Google and Facebook
<jeswr> https://
jeswr: 2n thing i want to advertise, is one of the seesions for solid symposium...what infrastructure we need on top of LWS and solid layers
<jeswr> https://
jeswr: topic of restricting read and write on the server side
… that the applicarions are reading and writing the datamodels that they're certified to write
… please give feedback on proposal
<Zakim> bigbluehat, you wanted to say hi :)
bigbluehat: open invitation to upcoming JSONLD start incorporation
… and talk through anything you might want to see in JSON-LD going forward
<Zakim> gibsonf, you wanted to ask about application data issue
gibsonf1: Pierre - were not technically doing LD currently in solid...
… manahin how to write to thise sioloed areas is difficulty versus lets if a storage wereeffectively a linked data graph
Authentication & Authorization proposals
pchampin: I disagree that we're not doing LD. thats probably an offline discussion....
… but to your point, at the graph level rather than the resource level solve the problem
<acoburn> Authorization proposal
<gb> Pull Request 45 LWS Authorization (by acoburn)
<acoburn> Authentication proposal
<gb> Pull Request 43 LWS Authentication (by acoburn)
<jeswr> Imlementation of authN/authZ specs jeswr/
Containment discussion
jeswr: picking up on topic of containers which are similar to LWP but not exactly
… last weeks what a response might look like
… an option to get a framed jsonld response
… and the server implementations may allow you to contneg other content response types
… having a special application/json+lws type
… and a schema to describe this frame
… what these media type should look like
… what the BP around having HSON schema to describe the frame of JSON-LD objects
bigbluehat: whole profile sitation..failry fraught if you look over last 5 or 6 years
… of suggested patterns
… we minted serveal profile URLS
… we're full https URLs for profile values
… get spooked with http call in places
… blocking the use of profile equals http anything
… we now have application/vc which is still jason..unformtunate becauyse there a whole lot more top level media types
… not sure if it matters in this particular case
<Zakim> gibsonf, you wanted to ask, would't url encoding the profile fix that problem?
gibsonf1: wouldn't encoding the URL fix that problem with the browser.
bigbluehat: great question
… im not sure honestly
… the constrined corfes desktop mobile browser world
<TallTed> URL lengths, among other issues, come up when you really start working with profiled media types
bigbluehat: where the browser will just choke on it
… maybe a URN or a did or something starts to look better
jeswr: solid was a file system for the web...still is
… LDP ha skind of many similar functionality
… for lws, something looking to dowhen it comes to developers were looking to have structured json response so tht developers that are coming from more a world of dealing with json objects
… are able to just fetch json
<TallTed> jeswr -- please share URL to the gDoc you're sharing, so it may be more readable for us
jeswr: and not have to do any parsing of the document in RDF form
bigbluehat: key thing with signalling media type than your problem space
… the use of profile is nice, you can still use it, you just have to update the spec
… versus a url
… the web annotation group were to ever reboot, and I think web publications is still considering this route for EPUB
jeswr: in solid today, only two content types are json-ld and turtle
… when you get a json-ld response, no framing that servers have to respond with
… no solid framing to that at all, so in LWS be more strict with that
… to enable clients to specify that particular frame if they want that
… to be guaranteed to get what they really want
tallted: 1st - and this is vitally important being the LWS WG. Solid is just another suite of applications that will make use of LWS storage locations
… I may have chosen to store my data in serveral diff LWS storage locations...
… applications tooks that I may be using with that data may make it their own choices about parceling the data out
… solid - 10 year old project
… which may or may not be use din LWS
… questions about backing it up...or what may be allowed to change it or can read from these locartions
… and write to ones
… it's important not to prematurely limit or permit things
… at this stage of the game it is better to say this is permitted under various conditions
<jeswr> https://
tallted: and be able to say what those are
<Zakim> bigbluehat, you wanted to ask about variability (especially of frames) and across time (versions of LWS, etc)
bigbluehat: if you're going to have a lws+json they're all going to share the same context with variability around the frames
… which makes them far less extensible
… more extensibility withing the media type name if LWS were a top level thing
… another last point, file extensions, you will have to mint a top-level media type
… toget a .lws file if you wanted that
… if you can push towards how often we're gonna push that handle...at the media type level that helps a ton
… what frames you would define up front?
pchampin: thats gonna alter the media type versus profile discussion
… convo in AP which is allowing developer sto manage this data as pure json if they want to do that
… extensibility and flexibility that REF offers for those who want that
… its a double-edge sword
… maybe steer the format in a way that any extension that would be added which is possible through additional contexts and mapping those extended terms to specific URI would maybe be harder to use in the wrong way
<Zakim> TallTed, you wanted to note built-in difficulties with "windowsize" or "filesize"
tallted: there is often an expressed desire to having a paging facility to be able to work with some window of records as jsonld or json
… tragically, http specified is byte-based
… its not about fields, its about bytes which makes it really hard to build good windowing tool
… and its big problem which i am trying to raise early
jeswr: finish up media type discussion, option 1 profile-based option
… we want to consider versions which we dont have yet. have something like lws-10
… not sure what it looks like on upgrade path
… are we having a different profile for each thing we are getting back when we gettign a repsponse back for a container
… do we doing something like this for all of the frames we want
jeswr: one frame for containers,expect others
acoburn: one perhaps for storage metadata
bigbluehat: you can use other http headers as well. wve mostly been focused on the media-type
… if variability is just versioning, maybe have an eye towards where youre gonna put the version number
… they're just going to need to mao to those frames and whatyou will do to your ecosystem if they dont change
<Zakim> gibsonf, you wanted to ask on lws version - can that be in Accept?
bigbluehat: collect all of the things, start your ENOM profile approach and maybe use lws+json profile
gibsonf1: if we require all LWS compliant servers, application can request whichever they want assuming the server is up to date
<Zakim> bendm, you wanted to ask why does this need to be out of band? can't we do it all in the actual frame and just have mimetype application/ld+json?
<TallTed> HTTP server is always in control of what it ships to a client, regardless of the *request* headers (hence their name)
bendm: wondering this needs to be, can this metadata just be part of the response json so part of the frame so that we dont need to create our own custom mime types media types these kind of things
… in my naive thinking prevents interoperability
<pchampin> note that for Turtle & co, the RDF & SPARQL WG defined a specific media-type parameter version=, distinct from profile=
acoburn: implies response could be just about anything. not a lot of structure
… if we do constrain it, that indicates to clients we are working with a constrained set of data which is where we are trying to get to
bendm: that not something you can just do with schema just as many other json apis can do
acoburn: we are straddling this boundary of both json and rdf
bigbluehat: that json schema thing is a actually a good thing..similar to a frame
… i want it to be a specific shape. How do you do that over the wire for your protocol?
… does the client then just say, i got a response and it has this context and this schema and so this frame URL as well
… aaron you mentioned something about the shape of the jsonld being constrained
acoburn: please review authorization and authentication work if you can
jeswr: flag to bejamin, last week, derive schema from jsonld frames so we can just define one
<bendm> related: KNowledgeOnWebScale/
bigbluehat: yeah, lets do it over email that would be great