Moving jupyterlab-comments repo from jupytercalpoly to jupyterlab

[JasonWeill]

This is a follow up item from a meeting with @3coins, @afshin, @jtpio, @martinRenou, @fcollonval, @hbcarlos, @Zsailer, and others on May 3, 2022.

Problem

Currently, there are two repositories for commenting functionality in JupyterLab:

1. https://github.com/jupyterlab/jupyterlab-commenting (Last modified May 1, 2020)
2. https://github.com/jupytercalpoly/jupyterlab-comments (Last modified December 3, 2021)

I've been talking with @ellisonbg about incorporating the jupytercalpoly/jupyterlab-comments repository into JupyterLab core. At a meeting on May 3, we discussed archiving the older "commenting" repo and bringing the newer "comments" repo into the JupyterLab project.

Proposed Solution

1. Archive the jupyterlab/jupyterlab-commenting repo
2. Move jupytercalpoly/jupyterlab-comments into the jupyterlab project space
3. Incorporate jupyterlab-comments (the extensions moved from jupytercalpoly) into the main jupyterlab/jupyterlab repository.

Additional context

The comments extension's UI should be integrated with the cell toolbar, which may require that the cell toolbar be modified to be visible even if it overlaps with cell content (jupyterlab/jupyterlab#12223).

[ellisonbg]

I think there is quite a bit of work still needed before (1) is ready for regular usage by JupyterLab users, but I think it is a much better starting point than (2) at this point. Based on this, I think the proposal makes sense. The other option is to use (1) create a branch of jupyterlab/jupyterlab, but that will be more difficult to develop and have people try out. For transparency, both the interns who built (1) and @jweill-aws work for me at Cal Poly and AWS respectively.

[JasonWeill]

Other concerns about the JupyterLab comments had to do with the organization of files. Currently, jupytercalpoly/jupyterlab-comments stores comments data as a secondary file. This means that a notebook doesn't contain its own comments embedded. Transmitting a workbook with embedded comments requires sending two files. Alternatively, we could embed comments in the metadata field of a notebook.

Pros of using the metadata field:

• Only one file required to share annotated notebooks

Cons of using the metadata field:

• Other clients besides JupyterLab might not parse the metadata correctly or may overwrite it inadvertently
• Doesn't solve the commenting problem for text files, which have no metadata field

[JasonWeill]

We discussed this issue at the JupyterLab weekly meeting yesterday — see minutes: #135 (comment)

We discussed soliciting feedback on these moves from @jupyterlab/jupyterlab-council members. Thoughts about archiving the old jupyterlab/jupyterlab-commenting repo and moving jupytercalpoly/jupyterlab-comments into jupyterlab? The long-term goal would be to incorporate the latter, newer module into JupyterLab core.

[ellisonbg]

This seems like a simple proposal. I would like to propose a vote on the matter.

…

On Thu, May 5, 2022 at 8:43 AM Jason Weill ***@***.***> wrote: We discussed this issue at the JupyterLab weekly meeting yesterday — see minutes: #135 (comment) <#135 (comment)> We discussed soliciting feedback on these moves from @jupyterlab/jupyterlab-council <https://github.com/orgs/jupyterlab/teams/jupyterlab-council> members. Thoughts about archiving the old jupyterlab/jupyterlab-commenting repo and moving jupytercalpoly/jupyterlab-comments into jupyterlab? The long-term goal would be to incorporate the latter, newer module into JupyterLab core. — Reply to this email directly, view it on GitHub <#145 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAGXUEGOAWEG6FAPURZBUTVIPUCBANCNFSM5U7W43IA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

-- Brian E. Granger Senior Principal Technologist, AWS AI/ML ***@***.***) On Leave - Professor of Physics and Data Science, Cal Poly @ellisonbg on GitHub

[jtpio]

For reference, linking to jupyterlab/jupyterlab#12588 which pulls jupyterlab-calpoly/jupyterlab-comments into core.

[aiqc]

Related: jupyterlab/jupyterlab#12032

[williamstein]

I would be really happy if somebody who actually works on this also suggests how they would embed comments in the ipynb file, based on their experience... since this sort of functionality is something people grading homework as ipynb files frequently want.

[ellisonbg]

When the interns built the newer extension we talked about the following: * We wanted the commenting system to work with potentially all file types (notebooks, source files, markdown, etc.). * Because of this, we couldn't rely on all file formats to have internal slots where we could store comments. * To test this idea out, the initial version stores all comments in separate files. * Longer term, we would like to move to a model where different files types can store comments in an appropriate location - so that notebooks could store them internally. * We also looked at using the W3C web annotation data model to store comments in the notebook file (https://www.w3.org/TR/annotation-model/). Eventually, we would want to make this part of the formal notebook document JSON schema. The interns only got to the first 3 of these steps, but I think it makes sense to continue to explore this space along the lines of the last two.

…

On Wed, May 18, 2022 at 9:22 AM William Stein ***@***.***> wrote: I would be really happy if somebody who actually works on this also suggests how they would embed comments in the ipynb file, based on their experience... since this sort of functionality is something people grading homework as ipynb files frequently want. — Reply to this email directly, view it on GitHub <#145 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAGXUC6KYIEM23IUBREH2DVKUKLDANCNFSM5U7W43IA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

-- Brian E. Granger Senior Principal Technologist, AWS AI/ML ***@***.***) On Leave - Professor of Physics and Data Science, Cal Poly @ellisonbg on GitHub

[JasonWeill]

I'm reviewing the W3C Web Annotation Data Model, which declares that each "Annotation" has a "type" and a "target". The target IRI is like a URI, but with non-ASCII characters permitted. What would such a target look like in a Jupyter notebook? Do we have, or are we planning to make, an IRI schema for referring to one cell in a notebook or a portion thereof?

[fcollonval]

an IRI schema for referring to one cell in a notebook or a portion thereof?

Is it not the fragment selector job to specify the position within the document and the target is the IRI to the notebook.
If so, looking at the PDF example (see previous link)

PDF http://tools.ietf.org/rfc/rfc3778 Example: page=10&viewrect=50,50,640,480

It seems we could do something similar using the standard cell uid and an editor positioning. But there is still the case of commenting an cell output to figure out then.