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 complex complex-geometry computable-mathematics computer-science constructive cosmology definitions deformation-theory descent diagrams differential differential-cohomology differential-equations differential-geometry digraphs duality elliptic-cohomology enriched fibration 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 nforum 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).

nLab > Latest Changes: enriched groupoid

Bottom of Page

1 to 15 of 15

  1.  
    • CommentRowNumber1.
    • CommentAuthorUrs
    • CommentTimeApr 24th 2023

    for completeness

    v1, current

    • CommentRowNumber2.
    • CommentAuthorUrs
    • CommentTimeJun 1st 2023
    • (edited Jun 1st 2023)

    added this pointer:

    diff, v4, current

    • CommentRowNumber3.
    • CommentAuthorUrs
    • CommentTimeJun 1st 2023

    added also pointer to

    (who does finally switch terminology from “simplicial groupoid” to “groupoid enriched over simplicial sets” but still does not state the definition of enriched groupoids)

    together with more comments on the history of the notion.

    diff, v4, current

    • CommentRowNumber4.
    • CommentAuthorvarkor
    • CommentTimeJun 1st 2023

    Presumably the assumption that VV be a cosmos can be relaxed to simply asking for VV to be a cartesian monoidal category?

    • CommentRowNumber5.
    • CommentAuthorUrs
    • CommentTimeJun 1st 2023

    how about formulating it this way:

    …a cartesian monoidal category (serving as an cosmos for enrichment)…

    diff, v6, current

    • CommentRowNumber6.
    • CommentAuthorTodd_Trimble
    • CommentTimeJun 1st 2023

    I think varkor is suggesting that the cosmos (or cartesian cosmos) assumptions are rather more than what is needed. In that case, I wouldn’t say “cosmos for enrichment”, but “base for enrichment” or something similar. Not sure we have a page that accommodates that extra generality, but if not, I think we should.

    • CommentRowNumber7.
    • CommentAuthorUrs
    • CommentTimeJun 1st 2023
    • (edited Jun 1st 2023)

    I know, that’s why I suggested the reformulation “serving as…”.

    Now base of enrichment is redirecting to cosmos. Feel invited to split it off as a separate entry.

    • CommentRowNumber8.
    • CommentAuthorTim_Porter
    • CommentTimeJun 1st 2023

    Fixed a typo. id Yid_Y should have benn id Xid_X.

    diff, v9, current

    • CommentRowNumber9.
    • CommentAuthorUrs
    • CommentTimeJun 2nd 2023

    added the example of strict 2-groupoids (here)

    diff, v10, current

    • CommentRowNumber10.
    • CommentAuthoranuyts
    • CommentTimeApr 27th 2024

    Using * for the terminal object, makes it look like you have a cartesian AND monoidal category.

    diff, v12, current

    • CommentRowNumber11.
    • CommentAuthoranuyts
    • CommentTimeApr 27th 2024
    @Urs: this definition also doesn't encompass ordered groups with contravariant inversion.
    • CommentRowNumber12.
    • CommentAuthorUrs
    • CommentTimeApr 27th 2024

    Have to admit that I am not sure what you are getting at with either of these comments.

    We need a cartesian monoidal base of enrichment in order to state the enriched existence of inverses. The entry is clear about this, and the notation seemed just fine.

    Whether this encompasses “ordered groups” is something that the entry on ordered groups needs to deal with. The notion of enriched groupoids is what it is.

    • CommentRowNumber13.
    • CommentAuthoranuyts
    • CommentTimeApr 27th 2024
    The symbol * is sometimes used for a monoidal product (maybe rarely in general, but at least in specific cases, and it is certainly a symbol used for binary operations), so (to me at least) (V, \times, *) looked like a category equipped with two binary operations. The edit is not overly important, but using \top for the terminal context seemed more immediately clear.

    Agreed on the other point.
    • CommentRowNumber14.
    • CommentAuthorUrs
    • CommentTimeApr 28th 2024

    Thanks for saying, now I understand your first comment. I am regularly using “*\ast” for terminal objects, it’s all over the nLab.

    • CommentRowNumber15.
    • CommentAuthorMike Shulman
    • CommentTimeApr 30th 2024

    I think this is an issue of different conventions in different communities. I don’t see a problem with sticking with *\ast, which is common in some communities, and people who are familiar with it would probably be just as confused by ⊤\top as you are by *\ast. The important thing is to define notation when there is any potential for confusion, and the entry does that in the first bullet point where it said “the tensor unit is a terminal object *\ast”. If this is too far away from the use of *\ast in the previous line, we could just remove it from the previous line and write “let 𝒱\mathcal{V} be a cartesian monoidal category” and only introduce the notation *\ast for the terminal object in the bullet point that states explicitly that it’s a terminal object.

1 to 15 of 15

  1.