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

Add W3C Solid CG Charter #323

Merged
merged 28 commits into from
Sep 7, 2023
Merged
Changes from 2 commits
Commits
Show all changes
28 commits
Select commit Hold shift + click to select a range
dec76ee
Add W3C Solid CG Charter
csarven Jul 4, 2023
e71d34d
Apply suggestions from code review
csarven Jul 5, 2023
e069abf
Apply suggestions from code review
csarven Jul 7, 2023
2593f0c
Minor
csarven Jul 7, 2023
790add5
Apply suggestions from code review
csarven Jul 8, 2023
4171fe4
Update solid-cg-charter.md
csarven Jul 8, 2023
2ba5e46
Move Design Principles under Coordination and to follow Recs
csarven Jul 10, 2023
471103e
Add Amendments to this Charter section
csarven Jul 10, 2023
2c2eed7
Add created, modified, version
csarven Jul 10, 2023
7a8cfc5
Add Solid QA towards improving Solid ecosystem and building confidence
csarven Jul 11, 2023
b8f5be1
Apply suggestions from code review
csarven Jul 19, 2023
3a4808a
Replace 'drafts of specifications' with 'work items'
csarven Jul 24, 2023
fbabbca
Refer to W3C Incubation and paraphrase CG focus/aim
csarven Jul 24, 2023
e9341c9
Apply suggestions from code review
csarven Jul 24, 2023
f4324e8
Reference Work Items in Contributing Guide
csarven Jul 26, 2023
68ad182
Remove redundant line: on up to three chairs at any given time
csarven Jul 27, 2023
e4cab8c
Add Vocabularies to Scope
csarven Jul 28, 2023
fafa6ea
Add examples to Federation in Scope
csarven Aug 1, 2023
423d03b
Remove access request/grants - captured by Authn/z in Scope
csarven Aug 1, 2023
1b3ded2
Add clarifications on participants/nominees wrt elections
csarven Aug 1, 2023
837e124
Clarify Scope items
csarven Aug 1, 2023
9cadcc6
Update Modified
csarven Aug 1, 2023
8bb0c90
Add effective date
csarven Aug 1, 2023
2a318a4
Clarify W3C and MIT license use
csarven Aug 10, 2023
8abb7d6
Correct spelling
csarven Aug 10, 2023
7916591
Remove clause on deviations
csarven Sep 5, 2023
ceca2f9
Update License section
csarven Sep 6, 2023
b6145d2
Update modified
csarven Sep 6, 2023
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
170 changes: 170 additions & 0 deletions solid-cg-charter.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,170 @@
# W3C Solid Community Group Charter

