[Request]: Make the terms in codeMeta have anchors so we can redirect to them in the website

[dgarijo]

Is this the right place?

• This is NOT suggesting an addition, alteration or removal of CodeMeta terms. Please request terms changes in the main CodeMeta repository.
• This is NOT a request for the CodeMeta Generator. Please request Generator changes in the Codemeta-Generator repository.

What change or feature would you like to request?

In https://codemeta.github.io/terms/#codemeta-terms would it be possible to give ids to each codemeta term so we can redirect from the vocabulary namespace?

For example, https://w3id.org/codemeta/terms/readme right now redirects to https://codemeta.github.io/terms/#codemeta-terms in HTML, which is ok. But ideally, it would be great to point to the term as https://codemeta.github.io/terms/#readme

Why is this needed.

This would improve the redirection of concrete terms, making them easier to find in the website.
Visually, it adds no changes to the website, so it is not very disruptive.

[meldra]

There is currently a term that is duplicated within the set of tables; identifier exists as a schema.org software term and a schema.org thing term.

Options that mitigate this (for now, assuming future terms are not duplicated) are:

1. Give all the terms IDs and prefix them as #parent-term based on the tables, thus disambiguating as #software-identifier and #thing-identifier
2. Give only the CodeMeta table's terms ids/anchors

I'm not sure either solution is amazing.

[progval]

Indeed, I don't think either works for @dgarijo's use case.

Some other options:

1. Decide that one of them is more important, and give it the #identifier anchor
2. Remove the distinction between SoftwareSourceCode's identifier and Person's
3. move all terms to the same table so they can be next to each other
4. Redirect to https://codemeta.github.io/terms/identifier instead of https://codemeta.github.io/terms/#identifier and generate a page that list all use cases of the term

Option 4 seems like the best one. We can also use that opportunity to add longer documentation for each term, including examples.

[dgarijo]

I think the second option suggested by Melissa would work. We only need anchors for the Codemeta extensions (I.e., new terms). There is no codemeta:identifier, so that would not need to be resolved. El dom., 25 ene. 2026 9:27 a. m., Val Lorentz ***@***.***> escribió:

…

*progval* left a comment (codemeta/codemeta.github.io#110) <#110 (comment)> Indeed, I don't think either works for @dgarijo <https://github.com/dgarijo>'s use case. Some other options: 1. Decide that one of them is more important, and give it the #identifier anchor 2. Remove the distinction between SoftwareSourceCode's identifier and Person's 3. move all terms to the same table so they can be next to each other 4. Redirect to https://codemeta.github.io/terms/identifier instead of https://codemeta.github.io/terms/#identifier and generate a page that list all use cases of the term Option 4 seems like the best one. We can also use that opportunity to add longer documentation for each term, including examples. — Reply to this email directly, view it on GitHub <#110 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AALTIGSQAUGTRJDSOKBH4UD4IR5AFAVCNFSM6AAAAACSQ4R5QCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTOOJWGE4TKNJXHE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[progval]

Indeed, my bad

[meldra]

Oh maintainer is Schema.org and CodeMeta too, but with the solution @dgarijo chose that doesn't matter.

Anyway, this is a 2 line change: #111

[progval]

Oh maintainer is Schema.org and CodeMeta too

but we don't use the one from schema.org, right? (we should fix that in v4 btw)

[meldra]

but we don't use the one from schema.org, right? (we should fix that in v4 btw)

I dont recall having seen schema:maintainer anywhere so likely not.

[meldra]

Oh maintainer is Schema.org and CodeMeta too

but we don't use the one from schema.org, right? (we should fix that in v4 btw)

I'm also now confused because my staging had it; i found it when testing a version of the change (that laptop is now packed for travel) and the live site doesn't. Did we introduce a bug somewhere with the other property parsing changes or was my staging hallucinating on misparsed data earlier?

[dgarijo]

This brings up an interesting case. Some of the CodeMeta properties will be lifted to schema.org (o that is the intent).
But when that happens, if they are deprecated in CodeMeta, we will still not face the resolvability problem I think (people will try to resolve schema:maintainer, which goes to https://schema.org/maintainer).