Want to take part in these discussions? Sign in if you have an account, or apply for one below
Vanilla 1.1.10 is a product of Lussumo. More Information: Documentation, Community Support.
As I have mentioned elsewhere, I am working on adding a mechanism for citations to the nLab, to hopefully improve on manually adding them as we currently do. Basically one will just be able to write \cite{Something} and everything will be taken of (after the citations details have been uploaded, if they are not already present).
The way the actual reference at the bottom of the page will be constructed is by running LaTeX (part of the uploaded reference will be a BibTeX entry), and then doing some post-processing. For this, I need to decide on a BibTeX style. I believe that ’alpha’ is the one that is preferred; is that correct?
It looks as follows for an ’incollection’ item.
[Kau05] Louis H. Kauffman. Knot diagrammatics. In Handbook of knot theory, pages 233-318. Amsterdam: Elsevier, 2005.
The link in the actual entry would be [Kau05].
The post-processing is a bit dependent on the style chosen, which is why I am asking now.
I will also add an arXiv and DOI link at the end of the reference if they are provided when uploading it.
WIll there be a .bib associated to each page?
This is exciting! It seems that most nlab pages currently use something close to either ’alpha’ or ’author-year’, making for either your [Kau05] or the more verbose “Kauffman 2005”. Probably ’alpha’ is a good choice.
Do I understand correctly that the reference database will be centralized, so that once a given reference is uploaded once it can be cited from any page? That would be great, although we’ll also have to discuss a global convention for the names of such references.
It would also be useful to be able to provide arbitrary links (e.g. to PDFs on authors’ web pages) in addition to arxiv and doi links.
How will the References section at the bottom of the page be created? Will it be just automatically tacked on to any page that uses \cite? A number of nLab pages currently include comments in and around the references about each one’s relevance to the page or place in the historical development, and/or group the references in some way that an automatic bibtex run wouldn’t do. If we have to give that up, I think it would be worth it, but it will require some manual going through to incorporate such information elsewhere on the page. (Actually I personally think that often those interspersed comments on references are distracting and confusing, but others seem to like them.)
Recently – and I promise I am not making this up now – a colleague told me that the extra information about the refernces is the “most useful” part of the nLab for him.
I think you all know how that kind of information can be really crucial when doing research and when citing. At the same time of course I see how it can be a distraction, if all one wants is the darn citation itself.
But any automated support for references should only alleviate this issue.
I’m not denying that information is useful. Just that my inclination would be to write it as text with citations, instead of interspersed with the references. So instead of
References
The concept was first defined in
- blah blah blah
and then developed further in
- blah blah blah
it would be
History
The concept was first defined in [Blah00] and then developed further in [Blah01].
References
[Blah00] blah blah blah
[Blah01] blah blah blah
Mainly this annoys me when I want to add a new reference that doesn’t fit into the “story” being told, but I have to add some extra weasely text like “For more information see” in front of it so that it doesn’t look like part of the story.
This is very minor, and I don’t want to force anyone else to follow my preferences here. However, I do think we need to think about how our styles will interact with an automated citation system. It’s unclear to me how an automated citation system could produce something like the first interspersed-story version. And I do want to be able to convert all our existing pages to use an automated citation system; I think there’ll be a great benefit to centralizing the style and information contained in references (so that, for instance, if the URL of a reference changes, it’ll automatically change on all pages that cite it). Does anyone have something in mind for how to deal with this?
Re: #3:
It would also be useful to be able to provide arbitrary links (e.g. to PDFs on authors’ web pages) in addition to arxiv and doi links.
Another thing that we should include is a link to our own nLab page about a reference, when such exists, e.g. Categories Work or Elephant.
Very good that we have this discussion!
Do I understand correctly that the reference database will be centralized, so that once a given reference is uploaded once it can be cited from any page?
Yes, exactly.
That would be great, although we’ll also have to discuss a global convention for the names of such references.
Currently, I generate such a key. It will look something like Kauffman2005KnotDiagrammatics for the example in #1, i.e. is a concatenation of authors, year, and title. It is permitted to enter a ’title mnemonic’ when uploading the reference which will then be used instead of ’KnotDiagrammatics’. Let me know if we could do something better. The keys are not always so short in this approach, but should be fairly readable and hopefully usually unique.
It would also be useful to be able to provide arbitrary links (e.g. to PDFs on authors’ web pages) in addition to arxiv and doi links.
Agreed.
How will the References section at the bottom of the page be created? Will it be just automatically tacked on to any page that uses \cite?
That was the initial plan if there is no existing References section. If there is already a References section, the plan was to add references created using \cite at the end of the existing ones (not a great solution, but I couldn’t think of anything better that can be done automatically, since we cannot rely on things being in alphabetical order or whatever).
However, in the light of the above discussion, I am thinking that maybe we could have the following possibilities.
1) If only \cite is used and there is no existing References section, we can generate References as initially planned.
2) We can, even if cite is used, allow References to be constructed manually. It might look something like the following.
\section{References}
\bibref{Kauffman2005KnotDiagrammatics}
\bibref{Something else}.
This would allow text to be included in between if people wish, and also retain backwards compatibility with references that have been added manually, whilst retaining the benefits of having a centralised reference database.
Maybe we make 1) and 2) mutually exclusive, i.e. if there is any manual creation of references, one must use 2) even with \cite.
What do people think?
Why not make a biliography optional?
It will be optional, like now. The idea is just to make the adding of references easier, and to add semantics by means of a central database.
Another thing that we should include is a link to our own nLab page about a reference, when such exists
Sounds good. I’d suggest that we manually specify such a page when uploading, rather than attempting to manually detect it. But I do plan to add automatic detection of author pages, i.e. ’Louis H. Kauffman’ will be linked in the example in #1 (if we have a page for him).
WIll there be a .bib associated to each page?
Good idea! I had not planned it in the first version, but it definitely sounds like a good idea to add this eventually.
That all sounds pretty good. I’d prefer significantly shorter reference keys if we could manage it; some articles have very long titles! Usually the alpha citation key (first few letters of single author’s name, or initials of multiple authors’ names, followed by 2-digit year) is enough to identify a paper, but of course for a global system we need to include additional information. The alpha system just adds a letter (Kau05a, Kau05b); that doesn’t work well globally, but the entire text of the title is overkill. One possibility would be to follow the alpha citation key by just the initials of the title, so for instance your example would be Kau05KD, while A unified treatment of transfinite constructions for free algebras, free monoids, colimits, associated sheaves, and so on would be Kel80AUTOTCFFAFMCASASO. A short manually-chosen mnemonic is useful too, of course, but I think it would be nice if someone knowing only the paper itself could deduce a correct nlab reference key for it that wouldn’t be horrifically long without also having to go look it up in the nLab citation database.
If we allow multiple ways to make a references section, I do think we should be careful to allow them to interact cleanly, e.g. if one style is used in a page and someone else edits it and starts (perhaps unwittingly) using the other style, it shouldn’t break all the existing first-style references. And we should make sure there is a clean upgrade path for existing references sections. Here’s a somewhat kludgy algorithm:
cites in the text also appear as bibrefs, then simply replace all bibrefs with the appropriate citations.bibrefs with appropriate citations, divide the existing References section into subheadings of Annotated references and Other references, with the former including all the bibrefs and the latter including additional autogenerated citations corresponding to all the cite commands that don’t appear in any bibref.FWIW, I just came across this old discussion.
Also, it occurs to me that there is a problem with autogenerated reference keys that include a publication year. Namely, when a preprint is first posted on the arXiv, the only “publication year” that can be associated to it is the year of its posting; but later, when it is officially published in a journal, the “publication year” should be updated to refer to the date of publication. So reference keys that include the publication year will not be constant over time, which seems like potentially a problem.
I like to reference by preprint year generally, even in publications. Gives a much better idea of the way things really developed.
I’m thinking that probably I’ll drop the automatic generation, and just leave the key to be entered manually, with guidance on conventions.
Re #11, there’s a certain sense to that logically, but I’m pretty sure it is against “the rules”.
1 to 13 of 13