csarven marked this conversation as resolved.
Show resolved Hide resolved
The aims of the [Solid project](https://solidproject.org/) are in line with those of the Web itself: empowerment towards "an equitable, informed and interconnected society" [[ethical-web-principles](https://www.w3.org/TR/ethical-web-principles/)]. Solid adds to existing Web standards to realise a space where individuals and communities can maintain their autonomy, control their data and privacy, and choose applications and services to fulfill their needs.

The mission of the [Solid Community Group](https://www.w3.org/groups/cg/solid/) is to explore and describe the interoperability between different classes of products by using Web communication protocols, global identifiers, authentication and authorization mechanisms, data formats and shapes, notifications, and query interfaces.

The group will aim to give authors of technical reports and software implementers confidence that they can rely on the Solid ecosystem to deliver on the promise of interoperability based on open standards.

csarven marked this conversation as resolved.
Show resolved Hide resolved
The task of the group includes drafting and incubating proposed technical specifications for further standardization and prototyping and testing implementations.


csarven marked this conversation as resolved.
Show resolved Hide resolved
csarven marked this conversation as resolved.
Show resolved Hide resolved
## Scope

In general, topics that are “in scope” include anything related to enabling affordances for decentralised Web applications to create and use data across decentralised storages in a way that is secure and privacy respecting for individuals and communities. Work items are intended to be compatible with or extend the [Architecture of the World Wide Web](https://www.w3.org/TR/webarch/). These topics include, but not limited to, the following:

* Protocols for the storage, transmission and portability of data.
* Authentication and authorization mechanisms.
* Notifications.
* Query interfaces.
* Data models that can be used in storages, e.g., policies, data privacy and rights, provenance records and auditing, error messages.
* Profile descriptions for social and software agents.
* Registering and finding data.
* Data shapes.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As mentioned during yesterdays CG call, I believe these two points would be better covered under a single broader point "Data interoperability".

Copy link
Contributor

@woutermont woutermont Jul 27, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
* Registering and finding data.
* Data shapes.
* Data interoperability: shared semantics of content (shapes) and actions (service descriptions).

EDIT: updated to include a more concrete description

csarven marked this conversation as resolved.
Show resolved Hide resolved
* Access requests and grants.
csarven marked this conversation as resolved.
Show resolved Hide resolved
* Signing messages.
* Federation.
csarven marked this conversation as resolved.
Show resolved Hide resolved
* Evaluation tools (software programs or online services) that help determine implementation conformance.
* Publishing test reports and communicating the level of adoption of technical reports.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would there be also for the UI layer metadata. As in a way to allow implementation of a view without forcing a library, yet allowing one implementation that we can replace. The metadata be used in either case. (Hoping that makes sense. Unsure if that's the same as "Autonomous Web Agent")

Copy link
Member Author

@csarven csarven Jul 24, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I want to understand better, can you please elaborate? Perhaps a few use cases? There is some UI work in SolidOS that seems to be related to what you're saying. See also An ontology for User Interface description, Hints and Forms . I wonder if we should boost this more into the Scope. It generally has to do with what some refer to "client-client" specifications but we can be more specific on the UI aspect. Will raise this in an upcoming CG call to check with everyone in the meantime.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would there be also for the UI layer metadata. As in a way to allow implementation of a view without forcing a library, yet allowing one implementation that we can replace. The metadata be used in either case. (Hoping that makes sense. Unsure if that's the same as "Autonomous Web Agent")

@renoirb, I'm going to interpret some of your words; please tell me if I'm right or not.

Your question concerns some agent (I suppose some application) which would use certain metadata (about a resource) that should be sufficient to render a UI display (of that resource) without relying on some proprietary library (i.e. other than a general library for interpreting that metadata). The question then is whether the CG scope includes looking into this metadata. Is this correct?

My questions to you would then be:

  • Do you suppose this would require other metadata than that which describes what kind of resource we are talking about?

  • Can I suggest that we bring this together with data shapes and other datatype-describing-vocabulary under the denominator of 'application interoperability'?

Copy link

@renoirb renoirb Jul 26, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm probably stating the obvious. It's probably out of scope, and I guess that's the point to ask here if this can/can't be part of this.


In any situation, an implementation of a pod (e.g. Inrupt‘s Community Solid Server "CSS", or another). will most probability also have a UI alongside the programmatic data centric HTTP API. In that API there's to say what to get, and some description of what's also possible and error messages and etc.

The human readable messages be probably in a language we can configure. Probably with locale, TimeZone, what text for an identifier, and etc.

Inrupt's CSS has ways to tell where the templates are (<aside >I haven't figured out how to actually do it, the examples in docs doesn't complete how to</aside>) it's using a templating engine, etc.

I'm wondering if we could have another HTTP API context root for the backend for the FrontEnd.

We could have a way to describe how to present the lists of things, and available actions stored into the pod. It's typically lists of objects, the properties (e.g. creation date, mime-type, etc.) for each of them, actions (e.g. delete, etc.) that are different based on the context of each of them (e.g. a directory with current user having right to write can upload a file vs a file you can write on would have a "replace" action).

All that logic can quickly be deeply embedded into the UI layer and hard to separate and then limits people when making it their own. We see that often in Microsoft SharePoint, we can't theme absolutely everything. — it's complex.

What if we had a way to describe collections of view descriptions.

The description doesn't contain the objects themselves only a blueprint, not the info specific to the current user (e.g. locale, calendar, TimeZone, etc)

The descriptions could be for things like:

  • a list of items to display for one object: (1) in a "date" component, use format "short", use property "CreatedAt" property for the value (the locale and calendar, and TimeZone be stored elsewhere, not here). (2) in a "file-type" component, use properties.

(I'll have to come back to continue writing this) Continued here

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The charter has a list of topics that are clearly in scope, as well as those which are out of scope. I think everything which isn't listed as out of scope is a good fit to be proposed using New Work Item workflow.
I don't see anything related to UI metadata listed as out of scope, which means that you should be able to simply propose your idea as a new work item.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As you describe it now, it feels much closer to Service Descriptions again. I would urge to look into those (they have some very basic but easy to grasp examples on the website of RESTdesc). Since they can be extended with any RDF statements about some resource/service, the descriptions can be made very elaborate.

E.g. you could easily define

  • that if you POST a resource with an rdfs:label, and an rdfs:description to /things/, they would be stored as an owl:Thing, and that the response would have it's URI in the Location header;
  • that if you POST anything else, the request will fail in a certain way;
  • that if you GET the URI of such an owl:Thing, e.g. /things/0123, with either text/turtle or application/ld+json as a Content-Type header, this would result in a response of the correct format, with the original data in the body, as well as a dc:date stating the date of creation, conforming to a specific date format;
  • that if you would perform a GET request on /things/ itself, you would receive a body that instead holds only the rdfs:label of every owl:Thing, and the dc:date but possibly in another format; etc.

And that is just for reading and writing simple resources; all kinds of form interaction and side effects could also be described.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What I'm mostly trying to get at is that, if it's really not about display/style, but about the semantics of resources and actions on them, this is already clearly present in the scope as data interoperability; but that if this is not enough, we should maybe add something or leave you to propose something as a new work item. 🙂

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll do some reading. Probably read more about RESTdesc, Hydra, etc. I'll write something somewhere to reorganize this, and see.

I'll go through the new work process once I have more notes and see to use the mentioned technologies.

what if it's just me mapping what I'm trying to say, and what I've just been exposed to. Thanks.

In any case. W.r.t. scope and incubation. I might be able to make a PoC using the mechanics.

Copy link

@renoirb renoirb Jul 27, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One thing though. I make distinction between the data from a description of assembly of that data.

But describing a schema, making sure an entry matches the model is neat though! If that data is a description, just data, regardless of what's there, that's a possibility.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The following Scope item covers a bit of the needs discussed here:

Data models that can be used in storages, e.g., policies, data privacy and rights, provenance records and auditing, error messages.

(See also e.g., structured error messages, service/storage description and use cases therein).

And we can add more to the listed examples there. Perhaps "actions"?

That aside, it'd be useful to revisit emphasis on class of work towards building smart(er) clients (Application, UI) in Solid that says a bit more than vocabs/data models/shapes/service descriptions/client-client. I'm in favour of a specific Scope item capturing "UI" or "Application". (Ditto what can capture for example the UI ontology). I find the term "Interoperability" too broad - after all, all these efforts are towards interop. But, interop between what and what product as far as conformance is concerned? (see Solid QA work). Variability in Specifications for instance generally mentions classes of products like Consumer/Player/Processor which may be closely related here.

I made an imperfect suggestion here https://github.com/solid/process/pull/323/files#r1277302683 , please review and suggestions towards what's intended if it is not adequate.


I suggest that we resolve this discussion soon. It is a touch too much into the weeds and perhaps we can use the solid/specification chat to continue the discussion and then propose changes here or make suggestions that can generally capture the related material.


csarven marked this conversation as resolved.
Show resolved Hide resolved
With the exception of integrating or bridging specifications developed by another active community in an open standards development body that specialises in a particular topic, the Solid Community Group defer the work to the other community.


### Out of Scope

In general, topics that are “out of scope” involve anything not directly related to the above. Some examples of these are listed here:
csarven marked this conversation as resolved.
Show resolved Hide resolved

* The relative merits of various economic, political, or sociological theories.
* Marketing or evangelizing of technologies not intended to be released under a license compatible with W3C specifications. Discussion of out-of-scope solutions should be limited to elaborating upon technological advantages/disadvantages.

csarven marked this conversation as resolved.
Show resolved Hide resolved

## Work Items

The Community Group current work items are listed at [Solid Technical Reports](https://solidproject.org/TR/).

In general, all documents in scope of the group are welcome. If there are individuals who will commit to being editors for a document, the group should agree to accept it as a work item even if it conflicts with previous work adopted by the community. Newly-accepted work items that extend beyond the scope of this Community Group Charter will lead to a reconsideration of the Charter. The Community Group may vote to revise the Charter in order to include new work, or to determine that the proposed work is unrelated.

### New Work Item Proposal

* Propose topic to the group in a meeting.
* Include publicly access link to abstract or draft.
* List and link to owners (at least 1 person for advancing the work item and 1 other person).
* Answer the following questions in order to document how you are meeting the requirements for a new work item at the W3C Solid Community Group. Please note if this work item supports certain programs or another government or private sector project.
1. Explain what you are trying to do using no jargon or acronyms.
2. How is it done today, and what are the limits of the current practice?
3. What is new in your approach and why do you think it will be successful?
4. How are you involving participants from multiple skill sets and global locations in this work item? (Skill sets: technical, design, product, marketing, anthropological, and UX. Global locations: Africa, the Americas, APAC, Europe, Middle East.)
5. What actions are you taking to make this work item accessible to a non-technical audience?
csarven marked this conversation as resolved.
Show resolved Hide resolved


## Coordination

The group will make good faith efforts to include the following communities in the progress of our work.

csarven marked this conversation as resolved.
Show resolved Hide resolved
* [Autonomous Agents on the Web Community Group](https://www.w3.org/groups/cg/webagents)
* [Credentials Community Group](https://www.w3.org/groups/cg/credentials)
* [Data Protection Vocabularies and Controls Community Group](https://www.w3.org/groups/cg/dpvcg)
csarven marked this conversation as resolved.
Show resolved Hide resolved
* [Decentralized Identifier Working Group](https://www.w3.org/groups/wg/did)
* [LDP Next Community Group](https://www.w3.org/groups/cg/ldpnext)
* [Notation 3 (N3) Community Group](https://www.w3.org/groups/cg/n3-dev)
* [ODRL Community Group](https://www.w3.org/groups/cg/odrl)
* [RDF-DEV Community Group](https://www.w3.org/groups/cg/rdf-dev)
* [RDF-star Working Group](https://www.w3.org/groups/wg/rdf-star)
* [Social Web Incubator Community Group](https://www.w3.org/groups/cg/socialcg)
* [Verifiable Credentials Working Group](https://www.w3.org/groups/wg/vc)
* [WebID Community Group](https://www.w3.org/groups/cg/webid)
* [Web Platform Incubator Community Group](https://www.w3.org/groups/cg/wicg)
* [Web of Things Working Group](https://www.w3.org/groups/wg/wot)

The group expects to follow the following W3C Recommendations, Guidelines, and Notes, and, if necessary, to liaise with the communities behind them:

* [Architecture of the World Wide Web, Volume I](https://www.w3.org/TR/webarch/)
* [Internationalization Technical Reports and Notes](http://www.w3.org/International/publications)
* [QA Framework: Specification Guidelines](http://www.w3.org/TR/qaframe-spec/)


## Participation

The group encourages questions, comments and issues on its public mailing lists and document repositories, as described in [Communication](#Communication)

The [Solid Technical Reports Contributing Guide](https://github.com/solid/specification/blob/main/CONTRIBUTING.md) is available to all members of the group that would like to make substantive contributions.
csarven marked this conversation as resolved.
Show resolved Hide resolved


## Communication

Technical discussions for this Community Group are conducted in public: the meeting minutes from teleconference and face-to-face meetings will be archived for public review, and technical discussions and issue tracking will be conducted in a manner that can be both read and written to by the general public. Drafts of specifications will be developed in public repositories and may permit direct public contribution requests. The meetings themselves are open to public participation.
jaxoncreed marked this conversation as resolved.
Show resolved Hide resolved

Most Solid Community Group teleconferences will focus on discussion of particular specifications and QA work, and will be conducted on an as-needed basis.

This group primarily conducts its technical work through:
* GitHub repositories, e.g., https://github.com/solid/specification
* Teleconference: https://meet.jit.si/solid-cg
* Ad-hoc discussions and coordination: https://matrix.to/#/#solid_specification:gitter.im

The public mailing list public-solid@w3.org may be used for general discussions and announcements.


## Decision Policy

To afford asynchronous decisions and organizational deliberation, any resolution (including publication decisions) taken in a face-to-face meeting or teleconference will be considered provisional. A call for consensus (CfC) will be issued for all resolutions (for example, via email, GitHub issue or web-based survey), with a response period from five to ten working days, depending on the chair's evaluation of the group consensus on the issue. If no objections are raised by the end of the response period, the resolution will be considered to have consensus as a resolution of the Community Group.
csarven marked this conversation as resolved.
Show resolved Hide resolved

All decisions made by the group should be considered resolved unless and until new information becomes available or unless reopened at the discretion of the Chairs.

This charter is written in accordance with the [W3C Process Document (Section 5.2.3, Deciding by Vote)](https://www.w3.org/Consortium/Process/#Votes) and includes no voting procedures beyond what the Process Document requires.


## License

The group will use the MIT license for all its work items.
csarven marked this conversation as resolved.
Show resolved Hide resolved
csarven marked this conversation as resolved.
Show resolved Hide resolved


## Community Group Process

Anything in this charter that conflicts with requirements of the [Community and Business Group Process](http://www.w3.org/community/about/agreements/) is void.

Unless otherwise stated, the Community Group will follow or aim to be compatible with the [W3C Process](https://www.w3.org/Consortium/Process/).

### Membership and Voting Rights

A general member of the Community Group can be an individual or a member on behalf of an organization. Consistent with W3C rules, in order to formally join the Community Group, a member must have a W3C account and push the “Join” button for the Community Group. However, W3C membership is not required to have a W3C account nor to join the Community Group.

Any member of the Community Group who has also accepted the [W3C Community Contributor License Agreement](https://www.w3.org/community/about/process/cla/) (CLA) as part of the enrollment process is eligible to vote on elections, charter amendments, and other community matters so long as they have completed enrollment by the date that the chairs announce those events to the public mailing list.

The Chairs will determine the list of eligible voting members as of the record date. The Chairs will make the list available to the Community Group two weeks before every election that requires voting members to be carefully identified, and the list will be verified by a third party such as a member of W3C staff or a neutral community member for which there are no strong objections. If the voting list is not ready, then the election date will be moved until two weeks after it is ready. If the third party has reasonable objections, the election will be delayed until two weeks after such objections are resolved.

### Chairs

The [role of the Chair](https://www.w3.org/Guide/chair/role.html) is described in the [Art of Consensus](https://www.w3.org/Guide/).

The Community Group members appoints (and re-appoints) Chairs for the group.
csarven marked this conversation as resolved.
Show resolved Hide resolved

The chair and the W3C Team Contact of the group SHOULD NOT be the same individual.

Participation as Chair afforded to the specific individuals elected or appointed to those positions, and a participant’s seat MUST NOT be delegated to any other person.

For most Chair nominees, the primary affiliation is their employer and will match their affiliation in the W3C database. For contractors and independents, this will normally be their contracting company or their independent status; in some cases (e.g. where a consultant is consulting for only one organization) this may be the organization for whom the nominee is consulting.

csarven marked this conversation as resolved.
Show resolved Hide resolved
#### Choosing a Chair

* At any given time there may be up to three co-chairs, each holding one seat. Each seat defines a 2 year cycle of service.
* In the first election after ratification of this charter, all seats will be up for election. Thereafter, in each year, a single election will be held to fill any vacant seats.
* In the case of interim vacancy, the remaining chairs may appoint a co-chair for each open seat, hold an election for the same, or wait until the next election, at their discretion. If the chairs do not take any action, the seat will automatically be up for election in any cycle. Any such interim appointments or elections shall hold the seat until the end of its natural cycle.
* There may be up to three Chairs at any given time. Reelection is restricted to two consecutive terms, with the possibility of being reelected after sitting out one election cycle.
* In an election year, current chairs will select a date for elections, which will set a nomination period of two weeks, starting 4 weeks prior to the election.
* For an individual to run for election, they must self-nominate and make a statement regarding their background and why they are running, on the group mailing list.
* The current chairs will host a conference call during the nomination period, during which candidates may make a statement and answer questions from the community.
* If, at the end of nominations, any given seat only has a single candidate, that candidate immediately wins that seat. For any seats with multiple nominees, there will be an election for those seats.
* If, after nominations, any given seat has no candidates, the remaining chairs after any election (if necessary for other seats), will address the vacancy as an interim vacancy, described above.
* To elect one of multiple candidates, a vote will be held by the election mechanism of ranked choice voting, in which voters rank candidates by preference on their ballots. The candidate with the majority (more than 50%) of first-choice votes wins outright. If no candidate gets a majority of first-choice votes, the candidate who ranked the worst is eliminated, and that candidate’s voters’ ballots are redistributed to their second-choice pick. If the vote results in a tie, an immediate runoff of the top two candidates shall be held. If the vote remains tied, the winner shall be the candidate whose nomination was first recorded publicly on the group email list.

#### Removing a Chair

* Chairs may be removed from their duties through a no-confidence vote.
* If a member of the community group wishes to call for the recall of a chair–for any reason–that member must first privately communicate with the other chairs their desire and reason for doing so. Those chairs must give the member an opportunity to discuss their concerns with a goal of resolving them. If, after 30 days, the member feels their issues are not addressed, they may then escalate to a public call for a no confidence vote. If after 60 days, the member has not made that call for a no confidence vote, the matter is dropped; any further attempts to remove the chair in question must begin with a new round of private communication.
* A public call for no confidence must be announced to the group email list stating the name of the chair subject to the recall and the names and emails of at least 3 members of the group who thereby call for a recall. This announcement must come from the member who initiated the private communication with the chairs to discuss their concerns. The other two supporting members MUST reply to that email on the public list within 48 hours to confirm their support for a no-confidence vote of the chair in question.
* The other chairs must acknowledge the call for no confidence within 7 days of all three members declaring their support.
* Within 30 days of a call for no confidence, the other chairs must hold a conference call at which the parties seeking no confidence will have an opportunity to present their case and members of the group will be able to ask clarifying questions. The chair in question shall not moderate this call. They will, however, have equal time to respond during that same call to the case made against them.
* During the week following this conference call, members may cast votes in favor or against the recall by posting to the email list. If affirmative votes cast that week (in favor of recall) comprise greater than two-thirds of the total votes cast, then the chair in question is removed and the seat shall be treated as an interim vacancy.
* Members are not required to vote. Abstentions may be recorded; such abstentions shall not count towards the total number of votes when calculating the two-thirds majority.
csarven marked this conversation as resolved.
Show resolved Hide resolved
* A Chair who has been removed may stand for re-election.
* Only one call for no-confidence, for one chair, may be in process at any given time. Priority shall be given to the first such vote to be publicly called. Any subsequent public calls must wait until any previous recalls are resolved, then must start with private communication as described above.
csarven marked this conversation as resolved.
Show resolved Hide resolved