Money fails as a value proxy

Over on his blog, Brad DeLong is asking where modern macro economics went off the rails and started ignoring well-understood economic history.

I stuck an opinion in the comment thread. This, though, is a bit too much for a comment.

If the efficient markets hypothesis doesn't hold (and I think you have to accept that it doesn't hold at this point; the Great Recession is a direct result of treating the efficient markets hypothesis as true), money isn't a good proxy for value.

Remember that value is the ratio between performance and price. In economic models, value is usually approximated as price, both because that's a whole lot simpler than attempting to determine value directly and because people have more or less lost the distinction; "what's that worth?" and "what's that cost?" are not inherently synonymous statements, but could certainly be used that way in conversation without anybody looking at you funny. Now, price is important; figuring out the price point to sell something at is a lot of what's involved in commercial success, and the price of money does constrain economic activity, and so on, but price and worth (value) aren't the same thing.

If money is not a good proxy for value -- and if the efficient markets hypothesis isn't true, it can't be -- all the arguments from models related to money break. Some things, like the notion of the velocity of money, continue to work because they're focused on spending, which is safely distinct from what the economy as a system is doing. But on the whole the models are modelling something subtly false of fact and will fail where they fall into the crevasse between the map and the territory.

An economy can be a machine to create general prosperity, or it can be a machine to concentrate wealth. Brad would know better than I which time periods represent which modes in the US economy, but I think it's pretty easy to point out that 1946 through 1970 or so represent a "generate prosperity" period and 2000 through the present represent a "concentrate wealth" period. 1970 through 2000 represent an interesting tussle intended to move the economy away from generating prosperity and toward concentrating wealth.

These two kinds of economy are not the same system, and while I am not an economist, I've never seen any popular or public discussion of economic policy which either directly address the question of what an economy is for, or treated the change from a basically level income distribution to a sharply tilted income distribution as a change in fundamental system (like the switch from steam to diesel-electric in railway locomotives, say) rather than as a side effects in shifts in marginal utility of different skills. Not thinking in terms of system lets you avoid "the purpose of a system is what it does" and treat policy as a question of operating within axiomatic constraints, rather than testing the axioms. (Anyone want to bet that the efficient markets hypothesis was the only busted axiom?)

So I think there's three problems:

1. not asking what an economy is for
2. attempting to model in terms of money, rather than value
3. no systematic attempt to test axioms

This gets to Brad's point about not looking at economic history when creating models, but I think it also gets to a point about really serious social pressure to not question the axioms. Once you're not questioning the axioms, whatever you're doing isn't science.

Science is about knowing how wrong you are. Until it starts being science, nobody's going to know who is wrong; not knowing who is wrong has enormous social utility on both the individual and political levels.

Down and Out

I don't think I moved where my feet were located to take these, though I did move which way they, I, and the camera, were pointed.

Oak Leaves

Elevated platforms can be a real help with this sort of shot.

Lumberjack

There's a bunch of these high bas-relief sculptures in the wall of one of the entrances to the Queen subway station. (Banks seem to like producing nice walk-through spaces in their buildings.) They're at eye-height for hobbits, and next try I should crouch down a bit. What I get for being opportunistic when walking through at the end of a photography day.
Still, I rather like this one; it's been battered by circumstances, but as an image of foundational Canadian industry, it does pretty well.

Outpouring

TOC Bird Walk–Shore Birds and Late Migrants, Tommy Thompson Park

For a day that was forecast to have hard rain start around noon, the actual start time (about 16h00) was a remarkably nice break from the weather.

Bob Kortright led the walk; this is the first walk of his I've been on, and his take on the park is noticeably different from that of other leaders of Tommy Thompson park bird walks. This was an interesting change, and I'll be going back to some of those corners of the park.

Based on some of the other birders on the walk, I have a long, long way to go when it comes to spotting birds in undergrowth and thick leaves.

Don't know what the group total was; I saw (meaning, saw it well enough that I either could, or believe I ought to have been able to, identify the bird) 34 species:

American robin
American widgeon
black duck
black-throated green warbler (included a fresh male in goldenrod; really vivid)
blue jay
blue-winged teal
brown creeper
Canada goose
chipping sparrow
common yellow-throat
Cooper's hawk (sitting on a chain link fence by the park's access control point; last bird of the day)
dark-eyed junco
double-crested cormorant
eastern kingbird
Eurasian starling
gadwall
golden-crowned kinglet (there were ruby-crowned, too, but I wasn't able to confirm any)
goldfinch (plucking thistle seeds, and letting the fluff float away...)
greater scaup
green heron (in clear view, on a dead branch, and it just stayed there)
killdeer
magnolia warbler
mallard duck
mute swan
northern flicker
northern pintail
palm warbler
phoebe
sharp-shinned hawk
shoveller duck
song sparrow
white-crowned sparrow
white-throated sparrow
yellow-bellied sapsucker

So quite wretched for shorebirds but a pretty good day all the same.

Inside

Part of the park is in a building. This is me trying to freeze the fan motion (and mostly succeeding) though the sky is a bit bright.

Silence

Emulation of a river

Pigeon for scale. :)

Late Bloomer

Outside, despite the shape of the leaves. Not looking unhappy, either; I have to assume that the urban heat island around Richmond and Yonge is pretty effective.

Toronto Ornithological Club Fall Field Day, Tommy Thompson Park

The TOC does a fall field day every year, and has done since 1934. This year, there was a formal division into groups looking at different areas—Tommy Thompson Park, High Park and area, and Durham Region.

In the interest of logistical sanity, I went on the Tommy Thompson part of this, since that was the easiest of the three areas for me to get myself to.

Despite that, I managed to miss four TTC connections in a row by margins of less than 30 seconds, and got there half an hour late. Fortunately, I knew where the group would have gone, and was able to catch up with the group by 08h30. The group, ably led by John Carley, started at 15 and was down to 7 by 16h00 or so, when there was a collective declaration of it being a day.

Out of the 53 bird species seen on the Tommy Thompson part of the walk, I saw 31:

black duck
bluejay
bluewing teal
brown-headed cowbird
brown thrasher
Canada goose
canvasback duck
cedar waxwing
double-crested cormorant
eastern phoebe
European starling
gadwall
goldfinch
great blue heron
great egret
green heron (impressively hard to see when it holds still)
greenwing teal (~60 in a flock, flying; this is very vivid)
grey catbird
herring gull
hooded merganser (juvenile)
killdeer
kingfisher
mallard duck
mourning dove
mute swan
northern flicker
peregrine falcon
redhead duck
redstart
shoveler duck
spotted sandpiper

Rust

I'm not at all sure I get this whole aesthetic of rust thing, but here's an attempt.

Garden Flowers

Flowers in handing pots, with the pots located in a small contemplative garden round the corner from an office building.
Flowers with mirrored walls in the middle distance tend to confuse the metering, but I think I got good detail on these.

The Agora

Even under entirely fortuitous circumstances, this street photography stuff is hard.

Waterfall with Cabalistic Signs

Kinda hope it speaks for itself.

An arragenement of lenses

Notable, alas, chiefly for having all the smudges and smutch on the glass in good focus, but I thought this arrangement on a shop door was neat.

Stress

Windows are rarely really flat. Here we have a lot of windows being differently not-flat, and I liked it.
I would have very much liked to move to the right, and up a bit, but there was this rather substantial wall in the way. Should try to get an evening-light shot of this view, too.

I've looked at light from both sides now

I'm sure any of the passers-by who noticed me intently photographing the window of an empty store thought I was a bit mad.

On the plus side, I did get the timing right on this one. (There are a number of others where the timing in rather less right. But that's OK.)

Small flowers

About 2/3 of the frame; the left edge of what you see is the left edge of the image as taken.
This one is the whole frame.
Flowers were quite teeny, about 2 cm across in total. Also quite low; I was sitting on my heels to get low enough for these.
No matter how much I wish it were an f1.8 instead of an f2.8 design, I have to admit that there is little to complain about in the rendering from the DA35.

Not a spec of orange

I probably shouldn't find this window funny at all, never mind as funny as I do, but there you go. The thing I use for a sense of humour doesn't seem to be into explicability a whole lot.

Vegetative Optimism

Flowering quite happily in the middle of September. Which isn't, I suppose, crazy optimistic any more, since Toronto can get well into November before there's a hard frost these days.
As usual, I have no idea what kind of flower this is; it's in a park, and I presume planted, and I think they're pretty.

None Shall Pass

I like the various shadows in this one probably more than I ought to.

Overflow

Top of the waterfall at Cloud Gardens Park in Toronto. I presume it's off due to the season, since the lower sections continue to run.

Brick and Mortar

Think there was a house there, once upon a time?

It's Titles All The Way Down

DITA uses the <title/> element for maps, topics, sections, examples, tables, and figures. (Among others; check the spec for the full glory of the title element.)

This is completely logical from a semantic tagging perspective. A title goes right on being a descriptive heading for a content grouping no matter what content grouping you're describing. During a transition to topic-based authoring with DITA, though, this may not seem entirely logical to the writing team.

Titles are Labels, Not Structure

Titles are not part of the main content tree structure represented by your XML document. They're in the XML document's tree structure, they have to be by the inflexible rules of XML. But a title element's limited descendants do not include the content of the thing for which they provide the descriptive heading, or indeed anything but the content of descriptive heading itself.

This means that you cannot follow the titles through the XML structure; they are labels stuck off to the side. They might not be there at all. (Even in a topic, titles are optional. You're going to have an interesting time with a CMS and displaying many title-less DITA topics, but you might think the interesting time is worth it.)

Structure is things like

• the composition of component maps into your main content deliverable map
• the sections of a topic
• the semantic labelling of some content inside a topic as a figure
• the nested group of topic reference elements in a map

Structural representation gives nodes in the content tree, that you can keep following down from the root and get to progressively finer divisions of the presented content.

Which is where the trouble with the "but is this an H2 or an H3?" question starts. (As you're transitioning to DITA, someone on your writing team is going to ask a question like that.)

In a desktop publishing application, heading levels are structure. The content is fundamentally flat, a continuous stream of characters. Structure is expressed through a change of formatting. In XML, structure must be expressed through the tree structure of the XML document; this is due to the rules of XML. Semantic structure can be expressed in other ways, but DITA uses strictly the XML tree structure.

In DITA XML structural terms, the title elements are descriptive labels for the other children of the title's parent node. It doesn't matter if that node is a figure or a bookmap; the title is a descriptive label for the other kids. (The title element itself has to be a child node of something by XML's inflexible rules. The title element is the child node of the node that's the parent of everything it labels.)

This is why using <title/> for everything that needs a descriptive heading works; the structure is already there in the XML tree, and all the processing needs from a human is the natural language label for this node of the tree.

Mistrust Of Automation

Any kind of authoring with DITA only works if the output generation works. You can do all the semantic tagging in XML you like, but if you can't get from the XML to what your customers expect as a delivery, the process as a whole is going to fail.

Oddly enough, the chances of the members of your writing team being filled with hope and confidence about any kind of software aren't good. There are a bunch of potential reasons for that, and I'm only going to go into one of them.

Unless (a very large unless) you're transitioning to XML from SGML, you and your writing team have never used anything primarily designed to create and maintain structure in your content. Whatever it is, it will have been designed to label text—strictly, some sequence of character data—with presentation information (font, font size, font style, and so on), possibly in clever ways (FrameMaker's concept of a frame as a container from which formatting properties derive, for instance). Even something like Structured Framemaker retains both the tight link between content and format and the concept of a formatting over-ride, so you're not seeing true form/content separation. Without true form/content separation, you're also seeing software that has to deal with an effectively arbitrary range of special cases, which makes it very hard to produce and fully test that software.

Once you have both XML and[1] true form/content separation in your content, the number of special cases the software has to deal with drops enormously; it no longer has to find a way to allow for "this one specific title element is different from all other title elements", and can proceed on the basis of "what to do with this title element is defined by its parent element".

As a result, output processing that really does Just Work is readily achieved using XSLT. It take awhile to believe this, and it might take your XSLT programmer a little while to achieve this, but it is straightforwardly possible.[2]

There may be minor issues with use of titles in figures and tables, where it's perfectly straightforward to put the title after the image or table in the delivered document, despite the title occurring before anything else (it's the first child element of the node it labels; this is a good convention!) in the DITA content. Practice will allow adjustment to this.

But is it an H2 or an H3?

This is usually asked about topic titles. The answer is "it depends on where it is in the structure of whatever you're processing into a delivered document".

A topic can be referenced by many different maps; it can be referenced more than once by the same map. It can also be processed directly, as itself. The heading level of a particular title element in the output depends on the position of the content node labeled by that title element in the DITA XML structure that's being processed into a delivered document.

Which is the same as saying that any individual topic title element could, depending on its position in the structure defined by a map, provide a title at any heading level in the eventual content delivered.[3].

This understanding of the topic as the individual brick from which the house of the content delivery is built can be—I've seen it split about fifty/fifty in a writing team—the really tough mental transition point. It's a topic; it goes somewhere in a content delivery. You don't know what the output processing is eventually going to do to the title elements in this, or any other topic. You don't have to worry about heading levels; just structure.

But What About Chapters?

In a regular DITA map, a chapter is a formatting convention, presumably a special case in the output processing that says "this is the first reference down from the root in the map, it must be a chapter". In a bookmap, chapters are an explict reference using the <chapter/> element or <topicref/> children of a <chapter/> element.

Keep in mind that even when formally semantically defined chapters exist, chapter handling may vary between output types. HTML output is unlikely to have a concept of chapter at all, but you might process bookmaps to HTML. PDF outputs may have a formal, starts-on-a-recto, chapter title halfway down the page, chapter, or they may do something like continuous text with outline numbers to distinguish where you are in the organization. The same map, depending on output processing, may be produced using either or both of these conventions, or any others that you may have. Output processing is not compelled to treat chapters in any particular way; chapter handling depends on what you have locally created as your output processing.

There's Stuff Between a Chapter and a Topic!

Sure, but that stuff is going to have <title/> elements, too.

Whether you provide titles for topic grouping through topic nesting, component maps that are assembled into your top-level content deliverable map, or some form of specialization, if you're using DITA, you have a tree representation of your content built into the XML. You can't hope to avoid this. You really shouldn't be trying to avoid that.

Given that DITA XML tree structure, the title element is the natural way to present a descriptive heading. Anything that would appear in a complete table of contents is going to be the title element child of a node in the XML structure of your DITA map.

Summary

DITA title elementa are descriptive labels for nodes in the content tree, irrespective of the amount of content tree below the labeled node.

The output processing can effectively and automatically determine how to represent each title.

This is a signficiant change from narrative authoring in a desk top publishing application, where heading levels function to demarcate structural divisions in the document. In DITA, a title becomes strictly a descriptive heading, and does not get overloaded as a structure representation. This simplifies the writing process; you'll never have to go and change an H2 to an H3 because you moved a block of content.


[1] This is a mighty and; it's perfectly possible (as both Open Office and recent versions of Word do) to use XML to represent the content in a desktop publishing application.

[2] There are of course other options for processing XML into delivered content. XSLT has the advantage of being designed to solve this specific problem of XML tree transformation.

[3] DITA itself allows arbitrarily deep nesting; you'll have to make a style decision about how much depth you want your output processing to support, and how you'll have the output processing respond to overly deep nesting. Because you can nest maps in maps, it's not straightforward to test for nesting depth before output processing.

[4] You can have multiple title elements in a single section element; this is entirely valid according to the DITA specification. It will also make a serious mess of your outline numbering, if outline numbering is involved. This is a good place for a Schematron rule.

TOC Bird Walk–High Park Fall Migration

Starting at a civilized (meaning I can get there on the subway) 8h00, the walk took place on a gorgeous sunny day with a high of 24 C and no wind to speak of.

Steven Favier lead the walk; he's impressively familiar with the park, and provided a good cluster-finding rule ("find the chickadees") for migrants, particularly migrant warblers.

I saw 40 birds; since the official list count was 43, I'm feeling pleased.

I saw:

American crow
American robin
black-and-white warbler
blackburnian warbler
black-crowned night heron
blackpoll warbler
blue-headed vireo
blue jay
Canada geese
cardinal
chestnut-sided warbler
chickadee
chipping sparrow
coopers hawk
double-crested cormorant
downy woodpecker (clouds of downy woodpeckers)
gadwall
goldfinch
great blue heron
great egret
house sparrow
kingfisher
magnolia warbler
mallard duck
mute swan
Nashville warbler
northern flicker (posing, on a bare, horizontal trunk against bright sky and calling)
pigeon
pine warbler
red-breasted nuthatch
red-eyed vireo
redstart
red-tailed hawk
rose-breasted grossbeak
ruby-throated hummingbird (3!)
Swainson's thrush
warbling vireo
white-breasted nuthatch
wood duck
yellow-bellied flycatcher


Personal highlights include being the first to spot the blue-headed vireo and one of the Coopers Hawks; seeing my first-ever male wood duck in breeding plumage (very fresh and glowy breeding plumage); and the cloud of downy woodpeckers, who for a while there were markedly outnumbering the house sparrows.

Maps in DITA

The basic DITA map concept is extremely generic; maps are how you arrange topics into a structure. Maps are all structure, and no content, though they may have meta-data. The "all structure" part can be one of the tougher parts of the mental transition to topic-based authoring.

Simple XML

The XML for a topic reference in a map is simple

<topicref href="topic_UID" type="task" />

to reference a single topic, and the topicref element nests, so you can produce tree structures:

<topicref type="topic" href="Intro_UID">
  <topicref type="concept" href="Subject1_UID">
    <topicref type="task" href="Subject1_Task1_UID" />
    <topicref type="task" href="Subject1_Task2_UID" />
    <topicref type="reference" href="Subject1_ChartsAndTables_UID" />
  </topicref>
  <topicref type="concept" href="Subject2_UID">
    <topicref type="task" href="Subject2_Task2_UID" />
    <topicref type="task" href="Subject2_Task2_UID" />
    <topicref type="reference" href="Subject2_TopographicMap_UID" />
  </topicref>
</topicref>



but the implications aren't as simple as the XML.

A Topic Doesn't Care Who Is Pointing at It

A good topic is independent of the topics around it. You can mix and match units of information to create the document you want for a particular purpose. Therefore, when topics are organized together by a map, the information about any group of topics—what it's for, why it's a group, who might want to read it, how you should approach reading it, what scenario is addressed by this particular sequence of topics—is not going to be contained in the component topics of the arrangement. So you need a way to provide this map structure description, contextual information linked to the specific map (the specific arrangement of topics).

Good topics do not know what maps, if any, reference them; it could be one map, no maps, or eleven thousand maps, and this should make no difference to the topic as a content object.

Map structure description is not independent of the structure of the map; it cannot be arbitrarily re-arranged or referenced by other maps. It is therefore not suitable for being delivered as a topic content object.

One solution to the problem of providing map structure description is to use unspecialized topics—the Intro_UID topic in the example above—to contain information about topic groupings. (The most basic information-causes change type of information involved in map structure description answers do I need to read this? for each known audience type you are addressing.)

This nest-in-generic-topics approach has the twin drawbacks of a) making it difficult to separate the topics that are the content objects and the topics that are map structure description in your CMS search system and b) introducing a considerable risk of natural language dependency between topics. Introducing natural language dependency is especially difficult to avoid early in the transition to topic-based authoring when it will remain conceptually easier to stick some informational content in the map structure description. This is the sort of topic-interdependence that hampers re-use and makes you have to know about the specific natural language content of a topic before you can use it in another map.

Ideally, some combination of good writing discipline, the content management system, and DITA specializations will prevent an outcome where map structure description takes on information content and hinders content object independence for topics and ease of topic re-use.

In terms of the CMS and DITA specializations, it is especially desirable to restrict topic content object references—the actual content — to being leaves, and only leaves, of the tree structure represented by the DITA map XML document. If this is the case, natural language dependencies between topics, including specialized topics used to provide map structure description, are almost impossible to introduce by accident, ease of re-use is maintained, and you can't get into structural trouble with map-in-map references.

[Subhead]Alternative approaches to providing map structure[/Subhead]
(Not an exhaustive list)

• specializing one or more map types so that they can contain their own structure description
• using the short description—<shortdesc/>—element of a topicmeta element in the map to contain the map structure description
• specializing a restricted topic type that functions strictly as map structure description
• accepting that you won't provide map structure description (which tends to raise fewer aesthetic issues in an HTML delivered document context than it does in a PDF or print delivered document context)
• automatically constructing map structure descriptions from the map's child topics
  
  • having the output processing pull the navtitle and the short description of each child topic, for instance
  • this approach requires extremely disciplined and consistent topic writing
  • no special-case topic types or map specialization

Map structure description is an issue your information architect and editors need to be on top of before anybody gets confused about it. This is one of the truly different things about topic-based authoring, compared to narrative authoring, and clear communication throughout the writing team is a big help with making that part of the transition go smoothly.

Maps of Maps ... of Maps!

Maps represent, and can contain, more than one type of structure. For instance, and non-exhaustively, maps can group topics as:

• a table of contents hierarchy
• the fulfilment of a particular scenario for a particular persona in scenario-based authoring
• a collection of thematically related information, such as a group of topics covering the safety precautions or operating requirements of a particular product

It is very important when selecting a content management system that you select one which fully supports all the types of grouping you want to be able to do with maps. While it's entirely possible to manage maps by hand, with human beings either typing or cut-and-pasting object ID references like href="gra1205267857891.xml", it's not really practical. You want select-from-search, drag-and-drop means to assemble your topics into maps, and a display mechanism for the assembled maps that both shows the primary tree structure and presents topics in terms of something human-readable, like their title and type.

DITA maps Can Be More Complex Than a Simple Hierarchy of References

One of the most useful additional map components is the DITA reltable element—relationship table—which can be used to define relationships between topics in the map other than the hierarchical, table-of-contents relationship of the main map structure. You can use these relationships to provide secondary information traversals for the content referenced by a map, such as those which fulfil particular scenarios for specific personae in your target audience.

In this application, the main, table-of-contents ordering is provided by the map structure and specific, persona-targeted information traversals associated with individual scenarios are provided by the relationship table element. This requires that you have output processing that can interpret relationship tables in this way. You'll either have to build that yourself or get your CMS vendor to do it. Hand-editing relationship tables is even less of a source of joy than hand-editing regular XML tables, so you also want to make sure you XML editor or CMS provide support for building relationship tables before you set out to use this approach in a production environment.

Divide and Conquer

When managing large maps—it's really easy to have a 500 topic map if you're providing a comprehensive user guide for a medium-sized software application—it can be much, much simpler to treat some or all of the main, represents-the-content-delivery map as a grouping of smaller maps.

Since DITA 1.1, map-in-map references are a standard part of DITA. The only (very slightly) confusing thing about this

<topicref href="map_UID" format="ditamap"></topicref>

is that it uses the topicref element, and distinguishes map references for processing by use of the format attribute.

One implication of map-in-map structures is that you can standardize a component map type, and use that map type to build the maps that correspond to a full content delivery.

It's very likely you will have emergent patterns in your maps; similar information being presented to similar audiences will be, or at least ought to be, expressed in similar ways.

An example of this kind of pattern is a standard lesson pattern where you have

• a concept topic (the subject in the abstract as an aide-mémoire for the instructor)
• one or more task topics (what the instructor is to do to deliver the lesson)
• one or more reference topics (supplementary information, such as bibliography or references for further reading)

Once you have identified these patterns in your content, you can create named template versions of your component map type to match the pattern. This facilitates both consistent patterns of information presentation and ease of large map construction. It's significantly easier to manage the main map has seven lessons in it and seven individual lesson-pattern maps than it is to manage one large map which references all the topics directly. Because the map inclusion is by reference, the component maps can become larger units of re-use; every installation guide gets the component map on ensuring you have a safe work area, for example, or every software manual gets the component map about how to contact the company, what the warranty is, and so on.

Maps, or at least the content delivery maps, have associated due dates, and anything with a due date has, or really ought to have, someone responsible for making sure it meets that date. This means that you should consider associating the due date and the map lead—the person responsible for making sure this map meets that due date—with the map as meta-data in your CMS. Once you've done that, you can include other role-related meta-data like a list of approving stakeholders or who the assigned editor is for this map.

Maps then function as:

• hierarchical table-of-contents organization for topics
• secondary, fulfils-a-scenario organization for topics
• hierarchical, table-of-contents organization of other maps
• templates for repeated patterns of topics in the content delivery
• a unit of assignment, through CMS meta-data giving due dates and assigning responsibility for completion

OFO bird walk: Toronto Islands

Started at 07h30 Saturday morning at the ferry docks, and ended up at 16h30 leaving from Hanlan's Point to go back to the ferry docks.

Ian Cannell ably lead a rather large group along the arc of the islands; personal highlights include the kingfisher (excellent view of repeated foraging flights), the great egret flying low past the north shore beach, the tercel kestrel chasing northern flickers away from the fence, and being asked what the field marks were for an F22 Raptor.

The Ex is on -- the Canadian National Exhibition -- and the associated air show gave an amazing demonstration of thrust-to-noise ratio.

A Blue Angels F-18C has 2 GE 404 turbofans, generating 48.9 kN of thrust; 79.2 kN with full burner. I'm going to assume that airshow performances don't involve afterburner stunts, so roughly 100 kN per F-18C.

An F-22 has 2 Pratt and Whitney F119 engines, in the "160 kN class", so 320 kN per aircraft. Which makes the "four F-18C approximately as loud as one F-22" qualitative impression at least reasonably plausible. Very different tone to the roar, though; I presume this is the different generations of thrust vectoring affecting the nozzel shape.

I saw 43 species of birds:

American robin
baltimore oriole
bay-breasted warbler
belted kingfisher
black and white warbler
blackburnian warbler
black-crowned night heron (sitting juvenile; flying group of 3 w. 2 juveniles)
black-throated blue warbler
blue jay (flock of 10+, many calling individuals throughout the day)
brown-headed cowbird
Canada geese
Canada warbler
canvasback duck (single juvenile diving along the edges of a mixed feeding aggregation of mallards and Canada geese)
cardinal
cedar waxwing
chestnut-sided warbler
double-crested cormorant
downy woodpecker
eastern wood peewee
eastern wood pheobe
European starling
goldfinch
great blue heron
great crested flycatcher (5 sightings over the course of the day)
great egret
grey catbird
house sparrow
kestrel (pair; tercel displaying along the airport fence and chasing flickers)
least flycatcher
magnolia warbler
mute swan
northern flicker
olive-sided flycatcher
osprey
red-eyed vireo
redstart (many over the course of the day; noted as being surprising frequent)
scarlet tanager (non-breeding plumage; very green with black wings, so male)
sharp-shinned hawk
Swainson's thrush
Tennessee warbler
warbling vireo
Wilson's warbler
yellow-bellied flycatcher

Fall warblers are tough; one of the truly beneficial things about these walks is having some very experienced birders around to assist with identification.

I'm not counting the gulls; it is a moral certainty that I saw a ringbilled gull, but I didn't actually try to identify any, so it doesn't count.

[When I published this initially, the Google ad was for "gas turbine overhauls".]

Pilings

A vertical combination of two hand held shots. (Kinda have to be hand held, they were taken from a narrow floating bridge.)
100% crop of the lower right hand corner, because I am sinfully pleased at the amount of detail the DA35 resolves.

And yes, the angle is rather off the vertical, but then so are the actual pilings.

The end of the summer

No new purple thistle-flowers would be left were it entirely autumnal, but the seeding-out thistle heads are both an end-of-summer/early autumn thing and making the goldfinches very happy.
I am inexplicably aesthetically fond of Scotch Thistle, despite having spent many a weary afternoon in my youth trying to eradicate them from the upper corners of the front hayfield. (Correct solution to this problem: get a goat. Just be aware that if it's a milk goat, the thistles affect the taste of the milk in ways certain to develop character.)

The personification of elegance

My initial response to this pose was "is it dead?"
But no, it is not dead; it was only sleeping on its back. (On a completely filthy tern nesting platform that's been taken over by waterfowl after the terns, rapid breeders that they are, fledged their young and departed.)
The cob swan on patrol around the platform.
This picture nicely illustrates why I want a Pentax version of an 800/8 or 800/5.6 mirror lens; the Rokinon coatings just aren't up to reflections off water.

Weary by the Owlswater

It's amazing how much difference the angle of the sun makes to the yellow.
Though some of it might be the generational difference in the lens coatings (top is FA 100, bottom is DA35) manifesting itself in subtlety.
Either way, I was reasonably happy with both of these.