Docmaps-Project / docmaps

Extensible protocol for document history metadata exchange, to enable trustworthy, rapid, open science, by and for preprint science communities.
MIT License
15 stars 1 forks source link

Add playground application #53

Closed ships closed 1 year ago

ships commented 1 year ago

Description

This new application is a simple stateless web app that allows you to visualize a docmap based on our Crossref-to-Docmap ETL library.

How to review

Take a gander over at the github pages hosting the app. You can plug in any DOI, and if crossref knows about it and it has reviews or a preprint, you'll get some interesting content back. A good one to start with is 10.5194/angeo-40-247-2022 .

Then glance over the code.

It relies on updates to render-rev that I have submitted via https://github.com/source-data/render-rev/pull/2 . Once that is merged, we can stop using the awkward fork-branch syntax for the new dependency.

It also relies on changes to the ts-etl package which are included in this PR. they should be released together automatically by multi-semantic-release.

Note that because the SPA is so minimal in logic it doesn't currently have lint or tests.

Related Issues

Resolves #45 Mutual with #15 Depends on #42

Checklist

Additional Information

Implemented using Svelte.

ships commented 1 year ago

@gabestein and @sheishistoric , feedback was that looking up docmap by DOI of a review object should produce docmap for the preprint it reviews. However, I'm realizing that we had decided something different last time we talked about that: see discussion on #49 and #48 . I am inclined to let the precedent stand, which means to pull this in without handling the "look up by review" case.

But I should fix the erroring behavior now, by essentially saying "we can't construct a docmap for this item, because it is a review; look up the preprint instead." maybe with helpful link.

I think that would make the SPA's behavior clear and coherent enough when user attempts this, without the complexity increase that we would pick up with #48 . Alternatively, we could change the desired behavior in #49 so that it returns a full docmap for the preprint; or implement that as an interim behavior expecting it to change (my least favorite of the options.)