bnewbold-archive: Comments and Annotations

Edit History - Comments and Annotation History

On mf6uwg7hjrckllvwrtoizyp22m at 2022-01-22 02:32:40

I don't see any actual edit here (in the diff)

On rldysjmpk5bu7d5ef6lkbip2im at 2022-01-05 15:29:39

This is just a landing page, not the actual article.

On 3csnpaqsuvau5mhgtxrldnnnqy at 2021-12-08 19:24:16

The single webcapture in this editgroup ( is paywalled.

On axv4kgrjofgn5phzi7q4drbreq at 2021-12-08 19:22:20

As far as I can tell this edit makes no change?

On ufrygqwkrrg4lc4coocyn76uoi at 2021-11-29 21:40:29

Interesting. This DOI was not auto-imported from Crossref because the publisher has not deposited a "title" in the DOI metadata:

The norm in fatcat is to normalize DOIs to lower-case. I will update this release after importing.

On iyux5axnujgove4gjn5k4552zq at 2021-11-20 00:23:11

Thank you for this contribution!

The updates to existing articles look good.

The updates to the container are mostly good, though the "URLs" should include only homepages, not references to other platforms (like DOAJ).

Some of the new releases look like they are duplicates of existing releases.

I can update this editgroup to correct the above issues, or wait for you to "unsubmit" (hit the "edit" button above), make changes, and then re-submit.

On lygprmypzzhsni2lcz336yctbm at 2021-11-15 21:10:37

This is a paywalled article; the web capture only includes the abstract. Not merging.

On gpvsm2f66ba3nd6ingx3ucqxg4 at 2021-10-04 05:31:13

This file is not the entire book, just some front matter

On jwf72dszkjc3bfvn6rnoww54ru at 2021-08-30 20:40:36

Thank you!

On v74oq3jqjjegjn3mrslf2ugqa4 at 2021-08-25 17:42:53

These mostly look good, but I don't consider Researchgate is a "publishert" in the traditional sense, only a platform / network. So I think the release stage should be set to "draft" or "blank" on these, and the publisher field cleared. Please comment here if you update the editgroup. If I don't see an update

On rsftzdxvuvawfgzqdm55juibwu at 2021-08-25 17:35:47

Sorry for the slow review on this. It was a large group!

On vn5ntinlgzfrvlem2rz6sdnd5q at 2021-07-26 17:16:43

The most recent edit looked good (, and I accepted that.

This editgroup and the other old one are now in limbo. I have "un-submitted" it so it doesn't show up in the global submit queue, but it will show up in your active editgroups. Adding support for deleting/archiving non-active editgroups is a known TODO, but not supported at the moment.

On vn5ntinlgzfrvlem2rz6sdnd5q at 2021-07-12 18:47:12

I think the term that applies in this case is "withdrawn", as opposed to "retracted". Usually a retraction involves publication of a separate "retraction notice" document. The terminology and norms are a little fuzzy and probably vary across disciplines. In this case I think the withdrawn_status field on the release entities should be set to the string "withdrawn", and the withdrawn_date and/or withdrawn_year fields should be filled in (if known). The release_stage field should still be "draft". Possibly the release_type could be switched to "stub", if these were accidentally uploaded and represent an accidental publication; if they were intentionally published and are now just deprecated/withdrawn, the release_type would stay as article or article-journal. When the withdrawn_status field is set, these release entities will be visually flagged and will be suppressed in search results. It is important to keep some database record with the registered DOIs in the catalog. Otherwise, our automated bots are likely to re-create the records in the future. Definitely open to feedback on these policies and metadata options. Our chat channel might be a better place to discuss:

On rsftzdxvuvawfgzqdm55juibwu at 2021-07-08 18:55:23

Same comment here as for We intend to maintain a catalog entry for each registered DOI, even drafts.

On vn5ntinlgzfrvlem2rz6sdnd5q at 2021-07-08 18:54:30

Hi! Because each of these releases has a distinct, registered DOI, our policy is to retain them as release entities in the catalog. Two metadata improvements that should be made are to mark all of the earlier versions of the work as 'draft' or 'submitted' as appropriate (in the release_stage field), and to merge them all under a single work (via the work_ident field). For figshare specifically, we intend to do automated merging of releases into works at some point, based on existing metadata and the structure of DOIs. Having the releases merged under works should improve the user experience on, eg,, which returns a single hit per work (not one per release). Thanks for submitting this edit, and sorry if it took a long time.

On jxhip7wazfebzlbkq3lgtucwgi at 2021-06-23 19:30:09

Sorry for the slow approve!

On cz6nn2jtrvhw3lozs5lof5geay at 2021-04-15 17:15:30

These look like "overlay" journal articles (which I am a big fan of!). It might be good to do some merging at the same time: either merge the release entities directly (so there is one release with the EPTCS DOI number and an arXiv identifier on the same release), or at least merge the releases under the same "work". I will admit we don't have much documentation or guidance on the "merge" process yet.

On 3kv4vhv7rzaa7hmiwjgw6ii3ty at 2021-04-12 17:07:06

This looks just right! In particular the work_id linkage, and setting the number field for the report ("report number").

On szfubtxhwrgzboa2yxaqjy2fmq at 2021-04-09 03:18:03

file_tijbcriqqvcfhlp7iskyebkdpy didn't get linked to a release; should it be release_uuo422mbg5bblmkyuwxaqqrpzu? ("Tcl: An Embeddable Command Language")

There is also a missing link between the created container and the created release.

I this editgroup is a good example of a bug I can see in the "edit an existing editgroup" workflow, where the release entities here are new, but appear as "updated".

On oeqfxxckvbalhe4v6uuvwraecy at 2021-04-07 00:37:41

Thank you!

On jrla2ddtfbgkhgfjxpevipbu4i at 2021-04-07 00:30:25

Did you mean this wikidata entity?

This edit currently has:

On tmde6kawtfgmviewhjrd4yhdr4 at 2021-03-30 18:03:03

Updated edit now has a homepage URL and publisher has been updated, great!

On tmde6kawtfgmviewhjrd4yhdr4 at 2021-03-24 21:19:26

I don't see any actual change in this edit, so "unsubmitting" for now

On 6jhp6y3f5bb7xi2brj76dswc6a at 2021-03-21 01:55:19

Thanks for your submission. It currently works a lot better to submit locations (URLs) via the "save paper now" interface: This will result in the file getting crawled by Internet Archive, and fills out a larger set of metadata (eg, SHA256 in addition to SHA1). I have submitted this URL via save-paper-now, and will un-submit this editgroup.

On czpwj5rqpvdvbntbbbnihpvcma at 2021-03-12 09:06:24

As a small detail, the Zenodo metadata for this particular DOI (a specific version of the work, "v1") has not been updated on Zenodo. But we'll accept the metadata update here.

On wtfmzuoynjckxgymqfrdihsqxu at 2021-03-12 09:01:39

The urls field, under extra, is an addition for releases I think. Thus far have avoided aggregating lists of links to "other locations", but open to adding them in some cases. To establish a reference and precedent for the edit, the ACL URL could be mentioned in the edit description (the field than currently says "Add my full name"). Or we could add another edit metadata field like reference_url or something like that.

On 2gu24s25rjhytpagh37ap77piy at 2021-03-03 02:34:28

Not sure we want to be including researchgate copies for now, so not accepting.

On nhob3337cnczjgxs2vtjpiqa2u at 2021-01-26 20:08:02

Hello! Thank you for contributing to Fatcat. The intention of the "urls" field for containers (journals) is to list only the canonical/authoritative web location of the journal itself, not references to third party sites.

On oqtblsxddbeuxculr4wb4wfz6e at 2020-11-19 19:43:23

hello! thanks for the edit, particularly the ISSN-E and ISSN-P fields. I am going to do a follow-up edit with two changes: the URLs should only include links to the homepage of the journal itself, not things like DOAJ or Google Scholar. And there is a separate field for abbreviations; they should not be included in the "title" field.

On l76vdsgkyngthkvvm3e6pfcikm at 2020-10-14 05:35:44

I agree and think there was confusion; there are several journals with very similar names. I updated a couple of them, including the container this editgroup was changing, here: I am going to "unsubmit" this editgroup so it doesn't show up for annotation. Currently there is no mechanism in the workflow to "decline" or "undo" edits.

On 7lwa2lc4kjec5jx72qtka7n3eu at 2020-10-14 03:35:28

Hi! I'm not sure why this edit removes the kbart.pkp_pln metadata for this item. Maybe because the editgroup started a long time ago? Something we should check for automatically. Regardless, I am going to edit the editgroup to merge the metadata.

On wzw3hiom3fdp5jhozrcepg6ixe at 2020-07-09 07:40:24


On 5f63ptxw7fgwdgenfh67fjuzei at 2020-06-01 16:56:33

As a follow-up, I pushed several of these changes through manually.

On 5f63ptxw7fgwdgenfh67fjuzei at 2020-06-01 05:11:16

Hi! Thank you for your edit. Two notes: - if the name and original_name are identical, there is no need to include the original_name - the country should be in ISO two-letter form (in this case, "id"). Neither of these are currently explained or enforced in the web interface; sorry about that!

On cvfyvjhau5gqrl3sppfapsezvu at 2019-12-21 02:12:31

Hello! Thank you for your edit. I think the two changes here are to add a Wikidata QID for the container, and to add "English" as the original name. The Wikidata ident is great, but original name is supposed to be for non-english names (if one exists). I'm going to "edit your edit" to remove that, and also re-capitalize the name.

On yfd2ydur5fbnvitqbgt23b5grm at 2019-10-11 01:34:12

This is an example comment on an editgroup. Hooray review!

On 72cueakghfayfmgtjcjnnvapye at 2019-08-12 21:47:04

@bfirsh indeed, edit previews generally don't show inbound graph relationships. The sort of wonkey reason is that when viewing an edit preview you are viewing an entity revision independent of the identifier, and graph relationships are based on identifiers. Of course, in the context of an edit preview (or history views) there is a specific identifier in play, so they could be auto-populated. I created a github issue.

Two other notes while i'm here:

  • The user experience of these edit threads isn't great yet; you won't get any indication (eg, an email) that i've replied to your edit
  • A full/proper entity "merge" doesn't work yet, eg redirecting one of these release entities to the other, via the web interface. Redirects can be done using the API.
On tevoriozbbcmljrcpqzpw4ndae at 2019-04-11 01:13:07

Looks good to me!

On d6g5ealebje3pl2ngslrdtn4ou at 2019-04-10 03:47:13

First comment in production, horray!