– DRAFT –
Linked Web Storage WG Meeting

Introductions and announcements

acoburn: Anyone new in this meeting?

laurens: Face-to-face meeting in Ghent, BE hosted by Digitaal Vlaanderen on October 8-10, 2025. Details have been sent out via the mailing list.

laurens: f2f meeting will be hosted in Belgium Oct 8-10. Details sent out via mailing list -- https://lists.w3.org/Archives/Member/member-lws-wg/2025Aug/0000.html
… please confirm attendance by Aug 29
… there is also an option to indicate that you will attend remotely
… we encourage in-person attendance
… there will likely be 1 or 2 more f2f meetings for this WG, so there will be other opportunities if this meeting doesn't work

jeswr: On August 18 the chairs will be out-of-office
… So I would like to focus on the topic of authz in that week
… I am designing an authz system I would like to propose to the group
… which works with the as-is requirements as well as ABAC (attribute based access control)
… I am trying to work this out. By August 18 I would like to go through an ontology for this.

Action Items

acoburn: I don't think we have any action items listed in Github
… Folks have been moving through specific action items on merging or specifying requirements.
… Any action items we should anticipate in the next week?

Continued clarification of requirements

Requirement 21 End-to-End Encryption

acoburn: This is the editor's draft document for UC&R
… We will start with requirement 21 "End-to-end encryption"
… We should ideally finish this next week.
… Not trying to solve any of these issues, but focusing on whether they are in-scope or out-of-scope.

<jeswr> +1

acoburn: On 21 "End-to-end encryption", I think this will probably be out-of-scope from a protocol perspective

<bendm> +1

<laurens> +1

<eBremer> +1

<gibsonf1> +1

<TallTed> +1

Requirement 20 Self-Descriptive and Discoverable APIs

acoburn: Let's move on to 20 "Self Descriptive and Discoverable APIs"

<gibsonf1> +1

acoburn: The protocol document currently has specific focus on discoverability so this will probably be important.

<laurens> +1

<bendm> +1

<eBremer> +1

<jeswr> +1

<TallTed> +1

Requirement 19 Search and Query

acoburn: This is going well so far, so let's move to 19 "Search and Query"
… I want to be careful on this on, we could easily spend the entire meeting on this.

TallTed: It appears that these are straw polls not resolutions.

acoburn: These are indeed straw polls.

acoburn: With query I want to dig in this a little bit, but stay at a high level.

jeswr: I would like to propose that we break this down as follows
… at present Erich and I are working on read and write operations
… And I am working on the authz parts
… I suggest we have a second specification document within the scope of LWS, which supports other types of content negotiation or any type of search that are supported.
… Servers could choose to support or not to support such features.
… These separate specifications could define type indexes, SPARQL, ... .
… I want to straw poll which types of search interfaces should be supported.
… Do we have other search specifications that should be considered?

acoburn: How do we structure this?

jeswr: Let's go through them one by one...
… starting with type indexes.
… Should type indexes be included in the server spec?

gibsonf1: We are using key-value, intersection of sets based querying (cfr. Apache Solr)

<otherJackson> Quick question on type index: would this be as implemented, or could this "some form of type index" be something auto-generated?

acoburn: Should some form of type indexes be supported in the server spec?

<laurens> -1

<jeswr> +0

<acoburn> +1

<gibsonf1> -1

<eBremer> +0

