(JSON-LD) Metadata for software discovery

[arfon]

Following up on our blog post here I'd love to hear your thoughts on the idea of using JSON-LD as a lightweight metadata format for describing scientific software.

Some questions to get us started:

1. Is this a good idea? The goal when writing about this was to identify both a minimal amount of information necessary to cite software (and therefore receive credit as an author) but also format for doing such.
2. Is it an error to not consider dependency management here? NodeJS uses package.json to define dependencies. I'd rather see software dependency management handled separately (and not by this file).
3. What's missing? I'd love to expand this keywords block into a subject/domain/software function block - what schemas and ontologies are available for doing this?

{
  "@context": "http://schema.org",
  "@type": "Code",
  "name": "Fidgit",
  "codeRepository": "https://github.com/arfon/fidgit",
  "citation": "http://dx.doi.org/10.6084/m9.figshare.828487",
  "description": "An ungodly union of GitHub and Figshare http://fidgit.arfon.org",
  "dateCreated": "2013-10-19",
  "license": "http://opensource.org/licenses/MIT",
  "author": [
    {
    "@type": "Person",
    "name": "Arfon Smith",
    "@id": "http://orcid.org/0000-0002-3957-2474",
    "email": "arfon@github.com"
    },
    {
    "@type": "Person",
    "name": "Kaitlin Thaney",
    "@id": "http://orcid.org/0000-0002-7217-4494",
    "email": "kaitlin@mozillafoundation.org"
    }
  ],
  "keywords": "publishing, DOI, credit for code"
}

[hubgit]

Generally I think this looks good.

The citation property doesn't quite fit, as citation is meant to be an object cited by this work, rather than another identifier for this work - identifier would be better, perhaps, or @id?

Could it also have version and datePublished properties, to mark the date a specific version was released (as these are likely to be used in citation of this object)?

[hubgit]

SoftwareApplication ("A software application") might also be a better fit for some uses than Code ("Computer programming source code") - I guess it depends on what's being described, though…

[egh]

It might be useful to look at expanding citeproc-json to support software. See http://blog.martinfenner.org/2013/07/30/citeproc-yaml-for-bibliographies/ and https://github.com/citation-style-language/schema/blob/master/csl-data.json

[lanthaler]

Generally, I quite like your approach. I'm a bit on the fence regarding dependency management. Since your main use case seems to be citations, I think dependencies are the most "objective" citations possible and thus shouldn't be ignored. On the other hand, duplicating such information (e.g. in code.jsonld and package.json) and keeping it in sync might be problematic. Thus, it might be worth looking for alternative approaches that allow to enrich (aka mark up) existing descriptions such as package.json or composer.json.

Btw. are you aware of digitalbazaar/jsonld.js#39?

[gramian]

I added a code.jsonld file to my repository: https://github.com/gramian/emgr/blob/master/code.jsonld . +1 for using keys from SoftwareApplication, especially softwareVersion.

[westurner]

@egh re: research into citeproc-js, Zotero, RDFa, CiteProc : https://forums.zotero.org/discussion/35992/export-to-schemaorg-rdfa-andor-microdata/

[westurner]

@arfon
The SEON ontologies model much of this domain: http://www.se-on.org/ (I'm not yet aware of any mappings to schema.org).

• http://www.reddit.com/r/MachineLearning/comments/1dycyd/why_not_model_computer_programs_its_just_as_fun/c9vc0qa

'ircChannel' is one property that may be worth championing:

• http://www.reddit.com/r/javascript/comments/1fq6gj/use_irc_for_your_github_project_make_it_easier/cacxbxe

[mr-c]

Other overlapping approaches to consider either aligning to or working with:

Python's implementation of the Trove classifers: http://legacy.python.org/dev/peps/pep-0301/#distutils-trove-classification

Debian's Upstream Metadata format: https://wiki.debian.org/UpstreamMetadata#Fields

[danielskatz]

Also see "Implementing Transitive Credit with JSON-LD": http://arxiv.org/abs/1407.5117

[kaythaney]

Also, an update on this work just posted this week by @acabunoc : http://mozillascience.org/code-as-as-research-object-new-phase/

[brainstorm]

Relevant to this discussion too: http://softwarediscoveryindex.org/

[westurner]

Python's implementation of the Trove classifers: http://legacy.python.org/dev/peps/pep-0301/#distutils-trove-classification

Notes from http://lists.w3.org/Archives/Public/public-vocabs/2014Oct/0018.html:

[...] There are structured fields for Python Packaging metadata [2][3] and there are tables in warehouse [4]. [...]

.

Debian's Upstream Metadata format: https://wiki.debian.org/UpstreamMetadata#Fields

• http://packages.qa.debian.org/p/python2.7.ttl
• http://packages.qa.debian.org/p/python2.7.rdf

[RichardLitt]

Other relevant fields:

  "dateModified": "schemaorg:dateModified",
  "datePublished": "schemaorg:datePublished"

This brings up a larger issue, in that some of these examples may be arrays: particularly, citation (parts of the work can be cited in multiple papers), and repositories. We've already seen a lot of projects switch from local svn environments at universities, to sourceforge, to GitHub. It's important to make sure that we have a way of recording various changes in sources. An array like so:

{ 
  "codeRepository":  [{
    "dateCreated": "schemaorg:dateCreated", 
    "src": "git@github.com:mozillascience/code-research-object", 
    "url": "https://github.com/mozillascience/code-research-object", 
    "versioningSoftware": ["git", "svn", ...] 
  }, 
  {
    "dateCreated": ... 
  }], 
}