This should be moved to your local ignore file

You can debug locally with https://github.com/codemeta/codemeta/blob/714e4f873b01ebf89dafbb02cca8bacb30c8a605/scripts/aggregate.py to see what's wrong

Does this test pass now?

If this seems hard, please ignore the comment. I don't want to hold things back.

I would suggest at this moment to list the added properties that are mapped with schema.org with only the SwMath column and without the schema.org column:
,articles_count
,classification

I don't see related_software in the .md, and the examples don't match https://schema.org/supportingData

Regarding this example, do you mean we should have on line 21, supportingData,id ?
If no what are we missing about exposing the related_software information?

 <related_software>
    <id>11008</id>
    <name>BayesDA</name>
  </related_software>

Regarding this example, do you mean we should have on line 21, supportingData,id ?

Sorry, I missed the notification and the link doesn't work anymore. Is it this BayesDA? https://cran.r-project.org/web/packages/BayesDA/index.html

If yes, then it is software and not data.

If no what are we missing about exposing the related_software information?

 <related_software>
    <id>11008</id>
    <name>BayesDA</name>
  </related_software>

You currently can't express that information in CodeMeta.

However, you can produce codemeta.json document with a property you would define yourself, eg.

{
  "@context": "https://w3id.org/codemeta/3.0",
  "@type": "SoftwareSourceCode",
  "identifier": "rms",
  "name": "rms",
  "description": "blah blah blah",
  "https://zbmath.org/relatedSoftware": [
    "https://zbmath.org/software/11008",
    "https://zbmath.org/software/4515",
    // ...
  ],
}

Yes it is BayesDA.

I believe data can be an acceptable compromise regarding no supportingSoftware term is available.
These software with data:

<codemeta:supportingData> <codemeta:name>MUMPS</codemeta:name> <codemeta:id>https://swmath.org/software/4013</codemeta:id> </codemeta:supportingData>

have been successfully deposited in SWH and can still in my opinion be understand by a reader and we would avoid creating extra term that are not standardized in Codemeta.

What is your opinion on it?

have been successfully deposited in SWH

because SWH does not check it

can still in my opinion be understand by a reader

but not by a machine because it would have different meaning than one it expects.

Plus, https://schema.org/supportingData states that values must have type http://schema.org/DataFeed, so in order to make it valid you need to add "@type": "schema:DataFeed"

Apologize for delayed reply. I just added a new term realtedSoftware to map related_software:
Mazztok45@1077530
Is it okay with you?

The .md says:

orms_id : an important id for every software could be (Runtime platform or script interpreter dependencies(Example - Java v1, Python2.3, .Net Framework 3.0). Supersedes runtime.)

I don't understand the definition grammatically, but it sounds like it would be a better match for runtimePlatform

orms_id

is the identifier of another software registry indexing this software, thus I believe relatedLink is relevant. What do you think about it?

Is is the identifier of a registry, or the identifier of this software in an other registry?

identifier of this software in another registry

then orms_id should be mapped to sameAs or identifier. relatedLink would be for a web page that talks about the software.

Moved the orms_id term to align with sameAs, grouping it with zbmath_url under an or condition.

This change logically groups these properties, as they all serve the same purpose: providing alternative identifiers for the same object.

See:
Mazztok45@3e0a41a

Do you have an example or documentation for this one?

This example contains an example at the bottom:

 <standard_articles>
    <authors></authors>
    <id>5380273</id>
    <source>zbMATH Open Web Interface contents unavailable due to conflicting licenses.</source>
    <title>zbMATH Open Web Interface contents unavailable due to conflicting licenses.</title>
    <year>2008</year>
  </standard_articles>

referencePublication in Codemeta must be a URI, and I don't see a way to turn this data into a URI. However, your example is Sage which has a 2008 publication: https://zbmath.org/1168.20004 that URL would be suitable as a referencePublication.

In https://codemeta.github.io/terms/ it says that the range for referencePublication is a ScholarlyArticle. This may be a URI, but may also be a ScholarlyArticle object, right? You can maybe do something like:

"codemeta:referencePublication": {
        "@id": "https://zbmath.org/1168.20004",
    	"identifier": "5380273",
        "@type": "ScholarlyArticle",
        "title":"zbMATH Open Web Interface contents unavailable due to conflicting licenses."
    },

Having a URI would be ideal though

Ah, indeed. I thought "@type": "@id" disallowed objects but I was wrong. (And it makes sense, in retrospect.)