Keith wrote:

> It's not so much that \\(F\\) does something to the graph, but rather that it picks or *instantiates* out a bunch of sets and functions between them that 'look like' the graph in question.

> Such sets and their functions are called *instances* in the book (and by Simon Willerton) above.

I read Anindya's comment more in terms of what happens to the morphisms than what happens to the objects. The behavior of morphisms under the functor is fully determined by the behavior of the arrows in our database schema, which is only a presentation of a category and does not contain all morphisms. Like how a linear map between vector spaces is fully determined by its action on a basis.

Sure, the objects are important, because that's where our data ends up by way of the functor. But with respect to **Puzzle 109**, we can factor every morphism into a string of ground arrows from the schema, so the _kinds_ of queries you can perform can be reduced to questions about the schema.

> It's not so much that \\(F\\) does something to the graph, but rather that it picks or *instantiates* out a bunch of sets and functions between them that 'look like' the graph in question.

> Such sets and their functions are called *instances* in the book (and by Simon Willerton) above.

I read Anindya's comment more in terms of what happens to the morphisms than what happens to the objects. The behavior of morphisms under the functor is fully determined by the behavior of the arrows in our database schema, which is only a presentation of a category and does not contain all morphisms. Like how a linear map between vector spaces is fully determined by its action on a basis.

Sure, the objects are important, because that's where our data ends up by way of the functor. But with respect to **Puzzle 109**, we can factor every morphism into a string of ground arrows from the schema, so the _kinds_ of queries you can perform can be reduced to questions about the schema.