(JSON-LD) Metadata for software discovery
arfon opened this issue · comments
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:
- 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.
- 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).
- What's missing? I'd love to expand this
keywordsblock 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"
}
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)?
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…
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
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?
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.
@egh re: research into citeproc-js, Zotero, RDFa, CiteProc : https://forums.zotero.org/discussion/35992/export-to-schemaorg-rdfa-andor-microdata/
@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).
'ircChannel' is one property that may be worth championing:
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
Also see "Implementing Transitive Credit with JSON-LD": http://arxiv.org/abs/1407.5117
Also, an update on this work just posted this week by @acabunoc : http://mozillascience.org/code-as-as-research-object-new-phase/
Relevant to this discussion too: http://softwarediscoveryindex.org/
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
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": ...
}],
}
http://www.w3.org/TR/json-ld-syntax/#terminology :
array
An array structure is represented as square brackets surrounding zero or more values. Values are separated by commas. In JSON, an array is an ordered sequence of zero or more values. While JSON-LD uses the same array representation as JSON, the collection is unordered by default. While order is preserved in regular JSON arrays, it is not in regular JSON-LD arrays unless specifically defined (see section 6.11 Sets and Lists).
... @list (or @container in the context): http://www.w3.org/TR/json-ld-syntax/#sets-and-lists
@westurner Good point. Perhaps startDate, endDate, instead? Or an active field.
Looking at my code block above, I meant to have the value for codeRepository be an array of objects. I must have been tired; sorry about that.
Sounds like a good solution to me.
On Oct 14, 2014 8:55 PM, "Richard Littauer" notifications@github.com
wrote:
@westurner https://github.com/westurner Good point. Perhaps startDate,
endDate, instead? Or an active field.Looking at my code block above, I meant to have the value for
codeRepository be an array of objects. I must have been tired; sorry about
that.—
Reply to this email directly or view it on GitHub
#15 (comment)
.
May be OT, but TIL about the AppStream software package metadata interoperability spec:
@arfon wrote:
I'd love to hear your thoughts on the idea of using JSON-LD as a lightweight metadata format for describing scientific software.
Curious if you're targeting standalone scientific software or software used in the context of research. If the latter, it would be a shame to not include/adopt any of the existing metadata conventions for describing the underlying data that the software is designed to consume.
Relevant discussion of the potential of JSON-LD as a format for dataset metadata at frictionlessdata/specs#110.
The use case that this needs to pass to make it useful for processing.
Given LD info on some web page, provide Edit this page on Github link. For example http://trafficserver.readthedocs.org/en/latest/