<TallTed> -0.5 (I'm not firmly convinced, but leaning against ... won't impact Virtuoso, as it's built in)

<bendm> +0

jeswr: I would believe such indexes to be managed by the server

<pchampin> +0

<otherJackson> -1

jeswr: There seams to be a slight lean against this option.

acoburn: Should full SPARQL querying be supported in the server spec?

<jeswr> +0.5 (as separate spec document, optional implementation)

<otherJackson> +1 (as long as it's optional and it has auth enforcement)

<acoburn> -1 (as a requirement) +0 (as an optional feature)

<eBremer> +1 (as an option)

<gibsonf1> +0 on Sparql (Sparql is just very complex and too hard for people to learn)

<bendm> +0 (same as jesse, I think the discoverability of those affordances are more important than the actual affordances)

<laurens> -1 (as requirement) +0 (as option)

<TallTed> -0.8 (as requirement, this would substantially lower the implementation count ... won't impact Virtuoso, as it's built in)

<gibsonf1> +1 on optional but not required

<pchampin> -1 (as a requirement) +0 (as an optional feature)

jeswr: Desireable as an optional feature, probably not as a requirement.

acoburn: Do members of the group have other querying interfaces to propose (RDF or non-RDF)?

otherJackson: I think QPF could be another interface to consider
… Additionally have we considered notifications for indexes? While leaving the actual index out-of-spec.

<TallTed> (what is QPF?)

<jeswr> QPF: https://linkeddatafragments.org/specification/quad-pattern-fragments/

acoburn: Quad pattern fragments (or triple pattern fragments) allows for matching against simple patterns in RDF.
… Let's consider solutions at a later point, but leave that separate. There is a topic on inter-user communication which will come later.

jeswr: Should QPF querying be required in the server spec?

<gibsonf1> -1

<dmitriz> QPR - -1 to required, +1 as optional

<acoburn> -1 (as a requirement) +0 (as optional)

<pchampin> -1 (as a requirement) +0 (as an optional feature)

<eBremer> +1 (as an option)

<laurens> +0.5 (as optional feature) -1 (as requirement)

<bendm> +0

<otherJackson> -0.5 to required +1 as optional

<TallTed> -1

acoburn: Leans positive as an optional feature.

acoburn: Let's jump to other kinds of interfaces (like Frederick's suggestion)

jeswr: Does gibsonf1 have an existing specification of such a querying mechanism?

gibsonf1: Looking into it.

<TallTed> (again, QPF won't impact Virtuoso, as it's built in -- https://docs.openlinksw.com/virtuoso/rdfviewquadmapatternsvalueandiriclasses/)

<dmitriz> i read 'optional' as exactly that - extensions, discoverable etc

acoburn: We have been discussing optional and required. But there is also a third option, for features that are optional but could be discovered on a server to server basis.
… How can we make affordances such that implementations can pursue alternative interfaces but still have some interop.

<otherJackson> I feel like option is directly mentioned in the spec, whereas "extension" wouldn't be mentioned.

<gibsonf1> https://solr.apache.org/guide/solr/latest/query-guide/common-query-parameters.html

<dmitriz> @otherJackson - i see, ok. i'll adopt that terminology as well

acoburn: We should be careful about hard bindings to specific implementations.

<Zakim> gibsonf, you wanted to say on query...

gibsonf1: We're not actually using the raw apache solr for the user

<TallTed> Loose coupling is key across the board.

gibsonf1: It is a simplified approach for the user, that is very powerful.
… The backend is using apache, but the frontend is simplified.
… We also have a secondary mechanism (tag search), which allows to find related documents.
… Those are our two basics.
… We have that in production.

<dmitriz> we should have extensible query mechanisms

<otherJackson> -1 to required -0.8 to optional +1 to an "extension" based system with required content negotiation

acoburn: Should there be an affordance for supporting alternative query interfaces in the protocol?

<laurens> +0.5

<gibsonf1> +1

<jeswr> +0.5

<eBremer> +1

<pchampin> +1

<dmitriz> +1 to the _affordance_ / discoverability of any query mechanism

bendm: Unclear what this straw poll is about.

acoburn: This is about the discoverability of the interface, not the interface itself.

<bendm> +1

<acoburn> +1 (for discoverability)

acoburn: When we get into the details of how this requirement is expressed in the protocol, there will be aspects related to pagination, ... that have to be resolved.

otherJackson: Two more things to consider would be (a) support for an easier data dump that doesn't require traversing the hierarchy of resources and (b) (more of a thought) I think we would want some kind of requirement to search and discover things across documents
… Something like QPF or SPARQL would be quite intense to support.
… But having some kind of baseline might be helpful.

<Zakim> gibsonf, you wanted to say, I'm assuming query is not only accross documents but any data and any pods on server

gibsonf1: My idea on search is that this would resolve any data on any pod on that server.

acoburn: I feel like there is a category of bulk operations, but it might be a bad match right now.
… Right now we don't have a lot of clarity on this.
… But it could fit under that heading.

jeswr: I know that eBremer has been working on CRUD interfaces, which could include some of these large file interfaces.

<Zakim> bendm, you wanted to ask about having a listing dump (which could bring the affordance to any kind of index operations)

jeswr: I propose we don't do this in the context of the large file operations, but discuss this separately next week related specifically to CRUD operations.

bendm: I have the feeling we need a requirement to dump the resource listing managed in the storage server.
… That would allow for external indexing and querying.

acoburn: Could you open a PR on the UCR to add that req?

<otherJackson> +1 to Ben's use case on discovering available documents

Requirement 18 Inter-User Communication

acoburn: Let's move to 18 "Inter-User Communication"
… This is about an agent that can subscribe to messages about changes on a set of resources.
… e.g. I want to know about changes on a resource or container.

<TallTed> so more "change tracking" than "inter-user commms"?

acoburn: Change tracking would be one use-case for this.

<gibsonf1> +1 (assuming this is an inbox kind of spec)

acoburn: Unsure if change tracking is sufficiently generic here.

<TallTed> feels like activitypub/activitystreams

jeswr: This should also include changes on auxiliary resources (e.g. comments, ACLs)

<TallTed> "subscribe to (changes to) Doc_X"

<otherJackson> +1 to change tracking

<pchampin> +1 "change tracking" is better than "inter-user com"

<bendm> +1

<laurens> +1 to change tracking

<eBremer> +1

<dmitriz> +1 to change tracking

<jeswr> +1 change tracking

<acoburn> +1 to change tracking

<gibsonf1> +1 change tracke (and +1 on an inbox spec for inter-user comms)

acoburn: This appears to be positive support on this.

<TallTed> +0.8 (certainly, extension/option; not so much about requirement ... and again probably already built in to Virtuoso)

<Zakim> gibsonf, you wanted to say including a results spec in the query very important for large scale

<dmitriz> @TallTed - re "feels like AP/AS2" -- so that could be one of the implementation details / mechanisms, for change tracking.

<dmitriz> @TallTed -- but also of course WebSub

otherJackson: Related but disjoined from change-tracking, but when access controls are changed that agent should be notified. This is distinct from change tracking as the agent could previously not have access to that resource.

<gibsonf1> +1 on making it more than just change-tracking, and an inbox kind of spec to handle all

acoburn: This is something we need to clarify in the specification.
… Or do we need to clarify this now?

Requirement 17 Contextual Access Control

acoburn: Let's move to 17 "Contextual Access Control"

jeswr: There are well known types of access control, currently they are largely role based access control.

<TallTed> so "policy-based access control" or "attribute-based access control", to use more common labels?

jeswr: There is also attribute based access controls, e.g. access grants in ACP specification
… I think that within this group we would want to have actual attributes of the person (e.g. in a VC) to be used.
… For example in the case of age restrictions, the authorization server might check that someone is over 18.
… In addition to role and attribute I think we will also potentially want to support capability delegation (e.g. ZCap).
… The question for the 18th will be, do we want role and attribute based access control potentially with capability delegation.
… Do we want attribute based access control?

<dmitriz> I think the question should be - just like with everything else (query mechanisms, notifications, etc) -- providing affordances for extensible authorization mechanisms

jeswr: Do we want capability delegation (i.e. the authorization server saying that Aaron has the capability to hand out permissions)?

laurens: in WAC/ACP we have discretionary access control. I would not quite call it role based. Attribute access control is complicated and I'd want to clarify role based first

dmitriz: I wanted to propose that instead of discussing which authz mechanism, we should just focus on an extensible, discoverable mechanism.
… And provide affordances.
… We need the extensibility as mechanisms will come and go.

<TallTed> (fwiw ... ABAC is built in for Virtuoso Enterprise, not available for Virtuoso Open Source ... RBAC is built in for both)

pchampin: I am not sure whether there has been enough incubation on this topic in Solid. It may have been incubated in other efforts. I would be mindful of sufficient incubation.

<gibsonf1> +1 on extensible

<Zakim> ryey, you wanted to comment on the extent of / complexity of access control mechanism to be supported in the spec; maybe basic ones + permission delegation as baseline, with extensibility possibility; also on single spec or more

ryey: To what extend do we want to support a complex access control mechanism in v1 of the specification.
… Should the access control mechanism be a secondary specification to the core protocol.
… One practical thing I could think of is to maybe support some basic principals (e.g. role based, group based, ...) and in addition support permission delegation.

<dmitriz> +1 to what ryey says -- separate specs / extension points

acoburn: We are at time.
… I feel like access control will be part of the spec, but we will have to define the scope of it.

<gibsonf1> +1 on base level that all servers comply with for interop

<otherJackson> +1 to certain required specs

<pchampin> +1

<dmitriz> agree, yeah.

acoburn: 15, 16 and 17 should probably be part in some way of the specification?

<eBremer> +1

<bendm> +1 on a bases, yes

<laurens> +0.8 (for the most part)

acoburn: For 14 we should consider if it is a duplicate of inter-user communication.

<TallTed> +1 for LWS as a concept to work, it will require some form of each of those items (which we should be referencing by name, not number)