Talk:Wikicite/grant/WikiCite addon for Zotero with citation graph support

Questions

• Have you notified the zotero community of this plan? Can you provide a link to their discussion to gauge their interest?
• How will you avoid users of this plug-in from creating duplicate entries?
• Can you provide some data on the level of adoption of Zotero?
• Zotero is backed by a for-profit company, right? Are they willing to commit something for this? E.g. running the Grobid server.

Thanks, BrokenSegue 18:31, 29 September 2020 (UTC)

@BrokenSegue: Thanks for your questions!

• Have you notified the zotero community of this plan? Can you provide a link to their discussion to gauge their interest?

I have. I have just updated the Community notification section to reflect this. In particular, I have posted to relevant Zotero forum threads here, here and here, and to the Zotero subreddit.

• How will you avoid users of this plug-in from creating duplicate entries?

In general, the plugin will automatically query the WikiData API to check for duplicates before requesting any edits.

In particular, for citations: only citations between Zotero items both with QID will be available for syncing to WikiData. Therefore, it will be easy to check here if QID 1 already "cites work" QID 2.

On the other hand, for publications themselves: I still have to look into this more carefully. In principle, the plugin would reject any new entry creation if there is an item with the same UID (e.g., DOI, PMID, etc) or title in WikiData already. In addition, an approximate query by title may be requested and the user would be asked for confirmation if a close match is found.

• Can you provide some data on the level of adoption of Zotero?

Sure:

• • In a survey run in 2015 among 138 graduate students in a Canadian university, "Ninety-six respondents indicated that they used reference management software (...) the top four programs used were Mendeley (39%), EndNote (20%), Zotero (16%) and RefWorks (10%)". Of these four, only Zotero is open source.
  • Results were remarkably similar in this 2015-2016 Innovations in Scholarly Communication survey: Mendeley (35%), EndNote (19%), Zotero (13%) and RefWorks (11%).
  • This resource review from 2018 does not provide usage data, but chooses RefWorks, Endnote, Zotero and Mendeley as "popular tools" and highlights that Zotero is the only open source among them.
  • As a proxy for newer data I can provide Alexa Rank popularity for their websites (higher is less popular): Mendeley (4951), Zotero (16604), Endnote (36898), RefWorks (367400).
• Zotero is backed by a for-profit company, right? Are they willing to commit something for this? E.g. running the Grobid server.

As far as I know, it is "a project of the Corporation for Digital Scholarship, a nonprofit organization", according to their website's footer. According to its Wikipedia entry its development has been funded by the Andrew W. Mellon Foundation, the Alfred P. Sloan Foundation, and the Institute of Museum and Library Services, as well as user donations.

Although having a Grobid server running somewhere would be ideal, it is not crucial for the success of the project. In the meantime, users with enough technical skill can run their own instance, or they can use the Scholarcy Reference Extraction API.

Having said that, I agree it would nonetheless be great if an instance could be available on either Zotero or Wikimedia servers.

--Diegodlh (talk)

Remarks

• Kerko could be another example of a tool that provides a less than ideal solution to compensate for the lack of support for citation graphs in Zotero (see how Kerko handles this). Users would really appreciate a solution that's better integrated with Zotero. Note: I'm the author of Kerko. --David Lesieur (talk) 20:40, 29 September 2020 (UTC)

@David Lesieur: I didn't know Kerko. Great tool! Thanks for sharing! I will mention it in the proposal.

I still haven't decided what would be the best way to store citation information. In the extra field? In a Note, like you and the Zotero Plugin for Open Citations do? In a plugin-specific database? This is one of the things I have to look into more carefully. Comments and suggestions would be welcomed! --Diegodlh (talk)

@Diegodlh: Since Zotero's sync mechanism would automatically handle the Extra field or notes, any of those sound like an easier implementation choice than a plugin-specific database. --David Lesieur (talk) 19:07, 6 October 2020 (UTC)

