Meeting minutes
Linked Web Storage WG -- 2025-01-27
<acoburn> Scribe list
laurens: any annoucement?
pchampin: W3C is organising a breakout day in March
… halfway between 2 TPACs
… we could organise a session of LWS
<pchampin> w3c/
pchampin: it is not an obligation
Introductions and announcements
laurens: there are 2 action items
… assigned to Hadrian
Pending action items
hadrian: the labels are done
… the one that needs discussion today is basic storage 117
<kaefer3000> see w3c/
<gb> Issue 117 Basic Storage Context (by hzbarcea) [needs-discussion]
hadrian: the "needs discussion" must be curated continuously until we have list of requirements
hadrian: I went through issues and started getting requirements
… many UCs have a context assumed
… for every issue raised, things related to the context should not be discussed in the issue
… the discussion should be more focused
… I'm now working on a second batch
… there's something related to local storage
… there are things about query engines, about processing
csarven: I'd like to understand the Basic Storage Context
… some of them are new UCs and some of them are new, relative to issue 117
… not sure if these (which one?) are strong UCs as UCs
<csarven> Anyhting of significane should have a URI: https://
csarven: if you give everything of significance a URI
… this is more something of a requirement
… I'm a bit confused about what we do with basic storage
… can you elaborate more Hadrian?
hadrian: you say that these UCs are more like requirements
… true, I'll gather requirements from these UCs
… I'll distill these UCs into finer grained UCs
… I'll take all these things into one basic storage context (?)
csarven: if the intention is to have the context be related to requirements, don't use the UC template
<uvdsl> +1 to sarven's point
hadrian: I understand your point
… at smoe point we talked about identity of storage end users (?)
kaefer3000: don't call requirements UCs
… it's important that they are linked back to chich UC they come
hadrian: we did not discuss yet how we capture requirements
laurens: there is an action to be done, that is to have a template for requirements, or context
<pchampin> "proto-requirement"?
<ericP> +1
hadrian: I support that
ACTION: hadrian to define a requirements template for the lws-ucs repository
<gb> Created action #13
hadrian: the requirements should be linked to the UCs
… should then the UC issue closed?
laurens: it's how I understand it yes
hadrian: the problematic UCs should be phrased as requirements not user stories
laurens: is there anything to add on this topic
laurens: AOB?
Basic storage context (w3c/lws-ucs#117 )
<gb> Issue 117 Basic Storage Context (by hzbarcea) [needs-discussion]
hadrian: we can discuss the issue on basic storage context
ericP: need clarification
… do we split the UCs into ???
laurens: iti s best to have this kind of discussion asynchronously
<laurens> w3c/
<gb> Issue 110 [UC] Ability to split or aggregate storages (by hzbarcea) [usecase] [review]
ericP: the question was about whether to splitting pods
laurens: if you haven't additional issues to discuss now, we can continue asynchronously
laurens: maybe one issue of interest is 108
<gb> Issue 108 [UC] Uniquely identify storage globally (by hzbarcea) [usecase] [uc-identity] [review]
laurens: I'm looking for solutiosn to this
hadrian: you can have part of URL that is globally unique
laurens: we don't need to discuss solutions yet but talk in terms of requirements
laurens: will leave comments to github issues
csarven: if I look at issue 112 for instance, with linked data glasses, I don't se an issue to meet the use case. UC's Acceptance Criteria would help to determine what might be needed on an atomic level. So, e.g., moving from one provider to another and what that might entail.
… but different people will see them in different ways
hadrian: in this issue, this is about being able to move to a different storage provider
laurens: what you said csarven is related to acceptance requirements
uvdsl: could hadrian add explanation to the issues
… maybe just a few bullet points so we can understand better
laurens: we can help in clarifying the issues
hadrian: commenting on the issues help in clarifying the UC or issue
… so please respond to the Github issues
Identity & WebID
hadrian: what do we do about WebID in this group?
… this is a key decision to be made
laurens: this requires more elaborate discussion than we can have today
… but we can talk about it a bit
… it relates to the requirements
… what's the group member's opinion about WebID?
pchampin: previously DID specified the DID document
… that has an intersection with WebID
<balessan> +1
<laurens> https://
pchampin: we need to explore this in liaison with DID WG
… some part of DID work was moved to VC WG
… I agree that this is something that will need further discussion and clearer discussion once requirements are in
csarven: we had a discussion in December about scope
… to know what's acceptable to take on or update
… say we need authorisation
<hadrian> +1 pchampain, i wasn't aware of it, very helpful, I agree with the path you suggest
csarven: as a feature
… whether a solution must depend on a spec, we don't necessarily need to have a spec covering all of it
… e.g. WebID does not have to cover all aspects, all UCs
… we have too many UCs to address that cannot be covered entirely with existing spec
acoburn: there is no way that we will have a single spec that covers all the UCs
… we have to prioritise the requirements
… then we can look for solutions
<laurens> +1
acoburn: at the moment, discussing the merits of solution A vs solution B is not very productive
laurens: no other business, then we can ajourn