Jesse Wright jeswr

core_number: 0.18.1 versus PR 1673

Save core_number_criterion.rs and core_number_uv.py in a directory outside the rustworkx checkout. Run these commands sequentially; the first runs download/build dependencies:

RAYON_NUM_THREADS=1 cargo +nightly -Zscript run --release --manifest-path core_number_criterion.rs -- --bench

RAYON_NUM_THREADS=1 uv run --no-project --python 3.12 --with rustworkx==0.18.1 core_number_uv.py --label release-0.18.1

RAYON_NUM_THREADS=1 uv run --no-project --python 3.12 --with 'rustworkx @ git+https://github.com/jeswr/rustworkx@b701414e060a94f60c8c59df429b6b4289308c25' core_number_uv.py --label pr-b701414

rdfjs/N3.js — Triage board (2026-07-01)

Assembled read-only for @jeswr. Nothing has been posted, labelled, closed, or pushed — every proposed comment below waits for a ticked checkbox. Supporting memos: repo health, TypeScript migration.

1. State of the repo

N3.js is in good release shape — semantic-release from main works, runtime dependencies are clean, and the 100% coverage gate plus the 40-job W3C spec matrix are strong quality gates — but the one thing actively hurting day-to-day operation is spec-test flakiness (#609), a diagnosed rdf-test-suite cache race that strands dependabot automerge (#610) and can silently skip releases. The backlog itself is healthier than it looks: 18 small fixes have verified root causes (several with

title: "Avoiding Request-Content Re-Transmission for Cached HTTP QUERY" abbrev: "QUERY Digest Caching" docname: draft-wright-httpbis-query-digest-caching-00 category: exp updates: 10008 ipr: trust200902 area: "Web and Internet Transport" workgroup: "HTTP" keyword: [QUERY, cache, digest]

Is `create` a Good Upstream Candidate?

Yes, strongly. create fills a genuine gap in the ODRL vocabulary. ODRL has read, modify, and delete — three of the four CRUD operations — but no create. This is because ODRL was designed for digital rights over existing content (music, video, documents). The concept of "create a new resource inside a container" is a web/REST pattern that ODRL's original domain didn't need.

As ODRL is increasingly applied to web resource management (LWS, Solid, data spaces), the absence of create becomes a real interoperability problem — every profile in this space has to independently invent the same term. Making it a Common Vocabulary term benefits the whole ecosystem.

The definition would be straightforward:

Included in: odrl:use (like read, modify, delete)
Semantics: Create a new resource, typically within a collection or container
Distinct from: modify (which operates on an existing resource)

This file contains notes for a beginner Introduction to Solid Workshop. This should be accompanied with a Slide Deck for the presentation.

About Solid

About the Solid Project

Decentralized web
Project started by Sir Tim Berners-Lee; inventor of the World Wide Web

education

Courses which involve Solid https://rubenverborgh.github.io/WebFundamentals/semantic-web/.

Other existing education materials include:

Short article intros to Solid:

https://www.ateam-oracle.com/post/an-introduction-to-solid

	<!DOCTYPE html><html><head><meta charset="utf-8"><title>Create sparq-orchestrator App</title></head>
	<body style="font-family:system-ui;max-width:640px;margin:40px auto;line-height:1.5">
	<h2>Create the sparq-orchestrator GitHub App</h2>
	<p>Click the button once. GitHub will ask you to confirm, create the App, then send you back to the
	sparq repo with a <code>?code=…</code> in the address bar. Copy that code value and paste it to the agent.</p>
	<form action="https://github.com/settings/apps/new?state=sparq-orch" method="post">
	<input type="hidden" name="manifest" id="manifest">
	<button type="submit" style="font-size:18px;padding:10px 18px;cursor:pointer">Create sparq-orchestrator App</button>
	</form>
	<script>

	# SHACL Versioning Pattern for the Solid Ecosystem

	## Context & Problem Statement

	The Solid SHACL Shapes Catalogue (`solid/shapes`) already establishes that published shapes are immutable contracts — once merged, their validation rules must not be modified. Evolution happens through new shapes, not mutation of existing ones.

	This is a strong foundation, but it doesn't yet address several questions that become critical as the catalogue grows:

	- How do consumers know which shape is the "current" version of a concept?
	- How do apps discover that a shape they depend on has a successor?

	/* Style for design issues documents */

	body {
	font-family: opensans, sans-serif; /* serif */
	background-color: white; /* was for decades #f8fff8 */
	line-height: 1.2em;
	color: black;
	margin: 2em 8% 2em 10%; /* T R B L */
	}

	With data_0.n3s
	```
	@prefix : <https://example.org/ns#> .
	@prefix log: <http://www.w3.org/2000/10/swap/log#> .

	:ABC a :DepartmentPreference .
	:ABC a :ResearcherPreference .

	(_:WHAT) log:onNegativeSurface {
	_:WHAT a :DepartmentPreference .