Enable automatic assignment of DOIs to submitted tools?

[jure]

Perhaps?

We should take a look at https://github.com/arfon/fidgit to see what @arfon does. Are DOIs even necessary in this context? The floor is now open.

[arfon]

IMHO if you're going to issue a DOI then you also need to take a snapshot of the code. This is basically what fidgit does by persisting it into figshare.

[arfon]

...so to answer your question, no I don't think DOIs are necessary unless the functionality grows.

[jure]

Right, I agree, thanks for your input. When & if there is more functionality (user accounts, tool pages, gathering information about the uses of tools, etc.) maybe it would make sense to allow this flow:

• someone adds a use of a tool, e.g. it was used in a paper to calculate something
• ScienceToolbox asks the user what version of the code was used (commit sha)
• makes a snapshot of that commit and gives it a DOI

If another use appears using the same commit, you can reuse the DOI.

Thinking along these lines, this raises another question, how sensible are DOIs for versions of a tool as opposed to the tool itself. It makes tracking use harder, since there can be several DOIs per tool. But it also makes reusing easier, since we're talking about a specific commit.

Perhaps this is also a roll ScienceToolbox could play: top level of the hierarchy indexing all DOIs for a tool, e.g. "GET api.sciencetoolbox.org/astropy" returns

{ 
"DOIs": ["http://dx.doi.org/10.7554/eLife.01623.001", "http://dx.doi.org/10.7554/eLife.01623.002", "http://dx.doi.org/10.7554/eLife.01623.003"],
citations: ["http://dx.doi.org/10.7554/eLife.01623", ...],
stars: ...,
forks: ...,
url: ...,
...
}

[arfon]

I'd kinda like to see DOIs versioning which Dryad seems to support and I'm pretty sure the figshare and Zenodo folks are working on too.

[jure]

Ah, so by DOI versioning you mean a DOI that contains some kind of human-readable indication of a version, e.g. 10.7554/science_program.v2?

That would be cool, but I also think it's possible that DOIs for software are a bit of a mismatch. I know that everyone is used to them and a lot of services can consume them, but perhaps persistent URLs for ScienceToolbox, of the form http://sciencetoolbox.org/tool/LAICPMSmodel/v2 would be sufficient for citing purposes. We discussed this already and I think that's close to your opinion then, has it changed recently?

Semi-related: I'm continuing with the user profile in https://github.com/jure/sciencetoolbox/tree/users, and tool pages are next. A very interesting Google Scholar search is http://scholar.google.si/scholar?start=50&q=github.com&hl=en&as_sdt=0,5 Notice how I didn't use DOIs to find all that software... Indexing those 18000 results would give me a fantastic start for an index of open scientific software.

1/4-related: Would you be willing to hack on this for a while at #CW14? I'm going to come up with a plan soon, would be awesome if you pitch in with your ideas.

[arfon]

Ah, so by DOI versioning you mean a DOI that contains some kind of human-readable indication of a version, e.g. 10.7554/science_program.v2?

Yep.

but perhaps persistent URLs for ScienceToolbox, of the form http://sciencetoolbox.org/tool/LAICPMSmodel/v2 would be sufficient for citing purposes

I think it's acceptable but I think the ultimate goal should be to have people citing DOIs, right? That way it's a definitive reference.

Notice how I didn't use DOIs to find all that software...

:smile_cat: I suspect there's a lot of references to just GitHub there, not all to actual repos. I heard once that Google Scholar doesn't like being used as an API - do you know if this is the case?

Would you be willing to hack on this for a while at #CW14? I'm going to come up with a plan soon, would be awesome if you pitch in with your ideas.

:fireworks: let's do it!

[jure]

I know for a fact that Google Scholar does not want to be used as an API, but I wouldn't use it in an automatic fashion. I suppose I would do it in a semi-automatic fashion, so as to not break any licenses. Perhaps it would be sufficient to access data from individual publishers in an automated fashion instead, e.g.

http://www.sciencedirect.com/science?_ob=ArticleListURL&_method=list&_ArticleListID=-544448433&_sort=r&_st=13&view=c&_acct=C000228598&_version=1&_urlVersion=0&_userid=12975512&md5=96e8596c285d9ff1dce87150d9c6f187&searchtype=a

http://onlinelibrary.wiley.com/advanced/search/results

http://eds.a.ebscohost.com/eds/results?sid=7aee1740-f89e-4ff3-80e1-9a15a76eb741%40sessionmgr4005&vid=2&hid=4213&bquery=github.com&bdata=Jmxhbmc9c2wmdHlwZT0wJnNpdGU9ZWRzLWxpdmU%3d (2600+ results)

http://search.arxiv.org:8081/?query=github.com&in= (230 results) http://search.arxiv.org:8081/?query=bitbucket.org&in= (132 results)

Microsoft's Academic search does have an API: http://academic.research.microsoft.com/Search?query=github.com

But it only returns 21 results for GitHub and 2 for BitBucket.

If this is built in a modular fashion, we can start with building modules for sources that can be automatically indexed.

[jure]

I'll continue the discussion about indexing citations in #10.