• In case you find it useful, a few weeks ago I have searched the Zotero forums and GitHub issues on the subject of the citation graph or, more generally, semantic relations between Zotero items. Here are my main findings:
  • Semantic relations (still relevant, but from 2007-2008; links types of relations; mentions that the solution should be based on the future "custom fields" mechanism, which doesn't exists yet)
  • According to @dstillman, a Zotero developer: "eventually we'll support unidirectional, semantic relations with more meaningful predicates" (2014)
  • Hierarchical Item Relationships (from 2007-2009; discusses modeling with RDF, relation types in FRBR)
  • Many dead threads on typed and directional relations (from 2007-2019; there are probably more)
  • Citation analysis (2012)
  • Fetching references on import (2019)
  • --David Lesieur (talk) 21:29, 29 September 2020 (UTC)

@David Lesieur: Thank you, David! These remarks are really useful. In general, I will consider all these threads carefully to make sure any decisions about the plugin are compatible with future paths the Zotero community may be considering.

In particular, regarding "related" items, I agree that directed and labelled relationships would be useful. However, I wouldn't use the "related" field as a replacement for a "cites" field: only items which are both in Zotero already can be "related", whereas the "cites" field should be more general, allowing works one does not have in the library. Nonetheless, I do agree that both fields should interact: for example, it would make sense to relate items A and B if B is entered in A's "cites" field.

Regarding custom fields, I agree a convenient way to save citations would be in a custom "cites" field. In the meantime, an alternative would be to use the extra field, which is where the BBT plugin's export to citation graph looks for citations, and which is one of the options I'm considering for this proposal's plugin. --Diegodlh (talk)

@Diegodlh: I really appreciate the flexibility that you propose for the citation editor (if I understood correctly), in having the tool relate items in Zotero when they exist in the library, and allowing to cite library items that don't yet exist in WikiData. --David Lesieur (talk) 19:07, 6 October 2020 (UTC)

• I think many types of relations would be useful to researchers, aside from Cites and Cited by. I'm not familiar with WikiCite's data model, and that might be out of scope for your project, but support for something like the Citation Typing Ontology could be awesome. --David Lesieur (talk) 21:29, 29 September 2020 (UTC)

@David Lesieur: I definitely agree! In fact, my initial idea included supporting these citation "reasons", for which I wanted to propose a "reason" qualifier to the "cites work" (P2860) in WikiData. However, upon writing the proposal, I realized it was quite some work already, so I decided to drop it for now. But I did mention it as something that could be added in the future! :) --Diegodlh (talk)

@Diegodlh: That is a wise choice. ;-) I agree, there is a lot in the proposal already! --David Lesieur (talk) 19:07, 6 October 2020 (UTC)

Documentation

@Bluerasberry: I'm reposting and answering here the question you asked in the proposal:

Can you increase the budget and the allocation to documentation? Currently there is $180 requested for 9 hours. The wiki community thrives on accessibility and documentation. People may translate or adapt the text you produce now, so it is important to get this right. This project has a multiplatform software component (wiki + zotero), and already has global and multilingual community use, and which has some big technical, social, and ethical issues embedded in it. The WMF should provide some guidance on what kind of documentation it would like to fund and how much time to spend on this, but I see 9 hours as not enough. The proposer is from a Spanish speaking country, can you do English + Spanish documentation from the start? Do you both Zotero and the Wikimedia platform? Can you do documentation of "connecting Zotero to the wiki community" and "Wiki for the Zotero community"? I do not have great or high expectations for documentation, but if this project goes forward, I do not want people to see the tool and not be able to understand its basics. To throw a number out: if there room to increase the budget then I think 80 hours of documentation could be worthwhile. Document the code you develop, how to use it, and in English and Spanish user guides from perspectives of both Zotero and wiki. Truthfully, I care less about the actual tool than finding someone to write about how this should be done and what users need to know. We can always hire a developer to make a tool, but we cannot always find someone who understands the user communities well enough to explain what features matter.

—  Blue Rasberry , 13:18, 30 September 2020 (UTC)

