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.