Meeting minutes
Introductions & Announcements
acoburn: Any Announcements, Introductions, ...?
… : there being none, let's move on
Open PRs
acoburn: Let's make sure to move through the work on GitHub, not spending too much time, just making sure we are on the same page
… there are a couple of PRs, that I opened, not going into details
… some errors in spec documents, thanks elf-pavlik!
… and some terminology changes, mostly copy paste
… except the last part of #56 where I provide examples
<gb> Pull Request 56 Change 'end-user credential' to 'authentication credential' (by acoburn)
acoburn: please comment if you have anything to add
… then there is #55 about informative references
<gb> Pull Request 55 Update unresolvable informative references (by acoburn)
acoburn: that are not resolvable. I do not have a strong opinion how we solve this issue.
… please comment if you have an opinion
… that's all on the open PRs.
… any feedback on that now?
… there being none, let's move on
Triage open issues
acoburn: I'd like to timebox this to 10 minutes at MAX
… just we know which issues exist
… I'd like to group the issues into "needs-discussion", "we had discussion and is now ready for PR", "postponed", and "considered out-of-scope"
… if there is some ACTION that is required, I'd like to figure out who should take action on what.
w3c/lws-protocol#12 Include Solid User Stories and various UCRs into LWS UCR (by CxRes)
acoburn: first, #12, where we quickly moved on - I am unsure whether there is much discussion required here
… rather, is anyone willing to take action and move this issue forward?
bendm: I think we should investigate to see if anything is not covered already. I am not sure if anyone from the Solid CG (or closer linked to the CG) who might have a better view on this?
… if not, I could take a look, although I do not follow the CG that much
acoburn: Thanks, bendm, if you could take a look into how the CG UCRs are reflected in the WG UCRs, that be great.
w3c/lws-protocol#18 Prior Art Collection (by jeswr)
acoburn: #18, on prior art, jeswr, do you want to move this forward? Is this relevant as an open issue, or would this better be wrapped up in some way (wiki?)
jeswr: I propose closing the issue - the wiki is not really maintained, and I have not been able to follow as closely.
acoburn: Alright, I'll comment right now, and if no objects arise until the end of the week, we'
… we'll close it
w3c/lws-protocol#24 Reasons for separate rest bindings (by jeswr)
acoburn: #24, is there more discussion to be have?
uvdsl: I'd like to request a proper summary of the discussion before closing the issue
acoburn: if someone could jump in and assign themselves, that would be great. If we do not have someone by next week, we'll pick someone.
w3c/lws-protocol#27 Terminology: Resource Manager / Resource Controller / ... (by uvdsl)
acoburn: on #27, there is alot of ground to cover here, let's discuss this more
w3c/lws-protocol#28 Resource Identification (by uvdsl)
acoburn: on #28, mostly on terminology? uvdsl?
uvdsl: yes, but tied to #24, regarding the minimum to implement for the transport protocol of the LWS protocol
acoburn: I'll label it as needs discussion
WG Note on compatibility with Solid and/or migration
acoburn: this concludes 10 minutes of triage
acoburn: there has been questions on compatibility with Solid and migration paths for Solid
… I believe there would be value in documenting such things in a group note
… the group note does not require the rigor as other documents
… I'd like to propose that we do work on that
… but we would need someone or multiple people to work on this
… so question:
<acoburn> PROPOSAL: Should the LWS WG add a work item for creating a WG Note on compatibility with Solid and migration from Solid
<dmitriz> -0
<laurens> +1
<Luke> +1
<jeswr> +1
<eBremer> +1
<ryey> +1
<ericP> +.5
<gibsonf1> +.5 (Maybe Solid side could do this?)
<bendm> +0.5 indeed in collab with Solid CG
<acoburn> +.5
<TallTed> +0
<uvdsl> +0
RESOLUTION: Should the LWS WG add a work item for creating a WG Note on compatibility with Solid and migration from Solid
acoburn: General feedback is positive, collaboration with CG seems good, not asking for volunteers right now
<TallTed> SolidCG cannot produce a NOTE, only a REPORT
ericP: Wondering whether those who +1 have a strong opinion on whether the Note is published is WG vs CG?
… the reason I am asking is because the CG specs can be more of a moving target; we are required to lock something down and finish.
<gibsonf1> +1 on published from Solid CG side as its that community that would be interested in LWS relation
ericP: so, maybe it would be easier for the CG to produce such a document
<Luke> +1 for Solid CG, but for sure in collaboration with LWS WG
acoburn: I think it would be great if the CG would take that - but we could support that
ericP: right, we could help, we could even provide text
pchampin: I think that it would be desireable that this Note comes from the WG
… because we ARE diverging from the current state of Solid
… but we are also supposed to maintain a certain continuity
… I find it a bit weaker to let the CG come up with it
… just because we do not have to
acoburn: I'd like to finish up this agendum
… please, do consider this, and we'll discuss it next week
… moving on
LWS Containers
<laurens> https://
laurens: for the last couple of weeks, I have been working on a draft on how containers might work in LWS, based on the WG meeting in Gent.
… ** shares screen **
… this is still a draft, much work to be done to finalize, open to any comments. This is an invitation
… we will need a couple of iterations, before we can PR this
… I'll walk you through and highlight the important parts, especially where this diverges from Solid/LDP
… notably, containment in multiple containers
… wondering whether implementers will actually care
… then, there is a definition of terminology in here
… pchampin also pointed out a discussion on the notion of a root container
… gibsonf1 also opened a GitHub issue on this
… so we need to discuss this
… then, LWS resources are a subset of information resources (WEBARCH) that are stored on a LWS-compliant storage
… ** continues running through definitions too fast to scribe **
… multiple containment entails potential problems that we need to consider
… link-set notion is important to this concept
… if there are questions, please let me know
<gb> CLOSED Issue 39 link relations for RDF (by dret) [rfc5988bis]
laurens: containment relations are materialised on containers and on the resources itself.
… each resource's linkset must include a link to the containers it is part is
… containment link headers are also specified, supporting multiple containers
<Zakim> gibsonf, you wanted to ask about Storage itself as a container with having top level resources of potentially both "root" containers and root non-container resources
laurens: there are also some integrity requirements on containment relations, especially regarding relation
gibsonf1: On the multiple containment, as an implementer, we won't implement that. It is fine to have as an optional feature
… the main point, again, is the storage itself acting as a root container
… for example, you could have an "outside IRI" like foaf:Person, this could live in the root container without being contained
… so you could have one or more root container, and you could also have multiple root resources
laurens: I can follow for the containers but for the resources?
gibsonf1: The way to think about this is -- at least in our implementation -- there is hierarchy within the storage but there are also resources that do not belong within the hierarchy.
uvdsl: Just as input, did you look on DCAT DatasetSeries for the multiple containments?
ericP: In DCAT, this is absolutely possible
laurens: in the face-to-face meeting, we defined this as desirable, but we will see how this plays out
… continuing: resource identification
… discussing slash semantics
<gibsonf1> +1 on optional slash semantics
laurens: we should not normatively disallow this
… as it stands, having access to a container, allows for reading (seeing) the URIs contained, but we will need more clarification on the other actions
… container representation. It is a JSON-LD representation, with an LWS JSON-LD context
… optional aspects include total items count
… there is more work to be done here
… important: allow for pagination on container representations
<gibsonf1> +1 to ask about pagination
laurens: in Solid this was not straight forward
… but in LWS we want to support this including limit and offset
gibsonf1: On pagination, looks like you are following the LDP approach, which I find unimplementable and complex - but there is a pagination approach for everything: you have a start point and then you specify the amount.
<TallTed> `pagination including limit and offset` requires stuff atop HTTP, which only lets you use byte-count for limit and offset.
gibsonf1: I'd like to propose to go with most simple solution
laurens: there is no client-defined pagination
… so servers decide how this works
… servers just provide a `next`, `first` and `last`
gibsonf1: well this is complex
… a client just could give one IRI and then go from there
acoburn: this is just an overview, detailed conversations are welcome in the issues or similar
gibsonf1: I'd love to have pagination as a separate topic then
laurens: Please do leave a comment on this
pchampin: I wanted to point out what I think is a misunderstanding: This proposal does not mandate HOW a server is doing pagination, only requiring what links to provide like `next`.
… `last` may be too much to ask from a server, depending on the chosen approach - similar to what gibsonf1 mentioned
<acoburn> +1 on the challenges with a "last" link
laurens: moving on, there was discussion around resource creation using POST vs PUT
… POST using `slug` header to suggest a name, but servers must respond with a 201 CREATED including a Location header with the IRI of the newly created resource
… regardless of them taking the suggestion or ignoring it
… more complex: adding existing resources to containers (multiple containment)
… a new link relation is added to a linkset, using PATCH or PUT
… removing, similarly, deleting the link from the linkset
… deleting a container, then the semantics could be defined, more discussion required
uvdsl: resources and containers have link sets?
<pchampin> in the current proposal, the container->item relation is in the *representation* of the container, not in its linkset
laurens: both have link sets
acoburn: thank you laurens, looking forward to the conversation
<gibsonf1> Nice work laurens
pchampin, thanks! that clears it up!