Reducing differences between schema.org and codemeta #134
Description
Hi @mbjones @gothub @danielskatz @npch @arfon, others
Been thinking about @mfenner's comments about standardizing a bit more tightly to schema.org. Would really like group input, but personally I find Martin's suggestion very compelling, particularly in light of related working groups. While personally I don't think codemeta should be restricted to schema.org vocabulary, I do think it would be nice if a schema.org software description was approximately a subset of codemeta.
For starters, our current spec differs from schema.org in some ways that seem relatively arbitrary, where I think we could standardize more easily:
| codemeta | schema | comments |
|---|---|---|
| licenseId | license | Schema uses URL, suggest we do so too |
| controlledTerms | keywords | Not sure precisely how this differs from Tags. (seems to be Categories, but doesn't reference a controlled vocab list?) |
| tags | keywords | Seems "keywords" should suffice? |
| downloadLink | downloadUrl | Not sure why we've used something different |
| person | Person | types (classes) are upper case in schema |
| organization | Organization | ditto |
| depends | softwareRequirements | the schema term is a list of URLs only, while ours is more general |
Additionally, we could eliminate our use of dcterms terms in place of equivalent schema.org terms, for:
dcterms:identifiercould becomeschema:identiferdcterms:title->schema:title
We also re-type a lot of schema.org terms using XSD types, which also seems needlessly complicated. e.g. we use xsd:string instead of schema.org:Text. It might make sense to keep to the XSD versions if we write out an actual XSD schema for an XML version of codemeta (though presumably it would be better to declare the schema.org types match their the xsd types and the validator could still figure things out?), but in our JSON-LD context file this appears confusing. (Or maybe there's some other good reason for XSD types that I'm missing).
We should also give some thought to some more subtle differences in recognized properties of codemeta types as compared to schema types: e.g. schema:programmingLanguage does't include version. Likewise schema:softwareRequirementsis not technically a property of aschema:SoftwareSourceCodeobject but only of aschema:SoftwareApplication` object. I'm not sure that it really matters what properties schema.org associates with a type, e.g. I'm not sure if there's any problem in having something like:
{
"@context": { "@vocab": "https://schema.org" },
"@type": "programmingLanguage",
"@name": "Python",
"@version": "2.7"
}Conversely, schema.org softwareSourceCode and softwareApplication types do recognize additional properties that codemeta does not have, presumably it should not be a problem if a user includes these.
In the same way, a user should be able to specify the additional concepts introduced by the codemeta project that have no immediate analog in schema.org.
(My contention is that it is never an issue as long as the consumer develops their application appropriately for json-ld input).