Permanent URLs about econ-ark.org

[sbenthall]

Looks like the Scipy Conference uses CrossRef for its DOI management:

[sbenthall]

https://www.crossref.org/display-guidelines/#full

More info about DOIs:

scipy-conference/scipy_proceedings#258

[llorracc]

We have several questions to resolve here, I think:

1. What do we need to do to consider an item "finished" and ready for archiving
2. When we declare a project "finished" and ready for archiving, where do we put it for permanent access.
3. There are a number of authorities who can issue doi's. We need an infrastructure for obtaining a doi and accomplishing whatever needs to be done

I think we should use this blog post and the associated REMARK as the first test case.

It's not clear to me what we should do in the short run. I'd put this fairly high on your priority list.

PS. Last summer we had a discussion about how we would like people to cite us, which resulted in the acknowledging page.

[shaunagm]

Re your questions:

1. That's up to you, but just because something has a permanent URL doesn't mean it can't be updated if there are minor changes like typos to fix.
2. My preference would be to keep it in Github, although that would require not changing the organization, repository name, or directory structure. Possibly we could ask Andrij to create a redirect from, say, econ-ark.org/resources/unique-string to wherever we were hosting in Github which could be updated if we had to. Or we could just host elsewhere.
3. There are a number of services that offer DOIs - Zenodo, Figshare, I think others.

My sense is that we should figure out question 2 first, then once that's set up we can use our permanent url to get a DOI from whoever we decide for question 3.

[llorracc]

cc'ing @DrDrij

Maybe a redirect is safer -- there are a number of items which are migrating between the REMARK and DemARK and HARK/example repos based on judgments about their content and structure, and based on that experience I feel that it might be wisest for the permanent link to be something we can rethink as the content evolves. Possibly the right solution is that at some point each "object" needs a UUID in some database, and its name is just a fallback. "At some point" being the operative phrase.