As I see it, the plugin shouldn't be very complex. The idea is to integrate ideas and tools in a simple well-defined workflow. It will be as self-explanatory as possible, for which it will include tooltips and help messages where needed.

Anyway, I understand the need for documentation. The original 9h budgeted include writing basic documentation to install the plugin and describing its features.

Can you do documentation of "connecting Zotero to the wiki community" and "Wiki for the Zotero community"?

The presentation event will have an introduction in which I will explain the very basics of Zotero and WikiData. Now that you mention the topic I realize (in fact, I love the idea) that I can easily upload this introduction as a video tutorial, both in English and in Spanish (given that there will be an event in each of these languages). This introduction will also guide participants through the activities they will be engaged in: plugin installation, using the plugin to fetch citation data, identifying items without QID, manually or automatically add citation information to these items, upload these data to WikiData, and obtain citation graphs for their collections.

if there room to increase the budget then I think 80 hours of documentation could be worthwhile. Document the code you develop, how to use it, and in English and Spanish user guides from perspectives of both Zotero and wiki.

Writing this user guide may mean translating the video tutorial into a written user manual. I think 80h may be too much for this. Maybe 40h would be more reasonable. That would take the documentation budget to 800 USD$ and the total budget to 8540 USD$. If the rest of the community and the committee think it would be worth it, it can be done. Anyway, the video tutorial will be out there if somebody else would like to do it instead.

Finally, code comments and instructions to set up a development environment, so that other developers can contribute in the future, are part of the development hours already. --Diegodlh (talk) 15:06, 2 October 2020 (UTC)

@Diegodlh: Thanks for your consideration and reply. Yes, I support what you are saying. Videos like that would be great documentation and this world with more online meetings and fewer in person meetings needs more video. I support what you propose. Thanks. Blue Rasberry (talk) 15:41, 2 October 2020 (UTC)

Twitter thread on reference extraction strategies

I would like to link to a recent thread in Twitter because I think it is relevant to the discussions we are having here. Phil Gooch, founder of Scholarcy has confirmed the limits of the Scholarcy Reference Extraction API which I planned to offer in addition to Grobid: "We've removed rate limits except for max 1 per second (could reduce further if there's funds to pay for a bigger server) and file size limit is currently 11MB but can increase that. Limits are due to running on $7/month Heroku dyno". In addition, he pointed out that the public GROBID demo server may have an API (I thought it was just PHP). However, it would still be for testing purposes, so I should talk to the developer before using it in the plugin. Sebastian Karcher, one of Zotero's contributors, was also involved in discussing AnyStyle as an alternative references parser. --Diegodlh (talk)

Works and versions

Hi, what are your thoughts about dealing with Wikidata's use of works (d:Q386724) and versions (d:Q3331189)? And if a data model is locked into software, can it still be refined and revised in future? Pelagic (talk) 09:21, 12 October 2020 (UTC)

@Pelagic: I apologize for the looong delay in replying to this! I thought I had email notifications turned on, but apparently I hadn't :(. I'm not sure I understand what you mean. Could you please elaborate on your questions a bit further? Thanks! --Diegodlh (talk)

Hi, Diegodlh, no worries about the time gap. Regarding the work/edition split... For example, George Orwell's Animal Farm (Animal Farm (Q1396889)) has had many editions by different publishers over the years. So info like publisher, year, number of pages, etc. for the 1964 Longmans edition (Animal Farm (Longmans 1964) (Q98690789)) would be different from other editions. Academic papers don't often get republished in other journals, but it does happen. An academic preprint might differ from the final printed version, e.g. in pagination, or there might be substantive differences before and after peer review. A paper might appear in conference proceedings then later slightly revised as a chapter in a monograph. then page numbering matters. If you're citing an article as a whole (as is common with scientific papers), you may not care whether it's the pre-print or the final.

Stephen Debus' Birds of Prey of Australia has new content in the 4th edition that wasn't in the 3rd, so it would be important to state in a citation which one you're referring to, and we'd end up with Wikidata items for both. Each edition would be an {{{}}} of Birds of Prey of Australia. I haven't used Zotero, so

