[
Lists Home |
Date Index |
Thread Index
]
"Bullard, Claude L (Len)" wrote:
> In the sense that I want to ensure that if I send a RequestForProposal, a
> Proposal is returned, or am able to inquire that if I
> send a RequestForProposal, I can get back an answer that says, No, or Yes in
> a few weeks, or Yes by The Deadline You Specified,
The loosely-coupled web of outcomes architecture that I am describing directly
facilitates what you desire. You create an RFP document and publish it an
appropriate location (very RESTy). Access to that document at that location is
controlled by the now well understood mechanisms of the Web (again RESTy). Each
party interested in that document satisfies the access requirements in order to
GET it, thereby establishing basic understanding of and competence with that
document type. Each of those interested parties, as an expression of its
particular expertise, will consider--that is, process--that RFP in a unique
manner which takes account of, among other things, the specific, possibly
unique, manner in what that party would deliver on the contract if it were
awarded the job. In order to achieve the most exact statement of each party's
expertise, the outcome of the RFP creation process (as later the outcome of
each process under the contract will be) should be instantiated in a form which
specifically reflects the particular expertise of the functions which created
it, rather than in some pre-agreed form which may vitiate, or distort into
ambiguity or worse, the particular semantic outcome of that party's expert
process.
The expression of that outcome, however, will be a simple syntactic body--a
document--from which, upon reviewing that document in a subsequent process, the
original requester might elaborate marginally different semantics. Such
misalignment of understandings is inevitable and inherent in human
communication. The difference here is that the parties share a concrete
document--not a schema, but an instance--through their separate further
processing of which their different understandings might be brought closer into
line. That is what a contract is: a text agreed upon where the semantics
elaborated from it will necessarily differ with each reader, given their
inherent differences of perspective and expectation. Instead of hiding the
inevitable ambiguities of any transaction between peers, where one party does
not dictate the entirety of the semantics to the other, the document
represents--in fact, is--the best statement at any moment of the agreement and
common ground accepted by the parties. This is so precisely because it is a
bare instance and not the instantiation of agreed semantics. And on that
distinction hinges the crucial difference between the monolithic and the
loosely-coupled architectures.
Respectfully,
Walter Perry
|
