As has been discussed in #134 and related issues, I propose we adopt and release a new version of the codemeta.jsonld context file that is more closely aligned with Schema.org.

To recap, the main reasons for the switch are:

A. to better align with / be more interoperable with related efforts (e.g. paper.json, DataCite's schema based version, etc),
B. To permit a basic codemeta representation entirely within the schema.org vocabulary,
C. facilitate tool development, particularly in cases where schema.org terms are already in use (e.g. #91).

The new context file maintains most concepts from the original, but choses more existing schema.org properties to express them instead of inventing new terms. Type choices are also more closely aligned to schema.org types, avoiding the use of the equivalent xsd types. To help review these changes I've created an annotated version of the current v1 context file.

I've also posted the properties and types on the codemeta.github.io terms page, (analogous to the schema.org pages for Types, though the webpage doesn't have unique endpoints for the new codemeta terms yet). These tables are probably the easiest way to review the properties taken from schema.org and also the new properties introduced by codemeta: http://codemeta.github.io/terms/

Note that in addition to re-mapping some old codemeta terms to their schema equivalents, I've listed additional terms in the schema.org namespace that may be relevant to codemeta. See #139 Please weigh in if we want any of these new terms or not.