Codemeta v3.0 - generation

[hjonin]

Relates to #23.

Allow codemeta.json v3.0 file generation.

Still TODO:

• missing import for v3.0 -> see Codemeta v3.0 - import #40
• missing tests for generation/import v3.0
• extra validation? (e.g. end date > start date) -> see Add extra validation #39

@moranegg I'm attaching a screenshot so you can also validate the interface

[hjonin]

@moranegg @progval Should the generator now generate v3.0 by default (on value change)? If so, I'm also updating previous tests.
The other solution would be a switch button at the beginning, which I'm not found of: I think it's better to reduce the user cognitive load, and to encourage using the v3.0 by default.

[progval]

Good question. I think we should wait for Codemeta parsers to support v3.0. There's swh-indexer and a few listed here: https://codemeta.github.io/tools/ ; none of them seem to support v3.0 yet.

[hjonin]

Another question, should we add validation on cross terms, e.g. fix

if (fieldName.startsWith("codemeta:") || fieldName.startsWith("schema:")) {
    // Do not check fields from other versions FIXME ?
    return true;
}

?

[progval]

The current version of the generator refuses unknown fields. Whether that's a good idea is debatable; but we shouldn't change this behavior in a PR that is about something else (adding support for Codemeta v3). Instead, validation should allow both v2 and v3 terms, and reject everything else.

[hjonin]

I'm not sure to understand what do you mean by

validation should allow both v2 and v3 terms, and reject everything else.

What should it allow, and what should it reject, in terms of cross version terms (e.g. contIntegration/continuousIntegration/codemeta:contIntegration/codemeta:continuousIntegration)?

[progval]

It should allow both https://codemeta.github.io/terms/contIntegration and https://codemeta.github.io/terms/continuousIntegration. And because this PR still compacts with the v2 context (doc = await jsonld.compact(parsed, CODEMETA_CONTEXTS["2.0"].url); // Only import codemeta v2.0 for now), they are compacted respectively as contIntegration and codemeta:continuousIntegration.

[hjonin]

So, it should always fail in error, like this?

[progval]

No, these two are semantically the same document (they both expand to the exact same document), and they are both valid, because it is valid to use both https://codemeta.github.io/terms/contIntegration and https://codemeta.github.io/terms/continuousIntegration in the same document regardless of context.

[hjonin]

Ah ok, so for you it was ok to have this code without further validation?

[progval]

It's not, because codemeta:abcde should be disallowed, for example.

[hjonin]

Ah, I think I understand now. So, would it be ok/sufficient to have in validators:

"contIntegration": validateUrls,
"continuousIntegration": validateUrls,
"codemeta:contIntegration": noValidation,
"codemeta:continuousIntegration": noValidation,

[progval]

When compacting with a v2 context, you would never get a continuousIntegration property (because continuousIntegration is not in the v2 context) and you would only get a codemeta:contIntegration property if it does not have type @id. So:

• contIntegration -> validate URLs
• continuousIntegration -> can't happen
• codemeta:contIntegration -> always reject
• codemeta:continuousIntegration -> validate URLs

[progval]

It would be less confusing if we expanded the document before validating (ie. #29), instead of compacting with the v2 context. In particular, it would break this asymmetry, and the validation simply becomes:

"https://codemeta.github.io/terms/contIntegration": validateUrls,
"https://codemeta.github.io/terms/continuousIntegration": validateUrls,

[hjonin]

Do you mean that https://github.com/hjonin/codemeta-generator/blob/3c76b4b876df2de62e6f88eaeedc1bdfa0437a03/js/validation/index.js#L16

function validateDocument(doc) {

should take the expanded document for input (I did not get that at first for #29)?

[progval]

yes, exactly

[hjonin]

ok :) I'll do that in another PR indeed

[moranegg]

Excellent discussion and work!
Is the PR ready for merge?

[progval]

Thanks, looks great

[progval]

This won't be readable by v2-only parsers.

I believe we should return both formats, ie.

                "author": [
                    {
                        "type": "schema:Role",
                        "schema:author": {
                            "type": "Person",
                            "givenName": "Jane"
                        },
                        "schema:roleName": "Developer",
                        "schema:startDate": "2024-03-04",
                        "schema:endDate": "2024-04-03"
                    },
                    {
                        "type": "Person",
                        "givenName": "Jane"
                    }

or possibly only the latter in the v2 export.

[hjonin]

I've allowed the first solution in the last commit.

[progval]

Can you remind me why this is needed?

[hjonin]

It could happen when validating of multi-version document, where, for instance, in this case:

    {
              "@context": "https://w3id.org/codemeta/3.0",
              "type": "SoftwareSourceCode",
              "name": "My Test Software",
              "continuousIntegration": "https://test-ci.org/my-software",
              "codemeta:contIntegration": {
                  "id": "https://test-ci.org/my-software"
              }
      }

continuousIntegration could be validated but not codemeta:contIntegration. But this hack is removed with hjonin#1.

[progval]

Right. But then the "Unknown field" is never triggered because this addition allows every unknown property in the codemeta and schema.org namespaces.

Could you make this hack more specific, by explicitly listing the few properties that were added/removed? (and then remove it in the future of course)

[hjonin]

Done in the last commit.

[progval]

Thanks!