search

periodo / periodo-client

Client to browse and edit PeriodO data
https://client.perio.do
Other
15 stars 2 forks source link

How do you export a data source as a file? #191

Closed atomrab closed 4 years ago

atomrab commented 5 years ago

I don't see an option in the new client to export a local collection as a file. This is critical functionality in the workflow that I've used with both internal and external collaborators. Is it going to be added, or is there a way to do this that isn't apparent from any of the available menus?

rybesh commented 5 years ago

Yep, @ptgolden and I are aware of this and are working on putting it back in. The data source management stuff got completely rewritten and this was a temporary casualty.

atomrab commented 4 years ago

Just to put in another marker here, I'm directing several current contributors to the new client in order to take advantage of the additional fields, but I'm going to have a hard time checking their work (or preventing them from losing it in a cache-clearing accident) if we don't restore this functionality soon. Any movement on this front?

rybesh commented 4 years ago

Neither of us has had a chance to work on this yet, but it is still a top priority.

While it is needed for other reasons, do you think that you still need to look at the JSON-LD source to properly review someone's submission? We have tried reflect everything that is in the JSON-LD in the "review changes" UI. If there are things you feel are missing from the UI that keep you from reviewing properly or easily, it would be good to know.

atomrab commented 4 years ago

I haven't had a chance to patch a real submission yet, so maybe we'll use the École française as a test case. But I can say that having a potential submitter I'm working with send me a local file that I can open in the client, correct, and then send back with obvious corrections has been much better in terms of managing revisions that reviewing a patch and then having to explain in a narrative email what has to be fixed and why. The new interface looks like it will give me all the tools I need to accept or reject things with full information, but the file interchange has been a lot more productive for me, and I think has saved a lot of time. I assume it also makes it less frustrating for the contributor -- submitting three different versions and having them all rejected with a lengthy, wordy, obscure email from me about things to change would make me want to drop it, too.

None of this requires me looking at the source, by the way -- this is all about having a file that I can load into the client and check/correct there.

If it's helpful on this front, I can put together some of my longer email exchanges with contributors so that we have a project record of how this has played out.

atomrab commented 4 years ago

Just to put in another marker here, the download option is also important as a backup strategy. For some reason, my local PeriodO cache was cleared in both Firefox and Chrome recently (probably on my side, though I didn't do this manually, and I know Chrome wasn't updated), and while nothing critical was lost, I'm currently starting a much more labor-intensive phase and I don't want to lose hours of work across multiple authorities. Is there an ETA on this issue?

atomrab commented 4 years ago

I'm about to get a patch from the Ecole francaise, so we'll see if I can check everything fully with the patch review interface. For the purposes of collaboration, however, we definitely still want to be able to send files that can be loaded into the client back and forth. If, for example, the French do an all-French periodization, but our policy requires English labels and I want to save them the trouble by adding those myself, I'd need them to send me a file I can load in the client, load it, make the additions, download the new version, send it back to them, and then they'd load it on their side and submit the patch.

Alternately, we merge the patch without English labels and then I download their authority to a local IDB, add the labels, and re-merge it. This is perhaps more faithful on the provenance side, but it seems like there's more potential for error after the formal merge and generation of identifiers. I'd prefer to make sure the patch was fully formed before submitting it, hence the back and forth of files.

rybesh commented 4 years ago

First, rest assured that we understand the importance of being able to export an in-browser dataset and are working on that.

That said—your second alternative seems much preferable to me in this case. I'm not sure why you think it has more potential for error. It is good to know that the English labels were added later, by us, rather than as part of the original submission.

ptgolden commented 4 years ago

Implemented in b06c407181a78f60b2533e76d96e367772d01164 and 664dc137a671adebcc3c36f1987f08b1d95de2a8