Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Notebook metadata proposal (title, subtitle, authors, affiliations) #6073
While creating a presentation with the Notebook and Reveal.js I noticed it would be nice to add certain metadata to the notebook that could then be accessed in the template. Therefore, I would like to make a proposal of the metadata fields regarding the documents title, subtitle and affiliations.
I propose we separate authors from affiliations and use dictionaries to access them.
Regarding author names I propose we use the LaTeX way of Lastname/Firstname.
I've grouped these fields together into
As you can see these are quite a lot of new fields. While many won't we used that often I think it is good to "standardize" the metadata.
During conversion from the notebook to any other format these fields have to be accessible. If I am correct
At which point should this
Accessing metadata in templates
The metadata can then be accessed in templates, e.g. the title by calling
This would be nice! Thinking about utility of the data, it would be nice for a future nbviewer to be able to render a bibliography reference for download/cu-n-paste in a couple of formats (eg, bibtex, MLA, APA). For completeness, I'd suggest just mirroring all of bibtex's fields.
referenced this issue
Jul 3, 2014
In the past we have resisted adding this much formalized metadata to the
On Wed, Jul 2, 2014 at 4:01 PM, Doug Blank email@example.com wrote:
@ellisonbg would you happen to have some references to discussion surrounding this issue? It appears to be a bit Google-resistant.
One idea might be to use the existing Markdown YAML metadata syntax (see, for instance, the implementation in Pandoc's markdown). It's a bit unclear how one would deal with cases like multiple metadata-containing cells, however.
Either way, metadata would be rather nice. The current recommended means of changing the document author leaves much to be desired.
Unfortunately, I think that most of these discussions have happened in
A short summary of some of the points:
We would love someone to look into these questions. But in areas where we
On Thu, Oct 2, 2014 at 9:18 AM, Ben Gamari firstname.lastname@example.org wrote:
I propose treating, initially, every metadata block, but eventually, each entire notebook, as JSON-LD documents. Basically, this means adding/fiating a
JSON-LD provides a standards-based way to capture a much richer underlying structure to JSON data than JSON schema, for example. This "linked data" concept asserts that data has:
The example above with the multiple affiliations is trivial, not only to write, but to actually do something with, as there exist parsers in most major languages. Further, the specific pidgen
The biggest initial win would be in selecting and promoting a few, existing, productive namespaces for 99% of the cases of metadata that someone might want.
Now, the joke is that we could claim that we are using all of them, as one can make their OWN term, then use ontology dark magic to claim the it is the same as other standards. For example,
Longer term, JSON-LD provides things like internationalization, out-of-band context and other features that would contribute substantially to the overall impact of the IPython/Jupyter ecosystem.
Since the data-at-rest representation is still JSON, this introduces no real new challenges, but gives us a huge head start: we already have some great collections of concepts to pull in, rather than having to build the UI and the vocabulary at the same time.
I think for the time being we need to be extremely conservative in not
On Sat, Mar 21, 2015 at 10:20 PM, bollwyvl email@example.com wrote:
Agreed. That's one of the big advantages of JSON-LD: we can just say that the notebook is now JSON-LD, as interpreted by a particular context, and it is. But there is still a lot of information missing... my motivation here is the seemingly simple nbviewer issues, and influenced by making it work with, for example, google drive.
A ContentManager is, in the end, is responsible for giving the notebook a URL. Heck, I like the index.ipynb suggestion. But this suggests that the filename is a thing for machines, that the human might not even control. What is the name for people? At present, google is nice enough to pull an
I'm saying that when we add "real" metadata for metadata's sake (that some robot from outside the ecosystem would actually recognize as such), JSON-LD would be the right way to capture it.
So that when we enable populating the title of notebooks on nbviewer, even if it is to fall back to the filename, that someone should be able to override it. And when they provide it, and maybe still in
My preferred solution for the UI/UX challenge would be, however, to move the
Longer term, as was discussed on the list, really thinking about the Notebook document from the ground up as linked data would be incredible, and allow things like:
referenced this issue
Mar 26, 2015
referenced this issue
Dec 8, 2015
that could be a bit complicated and I am probably not the best person for the question. In principle you would need to write an nbextension that modifies the notebook model, but that part of the code base is only a semi-public API…
On Mon, Jan 22, 2018 at 2:34 PM, p2ya ***@***.***> wrote: @ellisonbg <https://github.com/ellisonbg> How can I have access to notebook metadata within the notebook ? I need to rewrite some part of the metadata based on parameters which are generated after running notebook cells. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#6073 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABr0JlW_APX-A6QliOPNTAHgTqwqxUxks5tNQ0IgaJpZM4CJeEe> .
-- Brian E. Granger Associate Professor of Physics and Data Science Cal Poly State University, San Luis Obispo @ellisonbg on Twitter and GitHub firstname.lastname@example.org and email@example.com