You need to study up on this issue a bit. The disputed issue isn't a database, by which you presumably mean the published MUNI schedules. The issue is the *arrival prediction information* which NBIS claims is covered by patents. The arrival information is determined based on realtime reported GPS position of the MUNI vehicles. Then, presumably, NBIS applies some algorithm taking into account traffic patterns to predict when the vehicle will reach each of its stops.

The basic issue is that since this is a *publicly funded* project, can NBIS keep the public from using this information in any way they, and San Francisco, desire.

The concern that I have with any so-called 'Clean Slate' approach to reinventing the Internet, is that it would tend to focus on problems perceived in the current Internet (security, mobility, etc.). The danger is that the strengths of the current architecture are likely to be overlooked.

Any new Internet architecture should hold true to the principles articulated in RFCs 1958 and 3439.

A focus on security issues without respecting current Internet architecture strengths is likely to result in something more closely resembling the PSTN or Cable TV networks. Both those networks are highly secure (relative to the Internet) and both are centrally managed. Of course, the downside is that the network manager exerts a large degree of control over what can be done on their network. This naturally has an negative impact on innovation. Innovation can only occur within the limits of what the network owner can currently think of and allow.

Internet architecture (in broad terms) differs from PSTN or Cable networks in using intelligent end-points and a relatively simple network core. PSTN and Cable networks are just the opposite: The 'intelligence' is contained in the network core and end-points are relatively 'dumb'.

I'm all for blue-sky investigation into all possibilities, but lets not rush forward with a focus on current problems without recognition of exactly what has made the current Internet a success.

This illustrates how Microsoft has taken User Interface development down a very bad path.

The original Mac OS UI standardized on a single location to find actions: The Menu Bar. Whatever you had to do, you knew where to look. This was in direct contrast to command line applications where you either had to keep the commands in your head, or look them up in documentation. Now, we have a proliferation of places to look for actions in a graphical interface: Menu Bar, multiple Toolbars, contextual menus, etc. This proliferation of places to look for actions is leading to greater UI confusion, and back to the UI problem of command line applications, as evidenced by the poster who didn't realize there was a way to mark an email as 'read' in the new Hotmail. The graphical interface is supposed to show you what you can do, you're not supposed to have to 'just know'. I find contextual menus particularly egregious, as there is no 'affordance' to indicate to the user that there's anything to look for. Does one just randomly right-click on everything to see if it has a contextual menu associated with it? Bah. UI design at its worst.

Unfortunately, due to the monopoly position of Windows, even the Mac OS has been forced to go down this path of providing toolbars and contextual menus. One mitigating trend I've observed in some (not all) Macintosh software is the use of contextual menus to duplicate operations presented in the menu bar.

UI design needs to return to a single canonical location to find operations (the Menu Bar). If UI designers want to use Toolbars and contextual menus, use them only as shortcuts for operations that are already presented in the Menu Bar.