Codemeta reexports schema:url, schema:dateCreated, ... with
"@type": "@id" and "type": "schema:Date" so that
{
"@context": "https://doi.org/10.5063/schema/codemeta-2.0",
"url": "http://example.org",
"dateCreated": "2022-10-26"
}expands to:
{
"http://schema.org/url": {
"@type": "@id",
"@value": "http://example.org"
},
"dateCreated": {
"@type": "http://schema.org/Date",
"@value": "2022-10-26"
}
}However, our translation tried to translate directly to a partially expanded
form, like this:
{
"@context": "https://doi.org/10.5063/schema/codemeta-2.0",
"url": {
"@value": "http://example.org"
},
"dateCreated": {
"@value": "2022-10-26"
}
}which prevents the compaction and expansion algorithms from adding a
type themselves, causing the document to be compacted to:
{
"@context": "https://doi.org/10.5063/schema/codemeta-2.0",
"schema:url": "http://example.org"
"schema:dateCreated": "2022-10-26"
}or expanded to:
{
"http://schema.org/url": {
"@value": "http://example.org"
},
"http://schema.org/dateCreated": {
"@value": "2022-10-26"
}
}which are not what we want.
This commit replaces the hack for @type with the right solution that
works for all properties.
I noticed this issue while writing tests for the diff that will resolve T4654.