In particular, I am interested in mapping the "BootSource" and "BootMode" of a computer into equivalent Redfish properties, and would like to understand
what the Redfish specification direction here is.
BootSource ==> The source the Computer will boot from ex, HDD, CD, ...
BootMode ==> The end target of the boot process, for ex, boot to BIOS or to a Diagnostic mode
Trying to identify where these best fit in. There is the "Boot" property in the Computer system schema which specifies
"BootSourceOverrideTarget" which is of type "BootSource" enum. That enum however, seems to cover both boot source and boot mode (For example value Hdd means local disk while BiosSetup would mean boot to bios)
There were additions made in the 2018.3 release to add some more useful functionality here. The "AliasBootOrder" to tie a permanent boot order to the functions of the bootable devices (in "BootOptions" collection) is of particular note... That was added to provide an abstraction for the user that existed in pre-UEFI terms.
There isn't a clear distinction between "BootSource" and "BootMode" as you describe it. The "Alias" definitions in BootOption (and ComputerSystem's Boot object) is, as you showed, really a list of both concepts.
And the Boot object in ComputerSystem deals with both the temporary boot "override" functions and the permanent boot order - where those options/devices are described by the BootOption collection.
While there are cases where a single boot 'source' may have several 'modes' - that distinction may not be important to a user. We added the Alias properties to allow scripting that doesn't depend on a priori knowledge of the exact configuration of the system. The popular use cases of "Boot to PXE" or "Boot the CD" shouldn't need to do a lot of searching and selection (because the system BIOS knows where these things live and will figure it out).
The whole "booting" area is always one that creates a lot of confusion and frustration, so if there's anything missing here we'd really like that feedback! I've said many times that it's unfortunate that the two most-used functions of remote systems management (boot order and system reset) are much more complicated than anyone would expect!