Some feedback on the Introduction section. I break it down here but it can be taken it as a whole to consider paraphrasing. I'm reviewing this (and other issues) based on how it comes across, and not making judgements about how it should work.
In the Solid ecosystem, storages and clients are loosely coupled.
Perhaps applications instead of clients? Client could be the user agent but I don't think that's what's intended in this specification. Hence, consider linking to or defining terms under Terminology/Definitions.
This means clients are tight to data models.
At this point it seems it should be clear that it is talking about applications as opposed to clients interacting with servers/storages. "Tight" seems a bit strange here. Storages and clients are loosely coupled, and clients are tightly coupled with data models? Another angle to approach this is to express that applications use domain-specific data models.
Furthermore, clients and thus storages should be able to be connected in a network of knowledge. The connection is only achievable if the data itself is easy to be interconnected.
Would introducing terms like data "discovery", "navigation", or "use" by applications would clarify?
This specification is written for Solid application developers as a solution that shows how to interconnect clients and data on storages.
I find this sentence narrowing on what's intended here. Consider replacing interconnect with more specific terms.
This specification details the use of Type Indexes which were implemented already in different clients.
This sentences should be omitted or replaced by something more significant to prove that there has been some incubation or adoption. For instance, if there are implementations, link to an index of them, or link to implementation reports along with a test suite. (We'll revisit this point.)
Type Indexes offer a fine-grained approach to describing the location of specific types of resources on a storage.
Okay.
This specification is accompanied with shape documents, [SHACL] and [ShEx], to help developers improve their implementations and maximize the promise of interconnected data.
Okay. Link to sections that introduce the shapes in the document or come back to linking to shapes directly. (Follow up with https://github.com/solid/shapes and publications at https://www.w3.org/ns/solid/shapes/{shortname}).
Re #introduction
Some feedback on the Introduction section. I break it down here but it can be taken it as a whole to consider paraphrasing. I'm reviewing this (and other issues) based on how it comes across, and not making judgements about how it should work.
Perhaps applications instead of clients? Client could be the user agent but I don't think that's what's intended in this specification. Hence, consider linking to or defining terms under Terminology/Definitions.
At this point it seems it should be clear that it is talking about applications as opposed to clients interacting with servers/storages. "Tight" seems a bit strange here. Storages and clients are loosely coupled, and clients are tightly coupled with data models? Another angle to approach this is to express that applications use domain-specific data models.
Would introducing terms like data "discovery", "navigation", or "use" by applications would clarify?
I find this sentence narrowing on what's intended here. Consider replacing interconnect with more specific terms.
This sentences should be omitted or replaced by something more significant to prove that there has been some incubation or adoption. For instance, if there are implementations, link to an index of them, or link to implementation reports along with a test suite. (We'll revisit this point.)
Okay.
Okay. Link to sections that introduce the shapes in the document or come back to linking to shapes directly. (Follow up with https://github.com/solid/shapes and publications at
https://www.w3.org/ns/solid/shapes/{shortname}).