Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider revising Introduction #13

Open
csarven opened this issue Mar 28, 2023 · 0 comments
Open

Consider revising Introduction #13

csarven opened this issue Mar 28, 2023 · 0 comments

Comments

@csarven
Copy link
Member

csarven commented Mar 28, 2023

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.

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}).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant