Add object.yml and Object content model

[geealbers]

For collection catalogues, Quire publications need to be able to handle Objects. Currently adding an object item with a number of arbitrary sub-attributes to the page YAML of a type: entry page will generate a table in the layout displaying that information.

title: The Luncheon on the Grass
weight: 101
object:
  artist: Édouard Manet
  year: 1863
  medium: Oil on canvas
  dimensions: 208 cm × 264.5 cm (81.9 in × 104.1 in)
  location: Musée d’Orsay, Paris
image: manet.jpg
type: entry

Along with this behavior, users should also be able to reference objects listed in an objects.yml file in the data directory by an id, rather than having the object data embedded directly in the page.

As mentioned above, the items listed under object are currently totally arbitrary. Whatever is listed there is automatically included in the generated table and there's nothing to say that the attributes will be consistent from project to project, or even from page to page. However, in its content model, Quire must define some attributes as specific, such as id so that we can meaningfully make use of them in templates. The obvious candidates might be those that are more regularized and data driven, such as start_date and end_date, or height and width. These in particular would let us implement sorting by dates, or showing a diagram of relative dimensions, both of which have been popular features in past catalogues. Are there other attributes like these that we should define as specific to an Object in Quire?

• Can/should Objects have Figures?
• Do we integrate Getty vocabs in some way to allow for more cross-linking? Meaning, can an Object have a Subject?
• In the case above, the object doesn't actually have a title of its own, the Page does. This is odd, but is it avoidable if every page has to have a title? Otherwise we're duplicating the title in two different places, which goes against our best practices.

[egardner]

I was thinking about this a little bit over the last day or two. The duplication of the title attribute across two files could be confusing. And for an object-specific page in a catalogue-style publication, both an object.yml file as well as a markdown page with the appropriate front matter would need to be defined. Seems like a lot of opportunities for things to go wrong.

This might be a good place to start using Hugo's new "page bundles" feature that was added in v0.32. This is the closest that Hugo comes to Middleman's data-driven pages feature (which allows you to build pages from arbitrary data files without a matching Markdown file).

Say you have a collection of objects that will all live in the catalogue section of the publication. You would probably want one or more top-level catalogue pages that list the info for the various objects in a grid, a data table, etc. so they can be surveyed at a glance. But then clicking on a given object would take you to its specific page with more information.

If each object was defined as a single markdown file in the catalogue folder (catalogue/1.md, etc), then on the catalogue/index.md) folder you could loop through the .Resources range and output whatever metadata you wanted, as well as linking to the stand-alone page for more info. Organizing things this way would also let you take advantage of the image-processing feature that was just added in the same release. So if you had a high-resolution catalogue/1.jpg image file, you could render a smaller version of it on the catalogue index page without having to manage a separate asset file.

And the latest version of Hugo v0.35 adds support for what it calls "headless" page bundles, so you could define a collection of objects which do not spit out stand-alone HTML files.

Quire does not support the "page bundle" feature yet (it's still locked to v0.31), but we could bump it to a more recent version of Hugo if we wanted to start utilizing these features. This represents a bit of a change from how we have done things in the past but it could be a chance for us to work "with the grain" of Hugo instead of going against it.

[geealbers]

This has largely been implemented, and is documented in the guide.

Eric's idea of using Hugo's developing "page bundles" feature and the ability to call .Resources was a good one, but I think counter to Quire's overall methodology, at least as we have it now. Currently, we're consistently handling data in a centralized place (figures.yml, references.yml, objects.yml) and we're able to leverage the singular contents-list.html partial to generate different tables of contents (inlcuding one styled as a grid) in different areas of the site (the main contents page, within sections, and in the menu navigation). That centralized data handling in particular seems important as we don't want to have to start dealing with figures or references on a per-page or per-section basis, and it works well enough for objects as well.

That said, I do wonder if the .Resources work in Hugo could help us in improving how we generate those various tables of contents, even while keeping data centralized. One of the big limitations to the way we generate contents lists now is that it only supports one level of sub-section. Ideally we'd have many more levels deep, but as the contents-list.html partial is written now, enabling that would become very challenging. I'm going to close this issue but open another to track this possibible improvement.