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

Discussion Tag Cloud

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 > nLab General Discussions: What would you want from a higher categorical database?

Bottom of Page

1 to 24 of 24

  1.  

  1. Hello Everyone,

    I’m an undergraduate computer science major and I’m working on developing a higher categorical database for the nLab for my senior project. I would like to start collecting properties that a category may or may not have. Such as

    concrete (equipped with a forgetful functor to Set) versus non-concrete

    locally representable versus not locally representable

    and have a rudimentary database functionality where one could enter a category name and mark which of these properties it has, which it does not have. Once the properties have been selected, all categories with those properties can be displayed, or those properties can be filled in by an nLab user for a particular category. The interface may look like the list of all categories, where one can select properties with a checkbox list or perhaps a multiple select list. So I’m asking everyone who cares to contribute, what categorical properties do you want to see in a database of categories? Thanks!

    • CommentRowNumber2.
    • CommentAuthorMike Shulman
    • CommentTimeFeb 12th 2011

    Wouldn’t it be better to have an interface where nLab users can add their own properties? Undoubtedly new properties will continue to pop up as important and interesting as time goes by.

    Also, what does “locally representable” mean?

  3. “Wouldn’t it be better to have an interface where nLab users can add their own properties? Undoubtedly new properties will continue to pop up as important and interesting as time goes by.”

    Yes, I meant to mention that. The interface is supposed to be dynamic so that nLab users can add properties to it. As for “locally representable”, I wondered about that myself. I copied and pasted that example from a discussion I had with someone on the database. I thought they meant ’locally presentable’, but I’m not sure.

    • CommentRowNumber4.
    • CommentAuthorTobyBartels
    • CommentTimeFeb 12th 2011
    • (edited Feb 12th 2011)

    Also, what does “locally representable” mean?

    I expect that he meant to write “locally presentable”. (That’s what Google thinks! Incidentally, one of Google’s two hits for that exact phrase is a typo on this very Forum, so Stephen may not be to blame for this error.)

    Edit: In the meantime, Stephen has answered this, but I still think that Google’s behaviour is interesting.

    • CommentRowNumber5.
    • CommentAuthorUrs
    • CommentTimeFeb 12th 2011

    Did I write this? It’s not my fault: it’s my finger’s fault!! ,-)

  6. “Did I write this? It’s not my fault: it’s my finger’s fault!! ,-)”

    Yes Dr. Schreiber. That was from a discussion we had.

    • CommentRowNumber7.
    • CommentAuthorMike Shulman
    • CommentTimeFeb 12th 2011

    The interface is supposed to be dynamic so that nLab users can add properties to it.

    So why do you want us to suggest properties now? Seems like you could just set it up and let people loose! (-:

  8. So why do you want us to suggest properties now? Seems like you could just set it up and let people loose! (-:

    I knew that would be the next question, but part of it has to do with database design. I would like to see how many properties I could get (without implementing an interface), to do normalization in order to make the system into a relational database. My course adviser seems to want normalization to be a part of the design.

    • CommentRowNumber9.
    • CommentAuthorTobyBartels
    • CommentTimeFeb 12th 2011

    So we want a preliminary list of properties, then add more later?

  10. So we want a preliminary list of properties, then add more later?

    Yes, at least that’s the idea for now.

    • CommentRowNumber11.
    • CommentAuthorMike Shulman
    • CommentTimeFeb 13th 2011

    I’m generally all in favor of normalization, but I don’t understand why you need data in order to do it. Are you suggesting that maybe there are different “types” of properties that will need to be stored differently in the database, and you want to find out what those might be?

    • CommentRowNumber12.
    • CommentAuthorUrs
    • CommentTimeFeb 13th 2011
    • (edited Feb 13th 2011)

    There is by now quite a prehistory to this discussion. Stephen had started out intending to add hard wired content into the database and was asking for advice on how to do that. I had been suggesting that the database should rather be designed such that it accumulates its content from the activity and those active on the nLab. But then it seemed that Stephen found such a flexible design to be more ambitious than what seemed possible given his resources, and so I agreed that then he should try to implement the design that seems to be achievable for him in the timespan of the project, maybe with the option to later build on that.

  13. Thanks Dr. Schreiber. It would be helpful if I could get a list of classes of categories that all the categories here fall under. Then, it would be possible to do normalization (dividing the database up into tables of categories).

    • CommentRowNumber14.
    • CommentAuthorMike Shulman
    • CommentTimeFeb 14th 2011

    I really don’t understand what you mean by “normalization”. Here’s how I would naively design a database to store categories and properties:

    • Table 1: categories. Fields category_id (primary key), name, etc.
    • Table 2: properties. Fields property_id (primary key), name, etc.
    • Table 3: category_properties: many-to-many join. Fields category_id (foreign key), property_id (foreign key), notes, etc.

    What further sort of “division into tables of categories” do you have in mind?

  15. I honestly do need specific values for the following properties to do normalization:

    • category_name
    • objects
    • morphisms
    • initial objects
    • terminal objects
    • products
    • coproducts
    • equalizers
    • coequalizers
    • pullbacks
    • pushouts
    • finite limits
    • finite colimits
    • small limits
    • small colimits
    • size
    • concretizability
    • dimension

    For example:

    • category_name: Set
    • objects: well-founded pure sets
    • morphisms: functions
    • initial objects: the empty set
    • terminal objects: all singletons
    • products: n-ary cartesian product
    • coproducts: n-ary disjoint sum
    • equalizers:
    • coequalizers:
    • pullbacks: cartesian products and their canonical projection morphisms
    • pushouts: set intersections and their inclusion maps
    • finite limits:
    • finite colimits:
    • small limits:
    • small colimits:
    • size: large
    • concretizability: Concretizable (can be equipped with an endofunctor)
    • dimension: 1
    • description: Set is the large concrete complete and cocomplete cartesian closed topos of small 0-categories

    I do not need values for all of the categories here, but say values for many of the properties would be helpful. I do not wish to waste anymore bandwidth requesting more information, that’s why I just listed the above specific properties that the database will be initially designed around. If you can provide the requested information, thank you. If not, I do not wish to disturb your research. I would not ask these questions if I did not need to. The sooner I receive the data the sooner I can get done!

    Here is link with information that I already have on the categories at category: category: http://stu.cbu.edu/~sbritton/nlabdb.html

    The above is not an actual database, just a mockup of a simple interface.

    • CommentRowNumber16.
    • CommentAuthorMike Shulman
    • CommentTimeFeb 15th 2011

    Ah, by “properties” you mean what I would call “attributes”: not just binary flags but something that can take many possible values. I still don’t understand what sort of normalization you’re planning to do, though.

    • CommentRowNumber17.
    • CommentAuthorTobyBartels
    • CommentTimeFeb 15th 2011

    Properties valued in truth-values aren’t that much different from properties valued in other sets; it’s properties valued in (higher) groupoids/categories that are really different (so called “structures”).

    However, at least “concretizability” is really a structure rather than a property. What we want here, however, is not every possible such structure (which for SetSet gives us all of the faithful endofunctors of SetSet) but that particular one which is considered standard (which for SetSet is the identity functor).

    • CommentRowNumber18.
    • CommentAuthorMike Shulman
    • CommentTimeFeb 16th 2011

    I made a list of a few of my favorite categories and a few of my favorite properties of them and posted it here in CSV format. I made separate entries for (e.g.) Cat considered as a 1-category, as a strict 2-category, and as a weak 2-category.

  19. Thanks alot Mike! This should help me get started.

    • CommentRowNumber20.
    • CommentAuthorMike Shulman
    • CommentTimeFeb 17th 2011

    The alot says you’re welcome! (-:O

  21. Ah, being corrected by the grammar police. I like that alot.

    • CommentRowNumber22.
    • CommentAuthorpdehaye
    • CommentTimeApr 29th 2013
    • (edited Apr 29th 2013)

    This link does not work anymore, and the CSV table that was here has also disappeared. I am interested in them. @Mike, Stephen, can you put copies up again? @Stephen, what was the outcome of your project?

    • CommentRowNumber23.
    • CommentAuthorMike Shulman
    • CommentTimeMay 1st 2013
    • CommentRowNumber24.
    • CommentAuthorpdehaye
    • CommentTimeMay 1st 2013

    Thanks abunch!

1 to 24 of 24

  1.