Review Comment:
Paper summary
The paper presents the "Community Solid Server (CSS)" as a modular implementation of the Solid Protocol.
First, in the introduction, the authors explain the problem of siloed personal data, and how Solid [sic] is aiming to provide a solution to that problem. CSS is mentioned towards the end of the introduction as a tool to support research and development of Solid specifications; to be presented in the paper at hand.
Next, in the related work section, the authors provide an overview of preliminaries on access controlled HTTP requests and the specification of the Solid Protocol. Existing other implementations of the Solid Protocol are mentioned.
Then, use cases for CSS are briefly outlined.
Following the use cases, requirements for the CSS are described.
For the CSS architecture, the authors proceed to present the main abstract components as well as a walkthrough of a HTTP request sequence in the CSS.
Next, configuration of the CSS is briefly explained as relying on the dependency injection framework Components.js, where code components are represented as RDF classes, then interlinked and thereby extensible and exchangeable.
Then, the authors address sustainability, usage and impact of the CSS:
For usage, the authors provide details from the CSS Github repository.
Claiming (community) impact, the authors provide a short list of Github repositories that use CSS in their work.
For (use case) impact, the authors describe how the modularity of the CSS configuration and architecture provide a solution for the outlined use cases.
For sustainability, the authors explain the employed test strategy and feedback they provided to the community, claiming community impact.
The authors provide pointers to available documentation, tutorials and supporting tools to help new users of the CSS.
Finally the authors conclude, summarizing the contents of the paper.
---
Strong points
- The presented tool seems very useful (and indeed is by my experience).
- The presented tool seems well documented and thus usable by new users (also according to my observation).
- The presented tool had a positive community impact (also according to my observation).
Weak points
- The paper does not clearly define terminology that is used throughout the paper.
- The paper does not clearly establish connections between the contents of single sections (e.g. sections 3 and 4, or sections 5 and 6).
- The paper does not clearly delineate what is "just" implementation of the Solid Protocol and what are (software) architectural design choices to provide the tool's main value.
---
Overall impression and general comments
The presented tool seems to be useful to and well regarded in the community.
The submitted paper therefore seems valuable to the community.
Considering the current state of the paper, however, I need to recommend a major revision for the paper to match the high quality of the presented tool.
Nonetheless, I highly encourage the authors to further work on this valuable paper!
The paper could be improved by focusing on what value the CSS provides that other implementations of the Solid Protocol do not provide.
While the paper's title indicates the unique selling point of the CSS, vast parts of the CSS functionality/capability description are defined by the Solid Protocol.
Therefore, a reader unfamiliar with the Solid Protocol is hardly able to distinguish what the CSS provides and what is simply implementation of specification.
To offer some guidance on what I would have expected:
The CSS is (A) an implementation of the Solid Protocol but most importantly (B) implemented in a dauntingly modular fashion.
For a tools report presenting CSS, (A) can be covered in a Preliminaries section, and checked off the list. (There are other implementations of the Solid Protocol, CSS is not special here.) (B), however, is the unique selling point of the CSS.
The tool's architecture description may center around explaining what design decisions, abstractions and other means make the CSS so modular.
So, rather than explaining that the CSS indeed implements the Solid Protocol, I encourage the authors to explain how the CSS is made so modular to support research and development as this is the premise of the paper.
Before commenting on the paper's structure, I would like to ask the authors to consider defining and delineating the terms "Solid", "Solid ecosystem", "Solid Protocol", "Solid Project" in the context of the paper. Which ones of those are interchangeable?
Similarly, I would encourage the authors to clearly define terminology used throughout the paper.
For example, what exactly is a "server", "resource", "Solid Pod" (never been introduced), "Solid server" and so on. While some terms are roughly explained, I am unsure if this is enough for a reader unfamiliar with the Solid Protocol to understand this paper.
For the paper structure, I would like to ask the authors to consider re-structuring the beginning of the paper:
1. The introduction does not seem to introduce the tool to be presented but instead presents preliminaries on the Solid ecosystem.
As a reader, I would have expected to learn about
- the problem which the tool addresses
- why is it interesting/important to solve that problem?
- what makes the problem non-trivial
- if there are previous solutions, what is wrong with the others / what is the tool offering over the others?
- what are the components is the tool composed of / what is the design approach
- are there any limitations?
Information on what the Solid Project tries to achieve could be placed in a Preliminaries section.
2. The authors may want to consider moving section 2.1 and 2.2 into a Preliminaries section. Sections 2.1 and 2.2 are not only related, they are fundamentals as are directly implemented in the CSS.
I would then suggest to first describe the specifications (identification, authentication, authorization, data operation), and then explaining a UML sequence diagram of an HTTP request. To this end, the authors might want to consider combining 2.1 and 5.2 (extracting common Solid Protocol elements to that section).
This would give section 5.2 more space to further explain the modularity in implementing the already presented details. Some of these details are already present, e.g. ResourceStore, DataAccessor and the details on content-negotiation.
For related work, are there other tools/systems reports that are similar to this work?
Maybe using other technologies, but also for the purpose of easing R&D efforts?
3. The use cases read like artificial user stories. The authors could improve this section by shortly describing how these use cases were created, collected and evaluated.
4. The text indicates that the requirements follow from the use cases. The section could be improved by providing a mapping between the presented use cases and the presented requirements. Otherwise, both read detached from each other and seem standalone.
5. The authors could improve the architecture section by explaining how their software design choices result in the claimed modularity.
Instead of focusing on a request sequence, which is well defined by the Solid Protocol, the authors could present a UML component diagram of the server, explaining interfaces that allow for the claimed modularity. In addition, the authors could explain particular design choices in their implementation that are not just trivially implementing the standard.
For example, I recall that CSS relies on concepts such as "waterfall handler" or "parallel initialiser", mentioned in the architecture documentation (https://communitysolidserver.github.io/CommunitySolidServer/latest/archi...).
6. I see two parts in this configuration section: First an introduction to Components.js, which could also be a short section in a preliminaries chapter. And second a description, what the choice of Components.js entails for the modularity / flexibility of the CSS. Which I think was sufficiently well explained.
As in Figure 1 the components of the CSS are listed, I would have expected in Section 5 to see a UML diagram that presents these components and how they relate to each other in the architecture.
7. Sustainability, Usage & Impact. The authors could improve this section by shortly explaining how sustainability is defined in the context of this paper.
While the authors outline current usage of the CSS within the community, do the authors know of any projects or institutions using the CSS for R&D purposes as outlined?
Overall, I appreciate the paper for the presentation of the CSS, a valuable tool for the Solid Community. I highly encourage the authors to continue improving the presentation in the paper to match the high quality of the software!
---
Detailed comments (expanding on the general comments from above)
0. Abstract
Summarizing the abstract:
Solid Protocol
- implementations exist
- ecosystem is evolving (comment: why ecosystem? why not protocol? specification?)
- therefore, need for implementation that enables research in features
setting up quickly varying development environments
CSS
- modular server
- with pre-defined configurations
- supports custom configuration
Goal of the server: evolve specification, support research into Solid specifications
As a reader, I would like to know as quickly as possible what the tool tries to accomplish.
Suggestion: Put the goal of the server towards the beginning of the abstract.
1. Introduction
Questions
1.)
- Despite this being a tools report, I would have expected some references for the claims stated in the beginning of the introduction.
- "a considerable challenge for newcomers trying to establish themselves in a particular sector" - how do the authors address this challenge with the tool? Why is this a problem the authors consider?
- recent legislative changes - which ones do the authors refer to?
- "tangible benefits from data sharing" - such as?
the idea described here is that users would share their data with services of high (enough) quality
but if users are required to share their data to use the service in the first place, what is the tangible benefit?
How does the tool relate to or have an impact on this vision?
- Description of the "Solid ecosystem" seems very detached from the first part of the introduction.
- Description of the "Solid ecosystem" mingles description what "open standards" mean and what the core idea of the Solid Protocol (decoupling identity, data, and application) entails, e.g. client's should be seen as views and controls over data. Which is also just an opinion and not defined as such in the Solid Protocol.
2. Related Work
2.1)
This section could benefit from a clear definition of terms used throughout the paper.
After having read this section, I am unsure what the definition of "server" is. (just a HTTP server, a Solid Pod, a Solid Pod server, an OpenID Provider, ...). The term "server" is used throughout the paper.
While I see the benefit of a high-level description of the client-server interaction, I wonder if the client-server interaction following the Solid Protocol is that much different from other client-server interaction that includes authentication, authorization and data access.
Perhaps the description of the protocol flow could be placed after the description of the Solid Protocol, allowing to reference the specifications from the flow description?
Questions
2.1)
- "client–server contract" The term contract seems ambiguous in this context. What kind of contract are the authors referring to? legal contract, smart contract, ...
2.1.1)
- "One suggested solution ..." suggested where?
- "WebIDs [4], which are Linked Data resources that uniquely identify ..."
should be: WebID, a HTTP URI that identifies an agent
- the roles involved in the protocol described in 2.1.2 are mentioned but not defined / clearly described in advance
- what is an identity provider?
- what is a Solid server?
- what is a Solid pod?
- what is a server?
2.1.2)
- The wording is a bit ambiguous in this section. In particular, it reads as "for each request to a Solid server". This would then entail that each time a client requests data from a Pod, the user needs to authenticate at an IDP.
2.2.1)
- The second paragraph of this section is what I would have expected to read in the introduction.
2.2.2)
- "it defines specific semantics for [...] interacting with containers of resources. Containers are resources that group other resources together by providing RDF descriptions with containment triples" how is this different from an LDP Basic Container?
2.2.3)
- "The Solid-OIDC specification [7] defines everything related to authenticating with Solid." is an incorrect statement. The Solid Protocol defines everything that may or may not be used for authenticating according to the Solid Protocol. While Solid-OIDC is the current normative specification for authentication in the Solid Protocol, WebID-TLS is an additional non-normative specification that defines an additional authentication method. Moreover, as the authors dove into the "history" of the Solid Protocol in 2.2.1, WebID-TLS once was the normative specification to implement authentication for the Solid Protocol.
2.3)
- "What about ..."
- GoLD? (https://github.com/linkeddata/gold)
- the Nextcloud plugin? (https://github.com/pdsinterop/solid-nextcloud)
- the PHP one? (https://github.com/pdsinterop/php-solid-server)
- Manas? (https://github.com/manomayam/manas)
3. Use Cases
- "In this section we will cover several use cases that give an overview of several use cases we wanted to support by creating a new server." there seems to be a doubling in wording?
3.1)
- "to inform future spec changes" - while the term "spec" is very common in the community, it is an informal abbreviation of the term specification. I would suggest using the formal wording in the paper.
3.4)
- The description lacks clarity regarding what the server should offer to the researchers to satisfy the use case.
4. Requirements
4.1) - How is this requirement distilled from the use cases?
4.2) - The authors could improve this paragraph by delineating it from Requirement 4.4. Is this requirement actually about versioning of different states of implementation and specification?
4.3)
- Clarity of the overall paper could be improved by providing precise descriptions of the terms and roles involved in the Solid Protocol in a dedicated section (as mentioned earlier):
"Multiple servers are involved in a Solid-based interaction: the pod server handles the core Solid protocol, and the OpenID Provider provides OIDC authentication."
- The authors could improve this paragraph by elaborating how the requirement of "supporting multiple server roles" would "allow[s] any part of the set of Solid specifications to be investigated and experimented with, not just a subset of it". This sounds to me more like a "implement everything" requirement.
5. Architecture
5.1.2) "The full of the request is reconstructed" somehow, there seems to be a link at the 'o' of the 'of'.
5.2)
- In which way is this special to the CSS? How is this different from a usual implementation of the Solid Protocol?
5.2.4)
- "The first store uses ..." What about the other stores?
- "Content negotiation" - this is the style I was expecting: Clearly explained design choices particular to the presented implementation.
In contrast to: "POST only works when targeting a container." which is clearly defined in the Solid Protocol.
6. Configuration
- Maybe the authors could add a section explaining the nature of linking that the configurations do, give an example on what that means?
7. Sustainability, Usage & Impact
7.1) Sustainability
- The authors could improve this section by defining the term sustainability in the context of this work.
- The authors could improve this section by explaining how their test strategy contributes to the sustainability of the tool. In addition,
7.2) Use case impact
- The authors may want to consider renaming this section. I am unsure if impact is a suitable word here.
- In 7.2.3: "We want to support" Do the authors mean "A researcher wants to ..."?
|