Not signed in (Sign In)

Not signed in

Want to take part in these discussions? Sign in if you have an account, or apply for one below

  • Sign in using OpenID

Site Tag Cloud

2-category 2-category-theory abelian-categories adjoint algebra algebraic algebraic-geometry algebraic-topology analysis analytic-geometry arithmetic arithmetic-geometry book bundles calculus categorical categories category category-theory chern-weil-theory cohesion cohesive-homotopy-type-theory cohomology colimits combinatorics comma complex complex-geometry computable-mathematics computer-science constructive cosmology deformation-theory descent diagrams differential differential-cohomology differential-equations differential-geometry digraphs duality elliptic-cohomology enriched fibration finite foundation foundations functional-analysis functor gauge-theory gebra geometric-quantization geometry graph graphs gravity grothendieck group group-theory harmonic-analysis higher higher-algebra higher-category-theory higher-differential-geometry higher-geometry higher-lie-theory higher-topos-theory homological homological-algebra homotopy homotopy-theory homotopy-type-theory index-theory integration integration-theory k-theory lie-theory limits linear linear-algebra locale localization logic mathematics measure-theory modal modal-logic model model-category-theory monad monads monoidal monoidal-category-theory morphism motives motivic-cohomology nlab noncommutative noncommutative-geometry number-theory of operads operator operator-algebra order-theory pages pasting philosophy physics pro-object probability probability-theory quantization quantum quantum-field quantum-field-theory quantum-mechanics quantum-physics quantum-theory question representation representation-theory riemannian-geometry scheme schemes set set-theory sheaf simplicial space spin-geometry stable-homotopy-theory stack string string-theory superalgebra supergeometry svg symplectic-geometry synthetic-differential-geometry terminology theory topology topos topos-theory tqft type type-theory universal variational-calculus

Vanilla 1.1.10 is a product of Lussumo. More Information: Documentation, Community Support.

Welcome to nForum
If you want to take part in these discussions either sign in now (if you have an account), apply for one now (if you don't).
    • CommentRowNumber1.
    • CommentAuthorRichard Williamson
    • CommentTimeJan 10th 2019
    • (edited Jan 10th 2019)

    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.

    • CommentRowNumber2.
    • CommentAuthorAli Caglayan
    • CommentTimeJan 10th 2019

    WIll there be a .bib associated to each page?

    • CommentRowNumber3.
    • CommentAuthorMike Shulman
    • CommentTimeJan 10th 2019

    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.)

    • CommentRowNumber4.
    • CommentAuthorGuest
    • CommentTimeJan 11th 2019
    Urs is particularly a fan of annotating the references in a way that they read like a story book. I think it makes it very clear why a reference is there as a result.

    Why not make a biliography optional? Kind of like the table of contents, that way if we want to write out our own bibliography, we can reference the central bib database just by annotating the comment style without having to rewrite a load of them. Or better yet have both!

    But we will see how it turns out.
    • CommentRowNumber5.
    • CommentAuthorUrs
    • CommentTimeJan 11th 2019
    • (edited Jan 11th 2019)

    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.

    • CommentRowNumber6.
    • CommentAuthorMike Shulman
    • CommentTimeJan 11th 2019

    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?

    • CommentRowNumber7.
    • CommentAuthorMike Shulman
    • CommentTimeJan 11th 2019

    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.

    • CommentRowNumber8.
    • CommentAuthorRichard Williamson
    • CommentTimeJan 13th 2019
    • (edited Jan 13th 2019)

    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.

    • CommentRowNumber9.
    • CommentAuthorMike Shulman
    • CommentTimeJan 13th 2019

    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:

    1. If all cites in the text also appear as bibrefs, then simply replace all bibrefs with the appropriate citations.
    2. Otherwise, in addition to replacing 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.
    • CommentRowNumber10.
    • CommentAuthorMike Shulman
    • CommentTimeFeb 3rd 2019

    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.

    • CommentRowNumber11.
    • CommentAuthorUrs
    • CommentTimeFeb 3rd 2019

    I like to reference by preprint year generally, even in publications. Gives a much better idea of the way things really developed.

  1. I’m thinking that probably I’ll drop the automatic generation, and just leave the key to be entered manually, with guidance on conventions.

    • CommentRowNumber13.
    • CommentAuthorMike Shulman
    • CommentTimeFeb 4th 2019

    Re #11, there’s a certain sense to that logically, but I’m pretty sure it is against “the rules”.