Meeting minutes
Introductions & Announcements
danbri: I have been involved in RDF since 1997. Currently unemployed dad and invited expert.
… I was an editor of RDF Schema, which was not ready at the end of the first RDF WG. Created the RDF Interest Group to continue the work.
… Invented FOAF in a pub with some friends, and got engaged in Linked Data since then.
… Worked on Schema.org at Google until recently.
… Interested in seeing how RDF, LWS progress, in particular in relation with AI.
Sam Gbafa: founder of Tiny Cloud, a small company where we care about sovereign user data.
… Not using Semantic Web technologies, but our vision seems aligned with that of this WG.
… I have a AI and crypto background, familiar with standard work and W3C.
… Worked with SpruceID before.
Pending Action Items](https://github.com/w3c/lws-protocol/issues?q=is%3Aopen+is%3Aissue+label%3Aaction )
acoburn: skipping the "permaitem" at the bottom
… hadrian, I think that w3c/lws-protocol#13 is complete, right?
hadrian: yes, the PR was merged
<gb> CLOSED Action 13 define a requirements template for the lws-ucs repository (on hzbarcea) due 2025-02-03
acoburn: the next one w3c/lws-protocol#15 is also assigned to hadrian.
<gb> Action 15 introduce both the term owner and controller in the glossary, and clarify their meaning. (on hzbarcea) due 2025-02-24
hadrian: this is kind of done; there are no roles specified at the moment.
… There will be more clarifications needed when we introduce them.
… pchampin made a comment suggesting to keep both terms.
pchampin: I don't remember this specific comment, but my recollection is that several people on the last call wanted to keep both.
acoburn: it boils down to the role of the glossary.
hadrian: I think that in the context of the glossary, they are interchangeable.
… But when we define roles, we might want to define them separately. But should be able to move forward right now.
acoburn: any objection to close w3c/lws-protocol#15 ?
csarven: not an objection but a comment.
… The issue introduces both terms, but the PR introduces only one.
… There seem to be a difference between the decision taken last week and the PR.
hadrian: there was an interesting discussion, suggesting we reuse the work done in the VC WG on the Controlled Identifier spec.
… I think the agreement last time was to introduce both as roles, but not as terms.
acoburn: my understanding was to have definitions of both terms, because they are slippery and may create confusion.
… So we should keep the issue open.
hadrian: then I would expect comments in the issue or the PR to clarify the ask.
acoburn: agreed, I'll comment in the issue.
Position of the WG w.r.t. the Editor's Draft of the protocol
acoburn: this one came up at the very end of last week meeting.
… The question is our position towards the Community Group working on the protocol CG report.
… The CG report was published as v0.11, and there is an Editors' Draft as well.
… Both are listed in our charter as input to this WG.
<sam> Can we link to the editors draft here?
acoburn: At the same time, the CG has been working on some issues (the content is not important here).
jesse: it was unclear to CG members whether the Editors' Draft was locked.
… It would be good if the LWS WG could signal 1) if it intends to consider changes made to the Editors' Draft now,
… and 2) when would be the deadline to take into account such changes?
<gb> MERGED Pull Request 63 clarify the handling of low-maturity normative references (by pchampin) [ac-review]
<Zakim> csarven, you wanted to discuss https://
pchampin: I would be concerned if the CG published a new version of the spec (wrong signal to the outside world), but working on the ED is ok IMO.
… The work done by the CG will be useful to us anyway.
csarven: some context on the writing of the charter:
… the chartering took time. The CG was continuing to publish new versions during that time (0.10 -> 0.11).
… The intention of mentioning the ED was *not* to lock it. The published version is locked, obviously.
… Another point: technically the notion of Editors' Draft does not exist for Community Groups, only for Working Group.
… We could decide to only take into account what's in the published version, on also what's in the ED.
<pchampin> s/only for Working Groups./only for Working Groups. This "ED" exists for historical reason.
acoburn: regardless of the actual issue, if something is amiss and the CG is able to sort that out, I think this would be helpful.
… I would only expect minor changes, though, not some radical rework of the spec.
csarven: the WG can pick and chose what it takes into account, it does not *have* to adopt the latest changes in the ED.
laurens: I would also be worried if the CG took a different direction with the protocol.
… Not a problem for us as we can chose what we adopt, but this could cause confusion for other people.
acoburn: jesse, hadrian: is this clear for you?
jesse: it is clear, and aligned with my expectations.
… It would be good to have a clear statement from the WG chairs to the public mailing list of the CG.
hadrian: that's also good for me.
csarven: there is a proposal @@1 proposing a mutual understanding.
… It is very flexible for either side.
acoburn: sounds great, I'll take an action to respond from the WG's side.
ACTION: acoburn will respond to the aforementioned thread from the LWS WG
<gb> Cannot create action. Validation failed. Maybe acoburn will respond is not a valid user for w3c/lws-protocol?
Moving towards a first draft of the Use Cases and Requirements document
pchampin: we are six months into wg. we have a lot of use cases, but we need to have more visible progress on UC document
pchampin: we are ~6 months into our charter, the have a lot of use-cases (that's good) but not much visible progress on the UCR document itself.
laurens: UCR document is a blocking requirement for work on the protocol
danbri: is there a Use Cases and Requirements from Solid, which we could reuse?
acoburn: there are a lot of different documents in different places.
… Some of them have not aged very well and are not very well defined.
… Our goal was to reference those when possible, but having our own list, better curated.
danbri: is there an informal sense that everyone is going in the same direction?
… Will our use-cases influence back the Solid community?
csarven: tough question. Generally yes, but the Solid vision is very broad and sometimes vague.
… Some solutions developed in other W3C groups or elsewhere have some overlap, sometimes compatible, not always integrated in the Solid spec.
danbri: it is natural for a project like Solid to be more exploratory.
pchampin: would this work benefit from a second editor?
hadrian: the question has been asked before, and the response was: yes, it would be great to have a co-editor.
… But noone volunteered so far.
acoburn: it is not necessary to answer right now. People can mull this over. People not on the call will also see it.
… Please think about it. If you are interested, you can reach out to any of the chair, pchampin, hadrian, or to the whole group.
… Any more comments on this topic, or another topic that we can fit into 5 minutes?
hadrian: the template for requirements, but there are no requirements there.
… My plan for next week is to add some.