Research Objects Specs includes

• manifest constructiion
• relationships
• workflow - which is the basis of the Common Workflow Language http://www.commonwl.org/
• minimum information model

This issue was created by @SOFTowaha via Mozilla Science Lab Collaborate

Assuming that the GitHub fields are mapping to the repositories API I have some comments/suggestions for modification:

This issue was created by @nniiicc via Mozilla Science Lab Collaborate

Add 'JISC' to the 'Software Entities Model" column to indicate that this is a
recommendation for usage of DataCite metadata fields, summarized in the
paper http://rrr.cs.st-andrews.ac.uk/wp-content/uploads/2015/10/guidelines-software-identification.pdf.

Gabor's API for querying system dependencies in R packages, http://sysreqs.r-hub.io/ , defines a nice practical json format for defining the system dependencies of an R package, https://github.com/r-hub/sysreqsdb

Can be food for thought on describing dependencies(?)

Software packages can have different level of requirements, for example, R has the
levels

• Depends
• Imports
• Suggests

The crosswalk currently has 'Dependency', but fields for 'Imports' and 'Suggests'
should be added.

Any ideas on more generic names for 'Imports' and 'Suggests'?

This issue was created by @zuzzzu54 via Mozilla Science Lab Collaborate

Determine fields from the github api, i.e. https://developer.github.com/v3/#schema, and use
info from the 'detailed representation' of a repo:

curl -i "https://api.github.com/repos/octokit/octokit.rb"

Apologies if this has been previously discussed but I couldn't find anything about it.

I have a few thoughts about potentially missing concepts in the crosswalk. Specifically, I didn't see entries for publisher, the programming language used, or entries that link to different versions of the same software. Also, it might be good to consider the concept of SoftwareContributor in addition to SoftwareAuthor

I think publisher and SoftwareContributor are important in terms of attribution. Publisher needs no explanation. SoftwareContributor could include those that didn't write any code but nevertheless made a contribution (e.g., project management, administration). Explicitly stating the programming language(s) has implications for discoverability and reuse (e.g., searching for a library which is written in Python only)

The idea of linking together different versions of the same software are relevant to the Software Entities Model . I did see that dependencies were discussed in the JSON-LD project here but I think this is a sligthly different concept.

Thoughts?

Following discussion in FORCE2016 CodeMeta workshop.

I just came across DOAP -- Description of a Project, another minimal software description. This one is reasonably well formalized as an OWL schema. Project details here:

https://github.com/edumbill/doap

At OS Codefest, we developed a mapping between the fields used by FigShare, Zenodo, and Arfon's code.jsonld for comparison purposes. Formalize this mapping table for discussion. See:

https://etherpad.mozilla.org/oscodefest-softwaremetadata

The Trove software map is used in many different commercial software repositories and catalogues.

Originally developed by Sourceforge, it's not available from the original location https://sourceforge.net/api/trove/index/rdf so I have linked to the archive.org version.

http://ksiresearchorg.ipage.com/seke/seke14paper/seke14paper_71.pdf

Hello,

I'm in the process (with @khinsen) of creating a peer-reviewed scientific journal that lives on github and which is dedicated to the replication of results in computational science. It is not yet officially open but you can get a better idea at https://github.com/ReScience/ReScience/wiki.
We're currently in the process of testing the review system to check if will allow us to ultimately publish an article with the associated DOI through Zenodo (ReScience/ReScience-submission#3).

I've just stumbled upon your project and while I'm not sure how I can help, I would be definitely interested in following your progress and integrate the proposed standardized metadata it in the journal.

Nicolas

This issue was created by @rougier via Mozilla Science Lab Collaborate

Journal Article Tag Suite http://jats.nlm.nih.gov/

Should add PyPI package descriptions to the list of vocabularies in crosswalk.csv

http://ontosoft.org/software/

Arfon Smith created some example JSON-LD schemas that are related to this effort. Codify them for reference and extension. See:

http://www.arfon.org/json-ld-for-software-discovery-reuse-and-credit

