Since early versions of the deposit (rDDEPf04c12ed5813676c1eed581ef5594d9a1379365c), xmlns:codemeta="https://doi.org/10.5063/SCHEMA/CODEMETA-2.0" is used, even though the actual Codemeta namespace is https://codemeta.github.io/terms/.
This means that this document:
<?xml version="1.0"?>
<entry xmlns="http://www.w3.org/2005/Atom"
xmlns:codemeta="https://doi.org/10.5063/SCHEMA/CODEMETA-2.0">
<title>Awesome Compiler</title>
<codemeta:id>1785io25c695</codemeta:id>
<codemeta:url>origin url</codemeta:url>
</entry>Should actually be translated to a JSON-LD document that looks like this:
{
"@context": [
"https://doi.org/10.5063/SCHEMA/CODEMETA-2.0",
{"atom": "http://www.w3.org/2005/Atom#"}
],
"atom:title": "Awesome Compiler",
"id": "1785io25c695",
"url": "origin url"
}(note the added # to the atom namespace, so it is valid JSON-LD; / would have worked too)
Which is equivalent to this in a somewhat expanded form:
{
"http://www.w3.org/2005/Atom#title": "Awesome Compiler",
"@id": "https://json-ld.org/playground/1785io25c695",
"http://schema.org/url": "https://json-ld.org/playground/origin url"
}This is very counter-intuitive, as one would expect XMLNSs to be mapped to JSON-LD compact URIs, like so:
{
"@context": {
"codemeta": "https://doi.org/10.5063/SCHEMA/CODEMETA-2.0#",
"atom": "http://www.w3.org/2005/Atom#"
},
"atom:title": "Awesome Compiler",
"codemeta:id": "1785io25c695",
"codemeta:url": "origin url"
}(note the added # as well)
which is equivalent to this:
{
"http://www.w3.org/2005/Atom#title": "Awesome Compiler",
"https://doi.org/10.5063/SCHEMA/CODEMETA-2.0#id": "1785io25c695",
"https://doi.org/10.5063/SCHEMA/CODEMETA-2.0#url": "origin url"
}which is clearly not a codemeta document.
We need to clearly document this pecular behavior, along with the rest of the implied JSON-LD <-> XML translations that are going on in the deposit.