There have been discussions about constraining some properties to only be allowed on editions but not works, but no consensus was reached that I remember. If you're storing the Zotero data as work (Q386724), then standard practice on Wikidata settles on the idea that a stand-alone entry should be a version, edition or translation (Q3331189), how hard is it to adapt the software to that change? (My own preference would be to create just version, edition or translation (Q3331189), though others would insist on having both work (Q386724) and version, edition or translation (Q3331189). If you do both, then that could affect the design a fair bit.)

Does that make sense? —Pelagic (talk) 22:41, 23 December 2020 (UTC)

@Pelagic: Oh, I see! Sure it makes sense! Thank your for raising this topic. My background is mostly experimental science so I am mostly used to paper citations, but from time to time I do come across other work citations such as books and book chapters. As far as I am aware, these citations tend to include the specific edition (publisher, edition number and publication date). Therefore, it would make sense to point at/create an edition rather than a work in Wikidata. Does this make sense? I have been working on the plugin's citation support module so far and I will start working on communication with Wikidata now, so this will be helpful. Also, your comment made me realize that supporting citation of specific pages may be useful as well. Right now I'm focusing on journal article citations, which I would hazard a guess that they are the most frequent citations in Wikidata (I'm downloading a recent dump to confirm this, because the SPARQL query is timing out), and as you said they are often cited as a whole. But I have posted this as a feature request in the Github repo I'm starting for future reference. --Diegodlh (talk)

Proofreading usecase

I like this idea; years ago, painfully proofreading and correcting publishers' errors, in Zotero, and manually sharing the resulting files with others, I wished for such a tool to more efficiently crowdshare the proofreading. It really is surprising how often publisher's own metadata will fail to list all the authors, mangle the Unicode to ASCII, or even get the title or year of publication slightly wrong. Please consider this usecase. There is a possibility that the Zotero maintainers, who get funding from paid cloud hosting of Zotero content, may not like this tool; I hope this is not the case but it might be worth checking. HLHJ (talk) 02:05, 19 October 2020 (UTC)

@HLHJ: Sorry for the looong delay in replying to this! I thought I had email notifications turned on, but apparently I hadn't. Thank you for your comments. Do you mean specifically citations metadata? Although not considered in the original proposal, eventually I would like to add an option to download citation metadata from Crossref as well. If I understood your comment correctly, I think this may help as a starting point for your proofreading. On the other hand, I don't see how this plugin would compete with Zotero's paid cloud hosting. As far as I know, their cloud hosting is for syncing file attachments, not metadata. --Diegodlh (talk)

Diegodlh, I did mean citations metadata. Zotero already downloads Crossref data with its ref autocomplete. The errors I describe were in the Crossref data! And Crossfref is really not Web 2.0, it's controlled by some sort of publishers consortium, and trying to get anyone to correct their database can be an exercise in frustration. But if the metadata is on Wikidata, I can correct it myself. If the source isn't in Wikidata yet, I want to be able to type the correct data into Zotero, then semi-automatically upload it from my Zotero database to Wikidata. People would be much more likely to do this if the interface of your addon was designed to make downloading from Wikidata and uploading to Wikidata an obvious and easy possibility. Please let me know if I am still not clear, here wouldf be a good place to ping me. HLHJ (talk) 02:26, 25 January 2021 (UTC)

@HLHJ:, thank you for your clarifications. I will try to address your concerns:

> Zotero already downloads Crossref data with its ref autocomplete.

That's true. I meant I would like to eventually add an option to download references metadata from Crossref. That is, information about what other works are cited by a given work. Actually, this information is already downloaded from Crossref along with the rest of the metadata, but it is currently discarded by Zotero.

> If the source isn't in Wikidata yet, I want to be able to type the correct data into Zotero, then semi-automatically upload it from my Zotero database to Wikidata. People would be much more likely to do this if the interface of your addon was designed to make downloading from Wikidata and uploading to Wikidata an obvious and easy possibility.

This is exactly what I have in mind, for cases for which the source (I understand the cited item) isn't in Wikidata yet. Let me expand on this a bit more. This plugin will focus on relationships between Wikidata entities (through the "cites work" P2860 property) rather than on entities themselves. Nonetheless, it will support creation of new entities for works not yet available in Wikidata. Consider these cases:

a. you will be able to add citations manually (offline) to any item in your Zotero, irrespective of whether the source/citing or target/cited items have QIDs (i.e. are in Wikidata or not).

b. you will be able to fetch the QID for any item in your Zotero, or for any of its cited items, from Wikidata. In principle, this will only be supported for items (citing or cited) with persistent identifiers such as DOI or ISBN. If no matching entries are found in Wikidata, the plugin will offer to create a new one using the local item's metadata.

c. if both citing (A) and cited (B) items in Zotero have QIDs, the plugin will offer to upload this citation link to Wikidata. That is, add a "cites work B" claim to entity A.

d. for any citing item in Zotero with a QID, you will be able to download citations from Wikidata unknown of locally. In these cases, the cited item metadata will be downloaded from Wikidata.

b and d will be the only two instances where item metadata other than citation links (i.e. title, authors, etc) will be copied to or from Wikidata, respectively. If citing and cited items already exist both in Zotero and in Wikidata, the plugin will just make sure the citation link between them remains synced. That is, if they are unlinked in Zotero, it will offer to unlink them in Wikidata too, and vice versa.

In the future, I may add the possibility to keep the other metadata (title, authors, etc) synced as well. That is, update the Zotero citing or cited items if they are changed in Wikidata, and vice versa. But I will keep it simpler for now.

The projected communication betwen Zotero and Wikidata seems a bit difficult to explain, but I hope it will be clearer soon when I publish the second pre-release version of the plugin, which will include some syncing capabilities with Wikidata already.

I hope my answers helped with your questions. Let me know if some things continue to remain unclear. Best! --Diegodlh (talk) 19:19, 25 January 2021 (UTC)

Fulltext/image feature request

Zotero items may include fulltext files. Could the proposed tool please support uploading suitably-licensed fulltexts to Commons (PDF) or Wikisource (machine-readable formats)? I realize that Wikisource importer for a variety of machine-readable formats could easily become a significant separate project, and the importer would probably be best hosted on Wikimedia, and this is well out-of-scope. A design that could interface with any such importer would be useful. Uploading split-out individual figures to Commons could also be advantageously automated (manually splitting out images is tedious; see also this proposal). Fulltext uploads may need individual manual activation if fulltext licensing is not machine-readable. Of course, Wikidata and Commons files should interlink. Any subset of this feature request would be useful. HLHJ (talk) 02:05, 19 October 2020 (UTC)

@HLHJ: Thanks for your comment. Your suggestion looks interesting, but I'm trying to keep the plugin as Wikicite- and citations-specific as possible. It may be a good idea for a separate plugin though. Thanks! --Diegodlh (talk)

Lock-in/dependency problems

Pelagic already mentioned this, but I'll make a separate section. Zotero now has a huge tangle of dependencies, reportedly making it very difficult to package. This is especially problematic for those without an internet connection, a major usecase for a citation database that anyone can mirror on an intranet (see Afripedia). Other programs have also copied some of Zotero's capabilities. While Zotero is still the most popular of the open-source programs, I not longer find it as attractive as it once was. If, however, the proposed tool can be made such that it can fairly readily interface with other citation managers, including potential future software, I would support that. HLHJ (talk) 02:05, 19 October 2020 (UTC)

@HLHJ: For now I'm developing the tool as a Zotero plugin, but I would be happy to help porting it to other citation managers in the future! Anyway, although the synchronization with Wikidata does need an internet connection, of course, the part that adds citations metadata support to Zotero can be used offline. In fact, eventually I would like to add a preference setting to use a custom instance of Wikidata that may be running locally instead. Hope this helps! --Diegodlh (talk)

Bib transfer

As a subproblem... Is it possible/would it be possible to export publication item as BibTeX and create items from BibTeX? Infovarius (talk) 21:22, 15 December 2020 (UTC)

@Infovarius: Sorry for the delay in replying to this! I thought I had email notifications turned on, but apparently I hadn't! I like this idea. So the plugin may have "import citations from BibTeX" and "export citations to BibTeX" buttons for any one item in Zotero, correct? I have added this as an issue to the plugin's Github repo. There is almost nothing there yet, but I will start uploading code very soon. Thanks! --Diegodlh (talk)

v0.0.1 very early pre-release published

I have just published the first very early pre-release of the plugin. So far I have only focused on the plugin module that adds citation metadata support to Zotero. The idea was to have a general data model and structure around which the other modules will be fit in as development continues. I can't emphasize enough how early a pre-release this is, but I wanted to show what I've been working, how my general idea looks like, and make the source code and repo public so we can move some of the technical discussions, feature requests, etc there. Briefly:

• It adds a Citations tab, where users can add, remove and edit citations metadata.
• Citations metadata is currently saved in the item’s extra field, but it will soon be moved to a note attachment.
• The Citations tab also includes shortcuts to modify source item UUIDs, such as DOI, QID and OpenCitations Corpus ID (OCC), which may be helpful for communication with Wikidata and other online providers.
• Placeholder buttons have been included for different actions, such as citation import, export and syncing, both at the item and citation level, and also for multiple-item selections. None of these actions is supported yet, but they will be implemented as the other modules of the plugin are developed.
• Right now the focus is on Journal Articles (both as source and target items), but support for other types of works is planned.
• Some stylistic improvements are pending also, including better element alignment on the Citations tab, making the Citation editor window more Zotero-like, etc.
• And probably many many bugs I haven’t had the time to identify yet, but which I expect to be polishing as development continues.

Now I will start working on the next module: communication with Wikidata.

Screenshot showing the Citations pane added to Zotero by the WikiCite plugin v0.0.1. Citation count, Add citation button, and More item actions button are shown at the top. Then, three citations are shown. To the left, an icon indicates the type of the citation's target item (e.g., "Journal Article"). To the right, six citation action buttons/icons are shown: "link to Zotero item", "sync to Wikidata", "move one up", "move one down", "remove", and "more actions". Finally, a shortcut to edit the citation source item's UUIDs QID, DOI and OCC is provided.

Screenshot showing the Citation editor window provided by the WikiCite plugin for Zotero v0.0.1. This window is used to edit the citation's target item metadata, and pops up to add a new citation manually, or to edit an preexisting citation. Style will be improved in future versions of the plugin.

Placeholder actions in the menus provided by the WikiCite plugin for Zotero v0.0.1. None of the actions shown is supported yet. They will be implemented as development continues. Left: item tree menu, for batch actions. Top right: citations pane item menu, for citation's source item-wide actions. Bottom right: citations pane citation menu, for citation-specific actions.

--Diegodlh (talk) 23:20, 6 January 2021 (UTC)

v0.0.2 pre-release published

I have just published v0.0.2 pre-release, including one-way communication with Wikidata. See release notes for a brief explanation of the changes included, or watch the demo video below for a walk through the main highlights. Now I will start working on upload to Wikidata and Local Citation Network support.

Demonstration video featuring the main highlights of v0.0.2 of the WikiCite plugin for Zotero, including: fetching QIDs for citing and cited items, syncing citations with Wikidata, seeing citations in OpenCitations, and linking citations to Zotero items.

--Diegodlh (talk) 00:51, 11 February 2021 (UTC)

OAuth

For uploading changes to Wikidata, I wanted to let users log in with their Wikidata account so changes can be saved as made by them, and special user permissions can be used.

Originally, I wanted to use OAuth to avoid having to ask users for their username and password directly. However, as the plugin would be running on the user's computer and it won't be able to keep the consumer secret hidden, users will have to register the consumer themselves as an owner-only consumer. However, this process may be too cumbersome for the user. Alternatively, I can set up a backend web service (see below), but I may not have enough time to implement such a service before the grant ends.

See this thread for a similar case, especially this message for possible solutions.

So my approach would be:

• First, support anonymous edits by default.
• Second, if the user wants to make changes using their Wikidata account, ask them for username and password each time a change is to be uploaded. These credentials won't be saved by the plugin, and the user will be asked for them each time a change is to be made. Alternatively, ask the user to create a bot password with limited permissions and have them provide these credentials instead.
• Maybe provide a third option in case the user wants to make changes using their Wikidata account but they don't want to enter their username and password. In this case, a set of QuickStatements commands would be generated for the user to run them manually using their account.
• Eventually (probably after the grant ends), I may try and set up a backend web service, as mentioned in the message cited above. I would register this service as the OAuth consumer instead, and have the plugin communicate with this service, which would forward requests to Wikidata.

To provide further context, changes would mostly be adding "cites work" (P2860) statements between items already in Wikidata. Creating new Wikidata entities might be more delicate. Not only should I make sure no duplicate items are created, but also it may be important to disambiguate author strings to their corresponding Wikidata entries. Therefore, to begin with, in these cases the plugin may provide QuickStatements commands to be run manually by the user, instead of automatically by the plugin.

I would be happy to read your comments about this intended approach. Whether you think it may be OK, or if I'm missing something important and I should consider a different path instead. Thanks! --Diegodlh (talk) 20:33, 23 February 2021 (UTC)

Anonymous edits by default seem undesirable to me. It makes it a lot harder to deal with users who use the tool in ways that add incorrect data. I don't see the problem with saying user data locally on the computer of the user. The edits should have a tag that makes it clear that this tool is responsible for it. ChristianKl ❪✉❫ 03:08, 24 February 2021 (UTC)

@ChristianKl: Thanks for your feedback! Then I may ask users for their username and password by default; I'll point them to the Create account page in case they don't have one, and invite them to create and use an app password (bot password) if desired. A checkbox would be available to not ask for username and password again. This would be implemented later as it would require (1) saving these credentials securely, and (2) having a preferences window where users can make them forgotten. Anyway, eventually, I would try and set up the backend web service to use OAuth instead, as described above. Finally, I totally agree with your suggestion of adding a tag that makes it clear an edit was made with this tool. Thanks! --Diegodlh (talk) 13:23, 24 February 2021 (UTC)

Maxlath, the developer of wikibase-edit (which I'm using to post changes to Wikidata) commented that OAuth 2 would be exactly useful for these cases where a desktop app can't hide the consumer secret. OAuth 2 is already supported by Wikidata, but not yet supported by wikibase-edit. In principle I will use username/password login as mentioned above, but if I have enough time I may help bringing OAuth 2 support to wikibase-edit. --Diegodlh (talk) 00:11, 3 March 2021 (UTC)

Simple new entity creation vs author disambiguation

The plugin focuses on syncing "cites work" relationships between a local Zotero library and Wikidata. Both citing and cited items must have a QID, and if the plugin fails to find one from Wikidata (using the reconciliation API) it offers to create a new entity.

I'm not sure whether to offer a simple way to do this, using the Wikidata's API, because to keep the plugin relatively simple (at least for now) I wouldn't include a way to disambiguate "author name string" statements into "author" statements. Alternatively, I could output a set of QuickStatements instructions for the user to paste and run themselves. This would allow users to manually "fix" these "author name string" statements, although it may discourage inexperienced users.

So the question would be: do we prefer a simple way of creating new entities, that may require later author disambiguation? Or a more advanced one using QuickStatements, that allows disambiguation upon entity creation?

I have also posted this question in the WikiProject Source Metadata talk page. I'd appreciate your feedback either here or there! Thanks --Diegodlh (talk) 19:05, 29 March 2021 (UTC)

v0.1.0 release

I have recently released version 0.1.0 of the plugin. I would really appreciate it if you could help me test it while I continue developing the remaining features. Because it hasn't been tested thoroughly yet, make sure you backup your database before giving it a try, just in case. Please report any bugs you may find here.

Demo video showing the new features in v0.1.0 of the WikiCite addon for Zotero

New features of version 0.1.0 include:

• Support making changes to Wikidata
  • Support adding new "cites work" claims to existing entities
  • Support creating new entities for items without QID
  • Support deleting "cites work" claims when synced local citation is removed
  • Support logged-in (regular and bot password) and anonymous edits
• Use item's title (in addition to DOI and ISBN) to fetch its QID, using Wikidata's reconciliation API, to help ensure no corresponding entity exists before offering to create a new one.
• Support sorting citations by authors, date and title, in addition to by index.
• Spanish translation.

I will now focus on the Local Citation Network module, on setting up a translation project in translatewiki.net, and on organizing the presentation workshops.

Please note that the project's end date has been changed to May 31st, 2021. However, some aspects of the original proposal had to be delayed and may remain unmet by this date, as will be explained in the grant's report. An issue has been posted for each of them:

• Automatically sync citations with Wikidata for new Zotero items (issue #59). Currently this has to be run manually.
• Add QID and Citations columns to Zotero's item tree (issue #23). Current workaround to quickly find items with unknown QID is to save a search of items that do not contain "qid" in their Extra field.
• Automatic citation extraction from PDF attachments (issue #61). Considering the new open citations landscape follwing Elsevier decision of opening their citations, the priority of this task has been downgraded relative to others.
• Exporting citations to OpenCitations' CROCI (issue #62).
• Exporting citations for visualization in VOSviewer (issue #63).

--Diegodlh (talk) 00:49, 9 April 2021 (UTC)

Addon page and English presentation workshop

New name and logo

I have created a page for the addon at https://www.wikidata.org/wiki/Wikidata:Zotero/Cita. Note I am in the process of rebranding it from its grant proposal name "Wikicite addon for Zotero" to a shorter name "Cita".

On the other hand, pre-registrations for the English presentation workshop to be held on May 31st are now open. More info, flyers and pre-registration form available at https://www.wikidata.org/wiki/Wikidata:Zotero/Cita#Presentation_workshop.

Spanish presentation workshop will be announced soon.

--Diegodlh (talk) 20:28, 13 April 2021 (UTC)

Crowdsourced translation is available

From today, crowdsourced translation of Cita to other languages is available at translatewiki.net. --Diegodlh (talk) 16:48, 20 April 2021 (UTC)

As I'm working on Local Citation Network support, which will be available in v0.3.0, I have just published v0.1.1, with German, French, Macedonian, Slovak, and (partial) Piedmontese support, thanks to translatewiki contributors. v0.1.1 also supports automatic updates. --Diegodlh (talk) 21:53, 26 April 2021 (UTC)

Taller de presentación en español (Spanish presentation workshop)

Ya está abierta la preinscripción para el taller de presentación en español que se llevará a cabo el jueves 27 de mayo a las 17hs UTC. Más información y formulario de preinscripción aquí. --Diegodlh (talk) 00:10, 6 May 2021 (UTC)

v0.2.0

Using latest citation graph visualization support to discover potentially relevant items not yet in my library

I have just published version 0.2.0 of the plugin. Full changelog is available in the release notes, but most important addition is citation graph visualization support with Tim Wölfle's Local Citation Network, for which batch fetching QIDs for multiple items and automatic linking of citations to Zotero items has been implemented as well. This time I will not be posting a video showing the new features, but I have posted a Quickstart Guide at Cita's homepage.

No new features will be added before the presentation workshops planned for May 27th and 31st. In the days left until then I will be fixing bugs and making small improvements for the workshops.

I will be happy if you can help me test the new version of the plugin and report any issues you may find. Although I haven't experienced any critical issues with it so far, I would still suggest that you backup your library before, just in case.

And I will be more than happy to see you at the workshop! Thank you all for your interest and support! --Diegodlh (talk) 21:33, 11 May 2021 (UTC)