Add support for non-codemeta contexts introducing their own terms for Codemeta/schema.org properties

For example:

{
    "@context": [
        "https://w3id.org/codemeta/3.0",
        {"alias_of_name": "name"}
    ],
    "type": "SoftwareSourceCode",
    "alias_of_name": "My Software"
}

is equivalent to

{
    "@context": "https://w3id.org/codemeta/3.0",
    "type": "SoftwareSourceCode",
    "name": "My Software"
}

but is rejected because we unconditionally substitute the context with our own before validating

We currently yet do not substitute the context before validating:

https://github.com/codemeta/codemeta-generator/blob/9bf79ad784a0e7b99be3c7ced5f7b6f8d8e7ace3/js/validation/index.js#L82C19-L82C35

Tested with revision 83e6919, we already got the error message:

@context must be "https://doi.org/10.5063/schema/codemeta-2.0", not ["https://w3id.org/codemeta/3.0",{"alias_of_name":"name"}]

What is the expected behavior in this case?

We currently yet do not substitute the context before validating:

I meant when importing

Tested with revision 83e6919, we already got the error message:

On the current version, I get Unknown field "alias_of_name".. The expected behavior is that it should be considered valid and be imported like

{
    "@context": "https://w3id.org/codemeta/3.0",
    "type": "SoftwareSourceCode",
    "name": "My Software"
}

On the current version, I get Unknown field "alias_of_name"..

Yes, it is already this behavior I'm getting with even an older revision (c1bce7d, if we comment out

codemeta-generator/js/validation/index.js

Line 34 in c1bce7d

    
           setError(`@context must be "https://doi.org/10.5063/schema/codemeta-2.0", not ${JSON.stringify(context)}`);

so we don't get the @context error).

This issue might be recategorized as enhancement (as it is not a regression) and the reason to work on in the description updated.