Duane Nickull Senior Standards Strategist for Adobe Systems set forth a set of goals on Ontolog Forum
Subject: Re: [ontolog-forum] Start thinking about the 2008 Ontology Summit
+ Free public API’s where organizations with folksonomies (tag clouds often represent these), can link terms in their folksonomies to disambiguate words like “Washington” which may have several meanings.
+ a system architecture with no single point of failure and a flexible service oriented approach to creating a platform for ontology work on the web.
+some artifacts to explain in simple lay terms, how to use the ontology and how to reference items in it from taxonomies and folksonomies with simple context and event declarations.
+ a strong thrust of work on context.
…which lit a fire of discussion over the term context.
Implementing Duane Nickull’s stated goals would benefit the general public in a number of ways. But there are unanswered questions for example: What is meant by a single point?
What system features fail and how can the single points of such failures be diffused to enable functional workarounds on the fly?
Duane Nickull states the following in response “Single point of failure in (Service Oriented and System) Architecture is a concept whereby one component has the power to render a larger set of components useless if it fails. When architecting ebXML, the W3C Web Services Architecture and the United Nations architecture, we employed multiple failsafes such as a federation of registries instead of a single registry repository since the single one represented a potential point of failure. Even if we employed multiple registry-repositories and syndicated master records from one, the one represented a single point of failure. Instead, all these architectures use a system of high water marks and federation (much like DNS for the internet) to guarantee no single point of failure can bring the entire infrastructure down”
SCIP, meaning the Stanford Computer Industry Project, reports “major computer industry problems such as interoperability, systems errors and project failures are in large part software problems.”
The other SCIP, meaning Specifications Consultants in Independent Practice, has lively discussions about failures. Everything from a wood floor product failing in adhesion, to windows not passing performance tests, to buildings falling down and exit doors failing to operate during an emergency. What emergencies are caused by the single point of failure in a system architecture?
In the real world, people get trapped in a nightclub fire and exit devices are not only invented, they are required by building codes and local laws. Where do ontology users get trapped?
Who maintains the system of building codes and laws to avoid system wide failures caused by single points in semantic space? In the case of an exit door in physical space, the point of failure is the unfortunate fact there is only one way out, the opening might be too narrow, and untrained people do not know how to operate the locks or control the flow.
The Construction Specification Institute CSI has a discussion forum on Code Interpretation and Failures. Because building the physical world is already an established process, the roles of contractor, architect and engineer are defined. Are the only architects designing “system architecture with no single point of failure and a flexible service oriented approach to creating a platform for ontology work on the web” actually engineers? Who are the Contractors and Owners of these semantic spaces and designs?
The CSI discussion on code interpretation and failures include contractors points of view “with a lot less time to research the code requirements than the Architect and the Engineer that already have the contract to produce construction documents, would it not be the proper thing to just list the requirements , instead of putting the responsibility on all the bidders to research code requirements which only one bidder will be successful?”
Architects designing systems without single points of failure are researching which code requirements? Common Logic? Conceptual Graphs? ISO Standards? Yet, outside of failures to communicate which could be caused by crossed wires between originators and interpreters for a million reasons – what are the current worse case scenarios? What fails, falls down, breaks and blocks the path of progress? What checklists are used to contract the Architects, Engineers, and Contractors for large scale public projects? What construction documents are available to end users as if the plans, specifications, and warranties were in the hands of a condo board, comprised of lawyers, waiting for their windows to leak?
What are the warranties against failure? Failure of what? Adhesion? Not passing performance testing? Emergency response or instantaneous reconfiguration, opening up, structural disappearance or collapse to allow large scale escape during an emergency? Has the digital age faced these emergencies yet?