Closed dragonstyle closed 1 year ago
(As I'm reading ahead to https://github.com/curvenote/notebooks-now/blob/main/02-notebooks-as-jats.md, I realize this change may have more ripples than simply here, so no need to just merge this- we can use as a placeholder for conversation around this idea if you like)
Certainly open to this -- also see a lot of ripples -- I think probably a call might be helpful for this one: I would love to have the conversation in context to inline execution / variables. I think those are the pieces that would exist in a main article, and having a copy of the full notebook for `{r radius}`
in one place seems like a lot of duplication.
Yeah agree- this is the one change / suggestion that I felt might warrant more discussion.
I'm around now / this afternoon if you want to chat. I think the one other scenario we should discuss is the scenario where the article is produced by a notebook which has code cells in it for producing plots / tables, etc... (and the where the code for those cells would go if it isn't included in the JATS rendered article).
I am going into a few meetings/prep for the next three hours. Would 2pm MT work?
Had a good chat with @dragonstyle and @fwkoch this afternoon. We came up with a few different proposals and think that including the executable content in the back
matter of an article might be a pretty good solution for both inline execution context (in all cases) and code in the main article that conforms to narrative flow/structure. This keeps the context with the article, doesn't duplicate content, and can xref
erence them in the same way that we would reference any other notebook content.
I likely won't get to a write up on this today, but will give it a shot in the next few days. @dragonstyle if you want to take a shot first, just let me know!
@dragonstyle based on #27 we are going in a different direction than where this hinted. I am going to close for now and revive if we run into problems with that approach!
Proposal:
Perhaps we should propose that the even a notebook that represents the source of the article itself be included as a
sub-article
(andxref
ed as appropriate).One of the great things about the sub-article approach is that it makes the source code that produces elements of the article available to reviewers or the manuscript system. In the case of a single notebook that is used to produce the article itself, the rendered JATS of the notebook may not include source code (and will have the narrative type structure). If we additionally include a
notebook
style rendering of the source notebook as asub-article
, the source code and computional version of the article could be viewed / utilized as well.This approach would allow us to focus on producing
xrefs
tosub-article
s. It will likely do things like exclude the code that generates figures in order to provide a more typical / usable article rendering.sub-article
s that represent the notebooks (as described in the next document), and includingself-uri
,supplementary-materials
and so on that provide all the notebook metadata (including ultimately the execution information).What do you think?