"binary executable" is not a top level subclass of software, it is a form of software distribution and there are several other subclasses of software distribution (source code, web site, library, toolkit, etc.).

Similarly, "network editor" is just one class of interactive editing tools.  Lots of others.

These are just a couple of examples.  Software really needs a complete reorganization.

The BRO used the initial design principle of: when in doubt make it flat at the top.  This is a design principle whose purpose is to get the class names 'on the board and agreed upon' first, i.e., it is a componentization of the design process. This is a way of avoiding getting into debates about hierarchical location too early in the process. We can discuss location in the hierarchy in the future; that is appropriate.

I (Peter Lyster) copy marginal notes that I also place in the 'Portals' class.  I think this helps to explain the design principles.

We adopted the design principle of (i) initially align the BRO top level with NIFSTD (Data Resource; Bibliographic Resource; Software; Research Supplies; Portals; Funding Source) (see agreement that was made in broad tcon of 20080416 http://na-mic.org/Wiki/index.php/SDIWG:Meeting_Minutes_20080416). As with the discussion on 'Software' class, the goal was to get a reasonable first cut and then stabilize the BRO development process; then the development team (called 'tiger team' after the April tcon) agreement (interdigitate etc) on the overall list of class names (this was successfully done by Rubin, Martone, and Lyster between July 28 and August 1 2008). This process was highly successful, and validated the logic behind taking one step at a time; (ii) continue to work with NIFSTD and other stakeholders to plan current and future efficient and effective mappings.  It is good to revisit in th future the position of upper-level classes such as 'portals' or 'funding source'.