One advantage the integrated Github -> Zenodo workflow seems to offer is that, in being assigned a DOI, the software is also then indexed, with metadata, in DataCite. Since we can query the DataCite API this seems like it would offer a plausible solution to a software discovery index (a la NIH's proposal for such an index, http://softwarediscoveryindex.org/).

So, perhaps the DataCite schema should also get a column on the crosswalk chart, to help track what metadata does and doesn't make it this far down the Github->Zenodo->DataCite pipeline (or any other pipeline that leads software to a datacite DOI).

Unfortunately, it seems the data that currently gets through this pipeline is pretty small (from a random example of software in zenodo: http://data.datacite.org/application/vnd.citationstyles.csl+json/10.5281/zenodo.15094).

Software citation requires being able to cite both the specific version used and the more general concept of a software product. Within the data world the idea of a Persistent Identifier that points at a specific version differs from a Series Identifier that points at a whole version chain, and that resolves to the latest version. Consider implementing this distinction in CodeMeta identifier semantics.

The Asset Description Metadata Schema for Software "is a metadata vocabulary to describe software making it possible to more easily explore, find, and link software on the Web. The specification reuses existing specifications, such as DOAP, SPDX, ISO 19770-2, ADMS, and the Trove software map. By using ADMS.SW to describe software in software forges, repositories, and catalogues, publishers increase discoverability and enable applications easily to consume software metadata."

However I'm not sure if anyone actually started implementing it.

Mozillian interested in science. This project could also be useful in peer-review to verify and reproduce results. Can contribute at any part of the stack (back-end or front-end)

This issue was created by @louisstow via Mozilla Science Lab Collaborate

Hi,

I'm interested in how to look at code or simple data structures as bases for puzzle-like interconnectivity among peers. On short if I write a piece of code, what would be the common data exchange path I should take in order for my app / code to talk with other's code.
This activity here looks promising.

This issue was created by @kosson via Mozilla Science Lab Collaborate

Does this refer to the code itself, or to the metadata? What provisions are there for editing metadata? Say that I have to update my email - how can I do that?

This isn't clear to me at the moment, but I may be missing something.

The Common Workflow Language (which uses JSON-LD :-)
http://www.commonwl.org/

There are many fields in the DCAT w3c schema that overlap with the proposed Code Metadata. It would be useful to review it:

https://www.w3.org/TR/vocab-dcat/

Add the following fields to the crosswalk concepts

• softwarePaperCitation
  • the citation for the paper that describes the software
• softwareCitation
  • the citation for the software itself
• downloadCount
  • download count of the software from a repository
• citationCount
  • count of citations for the software itself
• funding
  • funding for the research and development of the software
• relatedPublications
  • publications related to the software

I'd like to start including a citation metadata file following the codemeta standard with my software, but I'm a bit confused about what appears to me to be a chicken/egg problem: the codemeta schema wants an identifier (e.g. DOI)—but in order to get a DOI for my (GitHub) repo, I need to create a release of the software.

So, I'm a bit confused about the appropriate process here... if I create a release to get the DOI, it would be missing the full metadata associated with that release.

Consider / compare to metadata used by http://depsy.org?

@krzysztof mentioned that the pyld package would be useful to test the
codemeta.jsonld file from a unit test. The json-ld playground is
another testing resource but requires manual operation.

The Software Ontology (SWO) has similar classes. Add this to the mapping table.

See doi:10.1186/2041-1480-5-25 at http://www.jbiomedsem.com/content/5/1/25

Hello, I'm a science researcher in biochemistry, and I see the need for accessible, reusable, code in the fields of science. I'd like to see more professors cite the code that they use as a means of increasing reproducibility in science.

This issue was created by @claxtonh via Mozilla Science Lab Collaborate

I've been working in this area for a while, can contribute to discussion and documentation, trial and review code and docs, hack code (slowly).

http://www.researchobject.org/specifications/ includes relationships between things, manifest construction and workflow description, along with a minimu checklist ontology

• GitHub Guide on 'citable code' via Zenodo Integration https://guides.github.com/activities/citable-code/
• NIH vision for a Software Discovery Index: http://www.softwarediscoveryindex.org/
• This is a DataCite-based schema to represent software: http://rrr.cs.st-andrews.ac.uk/wp-content/uploads/2015/10/guidelines-software-identification.pdf

Hi all,

I'll throw my hat in the ring and say that I'm willing to contribute to this project, as I've found it useful in my investigations regarding research software preservation. I've made some updates to the crosswalk that I'm willing to share, though I can open separate issues/pull requests for those.

In the mean time I have a quick question about the crosswalk. Is there a reason that 'version' is not included in the Codemeta column even though it's there in the codemeta.jsonld, or is it just an omission?
-Fernando

I can't really contribute to the code, but I could certainly talk about the roadblocks in trying to cite software in my publications. Perhaps others can chime in as well?

The current context file is incomplete. Need to finalize handling of dependency elements and a few of the other fields.

http://figshare.com/articles/Minimal_information_for_reusable_scientific_software/1112528

Several of the terms in codemeta.jsonld have types that are currently serving as 'placeholders' until
more appropriate types can be determined, as neither schema.org or Dublin Core has something
close (maybe we have types added to schema.org or use another schema?). The terms that could be upgraded are:

• "accessList": "dcterms:accessRights"
• "buildInstructions": "schemaorg:URL"
• "citationCount": "schemaorg:integer"
• "contIntegration": "schemaorg:URL"
• "docsCoverage": "schemarg:integer"
• "downloadCount": "schemarg:integer"
• "embargoDate": "schemaor:date"
• "isAomatedBuild": "schemaorg:Text"
• "package": "schemaorg:Text"
• "inputs": "schemaorg:Text"
• "outputs": "schemaorg:Text"
• "function": "schemaorg:Text"
• "funding": "schemaorg:Text"
• "objectType": "dcterms:type"
• "programmingLanguage": "schemaorg:Text"
• "readme": "schemaorg:URL"
• "issueTracker": "schemaorg:URL"
• "relatedLink": "schemaorg:URL"
• "relatedPublications": "schemaorg:URL"
• "relationship": "schemaorg:Text"
• "testCoverage": "schemaorg:integer"
• "zippedCode": "schemaorg:URL"

http://casrai.org/CRediT/proposed-taxonomy/ <-- not working try:

http://www.cell.com/pb/assets/raw/shared/guidelines/CRediT-taxonomy.pdf

JSON-LD allows one to create a @context that is published in an external file and can be referenced by JSON files that want to import the JSON-LD context definition. This works like a schema definition for the vocabulary. Create one for codemeta.

We plan to categorize metadata fields by use cases. Set up a template and directory structure.

Many of the use case requirements listed in the use case table are necessary but not sufficient to handle the use case. Adding a column that indicates that 'Additional software metadata' are required for the use case would be useful.

The Software Discovery Index Report describes a system to identify, describe, and index software. They include an Appendix 1 which lists minimal software for metadata. Add it to our crosswalk table.