A permanent URL redirection service: you claim a path under https://w3id.org/,
and you control where requests for it are sent. See Overview.
No. The "w3" in the domain name stands for "World Wide Web". Other than hosting the Permanent Identifier Community Group, the World Wide Web Consortium has no involvement in the support or management of this service.
An identifier under w3id.org is not a W3C standard, recommendation, or publication, and carries no endorsement.
No. The service is run by a consortium of organisations that have pledged to keep it operating. See Overview — Who runs it.
The intent is decades — "as long as the Web is around". Identifiers are not deleted once they are in use, because deleting one breaks other people's data.
That commitment runs both ways: do not claim an identifier you are not prepared to look after. See Purpose — The commitment.
Open a pull request adding a directory under ids/. See
Creating an identifier.
If you would rather not use Git, you can ask on the mailing list instead — include the URL you want, where it should redirect to, and the status code.
No. This service redirects; it does not serve files. Publish your ontology, schema, or context somewhere you control and point the identifier at it.
This is the most common out-of-scope request. See
files/only-allowed-names and
Scope.
Probably not. Names that are single common words, that could be confused with an existing identifier or a known organisation, or that look like speculative claims are declined. Ask on the mailing list before opening a pull request if you are unsure. See Scope — Naming.
No. Claiming a directory is a long-term commitment, not a reservation. Come back when the project exists and the content is live.
No. Check ids/ for
what is taken — including case variants, since Foo and foo cannot coexist.
See tree/no-case-collision.
No. The service exists so that identifiers embedded in data keep resolving. If nothing is going to embed the identifier, this is the wrong tool. See Scope.
After a maintainer reviews and merges your pull request, the change is deployed to the service and is normally live shortly afterwards. Check it with:
curl -sIL https://w3id.org/my-project/It varies with maintainer availability. You can make it faster by opening a small, single-purpose pull request that follows the rules — most delay comes from review round-trips over things that were avoidable.
The most frequent reasons, in rough order:
- No maintainer GitHub username —
meta/maintainer-github-username - Content files committed —
files/only-allowed-names - Files changed outside your directory —
tree/only-own-identifier - The file is not named
.htaccess—files/only-allowed-names - Untested rules that do not work
- Uninformative commit messages, or a long unsquashed history
See the rule catalogue for the full list.
A new identifier should ideally be one commit. If you are not comfortable squashing, tick the box in the pull request template and a maintainer will squash when merging.
Your fork then needs resyncing before your next change. The squashed commit is
a new one, so your original commits are not in master, and a next change
built on top of them would carry them along.
In the browser, delete the merged branch (the merged pull request offers a
button for it), use Sync fork on your fork's page, and start the next
change on a new branch. If you committed straight to your fork's default branch
and it still shows commits ahead of perma-id/w3id.org:master, the dependable
fix in the browser is to delete the fork and fork again.
From the command line:
git fetch upstream
git switch master
git status # commit anything listed: reset discards it
git log upstream/master..master # dropped next: only the squashed commits?
git branch old-master # a copy to go back to
git reset --hard upstream/master
git push --force-with-lease origin masterOnce your next change is in, delete the copy with git branch -D old-master.
To avoid needing this at all, make each change on its own branch. GitHub's web editor offers "Create a new branch for this commit and start a pull request" when you commit.
Update .htaccess is by a wide margin the most common commit message in this
repository, on well over a thousand commits — more than twice the next most
common. When something breaks years later, that history is what somebody has
to read. Include your project name and what changed.
Only with the listed maintainer's involvement. Open it as its own pull request, explain why, and tag a maintainer from that directory to approve it. See Maintaining an identifier.
Probably one of three reasons.
The rule may be documented but not mechanized — a rule page marked
proposed in the catalogue has no check behind it yet.
The mistake may be outside what any checker can know. Nothing can tell that your redirect points at the wrong place, only that it is well-formed. Whether the target is the one you meant is yours to verify.
Or the check may only look at what your change touched. The checker reports what your own diff is responsible for, so a pre-existing problem elsewhere in the repository will not appear.
Note also that most of the identifiers already in this repository predate any
automated checking and have never been checked at all. A rule being enforced
today says nothing about whether the existing tree satisfies it — which is one
more reason not to copy a neighbouring .htaccess as a template.
302 for ordinary redirects. 303 for content-negotiated ontology IRIs, where the identifier names a concept and you redirect to a document about it.
Avoid 301. Browsers and caches may honour it indefinitely and never re-check, so a 301 you got wrong cannot be fully retracted. On a service built for identifiers that live for decades, that is a bad trade for a marginal caching benefit.
Your .htaccess has a syntax error, and Apache is refusing to parse it. Note
that a 500 affects every URL under the directory, not just the broken rule.
Check first for a space inside the flag brackets —
htaccess/no-flag-whitespace — and for a byte order
mark at the start of the file — format/no-bom.
Most likely an Options -Indexes directive interacting badly with a bare
identifier URL. Remove the Options lines; you do not need them. See
htaccess/no-options-directive.
Almost always because the pattern includes a leading slash or the identifier's
own directory name. The pattern is matched against the path relative to your
directory. See
htaccess/pattern-relative-to-dir.
Because it is a real directory. Apache first redirects the bare form to
https://w3id.org/my-project/ with a 301, and your rules run on the second
request.
This is normal and expected. Do not try to eliminate it with DirectorySlash Off
or Options -Indexes — that is how you get a 403. See
htaccess/no-options-directive.
Two likely causes:
- your redirect target is a
github.com/.../blob/...URL, which serves a web page rather than the file — seehtaccess/github-raw-target; - your content negotiation rule ordering puts a broad match above the specific ones — see Content negotiation.
You have a [R=406] catch-all fallback that is matching every request. Remove
it and end with an unconditional default. See
htaccess/no-406-fallback.
No. The service is HTTPS-only, end to end. Your redirect targets should be
HTTPS too — see htaccess/https-target.
No. There is no authentication or access control. Everything on the service is public. See Scope.
No. It issues redirects; it does not fetch or serve content.
Add a rule for the new location, keep the old paths resolving, and test both. See Maintaining an identifier.
Update the contact details in a pull request that both the outgoing and incoming maintainer are visible on, and do it while the outgoing maintainer is still reachable. See Maintaining an identifier.
Identifiers are not deleted — removing one turns it into a 404 for everyone
still using it. Instead, return 410 Gone or redirect to a page explaining what
happened. See
Maintaining an identifier.
No. The old identifier is still in other people's data, and repointing it means they silently start receiving something unrelated. Pick a different name.
The public-perma-id@w3.org mailing list. For problems with a specific identifier, the issue tracker.
Introduce yourself on the mailing list, then open an issue titled Seeking to join the W3ID Consortium. See Overview.
AGENTS.md in the
repository, then Scope and the rule catalogue.
Machine-readable versions of this site are at
/llms.txt and
/llms-full.txt, and any page is
available as raw Markdown by appending .md to its URL.