├── .github ├── CODEOWNER └── workflows │ └── lint_and_test.yml ├── .gitignore ├── CODE_OF_CONDUCT.md ├── CONTRIBUTING.md ├── Cargo.toml ├── Charter.md ├── LICENSE.md ├── README.md ├── dummy ├── Cargo.toml └── src │ └── lib.rs └── w3c.json /.github/CODEOWNER: -------------------------------------------------------------------------------- 1 | # The charter (/Charter.md) of the community groups (CG) defines the rules encoded below. 2 | # 3 | # See https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners#example-of-a-codeowners-file 4 | # for an example of the CODEOWNERS file syntax. 5 | 6 | # CG chairs own the whole repository -- and in particular of the CODEOWNERS file itself. 7 | * @pchampin @Tpt 8 | 9 | # Owners of the /dummy work-item 10 | /dummy @pchampin @Tpt # ... 11 | 12 | # Owners of another work item 13 | # ... 14 | -------------------------------------------------------------------------------- /.github/workflows/lint_and_test.yml: -------------------------------------------------------------------------------- 1 | name: Lint and Test 2 | 3 | on: [push, pull_request] 4 | 5 | jobs: 6 | fmt: 7 | name: fmt 8 | runs-on: ubuntu-latest 9 | steps: 10 | - uses: dtolnay/rust-toolchain@stable 11 | with: 12 | components: rustfmt 13 | - uses: actions/checkout@v4 14 | - run: cargo fmt -- --check 15 | 16 | clippy: 17 | name: clippy 18 | runs-on: ubuntu-latest 19 | steps: 20 | - uses: dtolnay/rust-toolchain@stable 21 | with: 22 | components: clippy 23 | - uses: actions/checkout@v4 24 | - run: cargo clippy --all --all-targets --all-features 25 | 26 | test: 27 | runs-on: ubuntu-latest 28 | steps: 29 | - uses: dtolnay/rust-toolchain@stable 30 | - uses: actions/checkout@v4 31 | with: 32 | submodules: true 33 | - run: cargo build --all-features 34 | - run: cargo test --verbose --all --all-features 35 | env: 36 | RUST_BACKTRACE: 1 37 | 38 | typos: 39 | runs-on: ubuntu-latest 40 | steps: 41 | - uses: actions/checkout@v4 42 | - uses: crate-ci/typos@master 43 | -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | Cargo.lock 2 | target 3 | -------------------------------------------------------------------------------- /CODE_OF_CONDUCT.md: -------------------------------------------------------------------------------- 1 | # Code of Conduct 2 | 3 | All documentation, code and communication under this repository are covered by the [W3C Code of Conduct](https://www.w3.org/policies/code-of-conduct/). 4 | -------------------------------------------------------------------------------- /CONTRIBUTING.md: -------------------------------------------------------------------------------- 1 | # RDF Rust Common Crates Community Group 2 | 3 | This repository is being used for work in the W3C RDF Rust Common Crates Community Group, governed by the [W3C Community License 4 | Agreement (CLA)](http://www.w3.org/community/about/agreements/cla/). To make substantive contributions, 5 | you must join the CG. 6 | 7 | If you are not the sole contributor to a contribution (pull request), please identify all 8 | contributors in the pull request comment. 9 | 10 | To add a contributor (other than yourself, that's automatic), mark them one per line as follows: 11 | 12 | ``` 13 | +@github_username 14 | ``` 15 | 16 | If you added a contributor by mistake, you can remove them in a comment with: 17 | 18 | ``` 19 | -@github_username 20 | ``` 21 | 22 | If you are making a pull request on behalf of someone else but you had no part in designing the 23 | feature, you can remove yourself with the above syntax. 24 | -------------------------------------------------------------------------------- /Cargo.toml: -------------------------------------------------------------------------------- 1 | [workspace] 2 | 3 | members = [ 4 | "dummy", 5 | ] 6 | resolver = "3" 7 | 8 | [workspace.package] 9 | version = "0.1.0" 10 | authors = ["R2C2 Community Group "] 11 | edition = "2024" 12 | repository = "https://github.com/w3c-cg/r2c2" 13 | readme = "./README.md" 14 | license-file = "./LICENSE.md" 15 | keywords = ["rdf", "linked-data", "semantic-web", "w3c"] # no more than 5 16 | 17 | [workspace.dependencies] 18 | dummy = { version = "0.1.0", path = "dummy" } 19 | 20 | [workspace.lints.clippy] 21 | enum_glob_use = "allow" 22 | 23 | -------------------------------------------------------------------------------- /Charter.md: -------------------------------------------------------------------------------- 1 | # RDF Rust Common Crates Community Group Charter 2 | 3 | - This Charter: https://github.com/w3c-cg/r2c2/blob/main/Charter.md 4 | - Previous Charter: N/A 5 | - Start Date: 2024-02-01 [*{TBD estimation}*] 6 | - Last Modified: (see [github history](https://github.com/w3c-cg/r2c2/commits/main/Charter.md)) 7 | 8 | ## Goals 9 | 10 | The mission of the RDF Rust Common Crates (R2C2) 11 | Community Group is to develop a **common API** for working with [RDF] in 12 | [Rust], published as a set of [library crates]. 13 | The goal is to improve the interoperability of the RDF ecosystem in Rust. 14 | 15 | ## Scope of Work 16 | 17 | The common API developed by the Community Group will be defined as a set of traits and/or lightweight type, 18 | that other crates are encouraged to implement and reuse, 19 | so that data values produced by an implementation can be reused by another one. 20 | 21 | For example, the triples produced by a [Turtle] 22 | parser, provided that they implement a trait defined by this Community Group, 23 | could be ingested by any independently developed implementation of a graph store. 24 | Similarly, if the latter implements the appropriate traits, 25 | it could be checked by any independently developed [SHACL] validator. 26 | 27 | As much as possible, 28 | the crates developed by the Community Group should aim at fulfilling the 29 | *[zero-cost abstraction]* motto: 30 | the provided traits should ideally be generic enough, 31 | to be directly implementable by any specific implementation, 32 | regardless of its internal design 33 | (as opposed to requiring a [wrapper type]). 34 | However, overly generic code can be hard too use in practice, 35 | so the Community Group will have to strike a balance between genericity and usability. 36 | 37 | The Community Group may also develop utility [library crates], i.e., 38 | crates providing common types or functions expected to be pervasively used in the implementations of the common API. 39 | For example, the Community Group may produce a crate for parsing and resolving IRIs. 40 | 41 | ### Out of Scope 42 | 43 | * develop an complete implementation of RDF-related standards 44 | 45 | ## Deliverables 46 | 47 | ### Rust Crates 48 | 49 | The main deliverables of the community group are Rust [library crates], 50 | which should eventually be published on the standard repository https://crates.io/. 51 | 52 | The public API of the code will be extensively documented using 53 | [doc comments](https://doc.rust-lang.org/reference/comments.html#doc-comments), 54 | and will include practical working examples. 55 | 56 | ### Specifications 57 | 58 | No Specifications will be produced under the current charter. 59 | 60 | ### Non-Normative Reports 61 | 62 | The community group may produce a user manual, or other kind of documentation, 63 | for the produced crates. 64 | 65 | 77 | 78 | ## Dependencies or Liaisons 79 | 80 | * the [RDF Javascript Libraries Community Group] has a similar goal to this Community Group, 81 | applied to the Javascript programming language. 82 | Interaction between the two groups could be mutually valuable, 83 | to share experience and lessons learned. 84 | * [all projects](https://github.com/search?q=rdf+language%3ARust+pushed%3A%3E2024-01-01+&type=repositories) 85 | implementing RDF (or related standards) is a potential candidate for implementing the R2C2 traits. 86 | The Community Group will strive to include the maintainers of these project in the discussions. 87 | 88 | ## Community and Business Group Process 89 | 90 | The group operates under the [Community and Business Group 91 | Process](https://www.w3.org/community/about/process/). Terms in this 92 | Charter that conflict with those of the Community and Business Group 93 | Process are void. 94 | 95 | As with other Community Groups, W3C seeks organizational licensing 96 | commitments under the [W3C Community Contributor License Agreement 97 | (CLA)](https://www.w3.org/community/about/process/cla/). When people 98 | request to participate without representing their organization\'s legal 99 | interests, W3C will in general approve those requests for this group 100 | with the following understanding: W3C will seek and expect an 101 | organizational commitment under the CLA starting with the individual\'s 102 | first request to make a contribution to a group 103 | [Deliverable](#deliverables). The section on [Contribution 104 | Mechanics](#contribution-mechanics) describes how W3C expects to monitor these 105 | contribution requests. 106 | 107 | The [W3C Code of Ethics and Professional 108 | Conduct](https://www.w3.org/Consortium/cepc/) applies to participation 109 | in this group. 110 | 111 | 118 | 119 | ## Contribution Mechanics 120 | 121 | Substantive Contributions to Specifications can only be made by 122 | Community Group Participants who have agreed to the [W3C Community 123 | Contributor License Agreement 124 | (CLA)](https://www.w3.org/community/about/process/cla/). 125 | 126 | Deliverables created in the Community Group must use the [W3C Software 127 | and Document 128 | License](http://www.w3.org/Consortium/Legal/2015/copyright-software-and-document). 129 | 130 | Community Group participants agree to make all contributions in the 131 | GitHub repository the group is using for the particular source code or document. This may be 132 | in the form of a pull request (preferred), by raising an issue, or by 133 | adding a comment to an existing issue. 134 | 135 | All GitHub repositories attached to the Community Group must contain a 136 | copy of the 137 | [CONTRIBUTING](https://github.com/w3c/licenses/blob/master/CG-CONTRIBUTING.md) 138 | and [LICENSE](https://github.com/w3c/licenses/blob/master/CG-LICENSE.md) 139 | files. 140 | 141 | ## Transparency 142 | 143 | The group will conduct all of its technical work in public. If the group 144 | uses GitHub, all technical work will occur in its GitHub repositories 145 | (and not in mailing list discussions). This is to ensure contributions 146 | can be tracked through a software tool. 147 | 148 | Meetings may be restricted to Community Group participants, but a public 149 | summary or minutes must be posted to the group\'s public mailing list, 150 | or to a GitHub issue if the group uses GitHub. 151 | 152 | ## Decision Process 153 | 154 | This group will seek to make decisions where there is consensus, as described in this section. 155 | 156 | ### Work item owners 157 | 158 | * Every work item (crate or report) worked on by the Community Group will have a list of owners which will always include the Chairs. 159 | * This list of owners will be recorded using GitHub's [CODEOWNERS] mechanism. 160 | * Only the Chairs are the owners of the CODEOWNERS file. 161 | * Any Community Group participant can ask to be promoted owner of a work item once a pull-request they have submitted on this work item is merged 162 | (this rule is loosely inspired by the [pull-request hack]). 163 | * The Chairs may demote an owner of a work item who has not contributed (with pull-requests or reviews) to that item in the past year. 164 | 165 | ### New work item 166 | 167 | * Any Community Group participant may propose a new work item (crate or report) by making a pull-request on the Community Group's GitHub repository 168 | with the label `new-work-item`, which constitutes a call for consensus. 169 | * No less than two weeks after the pull-request was posted, 170 | the Chairs assess consensus based on the feedback on the pull-request, 171 | and record a group decision on GitHub, following [Section 5.2] of the W3C process. 172 | * If the decision is to accept the new work item, the Chairs merge the pull-request and promote its author owner of the new work item. 173 | * Regardless of the consensus of its participant, the Community Group can not accept a work item that is not in its [scope](#scope-of-work), 174 | as defined by this charter. 175 | 176 | ### Merging pull-requests 177 | 178 | * Every Community Group participant will have [write access] to the group's GitHub repository, 179 | but merging a pull-request will require approval by at least two [owners](#work-item-owners) of the affected work item. 180 | * To ensure the applicability of the rule above, 181 | pull-requests spanning multiple work items are strongly discouraged, 182 | but the Chairs may decide to allow them on a per-case basis. 183 | * Once sufficiently approved by the appropriate owners (as defined above), 184 | a pull-request can be merged even if there is disagreement about it. 185 | Individuals who disagree with the choice are strongly encouraged to take ownership of their objection by submitting a subsequent pull-request. 186 | 187 | ### Publishing work 188 | 189 | * The Chairs are collectively the owners on [crates.io] of the crates released by the Community Group. 190 | * To request the release of a crate on crates.io, or the publication of a report as a [Final Community Group Report], 191 | a Community Group participant opens a pull-requests or an issue with the label `request-publication`, 192 | which constitutes a call for consensus. 193 | * No less than two weeks after the pull-request / issue was posted, 194 | the Chairs assess consensus based on the feedback on the pull-request, 195 | and record a group decision on GitHub, following [Section 5.2] of the W3C process, 196 | and take the appropriate action to implement the decision. 197 | * For releasing a crate where only the [PATCH version](https://semver.org) is changed (i.e. the only changes compared to the previous release are backward compatible bug fixes), the delay above can be reduced to one week. 198 | * A publication request fixing a known security issue can be accepted by the Chairs without any delay, provided that the new release only includes the fix, to the exclusion of any other pull-request merged since the last release.``` 199 | 200 | It is the Chairs\' responsibility to ensure that the decision process is 201 | fair, respects the consensus of the CG, and does not unreasonably favour 202 | or discriminate against any group participant or their employer. 203 | 204 | ## Chair Selection 205 | 206 | Participants in this group choose their Chair(s) and can replace their 207 | Chair(s) at any time using whatever means they prefer. However, if 5 208 | participants, no two from the same organisation, call for an election, 209 | the group must use the following process to replace any current Chair(s) 210 | with a new Chair, consulting the Community Development Lead on election 211 | operations (e.g., voting infrastructure and using [RFC 212 | 2777](https://tools.ietf.org/html/rfc2777)). 213 | 214 | 1. Participants announce their candidacies. Participants have 14 days 215 | to announce their candidacies, but this period ends as soon as all 216 | participants have announced their intentions. If there is only one 217 | candidate, that person becomes the Chair. If there are two or more 218 | candidates, there is a vote. Otherwise, nothing changes. 219 | 2. Participants vote. Participants have 21 days to vote for a single 220 | candidate, but this period ends as soon as all participants have 221 | voted. The individual who receives the most votes, no two from the 222 | same organisation, is elected chair. In case of a tie, RFC2777 is 223 | used to break the tie. An elected Chair may appoint co-Chairs. 224 | 225 | Participants dissatisfied with the outcome of an election may ask the 226 | Community Development Lead to intervene. The Community Development Lead, 227 | after evaluating the election, may take any action including no action. 228 | 229 | ## Amendments to this Charter 230 | 231 | The group can decide to work on a proposed amended charter, editing the 232 | text using the [Decision Process](#decision-process) described above. The 233 | decision on whether to adopt the amended charter is made by conducting a 234 | 30-day vote on the proposed new charter. The new charter, if approved, 235 | takes effect on either the proposed date in the charter itself, or 7 236 | days after the result of the election is announced, whichever is later. 237 | A new charter must receive 2/3 of the votes cast in the approval vote to 238 | pass. The group may make simple corrections to the charter such as 239 | deliverable dates by the simpler group decision process rather than this 240 | charter amendment process. The group will use the amendment process for 241 | any substantive changes to the goals, scope, deliverables, decision 242 | process or rules for amending the charter. 243 | 244 | [library crates]: https://doc.rust-lang.org/book/ch07-01-packages-and-crates.html 245 | [RDF]: https://www.w3.org/TR/rdf-primer/ 246 | [Rust]: https://www.rust-lang.org/ 247 | [Turtle]: https://www.w3.org/TR/rdf-turtle/ 248 | [SHACL]: https://www.w3.org/TR/shacl/ 249 | [zero-cost abstraction]: https://blog.rust-lang.org/2015/05/11/traits.html 250 | [wrapper type]: https://doc.rust-lang.org/book/ch20-03-advanced-traits.html#using-the-newtype-pattern-to-implement-external-traits-on-external-types 251 | [RDF Javascript Libraries Community Group]: https://www.w3.org/groups/cg/rdfjs/ 252 | [CODEOWNERS]: https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners#codeowners-and-branch-protection 253 | [write access]: https://docs.github.com/en/get-started/learning-about-github/github-glossary#write-access 254 | [pull-request hack]: https://felixge.de/2013/03/11/the-pull-request-hack/ 255 | [Section 5.2]: https://www.w3.org/policies/process/20231103/#consensus-building 256 | [crates.io]: https://crates.io/ 257 | [Final Community Group Report]: https://www.w3.org/community/about/faq/#how-do-we-publish-a-report 258 | 259 | -------------------------------------------------------------------------------- /LICENSE.md: -------------------------------------------------------------------------------- 1 | All Reports in this Repository are licensed by Contributors 2 | under the 3 | [W3C Software and Document License](https://www.w3.org/copyright/software-license/). 4 | 5 | 9 | 10 | Contributions to Source Code are made under the 11 | [W3C 3-clause BSD License](https://www.w3.org/copyright/3-clause-bsd-license-2008/) 12 | 13 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | 2 | # RDF Rust Common Crates (R2C2) Community Group 3 | 4 | The mission of the RDF Rust Common Crates (R2C2) 5 | Community Group is to develop a **common API** for working with [RDF] in 6 | [Rust], published as a set of [library crates]. 7 | The goal is to improve the interoperability of the RDF ecosystem in Rust. 8 | 9 | [library crates]: https://doc.rust-lang.org/book/ch07-01-packages-and-crates.html 10 | [RDF]: https://www.w3.org/TR/rdf-primer/ 11 | [Rust]: https://www.rust-lang.org/ 12 | 13 | * [Community Group Homepage](https://www.w3.org/groups/cg/r2c2) 14 | * [Community Group Charter](Charter.md) 15 | * [Community Group Code of Conduct](CODE_OF_CONDUCT.md) 16 | -------------------------------------------------------------------------------- /dummy/Cargo.toml: -------------------------------------------------------------------------------- 1 | [package] 2 | name = "r2c2_dummy" 3 | description = "This is a dummy package that will disappear as soon as the first real work-item is added." 4 | version.workspace = true 5 | authors.workspace = true 6 | edition.workspace = true 7 | repository.workspace = true 8 | readme.workspace = true 9 | license-file.workspace = true 10 | keywords.workspace = true 11 | 12 | [dependencies] 13 | 14 | [lints] 15 | workspace = true 16 | -------------------------------------------------------------------------------- /dummy/src/lib.rs: -------------------------------------------------------------------------------- 1 | //! Dummy crate, just used to make the whole repo a valid Cargo workspace. 2 | //! 3 | //! It will disappear as soon as the first real work-item is added. 4 | 5 | pub fn add(left: u64, right: u64) -> u64 { 6 | left + right 7 | } 8 | 9 | #[cfg(test)] 10 | mod tests { 11 | use super::*; 12 | 13 | #[test] 14 | fn it_works() { 15 | let result = add(2, 2); 16 | assert_eq!(result, 4); 17 | } 18 | } 19 | -------------------------------------------------------------------------------- /w3c.json: -------------------------------------------------------------------------------- 1 | { 2 | "group": [157420] 3 | , "contacts": ["ij@w3.org"] 4 | , "repo-type": "cg-report" 5 | } 6 | --------------------------------------------------------------------------------