-
Notifications
You must be signed in to change notification settings - Fork 4
Enable automatic assignment of DOIs to submitted tools? #5
Comments
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. |
...so to answer your question, no I don't think DOIs are necessary unless the functionality grows. |
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:
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
|
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. |
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: 1/4-related: |
Yep.
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.
😸 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?
🎆 let's do it! |
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://onlinelibrary.wiley.com/advanced/search/results http://search.arxiv.org:8081/?query=github.com&in= (230 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. |
I'll continue the discussion about indexing citations in #10. |
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.
The text was updated successfully, but these errors were encountered: