Systems and methods for establishing a user purpose class resource information computing environment (2024)

This patent application is a continuation of U.S. application Ser. No. 15/674,429 titled “Systems and Methods Enabling a Resource Assertion Environment for Evaluating the Appropriateness of Computer Resources for User Purposes,” filed Aug. 10, 2017, which is a continuation of U.S. application Ser. No. 15/163,407 (now U.S. Pat. No. 9,792,160) titled “Methods and Systems Supporting a Resource Environment for Contextual Purpose Computing,” filed May 24, 2016, which is a continuation of U.S. application Ser. No. 13/928,301 titled “Purposeful Computing,” filed Jun. 26, 2013 (now U.S. Pat. No. 9,378,065), which is a continuation-in-part of U.S. patent application Ser. No. 13/815,934 titled “Purposeful Computing,” filed on Mar. 15, 2013 (now U.S. Pat. No. 10,075,384), all of which are hereby incorporated by reference in their entirety.

Aspects of the disclosure relate in general to computing architecture. Aspects include an apparatus, a method and system configured to facilitate user purpose in a computing architecture.

Computing has become deeply embedded in the fabric of modern society. It has become one of the most ubiquitous types of human resources, along with water, food, energy, housing, and other people. It interfaces in profoundly diverse ways with the pantheon of other human resources types—it has become one of the two major doorways for human functioning, the other being direct physical interaction with tools, people, and/or the like.

Computing tools allow us to do many things that were unavailable—even unimaginable—not so many years ago, so much so that in recent years computing has become a binding foundation for the human community. It is used for administrating and operating a large portion of human infrastructure, for entertainment, socializing, communicating, sharing knowledge, and sharing between parties such as group members, friends, colleagues, community, and other affinity activities.

Most modern computer arrangements function as ubiquitous portals in a giant peer-to-peer Internet cloud. In the aggregate, along with the information they store and the real-time activities and the services they provide, today's computing arrangements can access and/or participate in a vast conglomeration of processing, storage, information, “experience,” and communication resource opportunities. The reason we use these computers arrangements is to employ tools as means towards whatever ends we, individually and collectively, choose to pursue at any given moment—that is we use computing arrangements to fulfill or otherwise satisfy our purposes. Fulfilling our purposes requires exploiting resources, and modern computing arrangements offer resource opportunities corresponding to a large portion of humanity's knowledge and expertise, as well as a virtually boundless variety of commercial, communication, entertainment, and interpersonal resources and resource combinatorial possibilities.

Altogether, modern computing, through both intranets and the Internet cloud, presents a huge, and from a human perspective, an unimaginably large, distributed array of candidate resources, relationships, and experience possibilities. This vast array, given its size, diversity, and global distribution, presents daunting challenges to fully, or even modestly, exploit, and no computing technology set provides reasonable ways for individuals or groups to see into the expanse of resource possibilities as they relate to anything other than their own highly specific areas of real expertise, except as to resources that may be materially, publicly promoted. Even experts, when operating in areas where their knowledge is incomplete, frequently have difficulty marshaling suitable best possible resource sets (set is at least one unit), particularly where the impetus for using resources is the pursuit, the acquisition of information and understanding. Since, the very nature of computing's exploding web of resource opportunities is unprecedented and involves vast, unharnessed arrays of resources, much of this massive variety and population of items, locations, and potential combinations lies within a vast information fog.

Embodiments include a system, device, method and computer-readable medium to facilitate user purpose in a computing architecture.

FIG. 1 is an example of purpose Domains with common members.

FIG. 2 is an example of a user's resource selection.

FIG. 3 is an illustrative example of resource interface.

FIG. 4 is an example resource 1 (laptop computer).

FIG. 5 is an example resource 2 (transparent resource interface).

FIG. 6 is an illustrative example of an (NPR) interaction through PERCos resource interface.

FIG. 7 is an example structure of a resource interface.

FIG. 8 is an illustrative example of the PERCos purpose cycle.

FIG. 9 is an example operating session embodiment.

FIG. 10 is an example operating session embodiment.

FIG. 11 is an example resource item.

FIG. 12 is an example resource embodiment.

FIG. 13 is an assimilation of non-PERCos resource into PERCos environment.

FIG. 14 is part 1 of operating resource creation example 1.

FIG. 15 is part 2 of operating resource creation example 1.

FIG. 16 is part 1 & 2 of operating resource creation example 2.

FIG. 17 is part 3 of operating resource creation example 2.

FIG. 18 is an illustrative example of Construct showing example of simplified participant resource.

FIG. 19 is an example of a simple class system.

FIG. 20 is an example simple class system, extended with mortal.

FIG. 21 is an example purpose Domain relationships.

FIG. 22 is an illustrative example of a “generic” resource.

FIG. 23 is an example resource with access through resource interface and a single resource element.

FIG. 24 is an example resource with multiple resource elements, including component resource.

FIG. 25 is an example transparent resource.

FIG. 26 is an illustrative example of resource relationship embodiments.

FIG. 27 is an illustrative example of relationships between resources and PERCos Dimension values.

FIG. 28 is an illustrative example of operating session comprising Frameworks and Foundations.

FIG. 29 is an example PRMS instance hierarchy.

FIG. 30 is an illustrative example of simplified resource management embodiment.

FIG. 31 is an example of the designator usage.

FIG. 32 is an illustrative example of accessing resources using designators.

FIG. 33 is an example of interaction between PRMS elements.

FIG. 34 is an example of i-Set created as resource for use by one or more users.

FIG. 35 is an example i-Set comprising Information (query results) and i-Element for resource.

FIG. 36 is an illustration of interaction between PIMS, Resource Services, and Persistence Services.

FIG. 37 is an illustrative example of Construct types including comprising resources.

FIG. 38 is an example Foundation Construct template.

FIG. 39 is an illustrative example of PERCos Platform Services.

FIG. 40 is an example of PIMS Structure for resource R.

FIG. 41 is an example of PRMS interaction with operation session and Coherence manager.

FIG. 42 is an example resource management system.

FIG. 43 is an example of resource service interaction.

FIG. 44 is an example RMDF configuration.

FIG. 45 is an example RMDF relationship.

FIG. 46 is a simplified illustrative example of PERCos resource systems and service grouping.

FIG. 47 is an example resource management assembly configuration.

FIG. 48 is an example resource management assembly configuration.

FIG. 49 is an illustrative example of resource assembly.

FIG. 50 is a simplified example of reservation service.

FIG. 51 is an illustrative example of resources and resource interface arrangements.

FIG. 52 is a simplified example of resource component with multiple interfaces (e.g., disk/storage system).

FIG. 53 is a simplified example of shared cloud resource showing separate i-element and multiple resource interfaces for a Common cloud resource.

FIG. 54 is a simplified example of shared cloud resource showing separate i-element and single resource interface controlling resource interactions.

FIG. 55 is an illustrative example of resource comprising multiple types of resource elements.

FIG. 56 is an illustrative simplified example resource.

FIG. 57 is an example resource hierarchy.

FIG. 58 is an example of sharing resource arrangement Information.

FIG. 59 is an example hierarchy of PIMS.

FIG. 60 is an example of “generic” PERCos service structure.

FIG. 61 is a simplified example of creation of resource from i-Set.

FIG. 62 is an example PRMS component configuration.

FIG. 63 is an illustrative interaction between operation session and resource manager.

FIG. 64 is a simplified illustrative example of processing of operating agreements.

FIG. 65 is an illustrative example of states and state transitions four resource provisioning.

FIG. 66 is an illustrative example of Construct usage.

FIG. 67 is an illustrative example of construction evolution from templates to operating Construct.

FIG. 68 is a simplified example of operating resources undergoing specification extraction.

FIG. 69 are operating elements and/or data flow, PERCos and non-PERCos elements.

FIG. 70 is an illustrative example of purpose class application class system.

FIG. 71 is an illustrative example of Master Dimension embodiments.

FIG. 72 are example metrics relationships.

FIG. 73 are example resonance specifications.

FIG. 74 is a mapping between the four types of purpose satisfaction.

FIG. 75 is an example commutative diagram.

FIG. 76 is an example metrics calculation process.

FIG. 77 is an illustrative example of a “generic” resource.

FIG. 78 is an example resource relationship.

FIG. 79 is a purpose Domain relationship.

FIG. 80 is an example REPute calculation process.

FIG. 81 is an illustrative example of Cred creation process.

FIG. 82 is an illustrative example of dynamic Cred creation process.

FIG. 83 is an example of Cred elements and composition.

FIG. 84 is an example of Cred elements.

FIG. 85 is an example Cred publishing and associated processing.

FIG. 86 is an example of three levels of Coherence.

FIG. 87 is an example “generic” service structure.

FIG. 88 is an illustrative simplified example of PERCos SRO implementation processing and Coherence services interactions.

FIG. 89 is an illustrative simplified example of Coherence dynamic Fabric.

FIG. 90 is an illustrative example of Coherence simulation embodiment.

FIG. 91 is an example of Coherence interaction with PERCos services.

FIG. 92 is an example of Coherence management configuration.

FIG. 93 is an example Coherence management configuration.

FIG. 94 is an illustrative example of PERCos cycle processing showing example Coherence interactions.

FIG. 95 is an example of PERCos simplified example service component.

FIG. 96 is a distributed Coherence management example.

FIG. 97 is multiple users with a shared purpose.

FIG. 98 is multiple users with multiple operating contexts.

FIG. 99 is an example Coherence management hierarchy.

FIG. 100 is an illustrative example of computer Edge processing and Coherence processing.

FIG. 101 is an example of Coherence interaction throughout the PERCos cycle.

FIG. 102 is a simplified PERCos cycle with Coherence processing.

FIG. 103 is an example generalized SRO process flow with Coherence.

FIG. 104 is an illustrative example of Coherence interactions with SRO processing.

FIG. 105 is an illustrative example of SRO specification processing and Coherence.

FIG. 106 is an illustrative example of SRO resolution processing and Coherence.

FIG. 107 is an illustrative example of SRO operational processing and Coherence.

FIG. 108 is an illustrative example of Coherence managers, operating agreements, and operating resources.

FIG. 109 is Coherence manager, shadow resources, and alternative control specifications.

FIG. 110 is a simplified example of an embodiment of resource arrangements.

FIG. 111 is an example Coherence dynamic Fabric manager.

FIG. 112 is an example Coherence manager services embodiment.

FIG. 113 is an illustrative SRO specification flow with Coherence support.

FIG. 114 is an example PERCos evaluation service instance.

FIG. 115 is an example of Coherence template publishing.

FIG. 116 is an example global purposeful network.

FIG. 117 is an example interpretation/translation process.

FIG. 118 is an example type 3 purpose expression processing.

FIG. 119 is an example “generic” PERCos service.

FIG. 120 is an example PERCos operating configuration.

FIG. 121 is an example shared Contextual Purpose Experience session.

FIG. 122 is an example “generic” PERCos service.

FIG. 123 is an example purpose cycle.

FIG. 124 is an example of operating system dynamic Fabric configuration and interaction.

FIG. 125 is an example user-related operating service configuration.

FIG. 126 is an example user-related operating service configuration.

FIG. 127 is an example user-related operating service configuration.

FIG. 128 is an example UIDF and RDF interaction.

FIG. 129 is an example UIDF and RDF interaction.

FIG. 130 is an example of detailed view of SRO processing.

FIG. 131 is an example of resource configuration at time t1.

FIG. 132 is an example of resource configuration at time t2.

FIG. 133 is an example of resource configuration at time t3.

FIG. 134 is a subgraph of an example class system relationship graph.

FIG. 135 is an example Knowledge extraction.

FIG. 136 is an example global purposeful network.

FIG. 137 is an example of detailed view of SRO processing.

FIG. 138 is an example of human-computer interaction.

FIG. 139 is an example of a single user session PERCos architecture.

FIG. 140 is an example of shared experience session PERCos architecture.

FIG. 141 is an example purpose cycle.

FIG. 142 is an illustration of waypoints, resources, and descriptive CPEs.

FIG. 143 is an example of human-computer interaction.

FIG. 144 is an illustrative example of Master Dimension embodiments.

FIG. 145 are examples of universal class system.

FIG. 146 is an example auxiliary category class system (WESN).

FIG. 147 is an example auxiliary purpose class system (PWSA).

FIG. 148 are example Construct templates for a class system editor.

FIG. 149 is an example user characteristic faceting list.

FIG. 150 is an example faceting purpose class application.

FIG. 151 is an example Coherence process.

FIG. 152 is an example Resource and publishing process.

FIG. 153 is an example purpose class process.

FIG. 154 is an example Repute creation process.

FIG. 155 is an example of publication phase of Repute creation process.

FIG. 156 is an example of information infrastructure process.

FIG. 157 is an example of user environment process.

FIG. 158 is an example of purpose cosmos.

FIG. 159 is an example of concept mapping achieved through approximation.

FIG. 160 is a simplified block diagram of an exemplary embodiment of a PERCos environment.

FIG. 161 is an example of a simplified interface, from the perspective of both user and publisher, comprising a Dimensional set of characteristics, represented as a quad of the Dimensions.

A Purpose Experience Resource Contextual Operating System/Environment (PERCos) is in part about computing arrangement users connecting to a universal purpose structured resource “network,” a self-organizing grid infused with expertise and enabled by a universe of others, with all their respective nuances of expertise, capabilities, and knowledge and any associated tools and support services. This cosmos, this grid, is a purpose structured network for resource access and provisioning, for identifying and supporting specific purpose related and optimized resource instances, including, for example, very specific purpose application environments and services, and for at least some embodiments furthering or alternatively supporting users gaining at least a portion of the expertise, capability, and/or knowledge inherent in such identified and deployed resources, as well as for applying at least one or more portions of such expertise, capability, and/or knowledge to user purpose related processes.

PERCos environments fundamentally differ from both current web technologies employing key word searching/retrieving for acquiring items and from semantically structured information stores. PERCos can rationalize, for example, through the use of Coherence services sets, essentially incoherent/disordered distributed information and associated resource stores and instantiations, for example, those comprising “big data”, as well as a universe of computing users, user groups, other Stakeholder parties, and enabling resources such as hardware, software, and services, collectively herein called Big Resource. No current technologies, including, for example, implementations of semantically organized information stores, provide efficient, comprehensive, purpose matching resource identification and provisioning. Generally, current web technologies operate on descriptive information stored and associated generally within an item. Other than recommender information, such as Amazon's or Yelp's general rating systems, these systems generally characterize direct attributes of items, rather than provide organized insights into their one or more contexts of use by users. PERCos embodiments can “insightfully” map efficient, standardized expressions of user situational specific purpose related objectives described at least in part by prescriptive user Contextual Purpose Expressions to, for example, relatively corresponding contextual purpose characterizing, quality to purpose filtered, Stakeholder published descriptive Contextual Purpose Expressions, which such prescriptive and descriptive expressions may be transmuted through use of complementary profile, crowd history information, and/or other metadata. The contrast between existing technologies and PERCos is the difference between a not organized to user priorities, optionally disparately tagged, inchoate distributed information mass of nearly boundless dimensions and diversity, to an efficiently structured, substantially standardized, and explicitly user purpose responsive, global information and related resources cosmos.

The human community is now entering an age where a form of pervasive connectedness is emerging. PERCos provides a deeply embeddable systematic way to harness such connectedness so as to be able to match our circumstances, as may be reflected by our purpose and contemporaneous context, with learning, knowledge, and discovery opportunities and methodologies. As in some PERCos embodiments, user and Stakeholder Contextual Purpose Expression of purpose approximations, when, for example, combined with purpose class arrangements, Repute quality to purpose and value infrastructure, PERCos Constructs, and Coherence services can readily connect users to resource opportunities that, by unfolding user inspection and evaluation and/or through the use of purpose neighborhoods and class and/or other grouping ontological and taxonomic arrangements, provides a setting for user learning and discovery and/or the like that enhances experience opportunities and general user productivity. By providing a systematized environment supporting a purpose related cosmos, PERCos allows users to adjust to the approximate level of knowledge they have related to their purpose and navigate according to their awareness of purpose and their unfolding passage through any interim results to Outcomes.

Often people are aware that they need to learn, or discover, in order to achieve optimally practical satisfaction of a given purpose objective. Unfortunately, frequently people are unaware of the value of learning and discovery as relates to optimal fulfilling of their purposes. Further, if people seek optimal resources and environments for purpose fulfillment, they will frequently find that tools to identify best specific to purpose resources are not available—they are unable to associate and assess resources as they relate to very their specific current, personal purposes, though such best resources may be obscurely residing somewhere in the vastness of the internet. No general resource ecosphere exists for discerning specific purpose fulfillment contributing resources, and as such, no system invites parties to, in a systematic way, tailor resource sets to specific user purposes, that is align resources to the specific context and nature of user computing session or cross session specific objectives.

Many PERCos embodiments are designed to integrate purpose, experience, resources, and context into human-computer interactive operating environments, applications, devices, and/or the like, which are optimized to support Outcomes and interim processes that are directly responsive to user purpose specifications and associated contextual input. These operating environments may be provided in the form of software operating systems/environments, software applications, device design, and/or the like which integrate into their design capabilities for user purpose responsive evaluation, management, and provisioning of resources and where such may be achieved through unified product design and/or through PERCos integration by use of APIs, plug-ins, and/or the like.

We live now live in a connected universe of billions of people and other resource items, and other than expense, efficiency, and accessibility, the only limitations in our deploying best available resources to satisfy a current purpose is sufficient knowledge or understanding of such possible, practical resources. While we are members of a vast population of connected parties and we have digital pathways to connect to nearly boundless resources, we are frequently applying far less than the optimal available resources to any given specific purpose than would be possible if we were better informed, that is had knowledge about, and practical access to, relevant, current purpose specific “best” resources.

Our processes in understanding and using resources towards a purpose satisfying outcome, whether social, entertainment, knowledge oriented, and/or commercial, are hampered by our absence, in any given instance, of, for most of our areas of activity, commanding expertise regarding the availability of resources, the arrangement of resources to our specific purposes, and, when applicable, the unfolding of a developing understanding related to our purposes, relevant resources and knowledge. If users could access any and all types and practical arrangements of resources in service of their differing, specific computing session purposes, if they could employ optimal selections of such resources and have access to expertise regarding such resources and/or their content and/or potential/capabilities, users could generally perform at much higher levels and have more satisfying results from their computing conduct. Computing users would find themselves far less frequently making do with a low quality of resources for a given purpose than a fully informed individual, and they would far less frequently find themselves trying to “reinvent the wheel.” Human activity choices and our knowledge of possibilities related to such opportunities now seem to be at a crossroads, where now, at times a boundless array of resources that may be utilized to satisfy purpose. Unfortunately, this relatively recent transformation from lives of relatively simple, basic activities, to lives where we can choose and manipulate resources to provide ourselves with better, quite specific results that are not simply tied to basic-short term survival has not been matched with a general tool set systematizing and supporting human interface with purposeful possibilities regarding what we wish to accomplish at any given moment. Generally speaking, now that much human activity is funneled through computing arrangement interfaces, this unshackling of human's from a basic survival set of tasks to a vast set of human activity types and corresponding purposes has emerged without any systematization integrating the exploding number of possibilities and accordant resources. No formalized, interoperable frameworks for interfacing our purposes with optimum enabling resources and resource portions have arisen.

In part, this absence of focus on human resource and resource choice selection and provision systems may be due to the fact that the history of mankind has been mostly characterized by environments of relatively few and inherently relatively simple choices, whose complexity does not normally involve choices concerning resource selection from a significant number of possibilities, much less vast, disordered stores. But the human community is now experiencing a profound resource explosion and the need for a highly systematized, standardized choice assistance and knowledge enhancement system has rapidly arisen and PERCos inventions implement the first such set of embodiments enabled, in part by various embodiments supporting standardized purpose expression including, for example, Core Purpose and other Master Dimensions and Facets, purpose classes and neighborhoods, Repute purpose related Cred assertions and Effective Facts (EFs), purpose provisioning Constructs, and coherence evaluation and resolution, and/or the like. PERCos technologies can provide an integrated environment for choice and purpose unfolding, assisting users in the identification, evaluation, and use of resources from vast diverse store and producing optimum purpose responsive results.

Human choice should be based upon user purpose and relevant related context, further enhanced as desired by Quality to Purpose and related quality assertions as well as by combinatorial arrangements of resources that are responsive to specific user purpose computing environments (which may be arranged for ad hoc and/or persistent use). Such a general system for web based Purpose management and fulfillment can substantially benefit from both an expertise based Quality to Purpose and related assertions architecture (Repute).

A purpose choice computing system can be optimized by purpose expression standardization for interoperable interpretation and efficiency, where such standardization is based at least in part upon higher level simplification principals, such as PERCos Master Dimensions and Facets, that support user ease in capturing/characterizing their purpose and related relevant context. The foregoing is important in reliable, efficient similarity matching between user purpose and resource store items, as well as to facilitate purpose responsive appropriate approximation results, such as purpose class(es) and/or other purpose neighborhoods and waypoints and/or sets of their members, which may be prioritized and otherwise evaluated based upon such purpose expressions, related context, and/or other metadata, and/or Boolean and/or other mixed or non-standardized user purpose expression components such as auxiliary Dimension elements. In managing a user's relationship to what appears to be boundless and often obscure resource opportunities, such purpose Dimension/Facet simplifications and other PERCos capabilities can bring users to purpose class/neighborhoods for inspection and assessment and further filtering and evaluation, transforming, particularly in conjunction with Repute capabilities, a chaotic set of possibilities into a relatively informed set of candidates supporting an unfolding purpose development environment leading to more productive, valuable, and/or satisfying Outcomes.

The possible potential dimensions and nuances of resources are now highly varied, and can take a vast number of forms, and may, as they are pursued, branch and unfold in many differing ways. Both during free time and while working, many people could now enjoy or otherwise use a cosmos of resources, and users awareness of such resources may unfold over time, and collectively users and other Stakeholders could self-organize resources and store or otherwise publish standardized and interoperable tools for Contextual Purpose Expression, resource profiling, purpose Coherence, resource prioritization, resonance purpose optimization, resource provisioning, resource class applications/Frameworks, and/or the like, all the foregoing supporting connecting users to a nearly boundless cosmos of other participants and resources for experience and other results fulfillment. Humans use computers to assist in realizing objectives. PERCos formalizes the human/computer arrangement relationship as a partnership between human and machines, whereby users provide input specifically and in a formal manner, to direct machine operations towards supporting purpose Outcomes.

PERCos—Purpose Experience Resource Contextual Operating System/Environment

In some embodiments, a PERCos system is, in part, a network and/or local operating system, system layer, and/or cooperative one or more applications and/or services for purposeful computing. PERCos in part, extends traditional operating system capabilities for resource management by enabling user expression of purpose for selection of, and/or matching to, optimally useful purpose satisfying resources. PERCos in part employs means and methods for comparing Contextual Purpose Expressions (CPEs) prescribed by users to comparable Stakeholder published CPEs associated with resources, resource portions, and/or resource and/or purpose class published information. Such Stakeholder CPE information anticipates possible user purposes and related contextual information. PERCos resources, depending on embodiment, may be available locally and/or through/on one or more available networks, including for example, Cloud services.

With certain embodiments of PERCos users can interact with a global “purposeful network,” and such network may, for example, encompass Big Data, users and user related groups, machines and devices, applications and other software, and local and cloud services, the foregoing comprising “Big Resource.” PERCos resource elements, individually and/or in combination, represent resource sets that can be made available and/or otherwise proffered specifically in response to user expressed Contextual Purpose Expressions.

A PERCos system provides a network management platform for one-to-boundless computing. That is, a user can potentially benefit from resources located anywhere, made available by anyone and in any simple to complex combination. For example, published materials, associated machines, devices, computer software, expert consultants, social networking companions, and/or other arrangements, including cloud services, might be used by anyone and/or any group, anywhere, in any allowable and/or operable user-selected combinations (subject to publisher and/or other Stakeholder restrictions and logical operational considerations). PERCos views computer operations as the interaction between users and their purpose related specifications and actions with computing arrangements, for example, for identifying, configuring, provisioning, and/or managing computer processing resources in a manner responsive to user purposes, that is PERCos employs an architecture that responds to user specifications and other purpose related input to effectuate purpose fulfillment processes. In the evaluation and/or provisioning of purpose fulfillment related resources, PERCos, through the use of its evaluation, monitoring, conflict resolving, completion, and other capabilities, synthesizes operating specifications through, as applicable, the use of user and applicable Stakeholder purpose expressions and related specified and/or otherwise allowed further input information such as, for example, resource metadata information, user profile information, and exogenous societal regulations or other considerations.

Human-computer interaction involves a set of human experiences that unfold during sessions that are generated using specified and/or selected resources: computing hardware, software, data (for example, permutations of Big Data), sensors, machines and related processes, and/or possibly other users, altogether known in PERCos as Big Resource. Purpose specifications and/or comparable user actions normally provide the initial, interim, and/or Outcome input for PERCos sessions, and involve at minimum users providing initiating purposes. Further, PERCos system, PERCos purpose specification, purpose class applications, purpose plug-ins, and/or similar arrangements, can guide both an evolving identification, selection, provisioning, and/or use of desired resources though interim purposeful user actions.

PERCos systems support both user ephemeral and Stakeholder declared purpose specifications, and, in various embodiments, associated purpose and resource related taxonomic and ontological arrangements. These purpose related, published or ephemerally declared arrangements are employed by users and PERCos for providing purpose satisfying outcomes, that is, purpose fulfilling computing session interim and/or culminating consequences. Publishers publish resource arrangements and related, declared purpose specifications, which may take the form of one or more purpose class applications and/or declaration of purpose class memberships. PERCos operating systems and/or layers alone and/or in conjunction with purpose class applications, application plug-ins, and/or API implementations and/or the like, can support user/computing arrangements that can then filter, identify, and prioritize, including qualitatively evaluate and provision, appropriate purpose fulfillment resource arrangements. Provisioned PERCos resources and/or a PERCos implementation can operate and manage user/computing domain cross-Edge communications in support of unfolding resource/user interactions.

In particular, PERCos is by design a cross-Edge user/computing arrangement architecture that supports, assists, and transforms human approximate and relational specific purpose concepts into computing resource parsing, provisioning, and processing capabilities. In response to such relational thinking and at least in part to user specifications/selections, PERCos can seek and/or provision from Big Resource particularly applicable purpose satisfying resource sets as purpose and/or purpose class specific user/computer purpose session user outcome fulfillment tools. Users rely on their inherent relational computing nature, the patterns people recognize through their foundation of experience, context, and memory. Computers employ a different class of operations: precise digital processes, processing arrangements, stored data, and any associated input/output. As applicable, PERCos capabilities, with or without direct user direction, can manage, filter, evaluate, organize, and/or provision computing arrangement resources into focused user purpose specific class applications, platforms, and/or other purpose fulfillment means that may operate on PERCos operating system and/or layer implementations, as well as on compatible computer applications which accept, for example, PERCos plug-ins and/or API code additions. Further, PERCos can employ Constructs associated with purpose expressions, such as Frameworks, Foundations, resonance specifications, and/or the like, the foregoing having been formulated and adapted at least in part to facilitate optimal adjustment of various resources synthesized to an optimally purpose compliant operating specification set balance. Such Constructs may specify “approximate” potential purpose associated PERCos session building blocks that contribute to the cohering of an optimally balanced purpose fulfillment operating specification set.

The foregoing may be complemented by any other information that in the used PERCos embodiment may be declared by Stakeholders and/or users.

PERCos, through its user/computer arrangement cross-Edge features and its various purpose support capabilities, helps resolve a primary current web resource usage challenge: user's inability to experience quality Outcomes to their underlying purposes, and in particular, users inability to identify quality and optimally productive user purpose fulfilling resource sets when such users lack a reasonable ability/knowledge base to frame their needs and characterize any associated requests. It is self-evident that such reasonable ability may be absent until developed and/or the user is otherwise supported. PERCos provides the innovative, supportive basis for such user framing, particularly in domains where users lack substantial command/experience/expertise. As a result, PERCos innovatively helps answer this current conundrum, the inability of users to reasonably frame requests for, and/or interact with, resources without sufficient relevant purpose domain related expertise. In such circumstances, users may lack necessary domain knowledge to effectively characterize their input and resource requests and they may be better served by a process approach where uses are presented with an approximate, purpose related resource neighborhood having resources that may be especially designed to support purpose knowledge enhancement and purpose related resource utilization and where such neighborhood resources may be identified, evaluated, filtered, prioritized, selected, and/or provisioned in a manner reflecting contextual purpose variable set matching and assessment processes. This challenge, the absence of user reasonable expertise (and which absence can include many variables such as information specifics, knowledge command over domain information, and user knowledge and command relating to the type, availability, and/or use of resources) is largely unresolved by currently available technologies that are unable to provide general systems for users' contextual realities and specific purpose orientation—these systems fail to systematize resource availability and provisioning based upon purpose considerations, and they further fail to both practically convey effective expertise support adapted to specific current user purpose(s) and to support the knowledge and opportunity development processes idiosyncratically specific to differing user purposes. In the face of the opportunities of Big Data and Big Resource, PERCos provides a broad based, practical, user ecumenical system for supporting user learning, discovery, resource provisioning, and resource use, including during session and/or cross session progressions that can leads to quality purpose fulfillment outcomes.

In most directed human activities, one or more explicit, articulable purposes underlie human actions and employment of resources. Satisfaction for participants in such activities normally results from either a perceived fulfillment of their initiating, underlying purposes, or the experiencing of sufficiently satisfying purpose related refinements, results, and/or associated experiences that evolve from such initiating purposes and processes. It seems evident that most individuals will experience or otherwise enjoy particularly satisfying computing session outcomes if their session specific computing resources are explicitly in alignment with their session computing activity purposes, and, in particular, if the “best of breed” applicable resources can be easily applied to fulfill the differing user purposes that occur at different times. Clearly, the capacity to identify and provision resources that are specifically aligned to one's current purpose, and, particularly the capacity to apply the most productive and applicable of such possible/available resources, would have great value since such purpose-aligned resources, and in particular, those consistent with user purpose related context, would be most likely to produce optimal outcomes and optimal user satisfaction.

But, as computer users and their computing arrangements are now inhabitants within a nearly boundless web of Internet and intranet resources (including other users and their computing arrangements), the challenges in identifying optimal, specifically purpose matching resources and resource sets is a great unmet dilemma that requires new technology approaches. Since the most powerful computing arrangement would be one that is most responsive/satisfying of a user's current purpose, it would seem that this might be a priority of current computing architecture. But, in fact, there are no general-purpose purpose fulfillment architectures. This is likely due to the vastness of type and location of web resources and the inherent complexity in determining the simplifying organizing purpose related conceptual dimensions that might be employed to replace a chaotic resource universe with a coherent and efficiently operating resource cosmos.

The complexity in identifying purpose fulfilling web based resources and resource combinations, given today's nearly boundless array of internet resource opportunities, types, locations, and qualities, is in part revealed by the clear absence of any formal system that enables consistent, straightforward, efficient, and reliable identification, categorization, evaluation, arrangement, provisioning, and support of user purpose resource sets. No current technologies enable the standardized specification and communication, relational approximation, identification, prioritization, cohering, and provisioning of specifically purpose aligned, purpose satisfying component resources. Further, no current system provides a sufficiently broad and unified view of both the nature of computing resources and the contextual perspectives necessary to optimally align resources to user intent.

Absent a well implemented general operating system, environment, layer and/or application means to associate resources with context specific, explicitly current, human purposes, identifying and applying web based resources to human purposes will remain fragmented, haphazard, and inefficient, that is often dysfunctional for many purposes. This is particularly applicable where a users' expertise in identifying, assessing, combining, and/or provisioning resources are any less than highly expert. This absence of a general, formal means for identifying “unknown to user” resource opportunities in a manner specifically responsive to, and optimized for, user current purposes, means the rich, deep, diverse possibilities of web based resources are obscured behind a veil of seemingly boundless, largely undifferentiated as regards to purpose, objects and services. At least for the foreseeable future, crowd behavior and semantic web, as well as fragmented topic based expert systems and related tools that try to deconstruct existing web information into useful indicators of user behavior and relevance will not have the adaptive particularity and comprehensive reach provided by the contextual purpose inventions provided by PERCos implementations and described herein. Further, search and retrieval technologies such as Google and Bing search environments and/or the like will perform consistently/adequately only in circumstances where users can sufficiently, and explicitly, describe the information, information resource, or such sufficient portion of key information resource characteristics that prove adequate to the material to be retrieved and satisfy such a limited purpose context. That is why these environments are often characterized as search and retrieval environments—the user normally needs to know enough to specify what to retrieve, or at minimum to give a sufficiently relevant search specification to result in a drop-down suggestion that the user is sufficiently informed so as to select. While information resource management systems such as knowledge graph, clustering, and domain specific expert systems can provide users with some useful capabilities and guide posts when pursuing knowledge and discovery activities. These systems tend to be relatively inefficient and impractical and insufficiently adaptable to specific user contexts and user objectives as regards users fulfilling their active purpose set.

As the developed and developing world increasingly participates in, and connects through, an electronic web having associated vast, seemingly boundless quantities of information, software, services, and human and group inhabitants, existing resource access, search, classification, identification, evaluation, and provisioning tools are unable to, in an integrated, efficient, and optimizing manner, support users and user group resource requirements. Users inherently want to use resources for the most satisfying Outcome, that is those resources that would “best” satisfy their current purpose(s). But current systems are not effectively responsive to individual and group current purpose needs since they lack any reasonable methods for user purpose specification enabling users to “outline” their objectives in a manner that efficiently leads to computing session specific resource sets, including supporting specific, specified purpose fulfillment “environments,” where such systems are responsive to user purposes, that is user specific, current needs and objectives.

In particular, there are no general purpose technologies providing reasonable methods to correspond user specifications of specific, current user purposes with possible resources, including performing quality to specific user purpose prioritization, and/or provision of optimal quality to purpose resource sets. Rather, existing technologies constitute a balkanized array of tools, such as characterization and retrieval search engines, recommender systems, clustering and knowledge representation (e.g. graphing) tools, classifiers, encyclopedias, expert systems, and other piece meal products and services.

People interface with the world around them through their senses. Such interfacing involves interacting with “resources,” including, for example, relating to other people, using tools to fulfill tasks, and experiencing the modification or enhancement of knowledge through observation, evaluation, and/or absorption of information. For most of the history of mankind, users interacted with resources that were in the immediate proximity of some or all of the participating individuals. Indeed, until recently, physical realities limited the volume and diversity of resources that could, or would, be physically present for any individual or group of individuals at any given point in time, and resource users normally needed to be either physically proximate to resources, or use human “agents” who were physically proximate to such resources. Given this historical physical proximity limitation regarding the practical use of most resources, information systems for organizing, identifying, evaluating, prioritizing, provisioning, and using resources have generally reflected such physical proximity limitation solutions, they were primarily systematized based on categorization of the direct attributes of each constituent member, and such members were placed in organizational hierarchies, such as class systems, that could “hold” such members in consistent and normally non redundant places, such as stacks in a library.

Historically, normally, a library member, for example, was physically positioned in only one place in the system, and the quality of a member resource to a given purpose, and differing arrays of purposes, was not codified. Users, and/or a librarian or like agent, would physically access desired such resources by retrieving them from a specific library storage location. Such general purpose systems for such large scale library information resource organization, such as Dewey Decimal Classification or Library of Congress Classification, inherently lack the capacity for efficient identification and deployment of members in variety of different places that might correspond to respective differing use purposes, and they further fail to supply “reschufflable” purpose related combinatorial resource arrangements (for example, effectively mashable) that can supply user specific purpose (and/or purpose supporting) and/or purpose class fulfilling environments. As a result, such classical classification systems share, for example, deficiencies with search and retrieval systems. For example, they generally require a level of knowledge/expertise regarding the nature of potential resources in order to reasonably efficiently support a user's quest for purpose specific best available, or even applicable, specific resources. And such systems do not provide specific purpose adapted combinations of different resources where such resources are responsible for complementary/different/differing contributing resource subsystems that support a given purpose fulfillment environment, and where such resource subsystems can, for example, contribute to at least in part standardized, published purpose Frameworks where such resources fulfill, for example, differing specified operative roles.

As with such library classification systems, current computing technology does little to assist users in efficiently identifying and provisioning resource sets that are aligned to a specific user purpose current at a given time. Generally resource providers have a somewhat similar challenge. They have no systematized capacity to identify and provision potential users where their resources might be particularly useful in contributing to specific user purpose Objectives. Such providers have no standardized, broadly interoperable arrangement by which to specify the appropriateness of their resources as tools that would contribute to optimal deployment and/or use of such resources for satisfying specific user computing session objectives.

Given substantial expertise relative to a current purpose, users may have the capacity to selectively identify, that is describe or point to, desired resources which they may then be able to retrieve and/or utilize. But regardless of whether any such user identified resources are functional for a given purpose, even with substantial expertise, users may indicate resources that are far less than optimal, given the massive resource diversity, including type, location, provider, timeliness of version, and explicit fit to specific purpose, that are now potentially available through web based computing. Further, for most objectives and topic areas, users have limited expertise—generally an individual's true mastery of most subject areas is quite limited, and often far more limited than they realize. In the absence of expertise, resource retrieval technologies and resources are still utilized in attempted satisfaction of user purposes related to such areas, and most people quickly learn to live with the readily available and may treat such resources as adequate or otherwise serviceable. It is normally not clear to individuals—in the absence of an understanding of available superior resources and PERCos new forms of (e.g. mashable) contributing component resource organization means—how profoundly many user purposes are under served by available computer tools. In fact such recognition would likely be, particularly for the average user, unproductive and unsettlingly frustrating since the journey to optimal resource identification and provisioning (when possible), can be too long and difficult a process using existing technologies.

Generally, in satisfying purposes through the use of resources materially involving learning and/or discovery processes, users need to be presented with appropriate resource environments and/or “evolving” differing resource set sequences versus “answers” or answer lists or knowledge graphs, such as available with search engines. Such learning and related environments enable user development of sufficiently meaningful representations of their specific desired purposes as they evolve their understanding towards a purpose fulfillment culmination or stopping point. Unfortunately, generally speaking, no architecture, no cosmos of technology and resource administration exists enabling the corresponding of computing resource sets and resource combinations to the often approximate nature of user usage purposes and their relevant contextual variables. Importantly, in pursuit of satisfaction of current purposes, users are frequently not seeking, or yet qualified to identify, specific purpose satisfying end results. How do users, for example, efficiently search, if they are not sufficiently knowledgeable to identify that which they wish to retrieve? Instead, users need resources that are appropriate and tailored to their user circumstances and purpose needs and this can be only be effectively, consistently achieved through a user purpose specifications process that is matched with one or more corresponding resource associated purpose specifications. Such a technology arrangement should support purposeful processes that unfold to results, either interim or final.

Given the nature of such unfolding user processes where users are developing and identifying purpose related results, users will often need to both declare and employ lossy approximating concepts such as specified by PERCos user purpose expressions, and employ PERCos and/or related application processes supporting a cross user/computing arrangement Edge where user experience reflects a progression of human relational thinking processes in response to an unfolding of resource supplied inputs that enable developing human knowledge/perspective. It should be noted that these processes normally, when users are in an at least in part learning mode, function most effectively when purpose class relational approximate information sets are employed, versus “precise” specific answers search engines, result lists, and/or, for example, knowledge graph and/or clustering groupings. While these tools might, under some circumstances, make a system seem responsive, they frequently provide the learning user with confusing, insufficiently informative, and/or damaging to user results. Generally, the foregoing results, particularly in many learning and discovery contexts, in less than optimal efficiency, costs, relationships with resources (including other possible participants), levels of complexity, and reduction in confusion; they provide far less than efficient time use and productivity outcomes, and can fail to provide optimally enjoyable networking environments and experiences.

With PERCos, resource supplied learning/discovery inputs—which in some embodiments can take the form of purpose neighborhoods for inspection/learning/evaluation processes by users—can be made available through identifying user purpose specific resource sets or at least in part purpose resource set application environments, that can, in cross “Edge” communication with users, present coherent purpose responsive results and/or purpose specific user interfaces and resource interaction supporting further purposeful steps that develop towards purpose fulfillment or closure.

PERCos systems are substantially purposeful, user and Stakeholder specification-driven environments. Applicable specifications, received from user and/or machine input, support the two primary groupings of PERCos platform activities, (1) identifying, evaluating, selecting, and/or provisioning of resource sets, and (2) use of resources in service of expressed user purpose(s). PERCos can employ its operating platform components in combination with purpose related local and/or remote PERCos compliant resources and user instructions in preparation for, and/or provisioning of, purpose fulfillment platform/resource combinations.

Stores of PERCos compliant resources are partially or entirely purpose specification arranged (and may, for example, be complemented by traditional category classification) with the organizational objective of best satisfying user purpose(s) given possible and/or practical available resources. Users relate to resource information through their tendering and/or provisioning. PERCos resource information management is specifically adapted through the use of standardized and interoperable purpose expression capabilities, and in some embodiments, purpose class and/or other ontological and/or taxonomic capabilities, to provide specification tools to organize and identify purpose related resources that are specially adapted and/or useful for specific purpose fulfillment objectives. Resources may be assessed through such purpose related specifications, and, for example, through the use of coherence processes, and PERCos may process any resource set, at least in part in response to at least a portion of such purpose specifications, for example, PERCos resolves collective applicable specifications in a manner optimally consistent with user and/or published Stakeholder purpose specifications, including identifying and resolving coherence managed conflicts and/or deficiencies among resources and/or between, for example, user and Stakeholder specifications, and any other applicable specifications, so as to produce a co-adapted and consonant resource set.

As referenced earlier, PERCos employs Contextual Purpose Expressions as specifications declared by users to, at least in part, represent their purpose(s) for a given computing activity set. Contextual Purpose Expressions are also employed by Stakeholders as purpose specifications associated with resources and resource and purpose classification groupings. CPEs normally describe human purpose concepts in the form of lossy, relationally approximate, notional representations. Such representations are operatively used to identify resources that relatively align with user purpose fulfillment objectives, either generally/comprehensively and/or in the form of a component that can contribute to a given purpose fulfillment process. PERCos uses CPEs both to represent user and Stakeholder purpose related conditions/objectives, but also to characterize one or more purpose classes instances that are associated with such purpose specifications, so as to operatively organize and optimize resource identification efficiency, particularly when dealing with vast data stores, such as Big Data or more encompassing Big Resource. In such circumstances, purpose classes may contain resource sets as members whose membership, in certain embodiments hereunder, are declared by Stakeholders, with such membership being associated with any such resource and therefor such resource being associated with the one or more of the purpose classes associated Contextual Purpose Expressions. In these circumstances, any given purpose class can constitute a purpose “neighborhood” populated by such Stakeholder declared members (and/or by members specified as such as a result of historical usage associations and/or class attribute inheritance and/or other algorithm calculations). The declaration of resource sets as members of one or more purpose classes can support a two or more step process involving the generalization of bringing users to one or more purpose neighborhoods comprised of resource members, where such member resources, for example, can be further ranked, examined, filtered, selected from, organized into groups, and the like. This can profoundly simplify managing Big Data or Big Resource usage by inspecting, for example, an index for purpose expressions for, for example, tens of thousands of purpose classes to derive appropriate one or more approximation neighborhoods, and then, for example, if desired further processing neighborhood member associated purpose related specification information. This provides an alternative to examining, for example, an index for all resources, which might comprise billions, and ultimately trillions or more of resource items and their corresponding huge one or more indexes and/or other information manager tools. For example, in certain embodiments, PERCos user prescriptive purpose specifications can be similarity matched either directly against information store arrangements for published purpose expressions (with or without other purpose related information) associated with resources sets, or can be similarity matched against purpose class CPEs (with or without further examination or other use of purpose class metadata). More detailed filtering may take place in evaluating purpose class members by using, for example, resource metadata, PERCos value to purpose Repute system input (including Cred quality assertions, Effective Facts (EF), and Faith Facts (FF)), and/or associated user purpose expression secondary information (information specified or acquired at least in part for such further member based filtering).

PERCos combining of inherently lossy “approximate” purpose specifications prepared by both users and resource Stakeholders (e.g. providers, creators, Cred asserters, and/or other Stakeholders) can enable users to enter into learning, discovery, and/or experiencing processes that correspond to their inherently generalized purposes and at least in part support user passage through such learning, discovery, and/or experiencing processes to session or other process sequence culmination or termination. As discussed, PERCos means can also support users using, in combination with their Contextual Purpose Expressions, similarly approximate and lossy purpose cosmos organizing purpose classes, enabling vast and massively diverse resource sets to function as practical purpose resource stores that are optimized for user purpose fulfillment related user evaluation, interaction, and/or provisioning. Elements from such resource stores can be practically matched and filtered and/or otherwise selected or filtered for their purpose fulfillment qualities. The efficiency and effectiveness of such purpose similarity matching processes can be potentiated in quality of Outcome through the use of Quality to Purpose Cred Repute processes that may further evaluate, prioritize, and/or provision resources, including performing such processes on resources specified as members of one or more appropriate purpose classes. Further, such resource stores can provide resources as building blocks for resource environments and other purpose frameworks, including purpose class applications, the foregoing in support of unfolding user purpose development and/or fulfillment processes.

PERCos provides a purpose expression architecture that operatively interacts with PERCos purpose related resource organization and resource provisioning (e.g. Coherence and PERCos Constructs). Such PERCos purpose specifications involve standardized and/or otherwise interpretable descriptions of user objectives and related, particularly relevant conditions that provide information informing PERCos processes of user purpose, for example: focus, context, and quality to purpose facets, the foregoing for calculating and/or otherwise identifying degree of match, and value of, resource sets to user purposes. In particular, PERCos purpose specification can employ combinations of one or more verbs and one or more categories and/or subcategories that together represent user Core Purposes that approximately correspond to the central focus set for user activity. Such one or more Core Purposes may be combined with particularly relevant user standardized or otherwise inter-operatively interpretable contextual variables such as: available PERCos Master Dimensions including specific budget(s); available time duration and/or specific time; user expertise relative to Core Purpose focus; desired complexity and/or “length” of resource material sets and/or portions thereof; complexity and/or arrangement of interfaces; quality of experience variables; and any one or more characteristics regarding any expert and/or crowd and/or historical resource set(s), including any Repute assertions and/or derived values relevant to such resources and/or resource classes and/or the like. The foregoing may further take into account the association of PERCos processes and results with “external” cross-Edge computing arrangements for input, control, and/or other management purposes internally for PERCos and/or externally for any applicable portion of such external computing arrangement; and the like.

PERCos processes resource use results in session consequences that are responsive, at least in part, to user purpose specifications, including purpose related user experiences and/or other results, such as, for example, information acquisition, modification, and/or storage; social networking interactions; user entertainment activities; and/or purpose related communications regarding computing and/or other device arrangement performing tasks and/or producing results, such as results from PERCos cross-Edge purpose influenced manufacturing process control, process and real world (e.g. traffic) flow management, scheduling, and the like. An inherent aspect of PERCos resource usage are sets of unfolding interactive processes driven in part by user input responsive to cross-Edge computer to user communicated information and ensuing user interface functions.

Some embodiments of PERCos systems incorporate purpose class applications and other Framework Constructs that assist users in progressively expressing and/or satisfying purpose related user understanding as it evolves during and/or across one or more sessions. This includes user purpose related understanding improvement, refinement, and/or alteration resulting from changes in user knowledge during the course of one or more such PERCos purposeful sessions. PERCos can enhance this knowledge/perception progression by providing user purpose-supporting results development environments that enable capabilities not found in traditional “search engines,” “information retrieval” tools, and/or “knowledge management” systems. Such traditional tools do not support the specifically evaluative and purpose-directed aspects of PERCos standardized contextual purpose expression environments. For example, PERCos users can employ such domain specific purpose related environments for Big Resource identification, evaluation, prioritization, management and utilization and/or purpose results development. These environments can both optimally relate to PERCos Big Resource organization and further provide specialized user/computer purpose related tools for navigation, knowledge enhancement, and exploration.

The nature of identifying productive resource tools for characterizing purpose satisfaction, and often the quality of user use of such tools, normally differs in correspondence to a user's relative command over the pertinent subject matter. This differing usefulness of tools, and manner of tool use, is due to a user's relative purpose class and/or category expertise level as well as the nature of the specific user purpose at a given point-in-time. PERCos levels described below generally correspond to decreasing user specific subject knowledge and/or clarity of purpose and/or decreasing comprehension regarding relevant candidate and/or actual tool usage considerations.

PERCos can play a key role in enhancing purpose level 1 activities, for example, providing a resource set that enhances user understanding/sophistication related to a purpose set, and therefore revealing to a user the value in reframing purpose level 1 expressions to realize the enhanced value of a more knowledgeable/sophisticated perspective. But PERCos is particularly focused on purpose level 2 and/or 3, as well as any associated level 4 and/or 5 activities. In such cases, purpose is primarily about the identification, evaluation, prioritization, acquisition and/or provisioning of one or more resource sets best in alignment with users initiating, interim, and/or Outcome purposes. Generally speaking, PERCos isn't in most embodiments primarily about providing an “answer” to a retrieval request, such as search and retrieval products do. Rather, for example, PERCos is about resource related processes that provide a user set with best “fitting” resources and/or resource capabilities/portions for realizing a desired Outcome. For example, the use of PERCos identified resources provides an environment, information, and/or the like that “answers,” and/or provides process support leading to answers, to user questions versus. In such an instance, PERCos is not providing a specific answer, but rather the tools that a user employ to realize objectives, such as answers.

In some embodiments, PERCos is an architecture for identifying, managing, and/or enhancing the benefits resulting from, purpose fulfilling resources. For example, PERCos may identify a resource set that may best serve user purpose, and further PERCos and/or a PERCos plug-in and/or API may provision capabilities within such a resource set that may provide a responsive environment tailored to developing and/or achieving a class of purpose of user desired Outcomes, and where, for example, the use of such resource application and/or other resource set of capabilities may provide an “answer” desired by a user set, in contrast to PERCos itself providing such an answer.

PERCos provides means to organize Big Resource, including Big Data, and provides further means to identify, evaluate, prioritize, provision, and/or use user desirable purpose fulfilling resource sets and/or capabilities

Defining this new partnership between humans and their computing arrangements, the marriage of the differing context, circumstances and capabilities of differing people and computing resources, requires a new architecture for human-computer interaction that supports eliciting, interpreting, specifying, and/or otherwise identifying and/or initiating human purpose-satisfying Outcomes. Even for the less demanding simpler end of the usage spectrum where the user is better informed regarding the domain of their purposeful activities, this new broad architecture approach can provide significant benefits to many users.

With some embodiments, each of these categories and/or any category combination and/or overlap and/or any purpose class and/or domain and/or class subset arrangement, including any associated member, may be supported by one or more special purpose “interface modes” that optimize and simplify user interactions for one or more purpose classes and/or CPE types. Such interface modes may suggest and/or implement maximization of resonance to improve effectiveness for purpose, and where such interface modes may optimize resonance through algorithmic strategies employed by Coherence processes, local to the user, in the network, and/or at cloud service locations, the foregoing in preparation for operating Purpose Statements, in similarity matching, in further filtering or evaluation and/or prioritization and/or other PERCos resource organization and/or user interface activities. The foregoing can be employed, for example, as users' purpose activities and PERCos processes unfold and evolve during and/or across sessions. Such interface modes may further employ intelligent user assistance by incorporating expert system tools, such as faceting engines, semantic information databases, and/or expert database capabilities, as well as, for example, other user selection and information visualization features.

Some embodiments may explicitly provide one or more purpose navigation interfaces and/or functionally similar means to minimize the effort for a user to visualize, understand, and/or reveal purpose relevant and/or otherwise interesting and/or useful aspects of, and/or otherwise control representations of, at least one or more portions of one or more major purpose-related Dimensions (or any portions thereof) and/or purpose related metadata. This includes user response in evaluation of and/or selection of resources and/or relevant identification and/or evaluation variables, including resource relationships and/or combinations, where the foregoing may be used to support the managing of resources for purpose satisfaction including, for example, user knowledge development. For example, and without limitation, a purpose navigation may provide means to examine, control, and/or modify the “expression” and/or organization of a current interface mode, Master Dimensions, Facet, other Dimension information, purpose expressions, resource conditions/parameters, including, for example, conditions related to resource provisioning and/or use, user characteristics and preferences and/or other important contextual elements and/or sets not included or specified in a Dimension, and/or any portions and/or combinations of any of the foregoing.

PERCos, in some embodiments, treats all processable, published elements as resources in an unbiased, specification managed manner. This includes purpose fulfillment contributing elements that are represented by specifications with which PERCos may directly or indirectly interface and provide control contributing input. PERCos embodiments can provide specialized purpose fulfillment resource organization schemas employing, for example, purpose and resource class organizations with resources as class members, as well as in the form of related purpose Ontology groupings, such as at least in part relational ontologies having resources associated with ontological positions, and purpose indexes that include, at least in part, purpose Dimension variables for efficient and easy parsing/filtering of vast resources stores into purpose responsive resource candidate sets.

In many embodiments, a key to PERCos performance is its unique organization/management of resource stores and its further, associated tools for interrogating such store arrangements, for example, PERCos tools that enable interrogation of Big Resource for similarity matching to user Contextual Purpose Expressions. In certain embodiments, resource publishers and/or creators and/or other Stakeholders declare descriptive CPEs and may further associate one or more other purpose related specifications, wherein such Stakeholder declared specifications may be descriptive of resource usage purpose information, including, for example, in the form of Core Purposes and purpose germane contextual information. Such Stakeholders may further declare any such resources as members of one or more purpose related classes, where such purpose classes and/or purpose class structures may have been declared by Domain experts for structuring purpose class resource neighborhoods to support relational approximation association with user purpose expressions associated with such classes. Authorities, including experts and/or utilities and/or standards bodies, associations, and/or the like, may declare such purpose class arrangements for their respective one or more associated Domains to enable resource management and administration of resources. Such declarations may include associated CPEs and/or other purpose expression specifications declaring purpose associations for such purpose classes and, as a result, for their declared resources that function as their class members. Such purpose class arrangements, when for example declared/specified by one or more Domain experts, for example, functioning as an effective domain class committee, may identify purpose classes that, in their judgment, correspond to conceptual neighborhoods so as to allow purpose supporting resources to be organized according to their pertinence to fulfilling user purpose concepts. This may prove useful where a user CPE is sufficiently similar to a purpose class CPE, or some subset thereof. In some embodiments, resources may be declared as members of a plurality of such classes, which may be associated with any logical taxonomic and/or ontological arrangements.

Certain, or any, third party Stakeholders may, in some embodiments, also declare CPEs or other purpose metadata specifications as associated with, or function as members in, any one or more resource sets, purpose classes, and/or resource portions/capabilities to enhance resource and/or purpose class member user purpose matching, including filtering, identification, evaluation, prioritization, provisioning, and/or use. This declaration of, for example, resource CPEs and purpose classes, by resource creators, providers, and/or other Stakeholders, provides, along with other PERCos capabilities, highly efficient scaffolding for bringing users, based on their purpose expressions and any associated input, into an appropriate resource “neighborhood,” and provide a basis for users to proceed with fulfilling, in particular purpose level 2 and level 3 objectives, and which may further involve level 1, 4, and/or 5 objectives.

Many users prefer to deal with standardized and/or familiar interfaces and conceptual models, and don't want to learn a new interface or new model for each new purposeful interaction. Most users prefer simplicity over complexity and it's an important priority of PERCos to enable easy, efficient purpose expressions means. The vast range and variety of nuances of possible purposes and experiences can, in the absence of consistency, standardization, and expression bounding (filtering), exceed the complexity that most users are comfortable dealing with most of the time. One standardizing and conceptually simplifying PERCos technology set is organizing contextual variable expression, and associated values, in simplified Dimensions and, where applicable, sub-Dimensions. Dimensions represent conceptually logical groupings of differing contextual perspectives and each Master Dimension has a limited number of standardized, easily interoperable and interpretable Facets. Dimensions in certain embodiments comprise a small set of conceptual familiar to user groupings, enabling users to easily “relate” to user purpose enhancing key Dimension characteristics. In one embodiment, PERCos supports five primary Dimensions, including Core Purposes, for example, and user, resource, Repute (assertions, et al.) and symbols.

Dimensions beyond Core Purpose may be used to great effect, for example, in Contextual Purpose Expressions as further specification of user purpose(s) beyond that initially specified by one or more Core Purposes. Dimensions have a wide and flexible applicability, and can help reduce user expression and navigation complexities by providing logical grouping values for similarity/matching, prioritization, and navigation and normally providing approximate contextual summary attributes that contribute to PERCos relational computing and help users relate and translate user classes and concepts to computing declared classes. These features are widely applicable and can serve both to orient users within a PERCos Cosmos and to assist them in retrieval, learning and edification, and navigation and exploration.

A Dimension is a PERCos expression structure representing an organizational subset of purpose expression contextual specification and approximation. In some embodiments, Dimensions may have standardized, interoperable expression Facets (such as Master Dimensions) for efficiency, understandability, interpretability, and/or inter-operational consistency. Such Facet set and selectable options may be limited to a set that has been pre-defined for the embodiment by a Utility and/or other standards body set, and might in some embodiments be augmented, for example, by any that have been declared and published by experts or others independent of the standards body set, such as parties associated with an affinity group, such as a professional association.

In some embodiments, additional Dimensions, either Domain-specific or cross-Domain, may be declared by Domain set specific acknowledged experts, standards setting one or more bodies, and/or by Participants for their own use. However, unstandardized personal Dimensions may not be interoperable and those declared by a group may only interoperate within that group.

A declared context is a set of resource and/or system selected Dimensions Facets, any associated Values, and any other, such as auxiliary Dimension information, specified as a component set for purpose expression, and constraining purpose Outcomes to reflect user objectives that in some embodiments complement Core Purpose Expressions and/or other broader CPEs, and may be employed as locally stored and/or as published building block components available for user and/or Stakeholder use.

In some embodiments, a relatively small number of Dimensions representing basic general forms of PERCos specification groupings will be distinguished as Master Dimensions, which are logical major groupings of characteristics that may significantly influence, for example, user resource identification, similarity assessment, prioritization and/or other organization, navigation, filtering, provisioning, and evaluation. These basic PERCos specification types can function as key simplification concepts for user purpose expression understanding and organization, facilitating user and Stakeholder input and comprising basic high level computer types of PERCos specification user and Stakeholder input. In some embodiments, PERCos enabled interfaces will provide easy access to, and control of, Master Dimensions as general specification and resource navigational tools. Master Dimensions, as a simplification organization of contextual attribute types, functions as a means for assisting user understanding and expression of contextual priorities and may help enable Coherence and/or other PERCos process sets to efficiently manage and functionalize the combination of various contextual dimensional input to be employed in similarity matching, purpose class assessment, resource provisioning, and the like. Given the standardization and interoperable features of such Dimension specifications, and in some circumstances, information derived at least in part from such specifications, Dimension information or such related information can be employed efficiently in approximation similarity matching to purpose class and/or other resource purpose specifications to simplify processes and constrain large resource sets. Some PERCos embodiments provide interfaces that provide easy access to, and control of, the balance among such Dimensions and their Facets and any values, as general navigational tools.

PERCos employs quality to purpose assertions of experts in the form of Repute elements employing standardized and structured assertion one or more facets, which may have associated values, and/or other standardized evaluation representations. Such evaluation representations represent the quality of a given resource, resource set, and/or resource class to satisfying a purpose, or contributing, along with other one or more resources to, a purpose, purpose class, resource, certain other PERCos Constructs, and/or one to or more associated resource quality of usefulness and/or reliability parameters. The foregoing may be standardized for interoperability, ease of use, and/or to represent an approximate class for a resource characteristic grouping employed as a filtering and/or evaluation vector.

Additionally, PERCos purpose fulfillment can employ other PERCos Constructs such as, for example, purpose class applications, purpose Frameworks, purpose user Foundations, resonances, purpose plug-ins, and the like, all the foregoing providing building blocks for creating purpose fulfillment environments and supporting complementary, efficient evaluation, management, and/or provisioning of resources in satisfaction of specific user purpose expressions specification one or more sets. Such PERCos Constructs, where applicable, are used in conjunction with direct user interface input, purpose/resource matching and similarity, and Coherence construction and management of operating Purpose Statement specifications, for resolving optimized resource identification, prioritization, provisioning, testing, and session monitoring and management.

A PERCos unified architecture of purpose specification and purpose responsive resource Constructs helps ensure, in a broad variety of cases, that human purposeful computing activities are optimally realized, both in quality and efficiency of outcome and subject to relevant contextual considerations. Such a unified cosmos of purpose specifications, declared by users and published by Stakeholders associated with resources, coupled with associated Reputes, Creds, FF, and EF filtering input, Constructs, and Coherence monitoring, analysis, and resolution and other PERCos local, cloud and network services, optimizes the identification, evaluation, and provisioning of resource sets to enhance user purpose fulfillment when user purpose focus extends beyond areas of user expertise and ability to reliably identify optimal resource sets.

The PERCos combination of purpose related specifications and Constructs, purpose and other class information stores, Coherence Services and other PERCos services, both local, network, and distributed, allows the full breadth of possible contributing resources to be integrated as a single environment supporting a purpose, experience, resource, Context operating system and/or services environment. This described matrix of complementary technology domains rationalizes the nearly boundless resources of the web into a practical, accessible, and responsive operating context and supports best general overall performance. In sum, the PERCos technology domains, through their complementary performance, enable identification and alignment of potentially best for purpose resources from diverse, vast distributed resources arrangements. This cooperative coordination of differing specifications, technology operations, and process steps supports alignment of resources opportunities that are optimally focused on supporting purpose fulfillment processes with the best possible resources sets consistent with user context and purpose(s).

PERCos implementations may employ PERCos Coherence mechanisms to resolve incomplete and aggregated purpose related specifications and associated stored information into practical purpose optimized operating Purpose Statements. Coherence Services with some embodiments can manage the provisioning of operating specification process instructions through the interpretation, integration, completion, and/or conflict resolution of purpose processing input. Coherence processes may take place at any one or combination of local, network, and/or cloud service locations, that may respectively contribute to resource evaluation, proffering, and/or provisioning, including pre resource combinatorial and/or contextual testing, and session processes including PERCos session process monitoring, testing, and/or collecting/storing session states, information, and/or process flows, the foregoing being at least in part performed based on session related rules and/or control algorithms (such as included in CPEs, Purpose Statements, profile information, resonances, Foundations, Frameworks, class applications, purpose class and other purpose Plug-ins, and the like).

PERCos in some embodiments, including, for example, in some PERCos PSNS embodiments, may support, for example, Participant, including Stakeholder simplification types, for testable and/or reliably certified Participant characteristics specification in user CPEs, where such types may be used in standardized and interoperable manner for contributing to the filtering of candidate resources. Such processes may, for example, provide a limiting, specific characteristic set for matching with Repute Creds, EF effective facts, and/or FF faith facts for finding corresponding appropriate asserters (and/or Cred role performers) having the appropriate characteristics so as to help ensure optimum expert input in managing large resource sets into prioritized, constrained sets. Such characterization simplifications, as applied for similarity matching to Repute publisher, creator, and/or provider characteristics, can help constrain, for example, the set of all Creds expressing Quality to Purpose value sets regarding a resource set (or a portion set thereof) to one or more expert types who have appropriate relevant, for example, reputations and/or credentials, as demonstrated by Creds and EFs on them. This enables a user to employ for assertions and/or factual claims regarding a resource set, a filtering process on the characteristics of, for example, Cred asserters, that is parties with points-of-view, and only, for example, those asserters satisfying such user required characteristics who have made assertions regarding a best resource for a purpose or on a specific resource's quality might then be used as input towards identifying, evaluating, prioritizing, selecting, and/or provision a resource set.

Cred, EF, and FF characteristics may be in some embodiments associated with one or more of Reputes Creds, EFs, or FF publisher, provider, editor, and/or creator, and or the like. These characteristics are descriptive attributes, and may in some embodiments comprise, for example, an adaptable constrained available subset of such characteristics, where such available choices for user specification are limited to subset characteristic types that are logically related, for example, of some particular value, to a given user Contextual Purpose Expression and/or associated purpose class. In order to identify Creds and EFs created, published, and/or provided by parties having sufficient desired qualities (and/or in some cases not having one or more certain specified qualities), user sets may select from a list of such categories proffered, for example, in response to user specified Core Purpose or the like, and where after a user set selects any one or more categories, such user set may then review, for example, with a faceting interface, a list of options associated with each respective category, for example, where such options that are available were selected by, or otherwise identified through processing that produces a constrained list. Such a constrained list may have been provided as a result of some expert set and/or administering authority determining an optimum or logical set providing desirable user selectable characteristics. Such expert, consulting, authority or the like set might publish their lists, at least a portion thereof being associated with a specific current purpose expression, or may be a member of or otherwise associated with in a purpose class, resource class, Domain category class and/or any other relevant taxonomically and/or ontologically related grouping. For example, a choice set in response to a user Core Purpose “‘Learn’ ‘earthquake risk’” an expert set might provide as a recommended faceting option for selecting experts with graduate degrees, experts who've published peer-review articles in the area of the Core Purpose, and experts with professorship positions in earth sciences or geology or the like from us national universities, or from “top” 10 universities, and/or from top 100 global universities and research institutes in the earth sciences domain, and/or from government scientists, and the like

It may be significant in some embodiments in support of crowd and/or specified group discussions and user set learning, discovery, and experience processes, that not only resource items have unique identification, as resources have as a consequence of their publishing and registration processes and/or as are elsewise interpretable in a reliable manner by PERCos related processes and/or parties, and that subjects of such resources that are other resource instances have by extension (and therefore may have directly associated with them associated unique identity sets), but that non resource abstract concepts also have explicit identifications, where they allow declared classes, members, and/or other subject instances to be individually organized and identified in ontologies and taxonomies. Such at least in part abstract subject matters may, in some embodiments, be at least in part published as resource instances and/or instance sets by general and/or Domain Experts and/or authorities so as to provide one or more taxonomy and/or ontology arrangements, such as groupings, for subject and/or subject approximation class/neighborhood consistency, the foregoing being employed and providing for, at least in part, subject associated identity services. Such pre-setting of subject, for example, popular, timely, and/or important such subject approximations, may facilitate, in some embodiments, user ease of use and might employ, for example, faceting interfaces or the like in a manner as discussed elsewhere herein for selection of approximation/neighborhood included items such as class member instances.

Further or instead, such PERCos expert, utility and/or other standards setting set arrangement(s), may, in some PERCos embodiments, support Domain specific and/or universal, that is PERCos cosmos wide, naming and identification structures that support both resources types, that is explicitly published items, and abstractions, such as concepts, labels, and/or the like. At least in part abstractions/generalizations naming and identification structures, such as one or more taxonomies and/or ontologies, can provide an at least in part, prepared scaffolding for the issuance of specific subject IDs, such as upon request of a user or Stakeholder, or as may be automatically requested by a PERCos service as a result of some evaluation and/or aggregating process. An integrated PERCos universal and/or Domain set taxonomy and ontology arrangement can provide the means for the automated issuance of unique IDs, for example, (a) in response to parsing of such subject abstract concept specifications, by identifying Core Purposes and/or Domain categories and/or associated declared classes and/or the like and placing a user or Stakeholder and/or other party submitted subject concept description into one or more appropriate taxonomical nodes and/or ontological “positions” along with issuing a specific or approximation/generalization corresponding group, such as a resource class, identity, and/or (b) employ at least in part a standards body (association, corporations, other organization, and/or other like group) agent arrangement for human agent inspection and at least in part determination, with the aid of such ontological and/or taxonomical tools, of appropriate classification positioning and associated unique or group identity set, for example, and/or the like. For example, classification may, in some embodiments, in addition or alternatively assign a concept representative identity to a submitted concept, whereby an identity represents a plurality of differing but closely related concepts in a concept approximation structure established, for example, in some embodiments, to support consistent and/or aggregated and/or co-provisioning of such approximations while, for example, allowing certain flexibility in specifications for practical user approximation and resource management purposes.

In some PERCos embodiments, subject concept specification may employ (for example, in resource information arrangements and in CPE specification arrangements) certain PERCos Master Dimension interface technology types, such as standardized logical grouping specification Facets, which may employ verb, category, adjective, adverb, preposition and/or the like where specifications options may constrain to logically appropriate and/or likely choice sets as a user or Stakeholder specification process unfolds, for example, when progressively selecting a category, a subcategory, an adjective, a verb, and/or the like in any logical order.

Concepts representing abstract, generalizing notions that approximately frame a Domain area can also be published individually or in some logical grouping as resources, wherein the subject of the resource is an abstract, generalized subject, e.g. Wild Salmon, Ceramic-on-Ceramic hip prostheses, Global Warming, Wahhabi Islam, Greek Orthodox Church, and/or the like. Such resources could then include or otherwise have associated purpose expressions that may correspond to prescriptive CPEs of users. This would enable users to identify, in a purpose oriented, contextual manner, standardized subject matters and if stored with the subject matters, their identities, including such abstract concepts. For example, in some embodiments, if a user wanted to locate resources for asserting on, or reviewing Creds on, global warming, they could create a CPE “‘Assertion’ ‘Global Warming’” and through processes discussed herein, identify purpose class and/or domain category set (e.g. a domain category called “Global Warming” whose member resources (and/or resource portions) could be prioritized by similarity matching and which, at least materially in part had members that may correspond to user purpose expressions and which are identified through inspection of such resources information sets. This could be, for example, be followed by a second step PERCos process of examining such members, for example, review Creds by Ph.D. scientists in Environmental Sciences (and/or the like) regarding Global Warming which express in the aggregate, for example, a Reliability Facet Values of above 7 on a scale of 1 to 10 (or, for example, a 3 on a scale of −10 to +20). In some instances the Cred resource might include other information associated with included subject matter instance or instances or groups and/or Facet assertion values, where such other information complements the information set in the subject of such member resource set. Such complementing information may include for example, in some embodiments, numbers of reported use of a resource instance, or the resource's subject matter or group, Creds on a subject matter or group (such as which subject matter instance might be recommended using various Cred (and/or EF and/or FF) techniques discussed herein as the most useful to user purpose, that is most popular and/or most used by participants with certain characteristics, and/or the like. Further information might be provided or referenced by such resource where such information is a complementary information set, such as, for example, an information set from another party that complements and/or supports at least a portion of the assertion set of a Cred or in some manner supports and/or complements and/or provides counterpoint information (e.g. as provided by aggregate Cred sets) contrary to resource subject matter.

Cred subject matters may be uniquely identified through user and/or Stakeholder explicit referencing of one or more, for example, recognized, at least in part, topic matter directories, databases, reference materials, and/or the like subject matter provided by one or more authorities, such as web services. Such, authorities, such as Wikipedia, have unique identities, e.g. web page addresses to specific topics, which can be automatically interpreted or extracted through the use of a PERCos compatible interface. But while there are some ontology services that can provide an identity at least in some domains, today there is no service that assists, that is assigns and administers a member cosmos of unique identities to user subject instances, so as to support such resources, and their subject identities, in a global, systematic, intraoperative resource cosmos. Such service could, for example, also provide various characteristic descriptors associated with a taxonomic and/or ontological group to which such subject is assigned, such as leading purpose expression classes, CPEs and/or other purpose expressions, Creds and/or information derived from them and/or the like, and/or other items with relationships to such group and/or group member sets.

Some PERCos embodiments may provide identifier standards of expression to enable such interoperability interfacing. In some embodiments, such advantageous capabilities support Cred assertions regarding topics that are, at least to some degree abstract, (e.g. Wild Salmon, Fast Cars, Stone Wool Insulation, Portable Music Player) versus a subject that represents an explicit real-word resource having an operatively unique identity, and for example, associated unique name (e.g. Hilary Clinton, Republican Party, Ford, Safeway, Sony Corporation, Oxford Shorter Dictionary, Merriam-Webster's Unabridged Dictionary for iOS 3.29). Such standardization can be provided by one or more PERCos environment resource Domain or general coverage subject descriptor utility, standards body, and/or other provider set, such as a for profit corporation cloud service. The foregoing can enable consistent description of non-resource subject matters by assigning explicit identities to, for example, topical abstractions in a form interpretable, and in some embodiments, provided by, a root standardization authority/standards body for a PERCos embodiment, by Domain specific such bodies, and/or for other environments. This standardization and web based services (and/or local or network based information stores) can support subject matter disambiguation by offering specific subject matter instance suggestions, and their associated unambiguous identity (e.g. an explicit alpha and/or numeric code) in response to an apparently ambiguous subject matter specification, for example, by employing semantic analysis and/or look-ups to suggested synonyms, alternatives, and/or the like, and/or by support user interface expert interfaces, such as faceting interfaces, providing users with logical choices to select from for disambiguation, which may then be followed by assignment to an existing identity or the issuance of a new, operatively unique identity.

Abstract Creds, in some embodiments, can employ an abstract Cred Master Dimension, for specifying simplification and approximation and Cred information management purposes. For example, an abstract Cred can be associated with a purpose expression where a Quality to Purpose may be expressed regarding the value of an abstraction in serving user purpose fulfillment. For example, an Abstract Cred may have a subject “Wild Salmon,” or “Wild Alaskan Sockeye Salmon.” A Cred publisher can specify for a Cred an abstract purpose “Good Health” or “Good for Living Healthy” or the like. The Cred publisher can in some embodiments, for example, associate such a purpose expression with one of the described salmon subjects and provide a value 8 out of 10 on a Quality to Purpose (e.g. Good for Living Healthy) on scale of 1 to 10. In certain embodiments, abstract (and/or other) Creds may employ a Core Focus set as an alternative to, or in combination with, a Core Purpose set, so, for example, a Core Focus might be expressed as “Good Health” where in any embodiments this is considered sufficient and where a purpose verb or the functional equivalent, for example, may be logically assumed, where, for example, the Core Focus may be comprised of an adjective and noun pairing. User interface modes described herein for faceting for Core Purpose and Facet specification and where logical, constrained set options are provided through user interface selection may be used in a corresponding manner with Core Focus arrangements, such as offering logical adjective choice list for initially selected category as may have been determined by experts with a standards organization, such as associating “good” or “bad” or “delicate” adjectives with “health”, but not offering “red” or “loud” or “tasty” as adjectives with “health.”

With PERCos technology, user and Stakeholder computer interaction can involve, for example, in some embodiments, users and Stakeholders at least in part providing standardized purpose characterizing input in combination with one or more of: associated sets of other purpose relevant Specifications; purpose related specification Coherence resolution, including, for example, some set of specification inspection, identification, evaluation, conflict resolution, completion, multi-resource amalgamation assessment (for example, including user purpose related provisioning assessment), and/or the like; provisioning of resources for PERCos session set at least in part associated with such processes and specifications; associated initiating and unfolding of user experiences and/or other Outcomes, including, for example, support for at least in part recursive or otherwise unfolding user evolving processes leading to purpose Outcomes and/or interim results.

The foregoing can contribute, for example, to a user/computing arrangement purpose fulfillment operations set with purpose results generated using purposefully selected and/or assembled resources. This may involve in some embodiments, PERCos users and/or computing arrangement sets using resources that have not been published as a PERCos resource, but which may be provisioned by PERCos to satisfy specific purpose related specification(s), such as using a well-known word processor in a certain manner, for example, performing word processing functions as a component within a PERCos Framework. In some embodiments, such a resource instance, for example, Microsoft Word, might not have been published as PERCos resource, but, for example, one or more Stakeholders, an authority, expert, user, Repute publisher, and/or the like set may have declared that Microsoft Word is an acceptable resource, desirable to use in fulfilling word processing Roles. For example, Word may be provisioned within a Framework identified by a user and/or PERCos computing arrangement set as a Framework of choice and having a component function (which may include interface interactions and locations) Role for word processing that may contribute to certain purpose Fulfillment related activities. In such instance, for example, Repute, and/or other services may declare a traditionally published resource as a PERCos informal resource (or such may be inferred as a result of such a Repute assertion set, For example, a recognized expert or expert group may identify and publish an “informal” resource having a CPE set associated with a subject set comprising at least in part Microsoft Word, and which is associated with sufficiently reliable resource subject identity information, and where such expert Stakeholder can be specified as the “informal” publisher/creator of such a new PERCos informal resource, which resource may, for example, have associated with it (e.g. provided by such recognized expert set and/or organization) such other information as creator, original publisher, and/or provider resource (e.g. word processor related) information, including names, rights and/or one or more sets specifying other information regarding such resource, as may be necessary for use of such word processor.

PERCos embodiments are particularly adapted to support user identification, evaluation, and provisioning of web and intranet located resources where PERCos treats such resources as population instances of a resource Cosmos organized to support optimized “one-to-boundless” purpose fulfillment computing. PERCos is, in part, a technology set uniquely supporting user use of contextually best suitable resources located anywhere, made available by anyone, and individually or in combination, and as may be best responsive to user purpose objectives. As such,

PERCos embodiments can uniquely support the CPE framing of user resource utilization objectives and related purpose Outcomes through its standardized implementations of user purpose expression capabilities. For example, in some embodiments, PERCos can support one or more standardized parameterizations of Core Purpose intent and other contextually appropriate criteria enabling consistent and efficient interoperable user and Stakeholder purpose characterizations. Such CPE framing optimizes user purpose fulfillment processes by, for example, enabling both generalized contextual user and Stakeholder purpose approximations and associated matching, and supporting Outcome sets as derived at least in part from purposeful utilization of optimum resource sets specifically responsive to such framing. Such resource utilization is a consequence of user and PERCos system and/or application expression and selection processes identifying, evaluating, prioritizing, selecting, combining, and/or provisioning one or more resource sets. In some embodiments, such sets are evaluated at least substantially in part regarding their responsiveness to user specification of standardized Core Purpose and/or broader Contextual Purpose Expressions associated with user and/or user computing arrangement related contextual variables, including in some embodiments, for example, standardized contextual Master Dimension Facets and any associated values, auxiliary Dimension information, user profiles, preferences, historical crowd behavior, and/or the like.

PERCos can identify resource store information elements that correspond to CPE and/or related purpose formulation elements for matching and similarity determination processes that may, for example, evaluate and/or identify and/or select and/or prioritize and/or provision candidate resources at least in part as a result of calculating the correspondence and/or other relevance of candidate resource sets available through such information store(s) to user related purpose expressions such as CPEs and purpose statements, as may be supplemented by other purpose related information. A PERCos based system may also employ inference determinations in support of the specification of, and/or related to the processing of, CPEs and/or purpose statements and/or other purpose expression formulations such as expression verb constraining or identifying categories and/or the like, for use in resource selection, and/or resource utilization evaluation, and/or other PERCos operations, the foregoing in support of user purpose calculations to identify, evaluate, select, prioritize, combine, provision, and/or use resources for initiating, interim, and/or Outcome purpose fulfillment.

A Resource Cosmos for Purpose Fulfillment, Including Associated Learning, Discovery, Cooperation, Experience Support, and Outcome Automation

A PERCos arrangement of resources and users may unfold over time and in part, in conjunction with PERCos standardization arrangements such as purpose expressions and their associated Master Dimensions and purpose classes, self-organize as a systematized purpose constituted resource cosmos. In some embodiments, this cosmos evolves primarily through the efforts of Stakeholders as they declare descriptive Contextual Purpose Expressions for respective resources, including for example, for Reputes assessing one or more other of such resource sets or elements thereof, and for which they may then, in some embodiments, declare one or more resource sets as members respectively of one or more purpose classes and/or other purpose neighborhoods. This purpose cosmos may employ such purpose expression, purpose membership, and/or Repute declarations associated with resources with, for example, user and/or crowd metadata such as, for example, related usage derived information associated with specific one or more purpose expressions, purpose classes, user classes, and/or the like. The result is an evolving cosmos of purpose related knowledge, experience, assessment, and actualization resources, known in PERCos as Big Resource. With PERCos, one or more “general” common purpose effectuating cosmos may be built substantially upon tools and standards for interoperable Contextual purpose expression, purpose related Repute resource assessment, purpose Coherence resolving and optimizing including, for example, resource evaluation, combination, and/or prioritization, and supporting human/computer edge purpose fulfillment interface technologies and processes (such as Foundations and Frameworks). Some embodiments of the foregoing may, for example, support purpose class resource organization, Repute resource appraisal, and resource provisioning Constructs such as purpose class applications and other Frameworks, user computing arrangement Foundations, and purpose facilitation resonances. Implementations of PERCos interfaces and applications may support adaptations for both discrete purpose fulfillment Outcomes and dynamic experience continuums, the latter involving unfolding user/computer/resource arrangements and associated cross Edge interactions such as iterative user purpose expressions through specification and/or resource selection and/or resource portion usage, where the foregoing may be specifically supported by related interface purpose support processes such as purpose expression element faceting interfaces. Such user cross Edge PERCos activities may include multi-user common purpose sessions and over time multi-user purpose collaboration, for example, involving multi-user collaborative document creation, cooperative web surfing, and shared entertainment experience (music, movies, game playing, and/or the like).

A principal aspect of PERCos purpose architecture is a “partnership” or otherwise cooperative and/or collaborative process occurring between users and machines, users and other users, and users and Stakeholders, whereby one or more humans at least in part guide machine operations towards satisfying their individual or shared purposes, initially and/or in an evolving process set involving the maturation of, for example, human perspective, knowledge, orientation, experience continuum, and/or priorities and/or the like. Through this interactive partnership, at least some embodiments of PERCos user/computer arrangement(s) can employ local and/or remote PERCos services and other resources that serve as portals to human knowledge, expertise, experience opportunities, and process opportunity, management, and Outcome control. Such embodiments can provide, for example, process management and other capability support of PERCos user/computer arrangement purpose Outcomes through, in part, the association of purpose expressions with respective resources, and, for example, through event management, including, for example, consequences resulting at least in part from purpose related programmatic instructions. As such, a primary role for general PERCos embodiments is the support of, including, for example, seeking to actualize, purposeful results, whether personal, interpersonal, commercial, and/or the like, and such support may, in some embodiments, include the gamut of user computing purpose objectives, from experiencing entertainment to social networking to user and/or group productivity to information learning and/or discovery to realizing commercial transaction fulfillment and/or or business process automation and/or the like and including any logical combination of the foregoing.

At any given time, users have certain objectives/desires whether explicitly understood or involving an evolving user perspective. To one extent or another, users undergo experience reflecting informational, experiential, tangible, and/or emotional/spiritual factors. To satisfy human purposes, PERCos transforms human perception of purpose into purpose expressions that orient PERCos computing resources to “best” attempt at supporting user purpose fulfillment computing processes. PERCos capabilities can extends into a computer context user purpose fulfillment perceptions by identifying, evaluating, selecting, combining, prioritizing, and/or provisioning resources and/or resource portions as purpose fulfillment tools and/or environments in response to user CPEs such as prescriptive Contextual Purpose Expression instructions, which may unfold as a result of a sequence of purpose related user/computing arrangement interactions, and which may reflect enhanced user knowledge, understanding, and/or experience satisfaction and/or other experience development. As a result, PERCos can supplant today's task oriented and silo computing arrangements with purpose specific support arrangements that may be influenced by expertise and framed for learning/discovering and/or other experience and/or results producing Outcomes. PERCos may specifically focus on satisfying “active” user purposes (or scheduled, time based, and/or event wise triggered and/or specified purpose specifications) by identifying one or more resource sets, including resource frameworks such as purpose class applications, that users can employ to provide satisfying and practically optimized purpose fulfillment results, and/or otherwise contribute to apparent to user set progress towards such fulfillment through unfolding PERCos and/or associated purpose application assisted processes.

What we may need or want to learn at any given time is a result of both the purpose we may be consciously or unconsciously be pursuing, given the context in which such pursuit is unfolding. This context includes how much we know and may further include how much we know about how much we know. In order to improve on the results of our activities, to better our condition and improve the quality of our experiences, it would serve users well to be in the best reasonable position to know what others know as and when it would be useful, and further to be able to apply such knowledge in an optimally productive manner.

The advent of the connected digital world has brought about a quantum leap in diversity of human activity resources and associated pursuit types, focus, and context. While generally, the human community has some sense of the enormous possibilities of being connected to such a seemingly boundless miscellany, no current technology set intelligently associates resource possibilities to one's explicit, current purpose. While knowledge graphs, other clustering, and/or the like can provide some guidance when generally exploring a domain, they are roughly drawn generalizing mediums largely structured according to the characteristics of things rather than the purpose of potential resource users. Generally such technologies fail to provide means that organize resources according to user purpose and, as a consequence, these technologies are unable to responsively identify and/or provision resources in a manner responsive to such user purposes. Further, since such current technologies are normally blind to user purpose, at least in any formal sense, they can't support capabilities that provide the assessment of resources regarding their quality in contributing to optimally satisfying a user specific purpose set, such as those provided by PERCos Repute technologies.

In some embodiments of PERCos, learning, discovery, and/or experience (“LDE”) may be deeply embedded into cloud services, such as, for example, PERCos LDE supporting capabilities related to PERCos Social, Knowledge, Commercial Networking Services (“PSKCNS(s)”). These PERCos capabilities provide innovative features that may transform the character of traditional social, knowledge, and commercial networking. With PERCos, by supporting users viewing other Participants as resources and potential common purpose users and by employing participant related specifications in user CPE specifications, and further by universally viewing other direct, specifiable elements that may contribute to a PERCos session as candidate resources, users can learn about and/or discover, that is identify, evaluate, and employ a “best” set of other participants in PSKCNS context, and more broadly, an optimized set of resources for any given purpose.

Many modern computer users now share an awareness of the presence of a seemingly boundless array of resources that might seem useful generally, particularly for certain well known tasks—Yelp may be useful in gathering information concerning crowd member reactions to, and aggregate ratings of, services such as neighborhood restaurants; similarly Amazon reviews can be useful in assessing reactions to products; and Netflix can inform regarding the crowd reactions to video entertainment; while IMDb is useful in obtaining expert movie reviewers views and scores for specific films and television shows; Healthgrades and Vitals in assessing hospitals and doctors; and eHow, Answers.com, WebMD, and Wikipedia, can responsively supply limited information responses on certain things. One major concern regarding these systems is that these services are not generally adaptive; they normally provide static characterizations of things (including services) with generally a highly specific focus on a preset category item. While these systems can provide useful information regarding certain limited categories of things, unlike PERCos mechanisms, they don't provide any significant ability to identify, or adjust, combine, and/or evaluate a resource to be responsive to a user's current specific purpose.

There are one or more services, for example, 43 things (www.43things.com), which provide simple mechanisms for sharing what its users characterize as goals, but such a system does not provide means to significantly systematize and/or evaluate purpose, but rather allows anyone to chat about anyone else's natural language expressed goal and has means to generally associate different goal expressions to support some grouping. This often leads to a cacophony of comments, which may motivate some people regarding a goal because it seems shared with others, but is not about any formalized system for resource management, identification, evaluation, prioritization, selection, composition, provisioning, and/or usage support in a manner responsive to user purpose, that is to enable common purpose computing, including sharing and/or the like. For the above services, when a computing arrangement user ventures beyond the assertions of the crowd, and/or in more limited circumstances the assertions of experts for branded products, services, and entertainment, that is when one wishes to launch a learning process leading towards an Outcome about an issue whose specific nature is defined by a user's purpose and not a category—the foregoing given one's individual constraints, interests, priorities, and/or state of knowledge and/or the like—current technologies are not oriented towards providing the facilitating layer(s) that bring one to “best” candidate one or more resource sets such as facilitating an Outcome related to, for example, a technology, a perspective on certain scientific research, a manufacturing technique, how to fix something specific, a social or commercial networking objective, and/or the like.

Current social networking, for example, through services such as Facebook, Google+, Twitter, MySpace, Instagram, and/or the like, primarily involve interacting with parties a user knows, may know, or has “friends” or other acquaintances in common. Those social networking services may also involve identifying or establishing threads or groups that share some stipulated interest, and one such service, 43 Things, is substantially focused on shared interest around a user natural language declared topic. But these networks are not general resource identification environments and are not structured as interface environments to, for example, Big Data and Big Resource. Generally, they do not provide a standardized contextual structure for purpose expression but rather support streams of comments from members associated with topics, where such comments generally speaking provide a smattering of disparate remarks and not a contextual purpose responsive resource array. These services are not designed around the principal of optimized user purpose satisfaction through identifying and provisioning desirable resources to support unfolding purpose satisfaction processes.

In certain PERCos embodiments, purpose class applications are particularly useful in supporting learning, discovery, and experience enhancement. In an emerging purpose based computing cosmos, people anywhere, of any inclination and ability and knowledge level, can, with some PERCos embodiments, publish resources such as purpose class applications, which are meant to support the learning, discovery, experience, and/or Outcome objectives associated with such applications associated CPEs. Such applications can function as specific purpose class (such as CPE) specific fulfillment environments and may be specified to support such purpose expression sets as narrowly and/or as broadly as may be specified by their design decisions and their concepts associated with such relevant CPEs. Such applications may incorporate any number and variety of purpose fulfillment subclasses, which may be formally declared as subclasses of such purpose class applications.

Over time and given sufficient participation, as well as sufficient evolution of Repute resources as filtering and prioritizing input, in some PERCos embodiments, users should be able to connect to a PERCos cosmos arrangement and be in the neighborhood of the best available resources and/or resource portions. Best purpose class applications may, for example, provide Domain specific guidance through interface and application capabilities that in a Domain specific manner support further learning, discovery, and/or experiencing options and processes that have been tailored by the talent and skill of such application publishers and/or their associated experts and/or based on user input such that learning, discovery, and/or unfolding experiences have been formulated by those having specific domain expertise, experience, and/or sufficient associated talent. Certain of such purpose class applications may to be considered to be, according to Repute resources responsive to user specification, the “best of breed” given user concerns and other contextual conditions (for example, Quality to Purpose, Quality to Value, user budget, user sophistication, available time, availability/affordability of Role contributing application sub-resources, and/or the like).

In some embodiments, PERCos purpose class applications, as learning, discovery, and/or experience unfolding environments, can be oriented towards any set of purpose fulfillment processes and activities, from narrow to broad. These may involve relatively uniform types of activity sets to compound activity sets and such architectures may involve senior and more subordinate purpose class foci, as well as provide purpose, for example, class-oriented, user navigation tools. For example, a purpose class application might be created for the moderately knowledgeable in the Domain of Physics, this application taking the form of a knowledge pursuit/imparting environment comprised of both more general tools and more specific tools, such as an expert system interface arrangement guiding users through their respective interest focuses, such as learning about specific issues involving the intersect of molecular and nuclear physics information.

For example, in some embodiments, a user might specify a CPE as:

“Learn+Physics+Nuclear&Molecular+ModerateExpertise+<$200.00+PurposeClassApp” (“+” adding an element and “&” being a horizontal connecting operator and “<” standing for less than), which might be purpose identified and in part prioritized by an aggregate of Repute representation of Repute Creds published by Ph.D.'s in Physics. Alternatively and/or in addition (by, for example, weighting variation, that is, for example, providing more weighting for) tenured Physics professors, may be specified by user set for their CPE Creds use, wherein such professors who published relevant Creds that, for example, have sufficiently similarity matched Creds CPE(s) as purpose expressions for Repute Creds and EFs, and/or as purpose expressions for the subject matter of such Repute items (and/or sufficiently similar Creds subject(s) if so specified), and who are employed at “major” globally ranked universities (e.g. ranked by US News and World Report) might be employed for aggregate Creds calculation, all the foregoing contributing to the PERCos determination (e.g. by Coherence Services), for example, in some embodiments, of a prioritized list of similarity matching of purpose class members based at least in part on such professors aggregated asserted views of sufficiently matching resources and/or portions thereof. Such purpose class member neighborhoods may be similarity matched and/or otherwise filtered, for example, for published purpose class applications that are members of the desired neighborhood set that are sufficiently corresponding to user CPE and/or components thereof. Such results may be, for example, provided in the form of a priority ranking reflecting the asserted assessment of the specified Repute input arrangement, such as such professors as discussed, who are in, or otherwise associated with, a CPE corresponding purpose class and/or Domain/category set, and who are employed at such globally significant universities. Some of such matching neighborhood, for example, purpose class, identified members might be providers of “master” purpose class applications that also provide portion sets focusing on both astro and bio physics, and wherein such subclass arrangement set is of sufficient apparent quality that Repute asserters consistently declare such a given such resource set, and/or resource portion set thereof, as “best of breed” or otherwise highly ranked for the user set for matching the user set CPE (make sure definition of user purpose and purpose, includes purpose set).

As discussed, PERCos capabilities in some embodiments can be applied or otherwise integrated into, if desired, computing arrangements in such a manner that PERCos capabilities can be applied to any specifiable purpose type. For example, in such embodiments, a moderately experienced off road bicyclist can employ PERCos to learn about moderate difficulty, not remote, not steep, moderately trafficked, biking trails near the user's new employee location; or a user interested could learn more about differing arguments regarding global warming and associated political action groups and their activities; or a user could learn about avoidance of repetitive wrist injuries when working as a software engineer or about the comparative efficiency of large versus multiple computer displays when working with multiple, large scale documents; or about the relationship between, availability, durability, cost, and shedding of wool v-neck sweater brands; or about contributing to the overall value of the comparative cost of travel, time spent in stores, cost of item, cost related to service and repair and support, for large appliance purchases; or about the technical progress and challenges in using stem cells in treating kidney disease; or about the challenges concerning, and available information regarding, near earth asteroids/comets and human community protective measures; or identifying the six most likely people with whom you could synergistically enjoy listing to classical blues music, or watch and discuss a series of documentaries across multiple session employing at least in part use of shared common purpose resources, and wherein PERCos capabilities are supportive of documentary resources identification, prioritization, and selection processes and further chat, video conferencing, and/or other forms of shared, common interest virtual presence and common participation.

In some embodiments, purpose class applications can employ, for example, array and provision resources in support of class related user purposes and can maintain Frameworks populated by purpose class specific resources such as references, videos, games, music, experts, and/or the like, available as managed resource opportunities supported by PERCos operating system, environment, and/or application resource management capabilities. As such, a purpose or more specifically a PSKCNS class on Sport Car Maintenances and Mechanics might have various auto manual and repair handbooks, videos, and other reference resources as well as lists (with or without their Creds as associated with list instances) of Participant Experts associated with the overall CPE set for the class and/or with contributing CPEs associated with class resource instances and/or portions thereof. Also, as such, an environment can be maintained, for example, by an affinity group such as a club administrator arrangement and/or commercial and/or nonprofit service wherein a CPE arrangement specific resource rich purpose fulfillment environment is available to participants, and, for example, in some embodiments, wherein membership/user of a PSKCNS purpose class application may have requirements such as speaking a certain language, a given degree level generally or in a certain academic area, being an alumnus of a given school or school type such as a nationally ranked university, having a specific or generally having union membership, being a licensed contractor, belonging to a national professional association, being of a certain age, being credential by a reputable credentialing authority, and/or any other logical, and in some embodiments or cases in particular, testable criteria where objective and/or verifiable/testable lists are maintained by, for example, reputable authority entities. This PSKCNS purpose class application “qualifying” criteria may be proffered by applying participants through PERCos PSKCNS compliant application forms, and wherein such specific proffered information instances, such as membership in an engineering organization, could be automatically checked against such information stored as information within a PERCos cosmos resource, such as by, for example, PERCos Test and Results Service, and wherein a PERCos form has sufficient field resource related information and associated capabilities such that a response in standardized format to a form question or list, such as membership in the ACLU or NRA or AFLCIO, could be automatically verified as, or flagged as not, true as an EF. Such organizations, including corporations, educational institutions, colleges, clubs, societies, publications, and the like, could provide such characterizing “list” information in a PERCos embodiment compliant or integrated form supporting such automatic identifying and/or validating and/or testing functions. An expanding PERCos resource cosmos would assist in such systemization and normalization of web based networking relationships by enabling use of EFs and Creds to provide users and Stakeholders with sufficient information, similar but in some ways enhanced over, traditional face to face human interactions.

PERCos, for example, in some embodiments, can support a coherently ordered social networking arrangement structured at least in part for use with resources and Big Resource environments and enabling groups of people to mutually participate in common purpose computing sessions and/or like interactions with an optimized access to, evaluation of, and/or provisioning of, specific session purpose supporting resource sets, including, for example, participant sets, prioritized, alphabetical, or otherwise organized and particularly suited to a user set CPE specification. Further, PERCos learning and discovery capabilities should substantially enhance social, knowledge, and commercial networking for many people by providing capabilities for users to learn and discover information regarding resources thereby enlarging user understanding of possible resources, including resource portions, and/or enhancing processes related to such resources.

PERCos can, in some embodiments, help users identify and structure synergistic multi-user arrangements specifically responsive to consonant respective purpose expressions, capabilities, other characteristics, and/or the like so as to form a commonly satisfying purpose fulfillment networking groups suitable for constructive, purpose fulfillment interactivity. PERCos can extend synergism evaluation and cohering processing to optimize matching among both users with other resources supportive of their mutual and/or consonant objectives, including the evaluation and cohering processing of non-Participant resource types in order to provide an optimum environment for shared purpose fulfilling processes. For example, a user set could specify a Contextual Purpose Expression regarding their purpose set (using, for example, Master Dimension specification, with or without auxiliary Dimensions) and PERCos could perform a similarity assessment of declared purpose classes, including, for example, PSKCNS oriented purpose classes or the like, which are, for example, defined/situated in ontology and/or taxonomic structures by Domain experts and/or other Stakeholders for PERCos purposes on behalf of a standards organization such as a PERCos purpose or specifically PSKCNS utility. In some embodiments, such class declarations could, for example, declare that one or more user prescriptive CPEs representative of PSKCNS purposes are associated with, for example, one or more purpose classes, and such expression sets can be used to, at least in part, identify one or more PSKCNS classes.

In some embodiments, such similarity matching of user CPEs to purpose class CPEs, other ontology neighborhoods, and/or resource instance CPEs, PERCos may use resonance resource instance sets, and such sets in some embodiments may, for example, employ purpose optimizing synergizing instructions. PERCos synergizing instructions can represent specifications of resource instance combinations and/or portions thereof where a plurality of resources perform, or may perform, a contributory purposeful one or more functions, for example, contribute one or more characteristics strengths as may be specified by their associated CPEs and/or metadata, where such resources may be associated in CPE purpose fulfillment as mutually complementary and/or otherwise advantageous, from a combinatorial standpoint, in realizing, or attempting to realize, a specified purpose Outcome or interim process and/or result.

In some embodiments, PERCOs synergizing to purpose, for example, employs building blocks in the form of resources and/or resource portions, including, for example, Constructs, knowledge information, Participants, devices, services, and/or the like, the foregoing representing families of different resource types that may be combined in some manner to optimally assist users in achieving their Outcome objectives by forming particularly productive arrangements for fulfilling, or otherwise attempting to fulfill, one or more CPEs. For example, resource items having differing characteristics might, for example, be useful in the specification of the following CPE: “learn thin film solar cell materials science and fabrication.”

In some PERCos embodiments, a publishing or synergizing set specification arrangement may be presented in a format that represents, for example, separate simultaneously displayed, vertical resource type prioritized (in order) characteristic instance choice lists. Such lists may be prioritized by resource instances being processed through Coherence Services evaluation, such as similarity matching against user and/or related purpose expression sets and/or filtering and/or evaluation based upon Repute Cred assertions and/or EF effective facts and/or other information such as group administrator governance information. For example, in some embodiments, an example list display might comprise, a first column displaying general topic textual-audio-and/or visual reference materials as a category area, a second column representing consulting domain experts (e.g. names) with teaching/tutoring/skills, a third column representing expert domain researchers that may be available to consult, including doing collaborative work, in the area, a fourth column representing expert manufacturing implementers (practical manufacturing engineers) with applied experience in the domain, a fifth column representing market analysts who have knowledge and experience concerning market interests and considerations, and whereby a user set can evaluate and/or select and/or proceed with further evaluation, discussion, information supplementation, and/or item selection. Such listed information may be complemented by supplementary information where, for example, such specific instance information may be complemented by further, more detailed characteristic related information by a user moving a cursor over a candidate list instance and with instance specific details appearing in an adjacent, well organized “balloon” temporary sub-window, toggled to alternative supplementary window, and/or the like. In this example and embodiment set, selecting instances from such lists of resources, includes, for example, potential Participants having synergistically complementing characteristics who can form a synergistic user group for what a user set, as assisted by their PERCos arrangement, perceives as an optimum Participant candidate synergistic resource combination which may “best” serve as CPE fulfillment interim and/or Outcome complementary users/contributors. Such tools may also be used with non-participant synergistic resource selection, for example, in the specification of elements of a purpose class application environment where such resources might at least in part be used to populate, for example, a PERCos Framework associated with the user set CPE set (including, for example, a collective, resolved PSNS group Purpose Statement) such as, when building a purpose class application light note writing, presenting a synergy arranged faceting list to select a productivity application that that would fill a Framework Role of word processor.

PERCos Repute resources may be particularly useful, in some embodiments and circumstances, in optimally identifying, filtering, and prioritizing candidate and/or to be provisioned resources for PSKCNS. Such Repute resources may, for example, employ EFs that were published as self-describing systematized profile/CV by participants, where, for example, a participant might declare that she is an MIT tenured Associate Professor in Biophysics, aged 53, with x specific and/or number of peer-reviewed authored publications, that she lives in the Boston Metro area, that she is available for online and/or in-person research and development consulting and/or knowledging session participation as PSKCNS group Participant, and that she expects and/or requires a fee of y dollars per hour of session participation and/or consulting. Creds on such professor by other tenured professors in Biophysics may, for example, be used in combination with the professor declared EF and CV information, such that the combination of such EF and other declared CV information might be used to determine that such professor could be helpful in a given PSKCNS session as a consultant, and such information, along with such Cred assertion information on such professor for such consulting purpose could elevate or downgrade its list ranking position relative to other candidate consulting professors. Further, in some embodiments, such self-describing systematized profile/CV may include personal information that may in part, or in whole, be included in Creds, including information regarding avocation, such as surfing, mountain climbing, astronomy, car racing and/or the like; hobbies, such as football, baseball, soccer, rugby, and/or the like; marital status, married, single, divorced; family status: number of children and age and sexual orientation, such as straight, gay, lesbian and/or the like; health status including material medical conditions such as diabetes, arthritis, and/or the like. In some embodiments, such personal information may be in part or all encrypted and rules controlled to contribute to personal policy enforcement regarding privacy of information and with whom any set of such information may be shared. Further, for example, in some embodiments such Creds may store portions of such characteristics information as Cred EF information, where such information is externally testable and/or verified, for example, by a certificate provided by a trusted authority and/or a test procedure set operated with an authority that maintains a PERCos compliant information verification arrangement. For example, a corporate publisher of a Cred may describe their identity in a form which satisfies EF reliability/testability requirements and may be described in the form of an EF where such publisher lists, for example, in a web accessible corporate database in a manner satisfying EF testing, including, for example, certificates, rules that affirms that the corporation is the publisher of such Cred, encryption techniques, administrative controls, and/or the like. For another example, a Cred published by a given Participant may contain, or reference, an EF regarding such participant being an employee of Boeing, where such individual is listed as an employee on a publicly accessible information listing on a Boeing website in a form compatible with a PERCos EF testing procedures.

In some embodiments, registered or otherwise declared resource members can be stored as accessible information elements within an overall metadata arrangement, where such information elements are, for example, classified as participant members of one or more category types derived at least in part from their employment with or by users, Stakeholders, other resources, and/or the like under one or more specified conditions. For example, a resource may be declared, or by historical usage association be identified as, a resource member of a purpose class, such as, for example, a synthetic biology “DNA reference Library of Functional Units” being used for, and a declared and/or being a historically derived resource member of, the purpose class of “create DNA preparations for tissue replacement” as identified and defined by an authorized Domain experts team for biosciences, while the same purpose class may also have the “Synthetic Biology Institute” at UC Berkeley as a declared and/or historical information derived participant grouping member of such same purpose class, and further, for example, EF verified or verifiable researchers at such Institute may also be stored as participant members of such class, along with, for example, with their self-assertions and Creds by other parties on their Quality to Purpose for such purpose class. Such metadata information elements can, for example, be associated with resource instances, groups, and/or PSKCNS classes for PSKCNS purposes.

Participant sets may, in some embodiments for example, declare themselves as resource member participant type instances belonging to one or more purpose classes and/or associated with any one or more purpose class applications as historical users and/or Stakeholders, along, for example, in some embodiments, with storing such member instance declarations of their self-assertions and/or third party EF and/or Cred declarations or assertions regarding their expertise level (e.g. beginner, moderate, expert), knowledge level (e.g. modest, medium, highly), trustability level (e.g. low, medium, high), experience level with, for example, a purpose class application, and/or the like. In some embodiments, for such declarations to be effective may require satisfaction of certain Expert set, utility set and/or other governing body set, rules, which may include tests for verification purposes, where such as one or more characteristics of participant set correspond to EF and/or Cred criteria, such as a requirement for being a member of a given affinity group, and for example, may include the declaring participant set being comprised of one or more tenured history professors at the University of Maryland, and might further require in certain instances, requiring for example that certificates associated with one or more EF elements and/or tests that validates the EF requirements, such as looking up a list published by University of Maryland of its tenured history professors and confirming such EF as sufficiently reliable as defined by PERCos arrangement related specifications. The latter may, in some embodiments, might require that the publisher of such be the University of Maryland and that University of Maryland publish such list in a form compatible with one or more PERCos embodiments such that such list can be securely evaluated, queried, and or otherwise tested and/or inspected. Further one or more such embodiments may, for example, require that such test be a sufficiently secure system arrangement in accordance with specifications for communication, testing, and/or security system features attributes (for example, for specified security level and/or other attributes) and whereby, for example, communication protocols, authentication procedures, encryption processes and specifications, information store and/or user access controls, and/or the like meet sufficient standards for a given security level to maintain overall sufficient system authenticity/reliability. Such trusted EF related information may, for example, in some embodiments, be used in PERCos identification, evaluation, filtering, prioritization, and/or the like processes.

PERCos classes may, in some embodiments, have resource participant member arrangements wherein participant individuals and/or groups and/or other resource instances and/or groups, associated with one or more resources, such as purpose class applications, could both be available in the form of prioritized lists of such member types, based for example on Repute input, as may be managed, for example, at least in part by a cloud utility and/or an administering expert set. For example, in some embodiments such resource sets may be prioritized and/or otherwise evaluated in relationship, for example, to a participant history related to any given CPE use and/or through the use of Stakeholders Repute Cred third party assertions as related to such Participant Quality to Purpose, Quality to Value, Quality to Contribution to Purpose, and/or the like use of any given CPE and/or associated purpose class applications and/or as associated with purpose classes and/or interactions with other participants and/or Stakeholders, for example, as may be associated with foregoing. For example, such evaluation may reflect such participant performance as a user regarding such user's Quality of Contribution to purpose in one or more common purpose computing sessions, and/or the like, and where Quality of Contribution to Purpose Cred information may be aggregated across various similar purposes to represent a Quality to Purpose rating for a higher order (such as a superclass) purpose class or purpose neighborhood. In some embodiments, such evaluation and information use may be applied, as applicable, to any resource instance and/or group in relationship to any other resource instance and/or group, that is for example, a given information resource may be evaluated as to Quality of Contribution to purpose if the resource serves as a contributing component in a CPE fulfillment process.

PERCos purpose class members could be, for example, in some embodiments, at least in part be comprised of a list, subclass, or other grouping sets of resource members in accordance with their types, such as participants, information reference resources, purpose class applications, Informal resources, cloud services, devices, computing platforms, Frameworks, Foundations, CPEs, and/or the like, along with their associated Creds, EFs, and/or any other associated metadata. Such class type members might further and/or alternatively comprise, in some embodiments, for example, Constructs, participants, tangible resources, and/or published CPE instances and/or sets, and/or the like. In some embodiments these class members can be organized and manipulated by type and by type combinations, for example, generally by resource, by participant, and/or by purpose class other associations of an instance or type. The foregoing may be manipulatable both separately and in combination to, for example, enable users and/or PERCos arrangements to, at least in part, assess resources for their historical associations and/or their Repute Quality to Purpose or Quality to Contribution to Purpose performance and/or relationship (expressed, for example, as Creds), and/or the like. This assessment may be performed, at least in part by, for example, evaluating Creds and/or EFs, and/or by evaluating Outcomes resulting at least in part from the use of certain resource sets as contributing components to other resources sets such as by being contributing participants, CPEs, Constructs, and/or the like, and, for example, as operating in purpose class applications or other Framework roles. Such evaluation information facilitates the evaluation by user, Stakeholders, and/or PERCos arrangements regarding the conditions and characteristics of working with different resource sets.

With some PERCos embodiments, users can identify, evaluate, filter, prioritize, and/or select member resource combinations that may respectively define resource networking component “spaces”, such as Hilbert spaces and/or the like. Much like PERCos Dimension CPE spaces, some PERCos embodiments enable users and PERCos computing arrangements to adjust such resource spaces to provide differing views into resource and resource portion sets so as to facilitate user and/or PERCos arrangement evaluation for purpose fulfillment options. By supporting user sets using, administrating, and/or manipulating PERCos information resources, including EFs and Quality to Purpose and/or, for example, other “Quality” Repute factors related to participants, published CPEs, and/or other resources and/or resource portions, for example, in some embodiments, user sets may direct PERCos capabilities, through, for example, Master and/or auxiliary Dimension PERCos specifications, to produce viewable and manipulatable sets of candidate participants and/or other support resources for PERCos session purpose fulfillment. For example, this ability to view and manipulate purpose fulfillment resource spaces can inform users regarding the relationships between a resource set characteristics and various purpose expressions such as Core Purposes, CPEs, and purpose statements and their desirable (or undesirable) characteristics. This can facilitate user assessment from historical, Repute information, and/or the like perspectives, regarding working with specific resource set(s). In some embodiments, by viewing Quality to Purpose, Quality to Value, Quality to Contribution to Purpose, and/or other Cred Repute assessments and EF considerations in combination with underlying purpose expression(s), one can calculate corresponding spaces that may then be used for assessing resource instance and/or resource combinations as to their differing relationships to such different purpose expressions and their possible relationship to such purpose expressions respective fulfillment, that is, such spaces may be assessed as to how they may correspond to desired Outcomes.

In some embodiments, PERCos session historical information may be stored where such information, for example, may be associated with resources, such as purpose class applications and/or participants and/or CPEs and/or other resource instances and/or purpose classes and/or other ontological groupings and/or the like, associating for example, chat, texting, blog, comment, edit, video conferencing, and/or the like activity types. Such information may be stored, for example, for use in any combination at some later time in association with, for example, such later current user purpose and/or Core Focus expression related PERCos activities. Such information type(s) may be associated with any specific and/or combination of such PERCos class member types, for example, where such member sets are members of PERCos class type that may be similarity matched with current user CPE set. Such historical information may, for example, be published in the form of a resource set as individual instances of associations with a specified purpose class, where such resource set may be “reused” as a social, commercial, and/or knowledge information asset set, for example, during, aiding, and/or otherwise being made available during, a PERCos session and/or other employed for commercial and/or social reasons, such as for information aggregation and advertising/promotional information marketing and use. For example, a multi-media video of a physics teaching session may be published as a resource associated with a CPE set and where, for example, such resource includes a table of contents and a contents index, and further where users in a PERCos enabled session may employ during such session a portion of such resource as may have been published associated with a CPE set for such portion as a result of previous usage (or Stakeholder declaration) of such portion for such purpose, and where any given portion associated CPE may be a subclass of a CPE, or a CPE set, for such multi-media video. Such resource information, that is the association of a portion set of a resource with a CPE set may be published in the form of their respective resource types, subtypes, aggregations, and/or any other logical information forms and/or combinations, where such information is associated with a specific given resource, resource combination, and/or portion, so as to be available for evaluation and/or processing purposes at some one or more later times.

In some embodiments, Repute is a core PERCos capability set providing powerful purpose computing tools for filtering through huge candidate resource sets based on reputation and relevancy related attributes and assertions. Repute can be used to evaluate, and/or, for example, to filter, sort, prioritize, and/or otherwise aid in the arrangement of candidate resources identified among large resource arrays to produce usefulness optimized and/or otherwise prioritized candidate results. These results can be based, at least in part, upon Repute attributes as they may relate to the apparent contextually related “qualities” of such resources—that is resource sets may be measured, at least in part, by quality of performance/usefulness and/or other germane indicators interpreted through the use of related contextually significant attributes, providing assessments of resource reputation as related to user purpose sets.

Repute results are produced by augmenting prescriptive and descriptive CPEs or Core Focuses with attributes and any associated values that are descriptive of the “quality” variables to be used in the relative assessment of, and frequently, comparative relative usefulness, of purpose fulfillment resources, and where such quality variables are informing regarding the possible relative potential usefulness of the subject matter of resources and/or resource portions, calculated employing such reputational relevant fact and/or assertion stipulations. Such stipulations can be expressed, for example, through (a) the expression of CPEs, (b) stipulated by non-CPE Metadata, (c) otherwise expressed through one or more preferences and/or profile settings including any governance sets, and/or otherwise historically, rules based, published, and/or contextually derived information. Such Repute resource organizing calculations may, for example, contribute to the filtering and/or in some other manner order one or more useful or possibly useful resources using assertions and/or facts that have been expressed employing and/or translated into standardized characteristic elements along with any applicable corresponding values.

Repute has three main specification groupings, Effective Facts, EFs, Faith Facts, and Creds. EF specifications contain “ascertained” and/or otherwise contributed factual assertions regarding a subject, such as the date a person was born or an institution's assertion that an individual is an employee and, for example, holds a certain position and/or title. Faith Facts are based upon spiritual beliefs and not subject to the testing and/or trusted authority rigor of Effective Facts, but may involve testing and/or validation/certification by a spiritual authority associated with the FF associated spiritual belief group. By contrast Creds contain and represent assertions, rather than settled or settable facts, such assertions are made by one or more parties that have respectively, at least one persistent, operatively unique identity, and where such assertions do not rise to the level of a factual attribute set that was stipulated by a reliable, recognized unbiased fact related “authority” of sufficient reliability as to the fact, as least under certain conditions. All EFs, FFs, and Creds have an identified subject matter characterization set. In some embodiments EFs, FFs, and Creds may require that certain information related to any one or more such subject matter characteristics sets or portions thereof, such as a persistent one or more identities to be associated to any of subject matter publisher(s), creator(s), provider(s), as well as in some embodiments providing one or more of: location(s), time(s), date(s), authoring and/or publishing id(s) and/or any other identifiable and inter-operably interpretable associated other characteristics desired or required by an embodiment, and where any one or more of such subject matter characteristics may be required to be reliably known (e.g. certified) and/or were otherwise testable, that is as Repute information related characterizing the subject's topic matter and/or any one or more other Repute related characteristic(s) related thereto. By contrast with EFs and FFs, in some embodiments, Cred subject matter may either not have a persistent one or more identities as generally meant herein regarding asserter identities, that is Cred subject matter may correspond to a user resource class, some affinity group, or some other logical grouping that, for example, may provide an group identity, or the subject matter may be explicitly identified through the use of a user resource and its associated UID, and/or otherwise may be a topic, such as a generalization, which, for example, is provided by a Cred publisher with a operatively, or sufficiently as may be prescribed under the circumstances, distinctive to unique ID, such as a web page address, or a taxonomic id created by such publisher/asserter. Persistent subject and/or publisher, creator, provider, and/or asserter identity(s) may contribute to a Creds trust and/or integrity level, and/or other characteristic representation(s), of Cred applicability, authority, and/or reliability.

Some PERCos embodiments will treat an expression of a subject characteristic as a fact, not an assertion, when such expression was made by a party having specific and convincing authority to declare a fact, such as an EF or FF, regarding a subject. Such interpretation of specific and convincing authority may be contextually dependent, for example, as related to topic and/or other assertion characteristic(s). By contrast, Creds represent assertions that may be generally recognized, or for example, disputed, and are expressed opinions regarding subjects and such assertions are not demonstrable as facts by reasonable testing. EFs, FFs, and Creds may be deployed according to reliability levels. Reliability levels can inform user(s) and/or associated computing resources (such as an operating PERCos session) as to whether a given degree of specified reliability satisfies either preset and/or current session rules and/or other criteria as to specified reliability. For example, in some embodiments, a user may be presented with the option to select from levels 1-10 reflecting the underlying level of EF of FF fact testing, such as related security procedures and/or the representing assessed (for example, by a PERCos utility or other administering body) authorities reliability in authenticating such facts.

EFs, FFs, and Creds can form, for example, filtering “vectors” that complement PERCos Core Purpose and other purpose expressions. They provide further, and in certain embodiments and/or circumstances primary, filtering and/or prioritizing input. In part as a result of the use of standardized purpose Repute expression specifications and related values reflecting factual and/or assertion characteristics of Repute subjects, Repute variables provide input for the calculation of results that can most closely correspond to, and/or otherwise implement and/or optimize, results related to the objectives of CPEs and any associated preferences, rules, historical information contributions, and/or the like. In use, EFs, FFs, and Creds may be used in combination, either with their own type (e.g. EFs with EFs) and/or in combination with the other type (e.g. EFs with Creds), and Creds, singularly, or in some combination, may be in some embodiments aggregated and/or otherwise algorithmically interpreted and associated as inter-operably interpretable values with any resource by, in part, the association of Repute information with the subject matter of such resource, and/or by association with any one or more resource characteristics, such as with one or more resource publishers, providers and/or creators and/or, for example, as associated with a performance characteristic of the subject matter, such as the reliability of a certain type of hardware memory for a certain type of fault tolerant application class. In such an instance, a purpose class CPE for employing fault tolerant hardware memory that contained fault tolerance as an expression subset might, in a given application, be employed in matching with resources and/or resource portions in a manner where the fault tolerance expression was matched against the stored information regarding asserted fault tolerance quality(ies) of a given resource set in a manner whereby resources were prioritized, at least in part, in accordance with the assertion by certain qualified experts. Such experts may be determined according, for example, to user(s) specification, and/or, for example, third party authority organizations such as certifying authorities and/or, for further example, by known generally assumed to be useful asserters, such as senior faculty members at institutions who are accepted as Domain experts, and/or as asserted by qualified asserter for the purpose such as an associated society or other Affinity Groups.

EFs and Creds and associated PERCos processing arrangements, in some embodiments, employ security tamper resistance technology, such as encryption encoding, secure digital rights management for secure rules governance, hardware tamper resistant processing and memory space for decryption and/or rules processing, and/or the like, the foregoing to help ensure that their respective fact verification and assertion information reliably represents their original published states.

Cred and EF subject matter, in some embodiments, have unique identities. Such identities can be important in ensuring that assertions and fact declarations are associated with the proper locater subject identities in order to facilitate proper, explicit, unique identification of a subject matter instance so that Cred assertions and EF fact declarations can be appropriately organized, aggregated, analyzed, and are properly associated, as may be desired for example, with CPE, purpose, Domain category, and/or resource, instances and/or classes and/or the like. Such unique identities help ensure that parties may, as desired, comment reliably on the intended subject matter and that it appropriately corresponds to the subject matter specification of the corresponding Repute Cred or EF.

Such identities may be associated with specific PERCOs Repute Facet standardized and interoperable characteristic approximations, for example, in some embodiments, Facets such as Quality to Purpose, Cost Value as to Purpose, and Reliability to Purpose (including, for example, correctness of subject's content, when applicable, or reliability of a device, when applicable, and/or the like), and/or Integrity as to Purpose.

In some embodiments, Repute variables such as Quality to Purpose values as associated with experts, and resources, may be specified as to be applied to an associated specified purpose class set for similarity matching, filtering, prioritization, and/or evaluation processes, when performed. Further Repute specifications may be applied during a user specified PERCos session, where such may be incorporated into Frameworks, Foundations, resonances, and/or other applicable resource purpose specifications, and/or may, for example, be referenced as and operate as underlying preference variables that may be automatically associated with purpose expressions and/or class sets for employment in sifting through and/or prioritizing resources and/or the like.

Repute resources further support, and in some embodiments may include applications, services, plug-in capabilities and the like that enable real-time human interaction between disparately located people, in particular providing evaluation and/or specialized monitoring capabilities regarding participant candidates and/or active participants with whom a user has little or no familiarity, but who offers to others (and/or between each other and/or is a candidate for) knowledge, expertise, instructional ability, companionship, entertainment interaction, friendship/companionship, and/or commercial opportunity, and where Repute can help users to determine whether such interaction involves participants who meet and/or exceed pre-set and/or currently selected user set and/or other user associated criteria (e.g. user employer and/or association parameters), including specific, relative, and/or otherwise algorithmically and/or historically influenced criteria. These capabilities may, for example, operate substantially based on stored information provided by web one or more services and/or may at least in part be extracted from effectively real-time biometric related evaluation of session participant behavior, as may be further evaluated through Repute information. These applications and services can greatly facilitate user and/or system identification, filtering, and/or prioritization of at least in part unfamiliar one or more candidate(s) for session participation and/or otherwise initiate and/or monitor a session employing one or more such candidates, participants, or PERCos session users).

Information and algorithmic resources supporting such PERCos capabilities, such as Creds assertion and assessment infrastructure, can, in some embodiments, provide a global system for standardized categories and value expressions stipulated by persistently identifiable asserters as descriptive evaluations of any subject matter, either as general assertions and/or as assertions associated with one or more instances and/or classes of purpose expressions, activities, tasks, groups, and/or other individual and/or ontologically and/or taxonomically organized items, and where such Creds themselves may be organized in ontologies and/or taxonomies and/or other organizing systems such as indexed and relational databases and/or the like. Creds subjects may include specific Creds or classes or other reliably identifiable groupings of Creds, that is any asserter may make one or more assertions about any subject matter, including Creds sets, creating Creds on Creds, that is Creds expressing aggregates of assertions and associated values reflecting asserters' views of the qualities of one or more, such as a group, of Creds asserted, by, for example, a particular individual, organization, collection of parties, and/or the like, as to a particular subject matter area. With Creds, an asserter may, for example, use selected standardized variables, for example, asserting relative values, either employing positive, or positive, neutral, and negative, values. Combined with other aspects of Repute, such as EF characteristics and values reflecting claims relevant to the importance, relevance, and/or usefulness of individuals or groups based upon facts and/or apparent facts associated such individuals or groups, Repute provides an unprecedented capacity to identify and organize resource possibilities from Big Data and Big Resource.

In some embodiments Cred asserters, may be evaluated by other Cred asserters regarding, for example, their professional credentials, schooling background, credit worthiness, age, location, affiliations, associations (including with individuals), historical behavior, for example, as associated with any purpose or activity instance and/or group set. In some embodiments, PERCos services can calculate and display, and/or employ specific and/or aggregate, values for standardized characteristics and/or standardized aggregation of characteristics, by, for example, displaying one or more values (e.g. a value or a value range) associated with each characteristic and/or aggregation, and wherein any such characteristic and/or aggregation may be associated with a task, historical activity, resource and/or purpose expression, instance, and/or class and/or the like. This allows users, for example, based on pre-set preferences and/or at least in part historically based actions and/or related results, to evaluate individuals and/or groups of individuals having, and/or who are otherwise associated with, any such characteristics and values.

PERCos can, in some embodiments, through its Cred, EF, and/or FF capabilities (as appropriate), evaluate candidate participants as to their satisfaction of user and/or user's group criteria regarding participation in a given context/computing scenario. Standardized characteristics, can include such variables as might be found in a curriculum vitae such as educational related background (including study and/or degree related details such as type, field(s), historical timing including dates and duration such as for employment, schooling (e.g. years at a college), language(s) spoken, work background (including job title(s), salary(ies), associated dates and durations, employment locations(s) related associated facts such as associated accomplishments, e.g. meeting a dollar amount for sales, profitability, revenue, number of people managed, details related to areas of responsibility such as product and/or services categories, specific instances, and/or related info such as innovations), family background such as childhood family including relatives names, information related to such relatives), military and/or other public service background (such as rank(s), time(s) and dates and duration(s), posting locations, and/or the like. Such Repute variable characteristics and/or values, including any Cred characteristics and/or values (for example, values as may associated with a given CPE or other purpose expression for example, as value associated with having been a military general in a given military service as associated to a CPE related to military strategy determination, may be algorithmically processed and/or combined with any Cred characteristics and values to produce relative measures of appropriateness/usefulness/adequateness.

Social, commercial, and knowledge networking services are tools for users and as such they may best perform when they are structured to be specifically responsive to user purpose and have the capability to support such specification. This enables such a service to provide experience/results that are relevant and productive in contrast to simply occupying time. Enabling individuals to constructively and systematically reach beyond their milieu may enable, on the whole, a substantial improvement in the nature of social networking. Towards this end, the role of purpose domain experts and/or administrators may be key to attenuating or eliminating the stream of often marginally thoughtful and/or relevant communications provided by parties participating in chat and other group, topically oriented environments. PERCos Repute capabilities can contribute considerable advantages to participants in social networking activities, particularly in group contexts. The use of EF filtering as to facts related to an individual—that the individual is a certified plumber, an officer in the US Navy, a mathematics teacher, a physician, a theoretical physicist—can matter a great deal in how their participation affects the quality of, and whether in a given instance they should participate in, social, knowledge, and/or commercial interactions.

Repute EFs, FFs, and Cred assertions provide input information regarding individual and/or a group sets concerning how and/or whether such individual and/or group sets should participate in common purpose computing session sets, that is the quality, relevance, usefulness, and/or the like of such participation. These capabilities can significantly influence how satisfying and productive such common purpose interaction may be. By organizing participants as resources associated with purpose classes, by being able to filter individuals based on their characteristics including EF and Creds, by having purpose administrators and/or collective group management arrangements and/or the like, through which rules of conduct can be enforced, such as the nature and/or quality of communications by a participant set, so as to ensure, in a manner not dissimilar to human traditional physical interaction scenarios, that who participates is evaluated and often understood, that participant conduct may be managed when necessary, and that social, commercial, and knowledge networking is satisfying, appealing, productive, and/or enhancing, as considered appropriate. For example, a licensed veterinarian who is EF declared as a veterinarian and has received high marks through Cred assertions regarding skills in treating behavioral problems in cats is likely to be more useful in participating in a think session responsive to a CPE “‘learn’ (or ‘treat’) ‘housecat behavior problems’” than a licensed taxi driver who is more interested in discussing traffic difficulties in a big city or action movies and how they may affect people's conduct when they leave the theater and take a cab.

In some embodiments, PERCos may manage a resource type as published participant resources, such as self-Creds that include self-characterizations by, for example, a veterinarian and/or connected-Creds by such veterinarian's clinic/employer/administrator, and/or unconnected (no or minimal conflict of interest) Creds by such veterinarian's veterinary school that he/she is licensed and, for example, has further credentialed graduate work specialty training in treating behavior problems in cats and dogs. Further, Creds may be supplied regarding the veterinarian providing assertions by other EF “verified” veterinarians and/or veterinarian associated groups, and/or by asserting client cat owners and/or their, for example, EF verified cat owning clubs and/or associations and/or the like. Such Creds may be, for example, in the form of differing aggregate ratings of assertions by asserting type such that, for example, a veterinarian is rated a 7 out of possible 10 for the purpose of treating cat behavioral problems by other veterinarians, 9 out of 10 by clients, 8 out of 10 by several professors of veterinary medicine at US accredited by the AVMA (American Veterinary Medical Association), all the former, for example, in some embodiments, stored and available for Coherence processing in aggregate and/or individual instance form for each set of asserting type so that a user set can review at least in part their (the Creds) respective evaluative assertion by type characteristics of asserter.

In some embodiments, exclusion, inclusion, prioritization, and/or other evaluation of possible and/or otherwise candidate resources may be performed depending on whether one or more integrity levels for reliability of information of respective and/or groupings or all of EF types specified in a CPE set are satisfied, such that user and/or Stakeholder sets instructions (including EF types for Cred asserters, providers, publishers, and/or the like), may be performed as may be required by such user and/or Stakeholder set CPE sets, user stored preferences, user group administrator governance sets, sovereign government instruction sets, and/or the like contributing specifications. In some embodiments, such types may be declared and established as a standard, when specified by Domain and/or general experts, for example, as employed by and/or consulting to a PERCos authority/utility set and/or by one or more Domain associations (such as the AVMA) and/or the like.

Tests may be available to, and/or certificates may be provided by one or more authorities, such as a PERCos one or more utilities, and/or other cloud services, to specifically support the assuring of a user and/or Stakeholder that they may trust, that is find sufficiently reliable for a given purpose class or overall, for example, an EF type declared attribute, such as being a graduate of a given University in a given academic area having a certain degree granted on a specific date in time or the like, however single or multi-faceted. Certain of such type information, such as having an EE bachelor degree, may be standardized, whereas the naming of a subspecialty to a degree may, in some embodiments, be stored as metadata but not be standardized as a subcategory for PERCos approximation efficiency and/or other PERCos embodiment reasons. A user may have, for example, specified in their CPE set or associated purpose statement to use all primary expert defined types by averaging all specified type category scores, by averaging and processing some but separately processing one or more others as distinct input, by associating one or more weights with any of these type values, and where the types, for example, provide, for example, through a standards body or utility or commercial cloud service set, one or more specific forms of associated authenticating certificates and/or other validation for their respective types, as they may be governed in differing manners.

For example, in some embodiments, a user set may wish a breadth of applicable expert input regarding an economics related learning purpose. Such user set may then provide their specification of associated EF participant asserters as professors of international economics at accredited north American universities, staff columnists at major economics related publications (e.g. Economist, NY Times, Wall Street Journal, and/or the like), federal government economics officials, and economists at major economic think tanks and consulting firms, and/or economists at certain significant corporations, and where one or more of the foregoing subtypes may be certified for authentication by an association, such as the AEA. The AEA itself, may for example, publish resources comprising such type arrangements to enable users to input into purpose similarity matching standardized Repute attributes for optimizing the level of expert input into an economics related purpose fulfillment process. As with the AEA, other affinity groups, standards authorities, and/or other Stakeholders may publish, for example, purpose class specific expertise type and subtype arrangements, including any differing one or more weightings for such subtypes, for example, as may be related to a purpose class or expression instance. As a result, affinity groups may, for example, publish standards employing Domain or general expert characterizations that are organized in simplified, constrained choice, standardized form in support of interoperability, ease of use, and approximation computing processes. In some embodiments, these standardized type and subtype arrangements may represent implementations by experts and/or authorities of constrained category types associated with Core Purpose, other CPEs, and/or purpose classes and/or other logical taxonomic and/or ontological groupings. These constrained choice sets may, for example, function as Repute (EF & Cred) and/or other resource related characteristics employed for evaluation, filtering, prioritizing and/or other ranking of candidate resources, for example, within a specified purpose class set or other neighborhood set.

The foregoing Repute formulations may be used as contributing (or as may be edited or otherwise transformed) specification information, for example, to user sets prescriptive CPE formulation and/or to Coherence processing (and/or otherwise to user and/or Stakeholder evaluation), with such information being processed as input along with any other specified Cred and/or Aggregate Cred instances and any other CPE expression elements.

Such types can be provided, for example, in certain embodiments, by a faceting interface listing the constrained number of type options which may be selected to be used individually and/or in any collective arrangement, and which such user may be selecting from during CPE specification arrangement and/or may have been selected by a previous preference selection process associated with a purpose class and/or CPE set and/or resource set and which may have been stored as part of a user set preference set. Domain and/or general purpose PERCos specific experts may identify, based on Core Purpose, on Domain category (including subcategory) and/or on other combinations of CPE elements, what types may be logically, or with such reasonable frequency, or as sufficient as a generalizing approximation, to be available for user selection, for example, from a faceting prompt, and/or for user typed entry, and/or the like. For example, in a situation where the category is, for example, newspaper reporter or college professor, an expert group can declare x number of subtypes, such as a constrained number (e.g. 5, 12, 18, 30, or the like) different categories, wherein such subcategories may serve as sufficient generalizations/simplifications representing coverage of differing variety of associated real world types. For example, a category for Professor of Wildlife Science for EF specification purposes might include when used such real world department names of Wildlife Science, Wildlife Ecology, Environmental Biology Management, and/or the like. Such type value arrangements systematize important PERCos related characteristics enabling efficient, for example, filtering, ease of user understanding and use and their effects, and appropriate to user purpose (such as constrained type sets as determined by experts and/or authorities regarding different Core purpose or Core Focus specifications, and/or the like). The foregoing helps ensure the reliability and responsive of PERCos processes and results as relates to user CPEs, including the reliability and responsiveness of PERCos, identification, filtering, evaluation, prioritization, and/or selections processes. Such reliability, and in some embodiments, for example, supported by some PERCos embodiments as selectable of trust assurance levels (e.g. 1-5 or the like) regarding EF testing and Cred quality helps insure that the Stakeholder involved in supplying knowledge and/or experience assisting users in identifying, evaluating, and/or selecting one or more resources is sufficiently reliable for the current active purpose, such as providing a user set and a PERCos (or like) arrangement with sufficient information to enable them to, and/or have others provide, as in the cat behavior example herein, sufficient expert information regarding diagnosing and/or treating of the user set's cat so as to have an optimum Outcome regarding rectifying the cat's behavioral problem.

In another PERCos example that can, for example, be supported in some embodiments, a user may decide to initiate a relationship set where a small group of approximately a dozen users may get together to discuss near-term planet/human ecological issues focusing initially on threatened species, circumstances related to such wildlife species status, and what generally member individuals collectively and individually may be able to do help preserve certain species. PERCos embodiments, might, for example, be used in differing ways to establish such a group.

For example, the initiating user (“IU”) could define differing characteristics that may provide synergistic, complementary contributors to the group function. For example, the IU may wish to have several individuals as members who have at least MS degrees in the academic area of Wildlife Science, Wildlife Management, Environmental Science, and/or the like. Further, the IU may wish these individuals to have good communication skills. Further, the IU wants such individuals, to have a particular interest in understanding and working towards the preservation of threatened mammal species. The IU further wants several individuals who are skilled, accomplished, and financially substantial business men and women, who have the same interests as above, and have a minimum bachelor's degree from an accredited college, but no requirement that the degree be in an ecological management or science area. Lastly, the IU wants several individuals who have a minimum bachelor's degree, and substantial experience and success in working with one or more non-profit groups and achieving notable success. The IU may specify a CPE for examining specific and/or general cosmos PERCos participant resources stores using specification criteria stipulated herein.

In another example supported in some embodiments, a user set decides to initiate a small movie co-viewing club comprised of approximately 20 individuals where the focus is collaborative researching, identifying, selecting, co-attending, discussion and co-blogging about adventure movies and dramas. The group is intended to function as a collective intelligence/knowledge, evaluation, experiencing, and publishing (blogs) movie club.

In another PSNS example supported in some embodiments, a researcher decides to put-together a collective research discussion, analysis, and mutual assistance group focusing on synthetic biology as relates to human liver regenesis and/or replacement.

To provide users with evaluative and purpose-directed resource identification, understanding, prioritization, and utilization in the face of boundless varieties and opportunities of Big Resource, PERCos provides PERCos cosmos, which is an at least in part administered space comprising a set of resource objects (and may further include resource portions) and related PERCos information management systems. PERCos cosmos may be further organized according to a set of purpose characterizing, simplification structures, called Dimensions and any associated Facets. Each Dimension and Facet comprises a set of values, which in some cases, may be ordered.

PERCos cosmos, in some embodiments, utilizes a variety of standardized and inter-operable Dimensions, including PERCos Master Dimensions and associated Facets. In one or more PERCos embodiments Master Dimensions and/or their associated Facets can be used to generate subspaces of a PERCos cosmos, each of which can have its own set of structures as well as the structures it inherits from its parent space.

For example, Dimension subspaces can be defined by using one or more Facets Dimensions. Each cosmos subspace, being a space, can also have its own Dimensions. For example, a Master Dimension subspace may have further standardized and interoperable information sets, such as for example, Core Purpose characteristics, user characteristics, resource characteristics, Reputes, and/or the like.

Just as a nautical chart has dimensions, such as depths, heights, coordinates, and/or the like, to characterize depths of water, heights of land, and/or the like, PERCos embodiments Dimensions and Facets can be used to characterize resources according to their Dimensional values. For example, in some embodiments, resource Dimensions may characterize resources according to certain concept approximation properties, such as for example, but not limited to, their Complexity (Material and Functional), Integrity, Reliability, Location, Sophistication/Associated Expertise, language, Quality to Purpose, Value to Purpose, Popularity to Purpose, and/or the like. These Dimensions may be complimented by other resource characteristics, such as Role, efficiency, location, budget, time, and other metrics. Dimensions may organize such descriptive characterizations of resources so to assist in their identification, discovery, evaluation, selection, combination, prioritization, provisioning, and/or usage. They may be used to analyze for similarity and related matching, and/or the like. Like nautical chart dimensions enable users to identify different points of Atlantic Ocean and compare their relative depths and other attributes, PERCos embodiments Dimensions and Facets enable users/Stakeholders and/or PERCos embodiment processes to identify and compare resources according to Dimensional values.

In some embodiments, Master Dimension Facets are particularly useful for specifying purpose class CPEs. Facets support PERCos approximation matching where the standardized and approximating nature of Facets used in user prescriptive purpose expressions can be matched against resource descriptive purpose expressions to identify one or more purpose classes who have member resources supported by information structures which may be subject to further PERCos purpose assessment and/or selection processes. For example, user characteristics as may be expressed using Facets from user Dimensions, may enable PERCos to employ assertions of user sophistication/expertise relative to any Domain and/or purpose class set in identifying/similarity matching/assessing/prioritizing/selecting/provisioning and/or using resource sets.

In certain embodiments, PERCos embodiment capabilities are meant to be, at least in part, ubiquitously available. In such cases, PERCos embodiments contextual purpose related features can form basal capabilities of a PERCos based operating environment. These embodiments can transform the nature of operating systems by establishing a new form of relationship between users and resources and their possible use, and may fundamentally alter the nature of a broad spectrum of computing activities. In these PERCos embodiments, contextual purpose features can be deeply interwoven with operating system and other operating environment resource management capabilities and services. This can enable users to have uniquely unified, relevant, and purpose-optimized views into session relevant candidate resource sets. These capabilities are particularly valuable when users are attempting to identify/employ resources outside their personal areas of particular expertise and command, and/or when users are extracting resources from web Big Data/Big Resource arrays.

With current technology, resources are generally segregated as different, separate things. While, for example, tags and/or full text abstracts may be used to indicate attributes of possible resource items, and clustering, semantic search information, and classification ontologies give certain user fields of view into resource subsets, there is no unified system, in particular Big Data system, that treats resources as atomic elements that are operatively responsive, as one or more resource sets, to at least substantially standardized, contextualized situation/instance-specific user purpose specifications. PERCos's unified system contextual purpose based view into candidate resource sets—complemented by certain key inventive PERCos attributes and attribute combinations, e.g. without limitation Repute, purpose class and other neighborhood ontology and taxonomic groupings and Domains, standardized purpose contextual Dimensions and Facets, and aggregate common purpose computing resolving such as performed by Coherence services—optimizes the efficiency and purpose appropriateness of a user's insight into resource and resource portion availability. It further optimizes resource provisioning and usage management through PERCos user purpose/resource expressions and resource and resource portion organization, matching, filtering, prioritization, cohering, combination, provisioning, and usage management. As a result of these capabilities, PERCos can transform and expand the disordered array of Big Data into a component area of Big Resource, comprised of ordered, purpose systematized, user current purpose responsive, component sets of PERCos operating environment arrangements.

PERCos in some embodiments supports a triality of (a) users, (b) resource value chain members, and (c) Repute asserters and fact declarers, the foregoing declaring their respective, operatively intersecting Contextual Purpose Expressions—which CPEs are in such embodiments comprised of at minimum, a duality of verbs (and/or inferred verbs) and categories, and which expression arrangement support a powerful triality of verbs, categories, and other contextual Dimension information, including Facet simplifications/approximations. This provides an effective purpose process resource framing and user cross-edge approximation computing capability set. For example, PERCos employs in some embodiments, at least in part key user purpose specification standardized and interoperable Core Purpose approximation simplification and approximation capabilities, further standardized approximation Dimensions and Facets, purpose class memberships and applications, resource relational neighborhoods, Repute evaluation/filtering/and prioritization, and common purpose computing Coherence resolution, provisioning, and usage management. These capabilities can be complemented by cross Edge user/computing arrangement dialogue capabilities for purpose expression—including resource selection—and/or resource utilization for session specific purpose fulfillment such as user purpose related knowledge enhancement and/or experience unfolding, including initiating and/or interim and/or Outcome purpose processes. This dialog can take the form of use of, for example, proffered resource instances and/or session specific resource Frameworks that provide user/computing arrangement purpose fulfillment scaffolding in the form of specific to purpose arrangement of resources, explicitly, by Role, and/or the like, and, for example, provisioned as a user purpose fulfillment environment set.

Through, at least in part, the standardized purpose expressions of the triality of users, resource value chain members, and Cred asserters, PERCos parties, combined, for example, a duality or triality of purpose expressions, enables far more effective and informed presentation of candidate purpose fulfillment arrangements compared with current technologies, particularly when drawing results from web based Big Data, or PERCos Big Resource or when involving resource instances that belong to domains with which users have limited or uneven expertise, that is having a limited capacity to point at (search and retrieve) truly optimal resource sets. PERCos, as such, provides unique, practical Big Data management and resource utilization solutions—though in some embodiments extended beyond Big Data to Big Resource—for example, as when using PERCos resource to provide purpose related computing environments, such as when using Frameworks involving disparately published, complementary resources, such as people, services, applications, information sets, devices, and the like.

Using user prescriptive interoperable Contextual Purpose Expressions as specifications to be matched against published resource descriptive Contextual Purpose Expression specifications (both direct CPE specifications for resources and referential Repute assertion, effective fact, and faith fact CPE specifications), PERCos can transform the nature of user relationships with Big Data as well as enlarging it to relationships with Big Resource, fundamentally altering the productivity of resource usage under many circumstances.

PERCos purpose matching with resources occurs directly and/or through intermediate use of one or more PERCos Purpose class ontologies and/or other information organizations. With PERCos, users relate to Big Resource by framing their needs in simple to more descriptive prescriptive purpose compositions, followed (as appropriate) by unfolding cross user/computing arrangement dialogs that orient Big Data and other Big Resource resource inspection through the relating of commonality of purpose (and optionally, other context/descriptive information, related to one or more users (and/or user group(s)). This integration changes the relationship between users and candidate computing arrangement resources. In some embodiments, PERCos supports the assessment and deployment of a new, much broader and more flexible concept of the nature of, and user relationship with, computing related resources, by organizing large, distributed and highly diverse data, services, software, participants, and/or physical resources into functional purpose fulfilling groups.

By providing means to optimally match potential resources to current user purposes, that is the one or more purposes contemporaneous with a current computing arrangement session, computing environments will be enable users to acquire, and/or shape, computing resources so as to specifically reflect and support their user purpose fulfillment. Rather than a user having, for example, nebulous relationships with possible resources, where resources are returned in response to key words rather in response to the actual, intended purpose of the resource set use, candidate resources are evaluated as to their capacity to optimally satisfy a user learning, discovery, and/or experience process set, that is the returned resources are considered a domain of user activity rather than an explicit one or more items to be retrieved. As a result, the nature of the user relationships to potential resources, including the full spectrum of resources that could be practically employed, may be fundamentally altered and improved, in particular when the user is not specifically pointing to, that is, specifically requesting/identifying, an explicit one or more particular resources, or if so performing a search and retrieval, when the user's request is insufficiently informed to best fulfill the user's underlying purpose(s).

Through tools that employ contextual purpose standardized and interoperable expressions, including, for example, purpose related resource set identification, filtering, selection, combination, prioritization, provisioning, and/or usage process management, user resource assessment and user/resource interaction can be inherently influenced, that is directed or otherwise at least in part guided, by such purpose expressions, which may be further combined with related contextual input as well as with user history and crowd behavior and related data and/or events.

With PERCos, resources can represent more than data that is executable by a computing system in the form of applications and/or associated information. In some embodiments, PERCos resources and PERCos operating systems and other environments represent a highly flexible, considerably broadened notion of resource management, identification, evaluation, and utilization where resources may—but are not required to—comprise the entire universe of possible, processable information types, including information that stands for, that is acts as descriptive, interface, and/or control proxies for resource items that reside in the physical world, including, for example, other people, and including interface control information for physical devices that can be directly or indirectly at least in part controlled by users through PERCos purpose fulfillment influenced or controlled processes.

In fact, through PERCos, as in everyday life, purpose fulfillment and resources are ultimately, frequently inseparable in the human mind. Following this principal, users, rather than being contained within silo configurations of current task execution applications and cloud services such as Word, PowerPoint, Google, Yahoo, Wikipedia, or Acrobat—can characterize their dynamic purpose (that is their current purpose) with an expectation that responsive resource sets in any reasonable combination, for example, published as sets, will be identified, filtered, evaluated, selected, prioritized, combined, provisioned, otherwise organized, and/or used, in a manner responsive to satisfying user purpose(s), that is helping users determine and/or computing arrangements calculate “best” available resources as individual items, or as sets, for example, in the form of purpose class application environments. PERCos, in some embodiments, can present an at least in part digital environment for user specific purpose quest unfolding and/or enhancement and/or fulfillment. PERCos, in some embodiments, can function, for example, as a portal to any and all PERCos compliant and/or otherwise interpretable resources, including PERCos resource items that have operatively (that is sufficiently or fully) unique one or more identities and associated one or more purpose expressions, purpose classes, and/or other meta data including broader context data use/purpose pertinent information.

Some important PERCos methods sets supporting PERCos exploration and/or discovery, for purpose refinement, and/or unfolding resource exploration, are for example, associated respectively with one or more of: purpose resource publishing, certification, authentication, other integrity processes, Repute purpose value rating, and purpose expression including other meta data specification, including, for example, purpose class specification, governance value chain features (subscription, advertising, societal and other Stakeholder governance, other rights management associated with prescriptive and/or descriptive purpose(s)) and/or PERCos resource Instances), and/or the like. These PERCos capabilities provide specification instances supporting, for example, purpose matching/identifying, filtering, selecting, prioritizing, combining, cohering, and/or the like, of multi-party purpose attributes/requirements—both user and Stakeholder, and form key capabilities in the formation, and evolving, at least in part in some embodiments, of self-organization of a purpose cosmos comprising a PERCos web arrangement.

For example, PERCos embodiment compliant resource sets, may, so long as such sets are cohere able where there are combinations, be activated, and further controlled over time, in a manner responsive to applicable, cohered, purpose expressions functioning as a common purpose set of operations, for further example, as such purpose expressions may represent an evolving sequence of unfolding user knowledge enhancement, discovery, experience processes, and/or results observation (whether direct or indirect).

In some PERCos embodiments, there may be several kinds of expressions that may be combined (along with any relevant other contextual, relevant information such as metadata) to provide a composite expression of user purpose. These may include for example:

And any combinations of the foregoing.

In some embodiments, during any of the foregoing operations, one or more new resources (including, for example, specifications) may be created through, for example, one or more instruction based processes, including, for example, instruction sets resulting from the use of purpose class applications, where user PERCos purposeful activity portions, extracted information, and/or derived information may be combined with any instruction set arrangement, with the results published, or otherwise retained, as a PERCos resource, which may be associated with purpose expression, purpose class, resource and/or resource lass (including, for example, any participant and/or participant class), Domain/category class, external to PERCos one or more classes, affinity groups, crowd groups, and/or the like.

Human purpose expressed across the Edge can take the form of an unfolding process where user output to computer (computer input) and output from computer to user (input to user) are dynamically interlinked and encompass a cross-time dialog and/or set of observations, an interactive flow of input involving both users and their PERCos computing arrangements (and any PERCos and/or otherwise complementary services) functioning as session interacting “actors.” For Example, such interactions may occur during purpose unfolding for purpose fulfillment, including purpose related learning, exploration, discovery, and/or event and/or user observed based interim results.

These cross-Edge interactions may span one or more sessions, that is the user/computer arrangement PERCos dialog may be paused/interrupted, and may be continued at a later time and/or at different PERCos node one or more locations.

Within such PERCos sessions, computer domain operations may include computer side PERCos supported processes that, based on historical user information, expert system operations, and/or artificial intelligence and/or the like, at least in part anticipate user/computer priorities as may be associated with user(s), purpose(s) and/or may include support for user/system interactions complemented by, and initiated at least in part by, artificial intelligence interpretation of user purpose related actions such as CPE specification and/or purpose class application user interface input, and where such AI and/or the like processes may further interpret information regarding user stored profile (including, for example, preferences) and/or historical use in general and/or as associated with one or more purpose classes and/or user specified CPE, as well as input related to one or more purpose classes and/or CPE set and/or in general derived from crowd, participant class, affinity group, profile and/or preferences, and/or other like input.

In some PERCos embodiments, one or more resources may assist purpose operations through recognition of informational, sequential, and/or temporal patterns involving user and/or user group input(s), and/or reading and interpreting user and/or at least an additional portion of a user group biometric information such as facial expressions, breathing patterns, voice amplitude, cadence, and/or frequency information, orientation and/or other physical positioning information between/among session participants and/or visual and/or other recognition of objects in a user computing arrangement and/or at least a portion of any change to such computing environment. Such information may also include provision of notices, reminders and/or other information in advance of one or more deadlines and/or other sequential and/or temporal events.

In some embodiments, a shared purpose expression is a specification of purpose agreed to by a group of users. shared purpose expressions may be used in one or more shared purpose sessions (for example, including the session in which the shared purpose expression was created and maintained), they may be published for later use by said same group, and/or they be publicly published for use by one or more specified affinity groups, participant classes, associated with and/or as a member of a purpose class set, and/or the like. shared purpose expressions may be created by one or more parties and then published to an affinity group set, participant class set, or universally, whereby it may attract other prospective users to shared purpose, common purpose computing session, or to a shared purpose distributed/aggregate session set where parties participate in such PERCos sessions (or parts thereof) independent of some or all other participants, but where one or more aspects, including, for example, results, are at least in part shared and comprise a shared Outcome, optionally with shared interim results. Shared purpose expressions may occur in a shared PERCos session set as shared purpose expression portion sets that specify differing roles for each participant set. Such shared purpose expressions and any associated shared purpose expression portion sets, may be memorialized at least in part in a legal agreement set that may stipulate sharing rights of participants sets to Outcome and/or interim results, including financial compensation for time invested, resources contributes, or the like, in respective participant/User set work related to such Outcome and/or interim results, creation rights, publishing rights, and/or value of at least certain aspects of Outcome produced.

In some embodiments, PERCos shared purpose sessions may comprise resources and users with standardized, interoperable purpose expressions which are resolved so that users may learn about and/or discover resource sets and/or resource portion sets and interact with other users having the same or sufficiently similar (by specification) shared purpose, and/or interact with other users and/or Stakeholders having an interest in such resulting resource and/or resource portion set. Because of users' varying contexts, and/or because of the approximation computing nature of user CPEs and the secondary differences that may exist between users employing the same CPE, different user sets results sets may differ leading to differing user experiences and/or other Outcomes.

In some embodiments, PERCos enables groups of users to declare and/or discover shared purposes. For example, a user may wish to declare their interest in a purpose, for example, fishing, home digital audio distribution, cooking Cajun food, and/or the like, and wish to interact in some fashion with other participants, perhaps unknown to an IU, regarding this common purpose, such as viewing and commenting on a movie together, sharing music with one or more people, and/or the like. For example, someone who has more expertise than the IU may be a desirable PERCos session companion (for example, along with using, for example, purpose class application tools supporting such sharing, for example, simulcast video and audio conferencing, texting, chatting, and the like). This may include, for example, identifying someone to help an IU set with a task such as a chemistry experiment, collective writing of one or more blog articles, replacing a hard drive in a notebook computer, singing in a music chorus, and/or playing in a band with the participants physically distant but sharing a common purpose computing session, and/or the like.

In some embodiments, shared purpose sessions may be interactive, for example, with users interacting with at least a portion of the same resources associated with shared purpose expressions for the session. In some embodiments, this may involve one or more publishers who have published resources for shared purpose sessions (individually and/or in groups). Users may elect to create resources that are specifically for one or more shared purposes and thereby act as publishers. Shared purpose class applications may be published as environments for users/participants to pursue shared purposes.

For example, in some PERCos embodiments, one aspect of shared purpose is social interactions and potential bonding through expressions of shared purpose and/or through sharing experiences during a common purpose computing activity. One or more users may dynamically undertake purpose operations within, for example, a shared purpose session, and may be subject to other user set preferences, for example, regarding interactions with other users and/or resources. Such dynamic activity may spawn event messages to other candidate one or more session users (and/or automatically provision a user set) and/or users, individually or collectively through, for example, polling, may decide to share at least a portion of their unfolding experiences in the form of a user set joining an in progress PERCos session, and/or recording, for example, and publishing as a resource, for a further user set session activity and/or results and providing such information to a user set. In such an example, as with earlier examples in this section, users may benefit not only from those resources associated with a purpose class and/or being sufficiently similarity matched with a user Purpose Statement and/or CPE, which, for example, might be augmented by other contextual information such as shared (and/or complementary) preferences, profiles, PERCos history information, and the like, but additionally benefit from other users' and/or Participants perspective, interactions, commentary and/or narrative associated with operations within that shared purpose session.

During and after such operations one or more users may establish relationships with other users, such as, for example, forming bonds associated with one or more purpose classes, resource classes (for example, participant classes), which may lead to further common benefit, social integration, and/or purpose satisfaction/fulfillment. For example, in some embodiments, one or more users may wish to create an affinity groups, such as, for example, a modern jazz appreciation group comprised of individuals who have moderate experience with modern jazz and enjoy it greatly and, who have graduate degrees in sociology or also enjoy Cajun cooking, and such participants, as users, may use PERCos Repute tools, PERCos identified other resources, and each other, to collaboratively, collectively help learn about and discover Modern Jazz and Cajun cooking, infused with an understanding and/or study of, for example, related sociology theory and related culture, such as cultural background for Jazz in Louisiana. In some embodiments, affinity groups may be based on shared purpose expressions such as shared purpose classes which may involve synergy complementary elements, forming potentially complex relationships of users and/or groups with resources—including participants who may become involved as users—the foregoing which may be associated with an expressed shared purpose specification set.

PERCos purpose expressions specification arrangements in different embodiments may take differing forms. Consistent among these embodiments are the principles of simplification of expression, where such expression may take the form of an approximation of such user purpose to facilitate efficiency of processes and the learning, experiencing, and/or discovery processes that may unfold responsive to such expression specifications.

PERCos operating environment/system may provide for the specification (and/or inferring) of verb and category sets, which may be interpreted in combination as Core Purpose Expressions. Some of these embodiments may be support the use of certain grammatical, clarifying elements such as prepositions and adverbs (particularly as constrained in variety as logically applicable to specific Core Purpose or other CPE sets), and may further support the specification of additional clarifying elements, including various situational and other contextual characteristics, such as in the form of other Master Dimension Facets and/or auxiliary Dimensions and/or the like. For simplicity of operation as well as standardization/interoperability management, options available in each grouping of characteristics or characteristic/subcharacteristics may be in constrained to limited list option sets, where such limited set of characteristic options facilitates easy of choice by users of logical and/or frequently applicable choices for purpose approximation representations and/or metadata matching. In some embodiments, synonym sets associated with specific such constrained list members may be user viewable for some or all of such members to inform user understanding and/or guide user characteristic selection for PERCos purpose expression, and/or usage of any of such synonyms may be automatically or with user approval, translated to the operative synonym terminology.

PERCos embodiments may employ differing expression approximation simplification schemas. For example, PERCos embodiments may provide for the separate specification of verbs and Domain categories (where categories, for example, may be organized in a manner comparable to DMOZ categorization hierarchical arrangement). Such embodiments might, for example, first, or simultaneously with category selection, present a faceting verb selection interface (or vice versa a Domain category faceting selection interface then a verb faceting interface). In such embodiments, for example, a user might select one or more categories and/or subcategories from an unrestricted, or restricted to logically consistent/appropriate, choice set. After completing such verb and Domain category selection, with or without additional selection or other entry of prepositions, adverbs, and/or the like, in such embodiments, the user would have specified a Core Purpose set employing standardized, interoperably interpretable expression elements and combinations and representing a Purpose approximation.

In PERCos embodiments, various Core Purpose supplementing approaches can be adopted where such approaches employ similar but differing purpose expression concept simplification schemas.

In one embodiment set, for example, Core Purposes are supplemented with other principle simplification characterizations provided through a Master Dimension/Facet arrangement, which may be further or alternatively use an auxiliary Dimension approach. In this embodiment set, Master Dimensions are comprised of standardized characterizations complementing Core purposes (which can also be defined, for example, as Master Dimension characterizations). These further Master Dimensions are grouped in principal, logical simplification, vector characterizing groupings.

Master Dimensions are comprised of Facets and any associated specified values. In some embodiments, these Core Purpose logically complementing Master Dimension groupings may be comprised of, for example, the categories of users; resources; Reputes knowledge/expertise/opinions assertions and Effective and Faith Facts regarding resources; and special Facets (e.g. icons and/or other symbolic or short-hand notions representing any Master Dimension and associated values expression set). Such Master Dimension Core Purpose and Dimension Facets are used to express purpose approximation components that, when combined with Core Purpose specifications, can be used for identifying, evaluating, determining, prioritizing, combining, and/or provisioning resource instances and/or neighborhoods and/or their members, such as, for example, identifying and provisioning for user inspection, for example, through similarity matching and prioritizing, most relevant one or more purpose classes, resource members sets, and/or resource instances (when not calculated after determination of class, neighborhood, or other grouping membership).

Supplementing these types of Master Dimension approximation embodiments, further or alternative specification in some embodiments may be made in support of further identification, evaluation, determination, prioritization, combination, and/or provisionment of class member resources and/or resource portions of resource neighborhoods, such as purpose classes sets, identified, for example, through use of Master Dimensions and Facets. In this embodiment or use case set, users and Stakeholders may specify auxiliary Dimensions. Auxiliary Dimension represent interpretable specifications which are not based primarily on standardized, interoperable lists of component elements used in defining purpose approximation neighborhoods, but which groupings may each represent open arrangements of interpretable element sets that may, for example, be used in similarity matching and filtering of purpose class or other neighborhood members and/or portions thereof. Auxiliary Dimension open specification instances may be inefficient and/or inappropriately specific when applied, under certain circumstances, for example, to identifying and/or evaluating items within Big Resource or Big Data to determine candidate groupings of resources, but auxiliary Dimensions may provide purpose specifications that are more appropriate under some embodiments or circumstances when applied to purpose approximation class or other group member sets to resolve in accordance with more specific user or Stakeholder specified criteria to specific resource instance results. Such auxiliary Dimensions of open specification arrangements of interpretable elements are organized in some embodiments in logical groupings and may be further organized with certain simplification subsets, the foregoing for assisting users and Stakeholders in understanding, selecting, and/or organizing such criteria representing contextual and process optimizing user and Stakeholder selecting/filtering/evaluating parameters.

In some PERCos embodiments, CPE specification interfaces may employ supplementing and/or alternative Master Dimensions arranged as groupings of controlled vocabulary choices where such Dimension groupings directly contain alternative user choices, versus representing Master Facet types (Core Purpose, user, resource, Repute, special symbol). For example, some embodiments in such expression simplification arrangements may provide controlled vocabulary instances representing choices available under certain specific Dimension types, such as, for example, some set of data characteristics; Roles; relationships among or between; tests and routines; resource items; quality of experience; modalities; and/or the like. One or more of these choice sets may itself have its options organized by class and/or other category structures to enable easier user navigation and choice if the choice set is sufficiently large. These choice sets may be organized in a manner comparable, for example, to the organization management that may be applied to Domain category choices. As with some other embodiments of PERCos, these embodiments may use user faceting interfaces to allow choices, based upon prior specification elements and/or user and/or crowd behavior patterns/history where faceting choices in any given selection column may be constrained by that set which is logically sensible and/or significantly likely as, for example, selected by one or more general and/or Domain expert and/or authority sets. Such a user interface can allow, as also may be supported in with choices within some Master Dimension embodiments, the toggle selection between a logically constrained set of choices derived as a subset of the full constrained vocabulary list for a given Dimension, and the full constrained or alternatively constrained vocabulary to allow users and Stakeholders to alter the logically available choices in other one or more Dimensions so as to evaluate the impact on user choices and to, for example, allow user choice between simple, versus more choice selection variety, such as choice between simple, moderate, and extended faceting list choice complexity arrangements. Custom constrained vocabulary sets may be specified by Participant sets, including, for example, affinity group sets. Such alternative controlled vocabulary arrangements may also, in some embodiments, be used for portions, or in some embodiments for all, for example, of auxiliary Dimensions user purpose expression specification interfaces.

Such a more elaborated category oriented design might be used in arrangements, for example, having fairly extensive choice selections under some or all of the Dimension category types, and can offer a differing perspective on user simplification specification sets for purpose approximation. This kind of arrangement may provide for more extensive, standardized resource characterization flexibility and may, under some circumstances, be more responsive and efficient for users than embodiments using free form parameterization to identify specific, purpose responsive resources, though these embodiments may be less effective in characterizing purpose approximation for identifying purpose neighborhoods. These embodiments may have, for certain examples, usefulness in arrangements, or circumstances, where direct similarity is evaluated against resource instances, but given quality of experience, modalities, and/or certain other variables, may be less efficient and beneficial in use for similarity matching with purpose approximation sets such as purpose classes.

In another PERCos embodiment set, CPE specification may employ Core Purpose specification through the use of standardized, constrained lists of verbs characterizing an intent perspective regarding activity type, and category arrangements, for example, structured in a manner comparable, or otherwise similar to, DMOZ. In this embodiment set, Master Dimension simplifications might be organized as verbs, categories, characteristics, focus, perspectives, tests, and Reputes. Other, further Master Dimensions might be employed representing “interactions” and/or “governance and rules” given the importance of interactive relationships and processes in the emerging connected world (or this Dimension might be a part of, for example, “perspectives”) and given the importance of automating processes and enforcing governmental/societal/affinity group rules and results/consequences (or this Dimension might be part of, for example, “characteristics”). As with the other described embodiment examples, these Dimensions are meant to comprise a logical groupings set that users can readily relate to as conceptually related organizational purpose specification simplification arrangements and where such Dimension choice structures, in some embodiments, are comprised of constrained sets of options to ensure reasonable simplicity of operation and where such constrained sets may, at any given point in a sequence set, may be limited number of logically related choices, including, for example, limited value selections, as determined by general and/or Domain experts and/or authority sets and to be appropriate for simplification, approximation, and/or efficiency reasons.

In some PERCos embodiments the notion of Concept Description Schema (CDS) is employed through, in part, the use of Dimension, Facets, and their instances and any associated values. CDSs are multi-dimensional spaces used for organizing concepts, for representing their similarities, differences, clustering, graphing, nearness analysis, and otherwise for providing elements for communications and evaluation. Its primary role is providing expression elements for PERCos environment participants to articulate purpose orientation characterizations—CPEs—for framing the foundation for a PERCos session and for making associations with resources that can contribute to PERCos sessions interim results and/or Outcomes. These structures support the identification, evaluation, prioritization (as used herein including, for example, ranking), selection, combination, and/or provisioning of resource sets and/or portions thereof, and associated user purpose orientations through the matching analysis and/or other association of CPEs (framing purpose expressions and/or purpose statements) with resource sets. All of this may involve generated, constructed, and/or identified elements matching and/or contributing to an appropriate user purpose fulfillment processes, including, for example, CDS facilitated information retrieval, unfolding multi-media entertainment, business productivity purpose class applications and other Frameworks, human interaction contexts, and/or the like.

Both for intellectual control, logical relational processing, and for implementation efficiency, in some embodiments, CDSs may be grouped into Dimensions (as with Master Dimensions described herein), which in certain embodiments may consist of a cluster of Facets that are conceptually more closely related to each other than to other Facets; in some embodiments, Facets may themselves be further structured into subfacets (and subsub Facets . . . ).

The specific structures described herein represent logical, and in some instances, compelling simplifications for purpose approximation. They facilitate functional and/or purpose optimization (of both users and Stakeholders); while these structures are not specifically, uniquely determined by the structure of the universe, by the natural language used, or by the way the human brain works, they are informed to one or another degree by each of these considerations, and normally are particularly informed by the nature of modern human behavioral and conceptual proclivities. In particular, the number of levels of subdomains within a domain involves two trade-offs: breadth vs. depth (more terms per level vs. more levels) and generality vs. specificity (a few broad classifications vs. many very specific ones).

There is significant correlation between terms employed by Facets in the exemplary Dimensions, and PERCos uses of grammatical parts of speech (in English): verbs and verb equivalents (as well as inferred verbs) typically involve verbs or verb like phrases or comparable actions; categories, nouns or noun phrases; characteristics, focuses, and perspectives, may, in some embodiments, employ adverbs, adjectives, and/or adjective-like constructions; tests, verbs or verb phrases; Reputes, standardized PERCos qualitative representations and associated information. However, this is in a matter of choice, as Master Dimensions employ verbs, categories, users, resources, Reputes, and symbols, and other embodiments may employ other simplification strategies.

For purpose approximation, in some embodiments, most of the benefit to a user from a specification standpoint comes from relatively coarse, approximating classifications, rather than highly-detailed schemes developed for information professionals, such as the Library of Congress Classifications, though certain CDS implementations, particularly certain use focused implementations, may have further levels of sub-domains.

The simplification groupings and other features of these embodiments may be in part or whole combined, that is their purpose simplification Dimensions and any associated features may be employed, as perspective specification tools, in any desired combination, using the same, or operatively similar, conceptual groupings.

PERCos compliant computer applications, such as purpose class and purpose class applications and non-PERCos resource applications employing a PERCos plug-in set and/or employing integrated capabilities made available through, for example, an API, may incorporate purpose language expression and interpretation capabilities for use by one or more users and/or Stakeholders and/or their computing arrangement(s) to specify and/or interpret a purpose expression or statement set in a manner consistent with context, purpose focus, interim results, Outcomes, and/or user experience set associated with the associated underlying purpose application design.

Purpose expression languages may have one or more vocabularies, which for example, may be segmented and/or combined to provide context appropriate purpose expressions and associated vocabularies to users and/or Stakeholders.

Purpose expression languages may include capabilities for interaction of users with “real world” tangible processes and resources, for example, physical transport, autonomous and semi-autonomous machinery, existing and legacy automation systems and/or other real world physical resources such as real world capabilities employed in manufacturing and/or services (e.g. production line provisioning and/or control, electricity provisioning and/or generation control, water provisioning and/or storage management, temperature control, knowledge/help and/or administration activities, and/or the like). purpose expression languages may include terms that reflect the real world, and provide support in some PERCos embodiments, for example, to interact with real world environments such as communicating with computing arrangements involved in electrical grid transformers and electric transmission systems, enabling real world physical resources to become part of, or be otherwise influenced and/or controlled by, a purposeful system such as found in the form of PERCos embodiments.

In some embodiments, PERCos purpose expressions include Core Purpose expressions, which comprise verb and category sets. Core Purpose Expression instances support effective, efficient and interoperable interactions of users across the Edge for purpose formulation, resolution, and/or results. Such Core Purpose Expressions can form a first order simplification that represents user objectives sets stated in a simple, high level form, and comprising of one or more verbs representing an action perspective set, and one or more categories representing a subject set. For example, the verb Learn might be combined with the Domain Science/Physics/Astronomical, or Perform Vehicle/Engine/Repair & Maintenance, or Consume Food/Chinese, as high level Outcome purposes, where resources such as corresponding purpose class applications appropriate to these desired purposes may be arrayed for user evaluation, selection, provisioning, and usage, and where such purpose class application interfaces may guide users to satisfying Outcomes, including, for example, specifying Consume Food/Chinese might use the users request and prompt, for example, with a faceting engine, for contextual information orienting to a more specific Outcome type such as healthy (e.g. low fat), whether at home or as a guest or at a restaurant, physical location, price, spiciness, regional type, ambience, parking, hours of operation, length of time in business, and/or Repute variables, and/or the like. In such instances Core Purpose Expressions may result in a user being presented with purpose class applications, where such one or more applications specialize in supporting, or are flexibly adaptive and can specifically support, the user sets specific Outcome type. A Core Purpose Expression may be represented by, for example, a standardized symbol that corresponds to its purpose. Purpose class applications may use such a Core Purpose symbol as part of a symbol representing a publisher's or other Stakeholder's specific instance of such an application, assisting the use in making a logical association to a purpose class application a simpler, more intuitive process.

Verbs and verb equivalents may function as key elements in the specification of purpose, since they express intent generalizations that can be associated with “things,” such as PERCos Domain categories. In some embodiments verbs may be organized into lexicons to provide users/Stakeholders with means to effectively identify and/or express their purpose approximation. In some embodiments, such lexicons may be significantly limited in quantity to comprise, for example, some tens of verbs such as approximately forty, or eighty, one hundred twenty; in some other embodiments, verbs may be limited to hundreds of verbs as a constrained verb vocabulary. This limitation of available verbs may be implemented in support of approximation learning, standardization, interoperability, efficiency of operation, and/or ease of use of user of at least a portion of a PERCos embodiment interface and/or ease of user understanding and/or use of and/or relating to verb specification options. Such limiting of verb choice variety to, for example, optimize standardization, interoperability, simplification, and/or purpose expression approximation may be presented for specification purposes, for example, as a capability of a faceting interface, whereby for example, a finite list of verbs is presented to a user or user group as a faceting scrollable option list, and for example, where such finite list may be visually expanded by, for example, cursor movement over a given verb to display a list of its operative synonyms, which such synonym list may form a verb purpose class perspective simplification associated with such given verb. From such a faceting constrained list, for example, a user may, for example, select one or more verbs and associate these, for example, by then using other aspects of such a faceting interface to view Domain category list(s), including any subsequent category refinement lists, for noun selection. Since learning and discovery are often concerned with arriving in resource neighborhood comprising suitable or best practically available resources to support user purposes, constrained verb lists may provide highly effective approximate conceptual perspective positioning when conjoined with Domain category information.

In some embodiments, such sets of verbs may be presented to users and/or Stakeholders in lexicons, such as, for example, simple, medium, advanced and/or these lexicons may be specific to one or more purpose classes and/or Domains categories and/or resource classes and where such lexicon variety may be a user interface and/or programmatic choice for users and/or Stakeholders. Lexicons may include, for example, automatic scaling, ordering, priority and/or other organizing principles, which may be, for example, resource class sets such as purpose class, Participant class, Domain class, Repute class, resonance class, and/or context specific set associated.

In some embodiments, verb set lexicons may comprise verbs that have associated classes with members comprising other associated verbs, for example, verb class “Learn” may comprise members “Understand, Train, Educate, Absorb, Study, Master, Familiarize” and/or the like, which may comprise purpose approximation simplification conceptual perspective synonyms. These verb classes may be extensible and/or ordering of verb members may determine priority and/or other metrics. Affinity Groups and standards bodies such as purpose class, Domain class, standards, and/or utility institutions and/or the like, including, for example, Domain society groups (e.g. ACM, IEEE, NSF, and/or the like), for profit corporations (like credentialing and security companies such as Symantec Corporation), or public utilities (such as publicly owned electricity utilities), governments, and/or the like, may manage and standardize verb lists for PERCos embodiment purpose approximation and Core Purpose Expression.

In some embodiments, PERCos categories may reference one or more verb lexicons, which, for example, may comprise verbs constrained by verb-category pairs that are in widespread use. For example, verb “Eat” may not be generally associated with category “Motorcycles” but may be associated with category “Fish”. Faceting “intelligent” user interfaces in some embodiments may organize choices as may be appropriate for approximation computing, and for example, a Domain category and any further subcategories may be first selected followed by a constrained list of standardized verbs that are logically appropriate for the category (similar pair associated verb/category lexicons may be employed in embodiments when the system and/or users first identifies a PERCos category set, including, for example, a Domain category set, and where only logically appropriate one or more verbs from a PERCos verb lexicon are made available for evaluation and/or selection). In some embodiments, there may be an “override” capability allowing users and/or administrators and/or some other authority to enable the use of an expanded, or unrestricted, verb list and/or direct entry, of one or more verbs by a user, this functioning as a less or unstandardized verb expression capability set that may complement general standardized lexicons, including constrained lists as described. These expanded or unrestricted verb expression capabilities may be less efficient, and have functional limitations from an interoperability standpoint, but when used with well-designed synonym lists, may allow for more natural user expression and may provide adequate matching capability to the classes and/or individual instance sets of resources, purpose expressions, CPEs, purpose statements, participants, and/or the like.

In certain embodiments, PERCos verb one or more lexicons are at least in part determined by general knowledge, Domain category, and/or purpose class experts. Such lexicon determinations may supplement a standardized, general, common purpose base lexicon (and/or base expertise level such as a base medium sophistication level for a given purpose class and/or Domain category class set). Such experts may be employed as consultants and/or employees by such affinity group and/or standards groups and/or web service companies as and/or may be contributors to the standards activities and/or knowledge base sets of such groups. Such experts attempt to, given their insight into the nature of use of verbs in their Domain and/or purpose classes, define a constrained, standardized list and/or relational arrangement, which can be used, for example, in support of user and/or Stakeholder Core Purpose Expression and/or other CPE specification activity in PERCos purpose approximation and approximation related learning for similarity matching and other shared and common purpose computing functions.

In some embodiments, user histories, historical crowd behavior in general, and/or as associated with a PERCos class set, may influence and/or constrain lexicons and/or the ordering of verb alternatives, such that users may be presented with a more effective, constrained and/or ordered verb (and/or respectively, Domain category) selection interface. In some embodiments, instances and/or classes of participants, affinity groups, Stakeholders, societal/governmental groups, and/or the like may create for their own use, for example, for parties for which they have a responsibility (such as employees, citizens, members and/or the like) and/or for wider publishing, lexicons that they have modified from a PERCos standard lexicon and/or which they have originated. PERCos standards bodies and/or other governing organizations may constrain who may create lexicons and/or associate rules of governance with any such lexicon so as to have a sufficiently ordered and/or interoperable and/or efficient PERCos cosmos, or set of cosmos purpose, Domain category, participant, broader or differently oriented resource, Repute, and/or the like embodiment classes or other ontological groupings.

In some embodiments, PERCos provides one or more Domain category and/or global category arrangements and/or combinations of the foregoing for purpose specification and operations. In some embodiments, category class structures like those described by Dmoz may be employed, such category organizations being presented to users, for example, by faceting interface arrangements that allow easy access to specific subcategories, such as selecting Science/Physics/Nuclear/Theoretical. Higher order categories may be represented by symbols, for example, where any such icon could be selected to bring an individual to a specification point in a category/subcategory sequence. For example, the symbol for Nuclear might be a small impression of a molecule while baking might show an icon image of a cake or pie. Such icons could be available for quick access and organized by users to reflect their interests and areas of focus. A user or Stakeholder selecting an icon could, for example, insert it into a CPE and/or open a faceting interface where the users could then select one or more subcategories for use in a CPE, or, for example, employ a stepped, further refined selection process.

Domain category selection supports user and Stakeholder expression of interoperable, interpretable, standardized Core Purpose and other CPE specification processes, as well as in some embodiments supporting similarity matching operations between user purpose expressions associated with any Domain category specification set which may be absent verb sets, that is absent Core Purpose set specification, and where, for example, verb sets are inferred from other context, history of like category user activities, and/or the like, for example, someone who owns home that is already landscape and has been using a landscape service, might, with some embodiments, default to landscape service when landscape or landscaping category is selected, since the property is already landscaped give the systems knowledge of the user.

As discussed, with some embodiments, expert arranged user interfaces provide choice and/or recommendation opportunities for navigating through and selecting action by user and/or Stakeholder sets. This may be supported, for example, in the form of faceting interfaces providing, for example, a classification structure for one or more Domain categories or as general purpose category arrangements that users and/or Stakeholders may use to associate one or more category sets with one or more PERCos verbs for specifying a Core Purpose set.

In various embodiments, Core Purpose specification capability through combining one or more verbs and one or more Domain categories is particularly useful in purpose approximation for similarity matching with Big Resource purpose classes, resource classes, and/or Big Resource resource instances and/or portions thereof. Users and Stakeholders use such Domain category specifications to focus on one or more verb and/or verb equivalent abstractions, such as learn, teach, purchase, sell, purchase, travel, consume, feel, want to swim, want to play, need to study (and other want to and need to permutations and/or the like), work, design, share, collaborate, communicate, and/or the like, with an operatively appropriate Domain category set, such physics, piano, chair, Chinese food, and/or the like. Such Domain category specification can be supported by generally known and accepted category organization information arrangements such as Domain category classes, whether inherited and/or relational and/or some combination thereof, and/or alternative information structures such as another ontology design or Lexicon set. Such system sets with some embodiments represent expert (and/or authority, such as standards body) logically structured category information structures available for user and/or Stakeholder evaluation and/or selection, such as when proffered as a choice set by a faceting interface for specification of a Core Purpose and/or CPE.

Category faceting can with some embodiments rely on classical Aristotelian approaches, in which category items are mutually exclusive and in the aggregate complete as to a general system, or for example, to a high-level Domain within a system. Users can use, for example, an interface such as a faceting list to select a category, then, for example, a subcategory. A faceting interface may allow plural categories to be identified and conjoined, either in sequential faceting steps or collectively presented on screen (multiple faceting selection columns). Faceting selections could be made such as “chemistry”+“material science”+“silicon”+“solar” with the verb “learn” to form a Core Purpose having a compound category set. The foregoing, if specified on a command line, might use an operator such as “+” to combine the categories, and the categories might be respectively weighted for contribution to processing if desired, for example, associating values 1 through 10 to a given category selection through a right mouse button pop-up selection, with categories defaulting at 5 if no selection is made (or using other values as an application might provide). Similarly, multiple verbs might be conjoined using a verb faceting choice array. Further, a faceting interface might default to displaying next to a faceting list selection, a second level faceting list of “members” of the first list, with subsequent level lists available as desired. With some embodiments, frequently used Core Purposes, and/or Domain category and/or other CPE sets, may be saved and published for local and/or distributed/published use, as desired, along, if desired with symbolic icon representation of each such Item, for quick access as a PERCos Construct. PERCos Domain categories may employ prepositions as operators as faceting list choices, for example, activated by a right mouse click and drop down menu choice and/or by selection of a Desktop item for prepositions represented by a symbol/icon and/or test label and/or the like. Alternatively, a faceting arrangement may, for example, present a choice list where “to play” may be adjacent to the category base word “play” for the Core Purpose “learn to play music” involving the verb “learn” and preposition “to” and the conjoined categories “to play+music.”

In various PERCos embodiments, Domain categories and subcategories function as the “base” focus of Core Purpose specification, with one or more verbs functioning as the user set activity perspective, with, for example, adpositions functioning as relational clarifiers. Whether or not used, for example, in combination with PERCos other Master Dimension Facets and/or resources and/or resource classes (including Constructs and/or Construct class sets), the intent of these capabilities in many PERCos embodiments is to, for example, constrain choices to practical standardized approximation operators that as a set and in combination maximize ease of use, including simplicity of choice and operation; maximize interoperability, consistency, and reliability; and/or support practical efficient Big Data and Big Resource approximation computing through purpose approximation and associated resolving to purpose neighborhood results for user/computing arrangement adaptive, unfolding processes to optimal interim results and/or Outcome.

In certain embodiments, PERCos category one or more information arrangements, whether in the form of lexicon, class, and/or ontology arrangements, are at least in part determined by Domain category and/or purpose class experts and/or standardization authorities. Such information arrangement determinations may supplement a standardized, general, common purpose base PERCos lexicon (and/or base expertise level lexicon such as corresponding to a base medium sophistication level for a given Purpose class and/or Domain category class set). Such experts may, for example, be employed as consultants and/or employees by one or more of affinity groups and/or standards groups and/or commercial group and/or the like as described above and/or may be contributors to the standards activities of any such groups. With some embodiments, such experts attempt to, given their insight into the nature of use of verbs in their domains, define a constrained, and therefore simplifying standardized list or relational arrangements, which can be used, for example, in user and/or Stakeholder Core Purpose Expression or other CPE specification activity in PERCos purpose approximation for similarity matching and other shared and common purpose computing functions.

With some embodiments, input other than verbs and/or Domain categories may provide a basis for specifying Core Purpose input, such as user historical, crowd behavior, biometric signals, and/or the like derived information. The foregoing may provide a contributing or determining basis for inferred verbs, Domain categories, and/or combinations thereof. For example, it may be visually recorded that each time a user listens to a certain type of music, he may be enjoying the experience—this may be visually interpreted by analysis of user expression, body language, spoken voice tones/frequencies and/or cadence, spoken words in conversations with other people present, and/or the like. This association of reaction to a resource set may be inferred and stored individually associated with a portion or all of the then current resource set and/or stored in the aggregate with one or more resource classes and/or purpose classes and/or similar logical groupings, with such resource set and/or class and/or other type characterizations being available to match with subsequent user purpose expressions, including using such information with AI processes to evaluate potentially most satisfying resource sets, portions thereof, and/or how user interface functions with resource sets.

Contextual Purpose Expressions (“CPE”s) are specifications representing respectively user and Stakeholder purpose concept approximations. In some embodiments, these approximations are specified to approximate user perceptions, user intent, and/or user classes. In certain PERCos embodiments, CPEs have, at minimum, at least one verb or verb equivalent representing user activity perspective and at least one category representing the subject upon which at least one or more verbs is conjoined, the set representing a Core Purpose specification. Such Core Purpose CPEs may be augmented by various other information sets. For example, in some embodiments, Core Purpose's may be augmented by Master Dimension Facet conceptual approximation perspectives and/or by auxiliary Dimension information. In some embodiments, CPEs may be particularly useful in characterizing purpose approximations relationships of resources and in identifying purpose responsive resource neighborhoods that may optimally support user learning, discovery, and/or experience purposeful processes and Outcomes.

CPEs may be prescriptive, specified by users as a characterization of, as well as any specified pertinent conditions regarding, a user set computing arrangement objective set, or they may be published as descriptive CPEs, specifying qualities related to a given resource set that may correspond, at least to a degree, to user CPEs, that is correspond to user purposes and specified other concomitant contextual considerations. Prescriptive CPEs are specified by users to characterize their purpose approximation concept set; they are ephemeral unless published by a user as a resource, or otherwise saved. Descriptive CPEs are published as the subject of, or are published in association as descriptive of, a resource set, including individual one or more resources and/or resource classes.

For example, resources may have one or more CPEs which describe Stakeholder purpose set one or more characterizations they declare as associated with a resource set, including, for example, a resource class set. These characterizations may, for example, portray a resource publisher or other Stakeholder set's perception of anticipated user CPE specifications and/or associated useful information for use in user and/or PERCos Coherence evaluation of a resource sets suitability—which may include, for example, relative suitability in relationship to a plurality of resources—for user purpose fulfillment, including for use in correspondence matching between resource associated descriptive CPEs and user CPEs representing user purpose approximation input. Descriptive Contextual Purpose Statements may also frame publisher and/or other Stakeholder governance, commercial, value chain function, automation, process automation, event triggers to any of the foregoing, and/or any other administrating, constraining, and/or other regulating variables related to such Stakeholder interests, including, for example, rights management, financial budget and/or other information to usage, and/or the like. For example, these Stakeholder specifications may be included in a CPE set framing any such Stakeholder interests as related conditions for, and/or instructions regarding use of, a resource set. As such, some embodiments of PERCos will support the specification of, for example, affinity group or commercial organization process automation instructions that are specialized Constructs that may, for example, within a corporation, or within an industry group such as a trade group or association, or with a club, or as specified by a government within its sovereign area of control, state that, for example, if a then b or any degree of complex derivation thereof. This allows for event based process control functions to be embedded in CPEs and/or Stakeholder Purpose Statements. In some embodiments, such embedded instruction set may be associated with one or more Core Purposes, other CPEs, purpose statements, and/or PERCos Dimension information, such as Facet information and/or any auxiliary Dimension information, including to a purpose expression set associated descriptive CPE and/or purpose statement set that may be used in similarity matching and/or user evaluation of their associated resource sets, to help ensure that the consequences of such embedded instruction set are consistent with, and/or otherwise contribute appropriately to, user purpose fulfillment considerations.

A published descriptive CPE is published, at least in part, in anticipation of its potential usefulness in supporting users in determining correspondence to, or otherwise determining sufficiently similar relationship with, potential users' prescriptive CPEs and/or purpose statements, thus enabling PERCos Coherence (and/or other) matching, either in the form of complete matches or otherwise in the form of, in accordance with associated specifications, relative degree of similarity matching. Such correspondence and matching processes may be applied uniformly between CPEs and/or purpose statements, and/or may, in some embodiments, be evaluated according to rules comparing subsets of such prescriptive and candidate descriptive CPEs in differing manners.

PERCos Master Dimension Facet variables represent conceptual simplifications that supply contextual information in a standardized, interoperable form. Such Dimension information adds conceptual perspective characterization to CPEs, and/or may add such characterization to Constructs such as resonances, Foundations, Frameworks, and/or the like through their associated purpose expressions. Master Dimension Facet specifications enhance insight into the purpose approximation objectives of users and similarly provide additional framing parameters for descriptive Contextual Purpose Expression specifications by Stakeholders.

PERCos Dimensions can provide broad logical groupings of contextual variables for simplification, ease of use, and/or standardization in the formulation of user CPE contextual perspectives as well as the creation of operative purpose statements. They are relationally relevant simplification groups for providing purpose concept approximating values. They may be used to portray orienting user approximating Dimension Facets so as to purposefully direct human/computing arrangement activity. PERCos Master Dimensions and Facets, as well as auxiliary Dimensions, can be used to form more contextually rich Contextual Purpose Expression approximation specifications identifying conceptual neighborhood sets for relevant resource and/or resource portion similarity matching in support of user set learning, discovery, process automation, and/or experience unfolding.

In some embodiments, such contextual Dimension variables may be in part or whole “ignored” in the response to rules and/or in the absence of pertinent corresponding prescriptive CPE user purpose expression information—that is, for example, PERCos matching may be in part based on the presence of certain Dimension and/or Dimension Facet specification indicated in a CPE and when or if some of such specific or comparable Dimension or Dimension Facet information is absent from a prescriptive purpose expression (including, for example, a purpose statement) but present in a descriptive resource purpose expression, its presence in the descriptive expression may be ignored in similarity matching or such non-corresponding descriptive expression portions contribution to similarity computation may be attenuated by application of desired instruction information to producing results based upon such instructions to ignore, attenuate, and/or otherwise transform such expression portion(s) set's contribution to a result set. Further, in some embodiments, PERCos may support selective differing processing of instructions for different purpose expression portions. That is, such instruction information may be collectively applied to a CPE as a whole, or the whole or any portion set of any such instruction set may be applied to one or more subsets of such descriptive purpose expression subsets missing from prescriptive expression values and such applications may apply variably in differing one or more manners to different one or more subsets of such non-corresponding CPE information. This ability to ignore, attenuate, and/or transform the input of such “missing” from prescriptive expression comparable or relatively corresponding expression portions, and the ability to process such items in a selectively differing manners, allows for expression subsets in resource descriptive purpose expressions that may not be consistently germane to overall, for example, current session, specific user purpose considerations for similarity matching to user purpose expressions and therefore are processed in some instruction managed manner so as not to interfere with relevant, that is in some circumstances more significant, similarity matching to subsets and/or subset combinations that may populate user purpose expressions.

PERCos Master Dimensions, through Facet and any associated value set specification, and as may be augmented by auxiliary Dimensions, provide PERCos processes with specifications reflecting the nature of user purposes, that is factors to be considered in producing PERCos processes and Outcomes that support users' respective purpose session sets. In certain PERCos embodiments, these factors may be specified at least substantially through the use of Dimension members called Facets, and any associated Facet values, describe generalizing principal features of a user sets' purpose focus and specified context conveyed in a standardized interoperably interpretable manner. These features reflect user conceptual approximation of their objective set as a basis, for example, for learning and/or discovery and/or experience unfolding, where at least material portions of such purpose characterization specified by a user set is performed by PERCos providing logical grouping of characterization considerations. These logical groupings may in some embodiments, for example, and as organized by standardized Facets, be selected, for example, from a Faceting or comparable selection list of respective Facet choices, and where such list may be constrained in some embodiments to provide only such standardized constrained choices as logically reasonable for such approximation and simplification purposes.

For example, in some embodiments, Core Purpose, or Core Purpose and one or more supplementing Master Dimension Facets and values—which either of the foregoing may be augmented by auxiliary Dimension information and/or any complementary input, such as stored profile information, preferences, usage history, crowd behavior history, resonance set, including synergy instructions, and/or the like—may form the basis for calculating approximation spaces that may be determined to hold, or otherwise correspond to, pertinent resource class and/or instance sets. These information intersections may be represented by corresponding spaces that may be populated by candidate resources, and where such spaces may be operatively represented by one or more most closely, similarity matched purpose classes or calculated purpose neighborhoods determined through correspondence analysis between prescriptive and descriptive purpose expressions such as their respective CPEs and/or Purpose Statements, and, when desired, with augmenting information.

PERCos, in some embodiments, thus can enable users to represent user classes through concept focus and context integration through prescriptive CPE specification. Such specifications may then be used in similarity matching with similar purpose expressions associated with purpose, resource, and/or participant class sets and/or instances and/or combinations thereof. This process may, in some embodiments, contribute to identifying, evaluating, prioritizing, selecting, combining, and/or provisioning one or more such classes and/or instance sets, resource members and/or member portions of which may then be prioritized and/or filtered according to at least a portion of the associated user purpose statement set so as to provide displayed, otherwise managed, and/or provisioned resource member and/or portion sets. Such resource member and/or member portion sets may represent sets associated with their respective parents classes or may be integrated, from multiple such class sets so as to produce a user purpose, purpose statement responsive neighborhood member set.

PERCos similarity matching processes may in some embodiments support two or more stage similarity matching sequences, where, for example, one or more purpose class and/or other purpose neighborhood sets are first identified, then another similarity matching sequence is started automatically or on instruction of a user set. For example, when PERCos Master Dimension Facets are used by users as a conceptual basis for selecting, and/or for specifying a CPE set which is then intended to be used in a multi-step matching operation sequence, Master Dimension Facets information can, for example, first be used for similarity (including for example, directly) matching with purpose class sets and/or other calculated neighborhoods containing resources declared as members by Stakeholders such as publishers and/or Repute Cred assertions. In some embodiments, this may be followed by further identification, prioritization, evaluation, selection, combination, and/or provisioning applied to all, or a selected germane subset of, members of such identified purpose class and/or neighborhood set. For example, further purpose expression and/or related information, for example, from auxiliary Dimension and/or other embodiment Dimension information and/or from user, user group, and/or crowd related purpose expression related profile, preference, historical behavior, and/or the like information, may be employed so as to identify, filter, prioritize, evaluate, compound, and/or otherwise process all or a portion of information regarding members of a purpose class and/or neighborhood set, where such second or more stage similarity matching involves matching against metadata and/or constituent data of such resources, for example, in the form of indexed and/or relational database stored information. The foregoing may, in some embodiments, enable users to perform more detailed and/or nuanced characterization of their purpose set which may be performed efficiently on the constrained set of resources comprised of, for example, first stage purpose class and/or other neighborhood results. This means that such auxiliary Dimension information employed with user purpose expressions may provide, for example, with some PERCos embodiments and under some circumstances, unstructured, non-standardized Dimension information that would be impractical or inefficient to employ with Big Resource (or other large, distributed information stores), but with the highly constrained interim result set following determining a purpose class or other neighborhood set, would now provide practical, efficient further parameters for use in evaluating, for example, meta-data indexes and/or the like, to arrive at a more precise, less approximate, results. Such two (or more) phase processing may be performed in a manner transparent to users, but provide users with the powerful benefits of purpose related standardized approximation processing followed by further evaluation using unstandardized (that is not PERCos standardized expression elements) and/or partially standardized, for example, auxiliary Dimension information. That is, some PERCos embodiments, for example, may employ a segmentation of user set CPE and/or purpose statement, for example, a set of Master Dimension information, for a first matching set, followed by, auxiliary Dimension and/or related information (such as preferences, profiles, crowd, and/or history related) for a second matching process (and which second set matching in some embodiments may be augmented by Master Dimension information in contributing to calculating the evaluation, such as for a prioritization, of a member set that may result, at least in part, from such first matching process). In such embodiments, this further matching, when using, for example, auxiliary Dimension information, may employ non-standardized elements, but since the group of resources to be analyzed is now a greatly constrained set resulting from, for example, a first matching process, in contrast to Big Resource or other large, diverse information stores, such further matching process, for example, involving Boolean open text expression, can now be practical and efficient since the focus is on a specific resource neighborhood set calculated to appropriately correspond to a user set purpose approximation specification set.

Users may, in some embodiments, be able to review, for example, be presented with, purpose class and/or other neighborhood members, evaluated and prioritized, for example, in accordance with standardized Master Dimension information, including for example, Core Purpose information, as well, for example, for comparison purposes, be presented with the results of further second stage processing using at least in part auxiliary Dimension information, which when both result sets are provided to a user set, such user set may identify opportunities to enhance and/or modify their auxiliary Dimension information to reflect an unfolding, knowledge enhancement, and/or experience preference development. PERCos may also provide, in response to a single common, or two related user input processes, the results of “traditional” search and retrieval technologies along with PERCos resource and/or resource portion identification, evaluation, prioritization, selection, combination, and/or provisioning as described herein, allowing for differing views into response sets resulting from purpose managed information systems and traditional, distributed web pages and/or other information resources. For example, a user might be exposed to a split user interface window, or separate windows, with for example, each modality occupying separate windows or window portions. Alternatively, a PERCos environment or traditional environment running a PERCos purpose class application may support toggling between a search and retrieval modality (e.g. Google, Bing, and/or the like) and a purpose based modality using techniques and interfaces described herein. Such an approach might provide user flexibility between performance optimized retrieval modes and learning, discovering, and/or experiencing enhancing purpose related PERCos modes. For these purposes, PERCos might transform a user CPE into traditional, Boolean unstructured text expression for use by such search and retrieval mode or may support a user set providing for example, unstructured, Boolean input. Boolean open text expression can now be practical and efficient since the focus is on a specific resource neighborhood set calculated to appropriately correspond to a user set purpose approximation specification set.

Core Purpose and Dimension Facet generalizing features may function, for example, as concept simplification vectors or axes corresponding to human conceptual purpose factors, such as, in an example, a verb representing a dynamic orienting user perspective factor such as “learn”, a category representing a thing, type, and/or place such as “biochemistry”, a user characteristic relative to a Core Purpose or Contextual Purpose describing user expertise/sophistication, such as “moderate” (versus beginner or expert), and a resource characteristic relative to the Core Purpose or Contextual Purpose describing a resource, for example, as “complex” (versus simple or medium, and for example, describing the complexity of material relative to a sophistication level). Together, these approximation simplifications may be treated as axes used for similarity matching with, for example, comparable purpose expression information associated with purpose expressions and/or class index sets, resource sets and/or resource class index sets, and/or the like.

These PERCos tools discussed herein in some embodiments may be combined with various web information management related tools, such as search and retrieval, semantic web, knowledge graphs and clustering, expert systems, and/or the like. Such tools without the use of a PERCos technology set, may fail to provide reasonably appropriate resources, much less optimum resources, and optimum resources may seem to, and practically be, unattainable, given the nature of such web information management technologies, at least in practical timeframes and with sensible amounts of effort. PERCos technology can, for an example, combine the operative perspective of a verb set from one or more constrained verb lists, combined with focusing domain category one or more sets, and complemented by suitable user, resource, and/or Repute one or more Dimension Facets such as described herein, and when, as appropriate, augmented by similarity matching with purpose class one or more arrangements, can transform Big Resource, and what may appear to be boundless information diversity, location, and attributes, to manageable, very useful user purpose related sets, which can be further narrowed according to further processes involving subsequent similarity matching, Repute recommendation, fit to history, fit to crowd, AI support, and/or incorporation of user nature and priorities related information.

In some embodiments, purpose expressions, in the form of Contextual Purpose Expressions, include Core Purpose Expressions, which may be further combined with Master Dimension Facet and/or any other PERCos compatible associated specification one or more sets (for example, auxiliary Dimension information) provided, as specified by users or Stakeholders and/or their PERCos computing arrangements, for the formulation of their CPEs and/or Purpose Statements. The foregoing specification information may optionally, for example, include specifically identified resource items such as participant, Construct, symbol, one or more instances and/or type resource classes, and/or, for example, may include instructions for facilitating resonance purpose optimization, process automation, societal/affinity rules events, thresholds, and management, and/or the like. Such expressions may optionally in some embodiments use, for example, conjoining operators such a “+” “−” “and” “not”, specification instance contribution weights and/or other instructions, and/or clarifying/narrowing adverbs, adjectives, prepositions, and/or the like. Descriptive adjectives may, in some embodiments be limited to, and/or particularly adapted for use with, auxiliary Dimension expression elements such as with Constructs, resonances, process automation, and/or the like. Further, constrained, preposition, adverb, and adjective lists may be employed and such lists may be constrained, at least in part, according to appropriate usage in a given Domain by an expert set and/or other authority/utility/standards set and such may be in some embodiments standardized such that, for example, one adverb, adjective, and/or the like may, as with categories, function as an approximation where the use of other similar terms or phrases would be treated as synonymous, as for example, as defined by experts and/or one or more standards bodies and/or the like. Flexibility of use, or the absence of use, of adjectives, adverbs, prepositions and/or the like may be determined by experts and/or one or more standards bodies based upon their ease of use, simplification, standardization, and/or approximation priorities. For example, as may be considered appropriate in some embodiments, prepositions and/or adverbs may be available for user choice, for example, as may be logically appropriate as associated with a Core Purpose set, but no, or a very constrained list of, adjectives would be available, or would only be available for use, for example, in auxiliary Dimension expression to reduce complexity and serve approximation objectives. In some embodiments, such constraint of available prepositions, adverbs, and/or adjectives, as discussed herein, may alternatively and/or in addition be Core Purpose, verb, and/or domain type and/or domain category specific constrained, that is constrained to options/choices normally and/or logically associated with such element, such as, for example, might be presented by a faceting interface context specific choice set for user selection. For example, the adverbs “softly” and “daringly” would make very little or no sense combine with a Core Purpose “learn nuclear physics,” while the adverbs “quickly” or “visually” could be informing clarification. For example, in some embodiments, domain experts can readily identify highly constrained adverb lists for use with very specific verb sets, making simplifications for faceting and/or comparable user interface modalities easy and efficient for users and Stakeholders alike, this facilitating PERCos simplification and concept specification. Similarly, adjectives (for languages that have adjectives) can be identified in a constrained manner for specific and/or classes of Core Purpose. For example, many types of adjectives may be inappropriate for use in PERCos purpose concept approximation with Core Purpose sets, or, for example, with Core Purposes as might be complemented with Master Dimensions Facet information, though such adjective use might be expert determined to be appropriate when used with auxiliary Dimension expression components. For example, in some embodiments, adjectives such as “rich” or “fastidious” may be decided to be inappropriate simplification choices for “learn nuclear physics” or “evaluate+purchase Italian car,” but, for example, “fast” and “affordable” are logically appropriate options. As with prepositions, language experts and/or applicable Domain Category experts (such as experts in Science (or, for example, more specifically physics), Cooking, Plumbing, Auto Mechanics, and/or the like) can readily screen and limit adverb and adjective and/or the like to practical, quite limited choice lists for easy user approximation specification selection, and such limitation may be determined to be appropriate when applied generally to CPE expressions, domain category specific, or purpose expression type specific (Core Purpose, Core Purpose plus Dimension information, Core Purpose plus Master Dimension Facet information, and/or the like in any reasonable combination). In some embodiments, this capability may be particularly useful for users and Stakeholder ease of use and approximation specification using PERCos simplification techniques for choice selection respective to specific Core Purpose and/or CPE sets, such as those association with a CPE associated purpose class, including for example, when specifically adapted to specific one or more purpose class application given their anticipated user profile information and/or purpose expression specifications.

In some embodiments, such choice management of verb, category, facet, and other list types, can be constrained and/or otherwise organized as reflective of the sophistication of a user in a given purpose context. For example, if a user is unsophisticated, for example, in the area of global economics, the set of category terms, for example, in purpose related to such area, may be simplified and constrained when relating to some PERCos embodiment interfaces for activities for category related purpose fulfillment. Such constraining and/or shift in organization presentation, can be based upon such user's purpose and/or domain specific characteristics, that is which each purpose or category domain shift, a different “level” may be employed in use interface operations.

PERCos embodiments may, as associated to such a level of specified or assumed expertise/sophistication/knowledge and/or the like, and provide for user Facet and or other choice selections that are automatically or by user selection provisioned, and where such choice option proffering or automatic provisioning may be associated with at least a portion of such user's characteristic set. For example, such a dynamically adjusting framing of choices option may be selected by a user, or by a user employer corporation or by other organization types, such as an affinity group or association. Such adjusting choice options may be in accordance with specified or presumed user “levels” as associated with a purpose or Core Focus set and an information structure may store such associations with sets for user (and/or user groups).

Such purpose or category adjusting level option arrangement may, for example, be defined and/or organized as a web service by domain or general experts, such as ontology and taxonomic academics and corporate professionals. Such capabilities can be embedded in purpose class applications, plug-ins, operating systems and environments, and the like, which may inspect user information, such as user profile and/or user preference information (such as a request to use contextual adjusting such levels) and/or history of PERCos embodiment usage. In some embodiments, the level may, for example, be at least in part determined by an analysis of estimated relevant user characteristics from some or all such information, and/or the like.

In some embodiments, users may select a characterized resource set by selecting an icon or some other symbolic representation of such resource set where such symbol was published by such Stakeholder, e.g. a resource publisher, as a branding, purpose characterizing, and/or other identifying representation. Users may also publish for their own use (and/or may publish as Stakeholders) Frameworks, purpose class applications, Foundations, resonances, CPEs, and/or other Constructs and associate any one or more of such Constructs with representative symbols for simplification of use, for example, when wishing to associate a group of symbols with a purpose class or other neighborhood. For example, purpose class applications and/or other Constructs by their type and/or collectively, may organized by visually similar symbols, such as using the same symbol in differing colors, for all Participant set, including Participant class, Construct use in association with a specific CPE or associated purpose class or the like. A user be specify one or more Core Purpose and/or CPE combinations and associate a symbol with such specification whereby resources employing such specification may automatically have such symbol associated with them, and where such symbol may be varied in some manner, such as font used for descriptive name, color, size, display orientation (e.g. off axis by a consistent amount per usage association distinction). The use of any symbols representing Constructs herein, may in certain embodiments, produce, that is extract from or otherwise transform such symbol to, its associated purpose specification, enabling such symbols to be inserted as shorthand into purpose expression specification and/or the like, and where such symbol may provide its corresponding specification information as input to other user purpose operations.

In some embodiments, Purpose Statements represent transformations of user CPE specifications where such transformations are effected at least in part as a result of processing input regarding user, user group, and/or user affinity group or other association preferences, profiles, PERCos usage history, PERCos and/or other crowd behavior information, user biometric input, Intelligent Tool input such as AI, and/or any other PERCos Purpose Statement input specification. Both CPEs and Purpose Statements may be employed in similarity matching to descriptive Contextual Purpose Expressions and/or descriptive Purpose Statements, depending upon the operational specifications. Similarly, Stakeholder CPEs may be transformed, at least in part, into Purpose Statements through the provisioning of Stakeholder profile and/or preferences information and/or one or more input types as described above (excepting user biometric information would instead be Stakeholder biometric information). Such preferences and/or other information types described above for users and Stakeholders, individually and/or as sets, may be associated with, for example, resource set, including resource class and/or resource portion sets, including, for example, CPEs and/or purpose class sets, Participant and/or Participant class sets, Constructs and/or Construct classes, and may include instruction information sets that are resource sets or, as may be employed, are directly provisioned, are non-published, and/or non-PERCos published. Such instruction sets may include, for example, resonance specifications, process automation information, such as commercial process automation event based instructions for Stakeholders interests, privacy right and/or security instructions, and/or financial budget management event based triggers and instructions for users, and/or the like.

In some PERCos embodiments, Master Dimensions provide key logical groupings of Facets and any associated values simplifications assisting users and Stakeholders in representing their purpose approximations. PERCos supports various embodiments of Master Dimension and Facets, with an exemplary embodiment detailed below.

A primary objective of Master Dimensions and Facets is to provide a simple means for users and Stakeholders to specify CPEs as practical approximations of purpose fulfilling resource sets and/or of resource portion sets. resources, in some embodiments, may be more a more prevalent objective when learning and/or discovering those resource sets whose usage may lead to fulfilling specific user purpose Outcomes, the latter, resources portions (including information derived at least from such resource portions), may be of particular interest when working with a resource, such as a purpose class application, in order to realize a specific Outcome, that is user purpose process end result, and where the resource portion may be specific information one or more instances provided by the purpose application as specific to user purpose knowledge/information enhancing and/or evaluation.

Relational operators may, in some embodiments, be used in Dimension expression specification to clarify/enhance contextual simplification (prepositions e.g. “under, with, to” and/or the like, positions and/or durations in time or location, and/or adjectives including colors, size (big, medium, small, short, moderate, long), emotional attributes (happy, sad, exciting, unexciting, stimulating, challenging, thought provoking, counter-pointal).

While various embodiments may provide differing sets of PERCos purpose Dimensions with different logical organizations and simplification characterizations, including various ways of representing and/or modifying them, for example, within PNIs, the contextual organizational and expression simplifications can in some embodiments primarily derive from separation in certain logically related groupings, such as groupings of user descriptive information as that which most significantly reflects the general and/or purpose specific characteristics of one or more users, the characteristics which are associated with published resources, the characteristics associated with Repute, the qualities of context reflected by Core Purpose specification, and the use of special symbols/descriptive representations, all the foregoing allowing for, in some embodiments, standardized, interoperable, purpose expressions. Other embodiments that provide certain or all of the PERCos expression capabilities may support inferring of purpose from context, such as (a) inferring verb and/or prompting for verb selection, and/or other characteristic set, from a at least in part inferred, logically appropriate choice list, (b) use of synonym such as word and phrase thesauri, (c) semantic analysis, user and/or crowd behavior related to resource, purpose expression, and/or purpose class and/or neighborhood and/or the like.

These Dimension groups and Facets assist users and Stakeholders in easy logical specification processes; they may first identify what in many circumstances and embodiments may be a first user purpose expression activity, identifying a Core Purpose such as “learn Ford auto mechanics,” which may then be followed by specification of certain Dimension specific characteristics, including the use of logically related Dimension Facet types, for example, within user characteristics Dimension Facets characteristics such as “medium sophistication/experience,” and “time<100 hours” and “budget<$200, which all the foregoing may be associated with the Core Purpose, followed by a user specifying, for example, resource characteristic, “‘moderate’ resource complexity’” and further specifying Repute Cred “Quality to Purpose” (levels “4” out of a 1-5 choice set), then specifying a further Repute Dimension using a publishing category Faceting list associated with the Core Purpose with the selection of “major automotive publication” and “national/regional newspaper” as respective EF characteristics of Repute Cred resource publishers.

As an example under an embodiment of a PERCos resource learning/discovery user CPE where a user set specifies using both Core Purpose and user and resource Dimension Facets:

“Core Purpose: (‘Learning’+‘Applied Synthetic Biology Research Skin Tissue Replacement’)+user Facet: Beginner to Purpose+user Facet: Education, College BS+resource Facet: Time Frame P (for publication timing)>twelve months+resource Facet: Time Frame T (timeliness of underlying work) within 48 months; Repute Facet: Tenured Professors (in synthetic biology) Value to Purpose.” In one embodiment, for example, a purpose class ‘Learning Synthetic Biology” and a Category class “Synthetic Biology” are identified through similarity matching to the Core Purpose “‘Learning’+‘Applied Synthetic Biology Skin Tissue Replacement’” as the closest, in such embodiment, classes having members covering the Core Purpose focus area. For example, the members of both classes can then matched against an index for each of the classes matched against a purpose expression for the Core Purpose and standardized Facet values. An article in the hypothetical journal “Online Applied Synthetic Biology Updates,” is a resource member of both classes, and is rated by such Domain tenured professors as the most valuable article for the less sophisticated, that is beginners, in learning about recent developments related to the Core Purpose. Interestingly, for the hypothetical example, the professors rate this particular article highly for the moderate and sophisticated, because it well serves the purpose of all Core Purpose interested parties, since it is very well written, has a concise overview in the beginning, and for the more sophisticated, has an extended section of more technical information. In this embodiment and with this hypothetical example, the second most highly rated resource through such same similarity matching for beginners with a college science education is a publication entitled “Introduction to Applied Synthetic Biology,” Chapter 6, Skin Therapy.

As discussed, user purpose expressions may in some embodiments include, and/or may otherwise be transformed by (as, for example, in generation of Purpose Statements), non-standardized input such as, historical input, and/or auxiliary Dimension information and/or the like. Such auxiliary Dimensions, for example, do not employ simplification Facets since by nature they may take an unlimited or available in large numbers of possible forms. In some embodiments, information under these Dimensions are PERCos interpretable and employ standardized commands, syntax, and/or other language elements and which be supported and/or otherwise at least in part managed by one or more standards managing arrangements such as society, association, club, and/or utility sets. Some embodiments make employ resource, participant, Stakeholder, user node, and/or associated forms of meta-data and/or other information that may be in non-standardized form as contributing input into user or Stakeholder Purpose Statement or other purpose expression formulation, where such input is interpreted, at least in part, by some PERCos embodiments processes with the aid of semantic, expert system, and/or other tools and associated information stores.

Biometric inferred information indicating using camera and/or audio and/or spoken word analysis to provide mood and/or reaction input.

PERCos may, in some embodiments, organize Dimension simplification and logical groupings around, for example, Core Purpose Dimension combined with process/outcome Dimension. Such process/outcome Dimensions might take the form of:

Dimensions, with some embodiments, not only may provide logical scaffolding assisting users in outlining their purposes, but also may function as weighting and/or algorithmic expression groupings reflecting a user's composite purpose focus and simplifying and improving efficiency of PERCos processes and results, and in particular when used with huge to “internet boundless” resource opportunities. In certain ways, such Dimensions may at least in part comprise a “Basic Level” common orientation, simplification means as commonly understood by users in a manner conceptually similar to Basic Levels in Postulate Theory. In some embodiments, such Dimensions, such as Master Dimensions, which are represented by one or more standardized Dimension Facets, can be expressed in any logical combination, and may comprise Master Dimension and their Facets and/or Dimensions purpose expression sets which may be augmented by one or more Dimensions attributes/values. In some embodiments, the foregoing may be supplemented in PERCos processing, at least in part, by otherwise normally interpretable natural and/or Boolean language expressions, with or without associated values. Dimensions and and/or their specified constituent standardized components may, with some embodiments, be expressed, for example, with associated weighting algorithms. For example, Dimensions may have user conceived weighting groups (e.g. with associated contribution values), for example, a combination of Dimensions, comprising a Core Purpose arrangement plus, for example, Dimensions weighting of 90% Social and 10% Intellectual, or 25% Intellectual, 70% Transactional, and 5% Experiential, or 50% Intellectual and 50% Societal. Such Dimension attribute values may be employed in matching and similarity, prioritization, provisioning, and the like. as may at least in part relatively, or absolutely, correspond with comparable Dimension attribute values associated with resources, for example, published by Stakeholders as germane descriptive information as expression components of CPEs.

For example, a user with a Core Purpose of Buy Camera might be primarily focused on the Intellectual (e.g., evaluative such as what are the important features, brands, models, specifications, comparative pricing and/or the like), and on the Transactional (e.g., actual venues for purchase and their requirements), or on the Social (e.g., acquiring, through communication with friends, their perspectives on candidate cameras), or on Sharing the transaction activity, such as buying together with a friend, and the like). Similarly, if one wanted to go to a pop music concert and was evaluating options, one might emphasize Intellectual, degree of emphasis placed on evaluating options, Social, co-participating with certain friends, experiential, partying and dancing, and Transactional, how much and where to purchase and set priorities of 50% for Experiential, 20% for Intellectual, 30% for Social (right friends co-participating), and such input could then in some embodiments be combined, for example, with Repute input, CPEs, any stored profile, crowd behavior, and/or affinity/Societal information, and with any other Dimension input, to provide input to formulating an operating Purpose Statement for purpose class selection, matching and similarity, Participant (to become active users) selection, and/or provisioning, and/or the like. Such Dimensions specification may as above weight the Dimensions, and/or weight Dimensions Facets or attributes, such as Experiential/dynamic dancing 15%, Social, with friends 45%.

In some embodiments, the relative weighting of Dimensions can influence, in part, the treatment of various resources (for example, how Intelligent Tools, such as expert system faceting systems and/or at least in part Postulate Theory and/or related Conceptual System based class or other ontological systems, constrain and prioritize the offering of selections, and/or presentation of, verbs, categories, purpose Facets, and/or divisions) and/or how such Intelligent Tools support user identification, evaluation, prioritization, expression formulation and/or selection processes.

Specified combinations and/or other algorithmic expressions of Dimensions can be published and employed as resonance instruction sets associated generally with a purpose class. For example, high weighting in a social dimension might lead to increased weight being given to certain resources (including, for example, other participants) related to high resonance factors, e.g. going to a concert/dance with a Participant off a certain friend list, or having a Participant with certain personal characteristics indicating they were good dancers and good to party with, and where such resource characteristics would be responsive to resonance instructions.

A PERCos matching and similarity web service that can be supported in some embodiments is provided by one or more utilities, associations, and/or corporations, and functions as a rating service arrangement that, for example, for resource publishers and/or the like and/or web advertisers and/or participant information aggregators, create purpose relating information systems that associate resource instances and/or resources groups, including, for example, ontological and/or taxonomic and/or organization sets of resources, including any resource type, such as participants, with any type of purpose expressions and/or classes and/or other neighborhood groupings, where such association information may be augmented by other resource and/or purpose related data such as user and/or crowd related historical behavior system usage information, preferences, profiles and/or the like. For example, such processes may evaluate a Participant, when active as a user, related to a participant self-published Cred(s), related Cred EFs, third party Creds on the participant, and/or participant profiles, preferences, and/or use history, such as the participant has a Ph.D. degree in biochemistry, an avocation in near earth objects, and frequently learns about astronomy issues using Popular Science and some advanced science publications, wherein such participant as an active user specifies a PERCos CPE of “‘Learn’ ‘astrophysics near earth objects’ ‘user Facet: Sophistication 7’ (on a scale of 1-20)”.

Such a web service can manage methods that will process purpose expressions, including, for example, Core Purpose and such associated Dimension Facet and/or other available participant related information, including, for example, Dimension Facets and/or auxiliary Dimensions and/or the like and/or preferences, profiles, history and/or the like and similarity and/or other processes and evaluate such information against descriptive CPE and/or purpose statements and/or resource metadata, to identify most practical purpose fulfillment match, and/or, for example, priority ranking of candidate resources and/or resource portions, for that specific Participant as an active user expressing such a CPE and/or having such user's PERCos arrangement specific operative Purpose Statement.

Core Purposes are comprised of verb and category combinations, which verbs may be in some embodiments, at least at times inferred. Such Core Purposes may be augmented by the contextual Dimension Facets described in the following sections. Core Purpose conjoined verbs and categories, in some embodiments comprised of constrain verb options that are associated with category descriptions, such as physics/molecular, may be employed in some embodiments with prepositions and/or adverbs and/or other informing grammar terms, for example, selected from option lists through the use of, for example, faceting interface arrangements, and where the available grammar options are logically relevant, given the Core Purpose, and may be constrained in variety, for example, most useful terms of a grammar type, so as to support the simplification and approximation capabilities of PERCos arrangements. Similarly, for example, Domain category options may be constrained to those logically sensible given a user chosen verb set. Correspondingly, verb options may alternatively or also be constrained to those logically sensible given a given category specification, and/or in some embodiments may be inferred from a category, which may be presented as a short, e.g. “beef steak” which might in some embodiments have the verb options of “purchase, cook, eat,” while the conjoined categories or sub category “health” “beef steak” or “health beef steak” might have verb options of “learn, teach, communicate”. For example, it may make sense to “learn” or “teach physics,” but it likely doesn't make sense to “purchase physics”. Similarly, while it may be appropriate to “research physics,” or to “purchase physics textbooks,” it may make no sense to “travel physics” or to “meet physics textbooks.” Language and/or Domain experts can, normally, readily identify logically appropriate verb sets for category and/or category sets for a verb set that are logically likely and/or sensible options, and similarly through such an arrangement, some embodiments may interpret and provide constrained options of adverbs, prepositions, and/or adjectives, given specified categories, verbs, and/or Core Purpose and/or other purpose expression sets.

In some embodiments Master Dimension Facets describe primary purpose properties normally used as approximate characterizations which, when used in combination with Core Purpose, may substantially illuminate the context of a specified or inferred prescriptive, and similarly inform descriptive, Core Purpose Expression. The following are Master Dimension Facets as may appear in some embodiments using some or all of the faceting options discussed herein:

In some embodiments, the foregoing Facet examples might be available in any combination, with or without variations in labeling or type. Such Facets may be organized as generalization approximation characterizations of key user/Participant concept sets, such as organized in a standardized expression and interpretation manner and may be further organized in focal logical groupings corresponding to human general and/or Domain general, key attributes, and employed in specification to, for example, provide input into identification, filtering, evaluation, prioritization, selection, provisioning and usage of resource and resource portion sets.

In some embodiments, PERCos published resource items may have four basic information types, resource identifier, publisher (which may have a unique identifier), subject matter, and at least one purpose expression, and may further have complementary types, such as creator, provider, contributor, ontological and/or complementary taxonomic information, and/or the like, as may be specified in some embodiments and/or specified by affinity groups, corporations, societal organizations, standards bodies, and/or the like.

In some embodiments, purpose expression specifications may use, for example, Domain category instances that may be used with, for example, clarifying prepositions, including adposition sets, positions and/or durations in time or location, and/or adjectives such as colors, size, emotional attributes, and/or the like as various embodiments may provide. Standardized Master Dimension Facet and/or other Dimension lexicons may be further constrained in some embodiments by selected verb, Domain category, and/or Core Purpose sets specified or otherwise selected by user set and/or user computing arrangement as a constrained set offering the logically associated optional contextual simplification variables for a given selection set (e.g. one or more previous selections). Users may define their own simplification sets that may employ their own choice list synonym, relational association, word/phrase, and/or like lists for customizing their own, or groups, purposes.

In some embodiments, one or more verbs can be associated with one or more Domain categories as descriptive Core Purposes in CPEs declared as descriptive of purpose class applications (and/or other resources) by one or more Stakeholders. Users may select such a characterized resource set by selecting an icon or some other symbolic representation of such resource set where a symbol, for example, was published by a Stakeholder, e.g., a resource publisher, or by a user set, as a branding, purpose characterizing, and/or other identifying representation. Users may also publish for their own use (and/or may publish as Stakeholders) Frameworks, purpose applications, Foundations, resonances, CPEs, and/or other Constructs and associate any one or more of such Constructs with representative symbols. By selecting such resource set, a user may be specifying one or more Core Purpose and/or CPE combinations, which such selection may produce, that is extract or otherwise transform to a purpose specification set that may be derived from other PERCos environment information and employed as input to other user purpose operations.

In some embodiments users may arrange information of their choosing (subject to context and any associated rights) into purpose expression organizations, for example, as classes, ontologies, taxonomies, and/or the like. Should a user wish to publish such organizations there may be one or more formalisms that are applied during publication to ensure standardization and/or interoperability for the wider and/or intended audience.

Experts may use standardized and/or interoperable purpose expression organizations for their information, such that they for example, conform to the specifications agreed with a domain of expertise, interoperate with one or more purpose applications, may be appropriately interpreted by one or more intended users, and/or in other manners provide an effective and efficient organization for purpose operations.

A user purpose expression represents “the tip of an iceberg”, the visible portion of complex set of human behavioral and thought processes. The orientation of purpose may evolve during purpose processing and may occur across portions of one or more PERCos sessions. User understanding of purpose is often constrained by the degree of expertise a user has relative to their purpose expression (and the Domain set of that purpose). During one or more sessions, a user's purpose may increasingly be represented by, due to the unfolding set of processes, an increasingly optimized purpose expression that is a more accurate or more satisfying, evolving representation of users' intent development.

An external resource service, such as a PERCos embodiments synonym service, may be invoked by other PERCos embodiments resources, such as Coherence, and may provide options and/optimizations to users, such as, for example, when CPE comprises “booking” (verb) and “Travel” (category), PERCos embodiments may prompt “Purchase” to user in substitution of “Booking”.

In some PERCos embodiments, lexicons can comprise the terms most commonly used in the identification of purpose experiences, and in common with other PERCos embodiments languages, provide standardized and interoperable means for users to manage, discover, select, and/or otherwise manipulate and/or inspect for later use, appropriate experiences and their resource (e.g. Participant, content instance, and/or the like), purpose expression, nodal arrangement information such as location, computing resources, and/or the like.

Purpose class applications, in some embodiments, provide significant capabilities for users to realize their purposes. Purpose class applications are resources that comprise a resource set that has been specifically arranged to provide a user computing environment for a specific, logically related set of purpose Outcomes. Users may employ a purpose class application with the specific understanding that they were constructed to provide specifically targeted (to one or more purpose expressions) sets of capabilities that may have particular, expert and/or otherwise fashioned features, such as software application interface (such as faceting engine), display, communications (for example, cross-Edge), expert system and AI support capabilities, all in a mutually complementary, multi-featured milieu specific to one or more class, hierarchical, ontological, and/or other logical and/or relational (for example, human associated) based organization of capabilities as specified in the context of a purpose expression set.

Purpose class applications may, in some embodiments, be used to populate user computing environment “desktops” with symbols corresponding to, and, in some embodiments, in part or whole incorporating, branding, purpose class, publisher name, Outcome one or more facets, and/or the like so that initiating user computing arrangement purpose fulfillment activities brings the user directly into a resource environment for the corresponding purpose fulfillment specified class arrangement. PERCos capabilities may then be, in some embodiments, infused into the capabilities of the purpose class application, providing information resource and/or resource portion assistance, for example, for more granular, targeted, knowledge enhancement, and associated learning and discovery. With some embodiments, over time, and with the evolution of a PERCos Domain set specific or general cosmos, much of user activity may be “funneled” by the user through purpose class applications, with PERCos capabilities serving the user in a more specific information, user purpose knowledge enhancement and/or decision making manner. For example, a purpose class application might comprise a “learning and practicing auto mechanics” environment populated, in part, with a spectrum of brand and/or model specific mechanics electronic manuals provided by experts and/or the respective manufacturing companies and/or associations thereof and/or the like, supported by logical, expert framed faceting capabilities for diagnosing problems and/or for choosing remedies, and further supporting a body of consulting experts available, for example, on request, and/or currently online, and/or, for example, further providing information regarding any associated consulting fees and/or other considerations, where such one or more consultants (e.g. contingent on availability, scheduling, and the like) may, for example, be called upon at a given point in a learning, diagnosing, and/or repair process, all the foregoing, in such example, may be supported by graphics capabilities that can “walk” a user set through diagnosing and/or servicing a vehicle mechanical problem, including learning support capabilities such as reference and diagnosis specialty information that may be contextual (at a process point) available, and/or graphical and/or video close-ups, for example, on user request. These and other capabilities can create very powerful application sets populated by contributing resources (which may include in some embodiments one or more other resources not meeting the definition of a PERCos published resource), that may be evaluated and/or, custom employed, for example, in using a purpose class application allowing for selectable resources to perform one or more Roles contributing to the applications resource array. Users may further “build” purpose class applications, for example, by working with a Framework that is associated with the user purpose “learning and practicing auto mechanics” which may provide a scaffolding, including, for example, a portion of useful resources (which may include in some embodiments one or more other resources not meeting the definition of a resource).

In some embodiments, purpose profiles may be used by both users/Stakeholder to store those characteristics they wish to associate with one or more purpose(s) and/or purpose ontological and/or taxonomic groups, including, for example, purpose classes. For example, an expert who has multiple domains of expertise, potentially with differing skills levels in each may develop a purpose profile associated with one or more Domains. In addition, one or more users/Stakeholders may also have purpose profiles that are optimized to their own specific stored purposes (as, for example, CPEs).

A PERCos web service arrangement may maintain participant characteristics, e.g. profile information, as associated with any purpose ontological and/or taxonomic arrangements, such that based on one or more characteristics associated with a specified purpose set, e.g. a purpose expression, associated one or more parties could be identified and prioritized, for example, as further assessed according to Creds on their characteristic qualities/capabilities (as well, for example, on EFs, such as descriptive participant professional attributes).

In some embodiments, such purpose profile formulations may be associated with and/or potentially be part of preferences, and may in part or in whole form the context for the intended and subsequent purpose operations.

In some embodiments, users may for example, choose a purpose profile from one or more Experts, Stakeholders, other users and/or social networks with which to undertake, for example, collaborate and/or share, their purpose fulfillment operations.

For example, a user group may be trying to repair a bicycle, car, electronic device and/or the like. As they undertake their purpose operations, for example, as they try to diagnose the problem, users may experience an evolving of understanding of the components and related issues that make up the devices and the match of symptoms to problems, for example, through the direct and/or indirect assistance of others who have experienced these issues and/or have material issues related expertise. This may lead, for example, to an expert and their published resources and/or online, real-time assistance, which may provide an informing context leading to appropriate remedial actions that satisfy a user purpose set.

For example, in some embodiments, user (U1) may express (PE1) which through use of class systems and PERCos embodiment processing, may result in a set of resources (RS1) comprising some classes with a significant and/or sufficient correlation/relevance to PE1. For example, RS1 may comprise classes C1, C2 and C3. Each of these classes may have as members resources, expressed as C1(r11 . . . rn1), C2(r21, . . . , rn2), and C3(r31, . . . , rn3), respectively.

In this example, user U1 has experience of RS1 and selects member of RS1, R(x), to be part of their iterated purpose expression. In some examples this may lead to creation of a new purpose expression, PE2, where none of the terms of PE1 are retained in PE2 or a revised PE, where some of the terms and/or expression combinations of PE1, for example, designated as PE1(a), are retained. For example, if PE1 comprised CPE(Learn, Solar Cells), then PE2 may comprise, for example, CPE(Purchase, Solar Panels) or PE1(a) may comprise CPE(Learn, Solar Panels).

In this example U1 may elect to retain each PE and associated result set, so that they may traverse their “tree of understanding”, enabling them to consider differing selections and digressions as they, through experience of considerations and evaluations of RS develop further understanding of their purpose Domain.

This may include retention (through, for example, one or more storage means) by U1 and/or those resources associated with U1 purpose operations, the relationship information and/or result set, including the selections and decision trees of U1.

In some examples classes of a purpose Domain may have some members in common and where evaluation of classes has previously taken place, such relationships may have been enumerated and retained by classes and/or resources as members thereof, for example, through PIDMX and/or other retention methods. For example, in FIG. 1, PD21 and PD 22 may have resources/members in common.

In other examples, classes of a purpose Domain may be disjoint. For example, PD2, PD4, and PD5 are disjoint where each purpose Domain may contain classes specifying a set of resources associated with “Java” having differing and disjoint resource sets, for example, PD2 has resources for computer programming, PD4 contains resources associated with coffee and PD5 for an island of Indonesia.

When a user expresses a purpose expression for which PERCos does not have sufficient information, PERCos may evaluate the purpose expression to find a set of purpose expressions that are as “near” as possible. Consider FIG. 1. Some purpose Domains share some common purposes, whereas other purpose Domains do not share any common purpose. A user may specify a purpose expression that generalizes to a purpose class in purpose Domain PD3. Further suppose that there is no descriptive CPE associated with a PD3. In such a case, PERCos may consider PD1 and PD2.

Illustrative Example of Purpose Domains with Common Members is Shown in FIG. 1: An Example of Purpose Domains with Common Members

In some embodiments, purpose Domains are a special type of class that are focused on purposes.

In some embodiments, purpose Domains nomenclature may be standardized and may be aligned with one or more class systems. Such standardization may include, for example, descriptive CPEs which may be associated with purpose Domains.

In some embodiments, there may be associated tables comprising one or more purpose expressions, such as verbs and categories, which represent associations of one or more purpose Domains with other resources and/or resource portions, including purpose Domains. For example, this may include verbs, categories, CPE and/or other purpose expressions and/or metrics (such as, for example, weightings) indicating the relative strength, closeness, nearness, co-occurrence, frequency of occurrence and/or any other metrics.

In some embodiments such tables and the values they comprise may be used by PERCos embodiments purpose operations to determine relative utility of those resources.

In some embodiments there may be additional purpose expressions associated with purpose Domains, for example, in some embodiments, this may include PIDMX which comprise all the purpose expressions with which purpose Domain has been associated and the relationships between purpose Domain (as a resource) and other purpose Domains (as resources).

For example, PD1 may have associated descriptive CPE [Learn Math] as this PD is a resource for learning general math. In some embodiments, PD1 may often be used by multiple users in conjunction with PD2 which has descriptive CPE [Learn Physics] and consequently, for example, each PD PIDMX may have this relationship enumerated so that PD1 and PD2 may, in some evaluations be determined to be close/near.

In some embodiments, provisioning of a user purpose may take into account factors such as for example, the user's postulates, one or more stored profiles, preferences, contexts, such as the user's expertise in the purpose domain, and/or the like. For example, suppose a user is interested in exploring investment strategies. FIG. 2 illustrates the user having three sets of decision points. First decision point may be to specify the user's “what if Postulates,” such as the user supposing what happens if Greece will default and the stock market will go down as a result. The second column of decision points may be the user exploring the user's expertise level, such as supposing the user is an expert investor, knowledgeable investor, beginning investor, and/or the like. The third column of decision points may be to explore different types of investment strategies. Based on the cumulative decisions, PERCos can, for example, interact with one or more resource Knowledge Bases to generate a list of resources employed to fulfill user's purpose.

Illustrative Example of a User's Resource Selection is Shown in FIG. 2: An Example of a User's Resource Selection

In some embodiments, users may have interactions involving their beliefs, for example, as expressed as user specified constraints on purpose operations and/or as constraints included in their evaluation operations on results sets created through purpose operations.

In some PERCos embodiments, user experience and discovery are reflected in user horizons as they adjust over time and process events, including interaction and experience events during their pursuit of purpose.

Unfolding management, in some PERCos embodiments, comprises cross Edge management where user outputs direct the potential results sets that may satisfy their dynamically unfolding purpose operations during one or more iterations of purpose expressions.

Users may also have multiple iterative purpose expressions reflecting users developing understanding within their purpose operations.

For example, a user may be trying to repair a bicycle, car, electronic device and/or the like. As users undertake these purposeful operations, (for example, as they try to diagnose the problems), they may gain a fuller understanding of the components that make up the devices. For example, they may match the symptoms of their problems with those of other users/participants who have experienced these same or similar issues. This may lead, for example, to an expert and their published resources which may comprise the appropriate remedial actions to satisfy their purpose.

For example, user (U1) may create a purpose expression (PE1) which through matching to one or more class systems may lead to the creation of a Result Set (RS1), comprising those classes with a significant and/or sufficient correlation/relevance to PE1. For example, RS1 may comprise classes C1, C2 and C3. Each of these classes may have as members resources, expressed as C1(r11 . . . rn1), C2(r21, . . . , rn2), and C3(r31, . . . , rn3), respectively.

In this example, user U1 may interact with RS1 and select members of RS1, R(x), to be a further part of their iterated purpose expression. In some examples this may lead to creation of a new purpose expression, PE2, where none of the terms of PE1 are retained in PE2 or a revised PE, where some of the terms of PE1, for example, designated as PE1(a) are retained. For example, if PE1 comprised CPE(Learn, Solar Cells), then PE2 may comprise, for example, CPE(Purchase, Solar Panels) or PE1(a) may comprise CPE(Learn, Solar Panels).

In this example U1 may elect to retain each PE and associated result set, so that they may traverse their “tree of understanding”, enabling them to consider differing selections and digressions as they, through experience of considerations and evaluations of RS develop further understanding of their purpose domain.

This may include retention by U1 and/or those resources and/or resource portions associated with U1 purpose operations, the relationship information and/or result set, including the selections and decision trees of U1.

In some examples classes of a purpose domain may have some members in common and where evaluation of classes has previously taken place, such relationships may have been enumerated and retained by classes (including any ontological groupings) and/or resources as members thereof, for example, through PIDMX and/or other retention methods. For example, in FIG. 1, PD21 and PD 22 may have resources/members in common. Such information may also, or alternatively, be retained associated with user and/or user groups, associated Participant information set.

In other examples, classes of a purpose Domain may be disjoint. For example, PD2, PD4, and PD5 are disjoint where each purpose Domain may contain classes specify a set of resources associated with “Java” though with differing and disjoint resource sets, for example, PD2 has resources for computer programming, PD4 contains resources associated with coffee and PD5 for an island of Indonesia.

In some embodiments, these arrangements of resources may be made persistent and/or published, often in line with PERCos embodiments Constructs as Foundations, Frameworks, and/or the like.

In some embodiments, user's initial purpose expression(s) may be processed and subsequently retained over time for further periodic processing. This may include processing and purpose results sets that are built up over time, which, for example, may include the creation and/or iteration of associated classes and/or other organizational structures.

Such contiguous, sequential, periodic and/or other temporal purpose expression processing may include specification of purpose expression lifespan, for example, quantized by user/Stakeholders based on metrics that may include for example, utility/time/cost/sufficiency/group dynamics and/or the like.

Users may elect to have their purpose operations produce results sets in any time frame (and/or series thereof). For example, users may elect to have purpose operations deliver results sets immediately as, for example, they may need such results to respond to a query at that point in time. However, users may also elect to have that results sets extended, expanded and/or modified over a time period, which, for example, may be set by user/Stakeholder over time, where further results may be composited into results sets for user.

Provisioning a user purpose takes into account factors such as for example, the user's postulates, preferences, contexts, such as the user's expertise in the purpose domain, and/or the like. For example, suppose a user is interested in exploring investment strategies. FIG. 2 illustrates the user having three sets of decision points. First decision point may be to specify the user's “what if postulates,” such as the user supposing what happens if the Greek government will default on its debt and the stock market will go down as a result. The second column of decision points may be the user exploring the user's expertise level, such as supposing the user is an expert investor, knowledgeable investor, beginning investor, and/or the like. The third column of decision points may be to explore different types of investment strategies. Based on the cumulative decisions, PERCos interacts with its uncertainty knowledge base to generate a list of resources to fulfill user's purpose.

In some embodiments, users purpose operations may include the utilization of one or more autonomous or semi-autonomous agents as resources that may represent users in the intranets, extranets, and/or the web and user purpose seeking agents may trawls resource space for appropriate resources selected by user as expressed in a purpose expression such as a CPE or Purpose Statement.

In some embodiments these resources may provide functionality that, for example, enables users to retrieve identify, select and/or retrieve resources for users controlling the agents. There may also be agent resources that represent the users (in whole or in part) and may provide interactive capabilities for other users (and or their resources).

In some embodiments, a user set may select one or more PERCos Repute categories from a list arrangement. Such category selecting, for example, may use a faceting interface. For example, a user may select as a desired attribute for a Cred set to be applied as associated with a user's Core Purpose, “‘learn’ ‘molecular physics developments’” select logically presented options of expert types in physics, such as for selecting, selecting a desired authority certifying type for administering a certification and/or other validation of a claim of a professional positions: licensing authority, board certifications, fellowship completions, and/or the like; academic/technical/professional degree types, such as an AA, BA or BS, Ph.D. and/or the like; memberships, such as ACM, IEEE, NRA, ACLU, and/or the like; employment position types, such assistant professor, public middle school teacher, vice president, fireman, manager, director (title or board based), lieutenant, and/or the like; employment institution types such as university, college, corporation, non-profit, religious, consulting firm, government, and/or the like; employment institution ranking types such as nationally recognized, internationally recognized, regional, local, and/or the like; region of location such as global, specific hemisphere, continent, subcontinent (middle east, central America), nation, state/province, city; asset status types of categories, and subcategories of available categories as practical and circumstantially appropriate. An IU can, in particular employ such category types when specifying Repute EFs and Creds for creating an expertise and/or otherwise appropriate informed and prioritized list of resource candidates for further evaluation and/or selection of and/or interaction with.

Non-Limiting Sample Embodiment of a General Purpose, Extended, Constrained Verb Set

Variations on this embodiment may involve combining certain separate verbs as approximation

In one aspect, PERCos embodiments view computer operations as involving a simple duality: the interaction between users and computer processing arrangements. Users are able to contextually, relationally compute and respond (human thinking and action), for example, in a form that reflects approximation thinking. Computers involve a rather different class of digital and analog processes and supporting elements.

PERCos embodiments arrange the totality of resources supporting computer users in a manner that is responsive to human instructions. The PERCos resource architecture provides the computational components within this simple human/computer duality. It organizes a totality of resources as elements that can be selectively combined and arranged to fulfill user purpose(s), including providing purpose responsive human experience elements and/or other results.

PERCos resources may be provided in some embodiments, for example, in several different forms, for example: Formal resources, Implied resources, Ephemeral resources, and Compound resources (multiple of these forms may apply to a given resource instance and/or resource class, either as to one or more parts and/or as to the whole):

A Formal resource is, at minimum, comprised of (a) a persistent, operatively unique, identity (e.g. should not be ephemeral or intentionally temporary and unreliable as an identifier, along with any enforcement of this criteria depending upon the embodiment), (b) a subject matter that is the processing and/or processable material (including, for example, a human Participant descriptive information, and which may, for example, include how to initiate contact, or use, a Participant, for example, as a resource), (c) a formal publisher set (named, or otherwise identified as may satisfy a rule set, including having a persistent, operatively unique, identifier, for example, as above) for such resource, and (d) at least one associated and context providing purpose expression such as a CPE, except in embodiments employing at least in part Core Focus instead of a purpose expression set. Such resources are interpretable by at least one or more PERCos embodiments, and their subject matter may or may not be useable, depending on the presence or absence of necessary other resources and/or conditions. Such formal resources may contain or otherwise reference other descriptive metadata, such as author, provider, language, interface, user and/or other participant set usage history (for example, generally and/or as associated to one or more purpose expression, participant, association with other resources/resources, sets), and/or any Repute information as described as a capability of a PERCos embodiment, or, for example, of publisher, creator, provider and/or the like sets, for example, including associated use of Effective Fact (EF) and/or Faith Fact (FF) sets.

An Informal resource is, at minimum, comprised of (a) a persistent, operatively unique, identity (e.g. should not be ephemeral or intentionally temporary and unreliable as an identity), (b) a subject matter that is the processing and/or processable substance of the resource (including, for example, a Word Processor such as Microsoft Word, that can be employed in creating and editing documents), (c) an implied resource publisher—this may be an interpreted or otherwise inferred originating publisher of such resource, or this may be, for example, a different Stakeholder type such as a Participant provided and caused to be stored preference information indicating choice of Microsoft Word as word processor, or when a Repute Cred asserter—or if sufficient information exists—a Repute EF declarer stipulates that Microsoft Word is a word processor) or when a user stipulates, or a user PERCos Foundation has been employing, a local version of Microsoft Word as a word processor, and (d) at least one purpose expression associated with such subject matter as specified by such implied resource publisher either directly by such publisher, and/or indirectly by a resource Creator and/or other Stakeholder set. Such informal resources may contain or otherwise reference other descriptive metadata, such as author, provider, language, interface, user and/or other participant set usage history (for example, generally and/or as associated to one or more purpose expression, participant, association with other resources/resources, sets), and/or any Repute information as described as a capability of a PERCos embodiment, or, for example, of publisher, creator, provider and/or the like sets, for example, including associated use of EF and/or FF sets.

An ephemeral resource can be, at minimum, comprised of a non-persistent subject matter that is a separately identifiable processing and/or processable substance arrangement that is dynamically produced, provisioned, and then no longer maintained, or not maintained beyond a short, session operatively appropriate time frame.

Compound resources have all the characteristics of formal and/or informal resources, but are further comprised of a plurality of formal and/or informal resources. Compound resources may also, respectively, be formal (if all compounding resources are formal), or informal (if not all compounding resources are formal).

Formal, Informal and Compound resource are persistently associated with at least one identity, where an identity is operatively associated with at least one resource interface arrangement. A resource interface arrangement provides sufficient information to validly invoke operatively associated methods of a resource instance. Common kinds of values that may be named include data/contents, and/or specifications for such data/contents, hardware, devices, processes, software/applications, and/or networks. PERCos resources are any identifiable element within, or accessible to, a PERCos system that may directly participate in computer processing operations, including data, software, a service, firmware, hardware, a device, a Participant, and/or a combination of the foregoing resources in PERCos arrangements. PERCos resources may be organized, managed, and deployed through the use of purpose, resource element, and Participant/Foundation ontologies and class structures, facilitated by metadata associated with PERCos elements.

A PERCos embodiment is a network operating environment which enables purposeful computing, extending traditional operating system capabilities by uniquely enabling user expressions of purpose, and further employing apparatus and methods to optimally match user Contextual Purpose expressions (CPEs)—and any associated specifications (including user, and other stakeholder preferences and/or rules), metadata and/or Foundations, and/or the like—to resources available and/or on one or more networks. A PERCos system embodiment is designed to support the deployment of resources to provide user experiences that are responsive to user purposes.

With PERCos embodiments, users can intelligently and efficiently interact with a global, nearly boundless “purposeful network,” comprising an immense diversity of possible resources that are aggregatable and configurable as purpose-responsive arrangements. A feature of some PERCos systems is their organization, and management of all potentially actively contributing elements of a session as components of a logically unified resource infrastructure. Processing elements, any and all contributing forms of information, any and all contributing forms of network resources, device arrangements, Participants, and the like are uniformly treated as resources. Resources may be aggregated, and are identifiable, assessable, and deployable in response to user purposes, subject to specification and other operational context. Computer memory, devices, microprocessors, databases, software, services, networks, Participants, and other specification types may all be managed by PERCos resource Managers.

In some PERCos embodiments, management of resources is separated from the resources themselves, with both resource managers and resources being able to be arranged in any manner to suit purpose operations. These distinct arrangements of resources and resource managers are combined into operating fabrics, providing dynamically flexible support for unfolding purpose operations.

Purpose specifications serve basic functional roles in the information management of resources within PERCos. Operating systems traditionally supply applications that are suitable for pre-identified general activity types (word processing, spread sheet, accounting presentation, email, and the like). A PERCos system embodiment, in contrast, is designed to supply experiences and results corresponding to expressed purpose specifications by providing resource arrangements whose unfolding executions are specifically in response to purpose specifications.

To minimize the level of effort users need to expend to formulate optimal purpose specifications, a PERCos system embodiment may provide a range of Constructs, specifications, services, tools, and/or utilities. These may include, for example:

A suite of identity management services to enable resource discovery, evaluation, selection, and/or assembly to be undertaken efficiently without necessarily directly manipulating underlying resources.

A suite of information management services configured to discover, extract, and/or manipulate useful purpose-specific information from huge arrays of data that have been captured and published as resources.

A suite of other platform services and utilities, such as registration/publishing, resource information matrix, commercial flow management, and Repute services to identify candidate resources in fulfillment of Contextual Purpose expressions.

Resource arrangements that may include Constructs of varying granularities that enable one or more users/Stakeholders, and/or systems to develop, identify, and/or prioritize rich, nuanced, and highly-responsive purpose operations leading to user purpose satisfaction through purpose experiences.

A suite of Coherence Services that may detect and/or attempt to rectify a wide range of limitations, imperfections, and/or exceptions, including, for example, inaccuracy, lack of clarity, incompleteness, inconsistency, inefficiency, suboptimal selections, and/or requests for unavailable resources.

A suite of Repute and resonance services to support optimization as to quality of purpose and purpose resource alignment for purpose Satisfaction. These services may lead to superior purpose experiences that integrate the interests of direct and indirect stakeholders.

A PERCos system embodiment takes purpose specifications and ascertains their validity to identify optimal arrangements of resources whose unfolding execution may provide experience and/or results that correspond to purpose specifications. Initially candidate specifications may possibly be incomplete and/or describe resources in abstract/general terms and/or contextually. In such an embodiment PERCos embodiments processing may evaluate, align, resolve, cohere, refine, filter, prioritize and/or otherwise operatively manipulate resources and their specifications (including any associated information sets) to ascertain the validity of such purpose specifications. In some embodiments, a PERCos system may use Coherence Services to validate purpose specifications.

A PERCos system embodiment may also check the availability of the identified resources. For example, such embodiments may check that a user has sufficient authorization to access one or more resources and that such resources are not already operatively committed by one or more conflicting uses. If appropriate, Coherence processes may interact with the user and/or Stakeholders for clarification and/or elaboration. For example, suppose that the user is not authorized to access some resource, and Coherence cannot find an alternative or substitute resource. In this case, the embodiment may then request the user and/or Stakeholders for further guidance.

A PERCos system embodiment may take a resolved and cohered purpose specification, allocate those resources that are available, and request reservations for the rest (for example, through PERCos resource reservation systems described in this disclosure). In some embodiments, the PERCos system may also generate operational specifications that have sufficient resource specifications and instances to provide an experience corresponding to the purpose specification. Some purpose specifications may require a given level of performance and reliability; some others may require a high degree of security and/or privacy. In some embodiments, a generated operational specification may comprise resource arrangements, such as Frameworks, resource assemblies, resource Foundations and/or other aggregations of resources that have previously been created and utilized.

Resource arrangements, together with suitable methods for accessing them (e.g., getting, setting, and modifying their values) may be used to construct “more abstract” resources and manage them. Thus, resources may be dynamically assembled into new resources for inspection, analysis, selection, and/or deployment purposes.

This disclosure describes a PERCos resource Management Systems (PRMS) that may be used in some embodiments of PERCos systems. A PRMS embodiment is configured to provide and manage arrangements of resources in accordance with Contextual Purpose Expressions and other PERCos information arrangements so that users may experience, store, and/or publish computer sessions and/or session elements that provide the best fit to the their purpose statements. PRMS embodiments provide a highly scalable and extensible resource architecture that allows PERCos systems to manage all types of resources, regardless of their size, complexity, diversity, location, format, and/or methods of creation and to treat them uniformly. Such a PERCos resource architecture enables PRMS to uniformly organize and process databases, computational processes, networks, Participants and specifications, including providing common service and/or resource management interfaces for individual and/or aggregations of resources in a seamless manner.

A PERCos resource architecture embodiment also enables aggregations of resources to be arranged and combined with a resource interface to create a composite resource. Composite resources, in turn, may be arranged with other resources and resource interface to create even more capable composite resources, ad infinitum. This enables users and/or other stakeholders to create and use resources at any chosen level of granularity.

A PERCos embodiment may include a PERCos Information Management System (PIMS) that may enable users (novice or expert) and/or other stakeholders to describe, capture, and organize information about resources, including metadata. A PIMS embodiment is fundamentally extensible in its ability to represent any form of resource that may be created. Organizing resource information through the use of PIMS enables resources for user purposes to be discovered and managed more efficiently than in existing forms of resource organization, management, and identification, which do not directly support user purposes. PIMS enables resource-related information to be organized in correspondence with CPE expressions and/or elements, regardless of their location. This allows users' purpose statements to be provisioned optimally without arbitrary constraints on the location or publisher of the resources used.

PRMS embodiments accept operational specifications that request levels of service from classes of resources. Such an embodiment checks accessible resources to determine the most suitable arrangement of available resources. (In some embodiments, PRMS may use Coherence Services, to harmonize the operational specification with the accessible resources.) Based on its determination, the embodiment may negotiate and establish one or more operating agreements that specify resource provisioning, including levels of services and/or methods to be supplied by each resource. Negotiated levels of service and methods may be explicitly specified by, and/or implicitly derived from, purpose statements, and may specify in some embodiments, for example, performance, functionality, reliability, redundancy, confidentiality, integrity, and/or other characteristics. PRMS embodiments may then manage and monitor the performance of resources to ensure their compliance with the negotiated operating agreements. In the event one or more resources fail to perform, PRMS embodiments may take appropriate actions, for example, executing corrective measures (e.g., replacing failing resource(s), adapting to event based circumstances), notifying and/or requesting action from appropriate processes, users, and/or other stakeholders.

PRMS Reservation Services, in collaboration with PIMS and/or PERCos Platform Persistence Services, enables the scheduling of resources, regardless of whether they are active, inactive, disconnected, or unavailable. PRMS Reservation Services also allow resource metadata to be persistently available for resources that may not be currently available for use. PERCos processes and/or services may use this same capability to resume their processing after pausing, and for example, using the PERCos Platform Services to persist part or all of their operating states, in a manner suitable for resumption and/or other processing.

PRMS embodiments may also allow users to reserve resources—for example, resource sets in the form of Frameworks and/or Foundations—that may not be operating and/or available at the time of reservation. Users may benefit from seamless reconfiguration of their Foundation resources. For example, a user may have one or more mobile devices as part-time elements of a Foundation—for periods of time, they may be inactive or disconnected. A user may arrange to reconnect disconnected mobile device(s) with minimal interruption to their operating experience, by reserving the mobile device(s) in advance. For example, if a user might use PERCos embodiment on an office desktop to obtain a contextual purpose experience, then leave the office and still continue to obtain the experience, without interruption, on a reserved mobile device.

PRMS may provide mechanisms for recording resource-related information, which includes those resources with which a resource has interacted and may include information such as performance, component configurations, activities, statistics, operational results, and purpose, class, and performance metrics. This information may, in whole or in part be based on the resource's recording specification.

Some PRMS embodiments may enable resources to have associated Repute information about themselves, and/or other resources with which they interact. For example, this may include assertions regarding some or all of a resource's performance, security, reliability and/or other operating characteristics, Repute information regarding CPEs, and/or the degree to which resources contributed to purpose satisfaction.

In some PERCos embodiments, a resource may comprise one or more identifiable elements that may be employed, or otherwise directly participate, in PERCos computer processing operations. Resources include “information resources,” “computational resources,” “communication resources,” and computer representations of users (Participants) and their actions. Any specifically identifiable element whether locally known or unknown can be made into a PERCos resource. Such an element may be (or refers to) any process or item, internal or external, and/or any algorithmic combination thereof. Common resource embodiments are specifications of content, hardware, devices, software, services, Participants, networks, and/or arrangements of the foregoing. PERCos embodiments flexibly support the organization, Provisioning, and purpose-related Governance of a potentially boundless collection of possible resources, often with the goal of achieving optimal responses or response candidates to purpose specifications.

In some PERCos embodiments, a resource has a persistently associated identifier and at least one resource interface. Common kinds of resources include specifications of content, hardware, devices, software, services, and/or networks.

The information in a PERCos system embodiment is accessed, processed, and stored by resources. Ultimately, all resources are about the results of information and/or information handling and/or processing: its generation, representation, storage, retrieval, consequences, and the like. Except at the user interface, users need not perceive the physical apparatus and method embodiments and processes involved in a PERCos system, only that appropriate inputs lead to corresponding outputs, with (if applicable) a stated degree of trustworthiness/security/reliability and/or other result.

A PERCos resource interface (PRi) provides sufficient information to validly invoke methods of a resource instance. Resource interfaces may include organizational, control and/or interface (including communication protocols) specifications and access to its method specifications and instances.

Resource interfaces may be standardized and interoperable, for example, providing standardized interfaces for resource Roles.

Resources may request operations of other resources by invoking method embodiments available through their resource interfaces. This enables resources to interact with each other in an “information handling ecology.”

Additionally there may be further specifications, including identity and resource characteristics specifications which are available (in part or in whole) to other resources, subject to agreed terms of interaction between the resources.

Resources may be comprised of any number of resources and/or resource elements. Conversely, a resource may be an element of any number of other resources, resource assemblies, Constructs and/or other resource arrangements. As instances they may be dynamic and have resources added, removed, and/or replaced.

As is described below, in some embodiments, resources may be arranged into PERCos Constructs.

A resource's behavior is characterized by its resource interface, and may be further enhanced and modified by further relevant specifications. This may include, for example, PERCos resource characteristics specifications, contextual purpose specifications, control specifications, Coherence specifications, resonance specifications and/or any other specifications. These specifications may be persistently or dynamically associated with resources.

For example, a resource may be characterized by a descriptive CPE, which has been provided by, for example, a resource publisher. Such embodiments may then be further modified by resource interface(s) and/or relevant specifications. Elements of a resource interface embodiment may be embedded in and/or referenced by resource metadata, and/or determined by applicable specifications.

In some embodiments, the resource interface determines to what degree, if any, access and/or interaction may be undertaken with the component suite instance of that PERCos resource interface.

For example, as illustrated in FIG. 3, Illustrative example of resource Interface.

PERCos resources comprise at least one resource interface and, in some embodiments, may include one or more elements. An element is an operational unit that is identifiable within PERCos. An element may or may not be a resource. Elements of resources may, for example, include one or more specifications, other resources and/or processes.

In some embodiments, there can be opaque resources and transparent resources. Opaque resources are resources in which their respective resource interfaces do not provide any methods for direct access to the underlying component resources. A transparent resource has one or more methods that provide direct access to resources and/or resource elements comprising that resource. Between these two extremes is a translucent resource, which has one or more methods for accessing some resource elements comprising the resource but these methods are filtered by the resource.

For example, a particular PERCos embodiment might have a purpose class application resource that helps a user select a resource that may best serve the user's purpose. The resource elements of this purpose class application might be several different resources that meet the purpose associated with the purpose class application in different ways. The purpose class application may have an interface that may guide a user to select and use the best resource for his particular purpose. However, if the user already knows which of the component resources best meets his purpose the purpose class application also has interfaces that allow the user to directly interact with the resource element of his choice.

For example, as illustrated in FIG. 4: Example resource 1 (Laptop Computer).

For example, as illustrated in FIG. 5: Example resource 2 (Transparent resource Interface)

A resource may also participate in the resource element suite of one or more other resources (e.g., a single disk may provide multiple partitions; a single processor may run multiple services).

When a resource is invoked, via its resource interface, it is not relevant to the invoker how the results are obtained—that is internal to the invoked resource. The invoker needs to know only that results are in accordance with the resource interface specification.

Common types of resources include CPEs, specifications, processes/services, Participants, data/content, hardware, devices, software/applications, communications media (such as a 1 mbit pipe) and/or any other PERCos expressions, and/or any other non-PERCos logical and/or physical elements, and the like.

In certain embodiments, resources comprise or otherwise reference resource interface and resource elements. Resource elements may comprise PERCos resources (PR) and non-PERCos resources (NPR). Non-PERCos resources are those without a currently available PERCos resource interface. Frequently, an arrangement of resources (and/or identifiers (e.g. UIDs) designating resources) is used to form one or more resource elements that comprise part of a higher-level resource.

In some embodiments, PERCos may interact with non-PERCos resources, when a PERCos resource interface is instantiated. This may occur through, for example, the use of a specialist resource type known as an assimilator utilizing an NPR specific method set known as a transformer.

PERCos resource interface embodiments may also be created by PERCos resources, to manage their interactions with non-PERCos resources. The degree to which PERCos resource interfaces (PRI) integrate with non-PERCos resources may be chosen by PERCos. In some embodiments, a PERCos resource may interact with non-PERCos resources, subject to appropriate communications being established, directly and/or through PERCos resource interface.

For example, as illustrated in FIG. 6, Illustrative example of an (NPR) interaction through PERCos resource Interface.

In the FIG. 6, the Participant may interact directly through invocation of an appropriate communications protocol and associated method(s) (in this example the HyperText Transfer protocol (HTTP) and a Browser) with a non-PERCos resource and/or may utilize the PERCos resource interface for that interaction. In either case, the non-PERCos resource interacts with PERCos only through its own communications capabilities.

If a PERCos resource uses the PERCos resource interface with a non-PERCos resource, then the PERCos resource may gain aspects of the resource interface and treat the NPR as if it were a PERCos resource. In one example, a PERCos resource tracks and manages all the interactions with a non-PERCos resource, such as a general purpose search engine like Google.com (Google™ is a Trademark of Google Inc.).

The degree of interaction may range from a simple identification of the NPR, through full integration with the PERCos resource interface.

PERCos resource Management System (PRMS) embodiments provide a dynamic environment that manages specified sets of PERCos resources, in whole or in part, as part of one or more PERCos operations.

Resource managers negotiate with operating session managers and/or other authorized processes so as to create an operating agreement. Operating agreements define the levels of service that an operating session can and may be committed to provide. Resource managers may interact with their respective information management system, such as PERCos Information Management Systems (PIMS) to obtain information on the specified resources, such as associated purpose expressions, publishers, Reputes, resource interfaces, functional capabilities, performance attributes, administrative requirements, control information, and the like, to assess its ability to monitor and comply with the requested levels of service. If a specified resource is a composite (i.e., an arrangement of resources), a resource manager may obtain information about the component resources that constitute the arranged resource. For example, suppose a laptop computer (for example, a Sony™ VGN-Z520 computer) is a composite resource. In such a case, a resource manager may obtain information about the component resources of the laptop computer, such as its NVIDIA driver, to determine whether or not the resource manager can provide the desired level of video image processing.

Resource managers embodiments are responsible for managing their respective set of resources to ensure that they satisfy their respective operating agreement(s). As with resource provisioning, resource managers may perform the management task in a recursive manner. A top level resource manager may divide the provisioned resources into a group of smaller “resources” and delegate the management of each group to a lower level resource manager instance.

Each resource manager instance, accepting the management task, monitors those resources under its responsibility. If a resource faults for whatever reason, the resource manager instance determines and performs the corrective actions, such as finding replacement resources and/or notifying appropriate process.

PERCos resource Manager Services (PRMS) may use a range of methods to satisfy an operational specification. One method, for example, is to split the operational specification into a set of “smaller” operational specifications in such a manner that the set of sub-operational specifications collective produce the same and purpose results as the original operational specification. Another method is to provision the specified resources in a recursive manner.

A top level resource manager instance, receiving an operational specification, selects the method based on factors such as the location of specified resources, levels of services that may be required for each specified resource, and the size of the resource set. For example, suppose the specified resources are from multiple organizations and located across multiple networks. Further suppose that the multiple organizations have widely different administrative requirements for the use of their respective resources. In such a case, the top level resource manager instance for example, may decide to delegate to lower level resource manager instances, one or more lower level resources to support each organizations administrative and/or operative requirements.

Part of delegation processing includes negotiating with a lower level resource manager a sub-operating agreement with which the lower level resource manager may comply. For example, in one embodiment, a top level resource manager instance may delegate the provisioning of a Foundation as part of the operating session. In such a case, the top level resource manager instance and the lower level resource manager instance may negotiate the levels of service that the Foundation resources may provide to ensure the fulfillment of the purpose expression.

Lower level resource manager instances also have the option of performing their respective tasks in a recursive manner. In addition, a lower level resource manager instance has the option of notifying its superior resource manager instance that it cannot perform its delegated task for some reason. One reason may be that it itself does not have sufficient resources to perform the task. For example, the task may require that the lower level resource manager instance use a high-powered encryption service, to which it does not have access. Another reason may be that a resource specified by the task is not available and it cannot find an alternate resource. In such cases, its superior resource manager instance may need to find an alternate lower level resource manager or resource. If the superior resource manager is not the top level resource manager instance, then it also has the option of notifying its inability to perform the task.

This organization of resources and resource elements into classes enables PERCos embodiments to define interoperable, dynamic relationships between resource-related classes. For example, a method suite class instance of method suite class may have a relation, “is implemented by” with component suite classes, where the set of methods in the method suite is implemented by components in the component suite class instance of a component suite class. Conversely, a component suite class instance of a component suite class may “implement” one or more method suite class instances. Resource interface class instances may include one or more component suite class instances and one or more method suite class instances.

FIG. 7 shows an example resource instance that is an arrangement resource interface instance and resource element suite instance. This example resource interface instance, in turn is comprised of a PERCos identity Matrix (PIDMX which is described further in this disclosure) instance, kernel session instance and method suite instance. This example resource element suite instance is comprised of component resources and PERCos platform resources.

For example, as illustrated in FIG. 7, An Example Structure of a resource Interface.

Such organization of resources into classes enables utilization of many features of PERCos class system. Thus for example, a class system is a buffer against the scale of a boundless collection of resources and is a powerful tool in Approximation Computing. A class system may have hundreds of thousands or millions of classes but since class systems may substantially be used to represent conceptual neighborhoods for interfacing with user purposes (and/or users). Frequently class systems may have permutations and/or be comprised of a constrained set of logical neighborhoods. Such constrained arrangements may be at least in part specified by acknowledged Domain experts, for example, functioning as Domain standardization/specification sets. Such class systems logically may be at least in part organized by, or otherwise include information associating resource classes and/or instances with, purpose expressions such as CPEs. Such purpose expression information may itself be correspondingly organized in class systems and both such class systems, as well as for example, crowd user data and/or Participant, Repute and/or Domain/category class systems may populate a common class arrangement populated at least in part by appropriate cross referencing. By starting a search for a resource that meets a purpose, with a search for the class that most likely contains the desired resource, PERCos enables the possibility of reducing a search space by several orders of magnitude.

Some embodiments of PERCos class systems may be relational, or may interface with other relational information organization structures (such as one or more relational class systems), to infuse such one or more embodiments with purpose related flexibility, which enhances user relational/conceptual navigation and evaluation processes. Thus for instance, the Open Directory Project (DMOZ, www.dmoz.org) is an ontology that implements certain relational organizational principles that can be similarly employed in PERCos purpose, resource, Participant, Repute and Domain class arrangements. A user of DMOZ interested in virtualization on Intel machines can traverse to a variety of computer virtualization solutions (VMware, Virtual box, QEMU) in three simple and natural hops (Computer→Emulators→Intel x86 architecture). In a PERCos class system, the user could also use relationships other than the class hierarchy relationships to traverse the class system. This may be particularly useful in user cross Edge evaluations of purpose, resource, Participant, Repute and Domain approximation neighborhoods represented individually and/or in combination.

PERCos class systems may, in some embodiments, introduce their own standardized structured vocabulary for describing instances. To illustrate this, consider a user who wants to learn about Virtual box virtualization where the host operating system is Linux and the guest operating system is Windows. Asking a keyword-based search engine to find this type of information can be time-consuming and frustrating, because a keyword of “Linux” is ambiguous in this search; the “Linux” keyword can either represent the host or the guest operating system. As a result, the user may need to filter out retrieved results where the keyword matches because the Linux operating system is the guest operating system. This ambiguity would even occur if we assumed that the term “Linux” was totally unambiguous by itself; the ambiguity is not an issue with the different meanings of the “Linux” keyword but an issue with the relationship (e.g. guest vs. host) between the Virtual box and Linux. Thus ref/sense processing may not help in this situation. In addition, it may be that the user gets very different results by replacing Linux with nearby concepts such as Ubuntu (a Linux variant) or Redhat.

PERCos embodiments address this inadequacy by enabling the user to interactively unfold the user's purpose. The user forms a purpose expression of “learn Virtualbox.” In addition, the user specifies a sophistication Facet of user variable Master Dimension to be moderate and a Repute Master Dimension of resources to be those whose authority is validated by Oracle Inc., the developer of the Virtualbox implementation.

The PERCos embodiment takes the user to the one or more neighborhoods of a “learn Virtualbox” waypoint and/or purpose class, or to any appropriate super-classes and/or super-waypoints, which is an interim result that may enable the user to perform additional exploration. In this case, an appropriate superclass might be a purpose class involving virtualization solutions in general which would include both Virtualbox and VMware. For either of these waypoints/classes, PERCos may provide additional information, such as, acknowledge Domain experts may have used the vocabulary of the PERCos class system to declare two Facet lists. One Facet list represents host operating systems (the operating system being used to run the virtualization solution) and the other Facet list represents guest operating systems (the operating system being emulated by the virtualization solution) operating system for the Virtualbox. The user can specify a guest operating system of “Windows” and a host operating system of “Linux” which may focus their experience on the Virtualbox platform that she is interested in learning about.

In some embodiments, class systems that include purpose classes may enable expressions of a wide variety of purposes and relationships. Such a purpose class system can include attributes that allow publishers to link resources which may populate one or more resource class arrangements, which may be comprised of inherited, declared, and/or inferred members, to purpose classes and/or members in one or more purpose class systems. By providing one or more well-defined standardized expression languages, PERCos embodiments can enable users and/or Stakeholders to formulate purpose statements that facilitate the maximization of the opportunity optimization.

PERCos, in some embodiments, provides unified, integrated, extensible purposeful computing Constructs. These Constructs are combined, standardized, and interoperable arrangements of PERCos resources. Resources may be combined in arbitrarily large and complex assemblages in pursuit of purpose satisfaction. In some embodiments, PERCos Construct templates provide a method of composing a set of resources, with their own descriptive specifications, resource interfaces, prerequisites, and/or other metadata into a single Construct resource, with its own descriptive specifications (CPE), resource interface, prerequisites, and/or other metadata. In some embodiments, Constructs comprising one or more component resources may be created by other processes.

Constructs embodiments enable users to efficiently and effectively create, build, arrange and/or instantiate specification arrangements that can be evolved, resolved, cohered, and/or transformed into operating Constructs in support of the pursuit of their purpose(s).

Constructs are declared, publishable specifications for providing users/Stakeholders, publishers, and/or acknowledged Domain experts which enable express optimal standardized and interoperable resource arrangements for fulfilling purposes.

Constructs may, in some embodiments, be created by users/Stakeholders including for example, publishers, and/or acknowledged Domain experts to provide other users/Stakeholders with optimal sets of resources and/or purpose-specific capabilities to aid them in their pursuit of purpose. Constructs may include, for example, Foundations, Frameworks, purpose class applications, and the like. Constructs may also be created by publishers to provide highly specific resources for one or more purpose operations. This may, for example, include resource assemblies.

To support a wide range of purposes, from those that are highly general, such as “exploring mathematics,” to those that are much more specific, such as “purchasing fishing lures for Bass in Lake Tahoe,” Constructs are intended and designed to be highly expressive, standardized, interoperable, and extensible. Constructs can range from highly general to narrow and specialized. For example, a user can create a highly general Construct to explore western music, or a highly-specialized Construct to analyze Beethoven piano sonatas.

Users may also create a single Construct that supports a range of purposes, from highly general to specific, by providing multiple Construct interfaces. Construct interfaces can be used to specify sufficient purpose metadata, such as descriptive Contextual Purpose expressions and/or Dimensions, to facilitate efficient matching of resources to users' prescriptive CPEs. In some embodiments, for example, users may use Dimensions to filter and/or reduce Result sets to those results (resources) with a high similarity to their expressed purpose. For example, suppose a publisher created a purpose class application for “learning analog audio electronics” intended to provide an introduction to this purpose domain for users with limited experience. The Construct interface of this purpose class application may have Dimensions and Facets enable a user to select values such as “Beginner” and “Simple”. In such an example, the match of user purpose to publisher purpose may be close to ideal, subject to the user's experience with the purpose class application.

Constructs embodiments may provide, in whole or in part, purpose unfolding operations, for example, in support of purpose formulation, e.g. supporting users/stakeholders in their expression of purpose, navigation and/or exploration and/or other associated interactions.

Some PERCos embodiments may use PERCos resource architecture to enable standardization and interoperability of computing elements that can be systematically combined and/or arranged into Constructs that support purpose operations.

Although any Construct may be used to support differing degree of generality and complexity of purposes, some Constructs may be better suited than others. The table below illustrates potential uses of each of the Constructs.

Any and all of these Constructs may be used in combination as each constitutes a resource.

Constructs in some embodiments may also include, by reference and/or embedding, other specification sets that express purpose and/or other metadata (such as descriptive CPE) associated with the Construct.

Constructs may be of arbitrary complexity, and is associated with at least one specification that specifies at least one resource. Constructs may, for example, may require further processing, such as, for example, by PERCos SRO processing (which is described in further detail in this disclosure), such that applicable and appropriate resources are suitably provisioned.

A PERCos operating agreement is a negotiated Outcome. The PERCos operating agreement is expressed as a PERCos specification wherein resource managers and/or other operating session managers have agreed (implicitly and/or explicitly) to deployment of related levels of service and/or performance of specified resources, which are to be managed in accordance with the specifications comprising the operating agreement(s).

An operating agreement embodiment is a specification that has been implicitly and/or explicitly acknowledged and accepted by one or more resources. This may include sets of resources, including Constructs, where, for example, a single operating agreement is negotiated for and by the Constructs, Construct resource managers (and/or their delegate processes, for example, PERCos SRO processes) then implement appropriate operating agreements for resources comprising such Constructs. An operating agreement comprises an identified set of resources, service performance and/or resource management metrics within a common agreed specification.

In some embodiments, each resource identified by an operating agreement may be specified to operate at defined levels and conditionality of functionality. As an example, an operating agreement might specify high levels of service availability, reliability, security, and the like depending on Participant specific qualifications and/or the specific nature of the specified initiating user purpose statement(s). A PERCos resource Management System embodiment may, for example, determine that the resource management needs to implement this requirement as a set of redundant services to ensure availability of at least one of the redundant services.

PRMS may interact with Coherence Services to negotiate, establish, harmonize and/or manage resources on Participants' and/or other Stakeholders' behalf, and as a consequence, implement operating agreement provisions, which may include, for example, specifications for resource management, persistence, recovery from service delivery failures and/or arbitration between specifications.

In some embodiments, computer Edge processing may interact with users to evaluate and interpret their inputs, such as tokens representing ref/senses, to generate internal representations/structures, such as class expressions. Computer Edge processing embodiments may support users with one or more intelligent tools to assist them in expressing their purpose intent. For example, computer Edge processing embodiments may enable users to express their purpose intent by providing services, such as PERCos navigation interface that uses classes, Facets, PERCos templates, and the like to specify their Core Purpose comprising one or more verbs and one or more categories, and then refine it iteratively. Based on the user context, which may be established for example, by interacting with Participant processing embodiments, they may provide users with one or more appropriate standardized and interoperable lexicons, which are collection of tokens appropriate for some audience (e.g., English and/or Greek words, ASCII, Braille, or icons) and purpose domain (e.g., broadcast communication, box scores, parsing, science, organic chemistry, auto mechanics, plumbing).

In some embodiments computer Edge processing embodiments may enable users to modify and/or refine existing purpose expressions published by other users/Stakeholders such as, acknowledged Domain experts, and, for example, identified and sourced by PERCos intelligent tools, thereby optimizing user purpose expressions through leveraging the expertise of acknowledged Domain experts. For example, consider a user who may be interested in exploring financial investment. Rather than expressing the purpose expression from scratch, the user could find a purpose expression that is nearest to the user's intent, such as, a purpose expression that explores different types of investments, ranging from fixed investment, a growth investment, and target-date retirement funds.

Participant processing embodiments enable users to interactively and iteratively establish their initial user context, which may be modified by subsequent processing, such as purpose formulation processing, SRO-S processing, and/or further PERCos processing. Initial user context may include information such as, a Participant Role a user wishes to use for such purpose operating session, applicable Master Dimensions, Master Dimension Facets, auxiliary Dimensions and/or further contextual information. Users may also provide authentication and authorization information, if appropriate. Participant processing embodiments in general operates in parallel with computer Edge processing, which evaluates and interprets user inputs into internal representations.

Purpose formulation processing embodiments iteratively interact with users to generate one or more purpose specifications that are the “best attempt” (after interacting with PERCos) by users to frame their respective purposes. They may generate purpose specifications by incorporating applicable contextual information, such as, without limitation, Master Dimensions and Master Dimension Facets, resonance, Reputes, Governance, and crowd data. For example, some users may have their user characteristics, historical data stored in an information management system, such as, PERCos Platform Information Management Systems. Purpose formulation processing embodiments may retrieve and evaluate such contextual information and incorporate that information that is applicable in generating the purpose specification. They may also try to improve purpose specification by using applicable resonance algorithms, if available. If they encounter possible problems, such as, ambiguities, conflicts, and the like, they may interact with Coherence service instances to resolve them. If they cannot, then they may request guidance from appropriate processes and/or users. Users may also provide additional contextual information, such as, for example, augmented Dimension values, such as, a preference for comprehensiveness of Outcome over speed of response time.

For example, as illustrated in FIG. 8, Illustrative example of the PERCos purpose cycle.

In some embodiments, Specification, Resolution and Operational (SRO) processing comprises one or more integrated sets of processing that evaluate, resolve, transform, and/or cohere purpose specifications to generate one or more resolved, cohered, and provisioned operating specifications that have sufficient information to initiate the launching of one or more operating sessions. SRO processing utilizes PERCos Platform Services, such as, for example, Coherence Services, Evaluation and Arbitration Services, Test and Result Services, Repute services, and the like provide its services. SRO processing may also use intelligent tools, such as PERCos Information Management System tools that they may use to leverage knowledge captured from past experiences. It generally performs its services in three phases: specification, Resolution and operational.

SRO-S processing embodiments evaluate purpose specifications and may incorporate relevant contextual information, such as, user Master Dimensions and Facets, user historical information, resonance algorithms, Foundations, governance, crowd data, and/or other information, such as, additional user purpose relevant profile information. SRO-S processing resolves and integrates these specifications, often in collaboration with one or more other PERCos platform processes including Coherence to generate a purpose statement that is sufficiently complete to determine its satisfiability (i.e., discover “available” resources to fulfill the purpose statement). The purpose statement may also include the user's contextual information (e.g., her level of expertise in a particular purpose Domain).

SRO-S processing embodiments may evaluate applicable governance rules to ensure that they are compatible with the user's purpose and context. For example, suppose a user is an employee of an organization that may have governance rules on resources the user may access, such as prohibiting the use of “insecure” resources that may tamper with the organization's resources.

SRO-S processing embodiments may also evaluate the user's Foundation resources to check that the resources can support the user purpose. For example, SRO-S processing embodiments may check that the platform the user is using is compatible with any data rights management requirements specified by the relevant resources to fulfill user purpose.

SRO-R processing embodiments take a Purpose Statement, generally generated by SRO-S processing, and generate an operational specification that specifies one or more resource sets that can fulfill the purpose statement. SRO-R processing interacts with one or more resource management systems, such as, PERCos Platform resource Management Systems (PRMS) to assign, allocate, and/or reserve resources that are suitable for fulfilling purpose statement. In some cases, SRO-R processing may request clarification and/or elaboration from users/Stakeholders, for example, in an iterative and or recursive manner. For example, consider the case where a user is not authorized to access some resource. In such a case, if SRO-R processing cannot find an alternative or substitute resource, it may request guidance from users/Stakeholders to resolve the conflict. This may, in some cases, require modification and/or re-specification of the purpose statement, or even CPE itself. Another example may be where the user has insufficient expertise to evaluate the resource opportunities and SRO-R processing may invoke one or more other processes, such as, one or more resonance algorithms that may offer one or more Constructs providing optimized resource arrangements that may better satisfy users purpose statement.

In some embodiments, SRO-O processing undertakes the provisioning, deploying and/or instantiating resources specified by the operational specifications and subsequently initiates launching of one or more operating sessions (including initiating resources into operating resources and/or invoking one or more processes and/or services) as specified. SRO-O processing may in some cases, create multiple other user purpose operation sessions and provision them with the launched operating resources.

User purpose operation sessions interact with users to provide them with one or more interim and/or final Outcomes that in part or in whole meet their respective purpose specifications. Operation sessions may also include the negotiation of one or more operating agreements with PRMS operating managers that can specify levels of performance of one or more resources, processes and/or services in pursuit of purpose expression.

Such operation sessions may enable users to manage their sessions, such as suspend, resume, replay, persist, and the like. For example, users may opt to persist one or more operating sessions in order to publish them as resources. Alternatively, for example, users may persist/suspend their operating sessions in order to be able to restore/resume it at a later time. Users might terminate one or more operating sessions because they may be satisfied and/or reached a conclusion, and/or the user has for other reasons decided to terminate the session.

In some embodiments, purpose cycle processing may be iterative, recursive, serial, parallel, asynchronous, synchronous, preemptive, multitasking, multi-threaded, and/or employ other multi-Dimensional methods for resolving users' purpose expressions to Outcomes. For example, one or more specifications (including purpose expressions, purpose specifications, and purpose statements) may be modified either by users/Stakeholders and/or by one or more PERCos processes.

For example, PERCos SRO-S processing may encounter a conflict when generating a purpose statement. At this point, SRO-S processing may invoke Coherence processing to resolve the conflict, however where it cannot, it may provide information regarding the conflict and/or potential solution/opportunities to the processing (including the management thereof) from which the specification originated, for example, in this case purpose formulation process. Purpose formulation processing may represent this information, including the affected purpose statement in a manner suitable for user interaction. This may include the conflict, opportunities for the conflict resolution, guidance as to potential optimizations and/or rationalizations for the users expressed purpose.

For example, SRO-S processing may not be able to resolve possible ambiguities in purpose statements. For example, suppose a user specifies a purpose to learn about Java. There may be multiple ref/senses that contain the term “Java”, such as coffee Ref/Sense, programming ref/sense, island ref/sense. SRO-S processing may attempt to resolve this ambiguity by evaluating the purpose expression. SRO-S processing may request for elaboration of the user's intent, such as Java as in a type of coffee, programming language, or an island.

A PERCos operating session is a set of managed functioning operating resources providing PERCos-related purposeful cross-Edge user interaction. As illustrated below (FIG. 9, FIG. 10) an operating session is initiated from a set of specifications, such as, control, organizational and interface specifications, that define the functionality of such operating session, and unfolds until users/Stakeholders interventions and/or satisfaction, termination, and/or other completion of the session's PERCos processes. Participating processes may take place in one or more users purpose operating sessions (including, for example, cross-Edge processes), in and/or among users' accessible computing arrangements, and/or in other available computing arrangements (e.g., computational clouds). The set of specifications may specify the composition and/or organization of operating session interface, which can be anything from a minimal set of interface elements to a full complement. Depending on the embodiment and/or the operational environment, the operating session interfaces may operate distributed, peered, hierarchical arrangements and/or in any combination thereof. For example, in FIG. 9, a single operating session interface provides the interface, whereas in FIG. 10, the interface is provided by multiple operating session interfaces, two of which operate in a peer-to-peer relationship and the other two in superior-subordinate relationship.

For example, as illustrated in FIG. 9, An Example Operating Session Embodiment.

For example, as illustrated in FIG. 10, An Example Operating Session Embodiment.

The type of operation sessions may depend on the set of specifications with which they are provided. For example, an operation session that is provided with an operating specification, which comprises control, organizational and interface specifications, may provide users/Stakeholders with the ability to pursue their respective purposes. There may be other operating sessions that interact with users to formulate purpose specifications can be transformed into operating specifications that can be used to provision, deploy and/or instantiate resources for the subsequent instantiation and/or launching of one or more operating sessions.

Some PERCos embodiments may associate contextual information of one or more users with operating sessions in support of fulfillment, which may include for example, one or more resonance algorithms to support in part optimization of purpose. This context may evolve as the operating session progresses and unfold. In some situations, a user and/or PERCos computing environment may start one or more sub-operating sessions with suitably modified contexts.

In some cases, an operating session may create a new operating session to accommodate one or more context changes. For example, consider an operating session shared by multiple Participants. Some of the Participants may have different or even contradictory context elements. In such a case, a PERCos embodiment may create multiple operating sessions, one or more sessions for each context. And yet, these operation sessions interact with each other to fulfill the shared purpose.

In some embodiments, operating sessions may be forked, persisted, restored, suspended, resumed, and terminated. Users may fork an operating session to try out different methods to achieve a purpose. Users may persist an operating session in order to publish it as a resource. Alternatively users may persist/suspend an operating session in order to be able to restore/resume it at a later time. Users might terminate an operating session because they may be satisfied and/or reached a conclusion, and/or the user has for other reasons decided to terminate the session.

In some embodiments, one or more operating sessions can have operating specifications which include one or more operating agreements. Operating agreements are negotiated between operating session managers and resource managers, such as using PERCos Platform resource Management System instances. In some embodiments, operating specifications may be persisted when an operating session is persisted so that they can then be restored when the operating session is restored.

This section considers potential implementations of PERCos specifications, PERCos resources, PERCos Platform Services, PERCos Information Management (PIMS), PERCos Identity Systems (PERID) and PERCos Hardware and Devices

A PERCos system is a network operating environment for purposeful computing, extending traditional operating system capabilities by uniquely enabling user expression of purpose, and further employing apparatus and methods for optimally matching user Contextual Purpose Expressions (CPEs)—and any associated preferences and foundation, user, and other Stakeholder rules, metadata, and the like—to resources available locally and/or on one or more networks. A PERCos system is designed to support the deployment of resources to provide user experiences that are responsive to user purposes.

With PERCos, users can intelligently and efficiently interact with a global, nearly boundless “purposeful network,” comprising an immense diversity of possible resources that are aggregatable and configurable as purpose-responsive arrangements. A feature of PERCos systems is their inclusion, organization, and management of all potentially actively contributing elements of a session as components of a logically unified resource infrastructure. Processing elements, any and all contributing forms of information, any and all contributing forms of network resources, device arrangements, and Participants, are uniformly treated as resources. They may be aggregated, and are identifiable, assessable, and deployable in response to user purposes. Computer memory, devices, microprocessors, databases, software, services, networks, Participants, and other specification types may all be managed by PERCos resource managers.

PERCos resources include “information resources,” “computational resources,” “communication resources,” and computer representations of users and their actions. Common kinds of resources include content, hardware, devices, software, services, Participants, and/or networks. PERCos flexibly supports the organization, provisioning, and purpose-related governance of a potentially boundless collection of possible resources, normally with the goal of achieving optimal responses or response candidates to purpose specifications.

A PERCos embodiment may include a distributed and hierarchical resource architecture that provides a uniform treatment for all types of resources regardless of their size, complexity, diversity, location, format and/or methods of their creation.

Resources, in general, are operatively associated with at least one resource interface arrangement. Common kinds of values that can be named include data/contents, and/or specifications for such data/contents, hardware, devices, processes, software/applications, and/or networks. resources may be PERCos interpretable.

A resource interface provides sufficient information to validly invoke operatively associated methods of a resource instance.

In some embodiments, PERCos resources include interface specifications, organization specifications and control specifications, which may refer to resource elements comprising resource and/or resource interactions with other resources.

FIG. 11 below provides one embodiment of a resource item. It shows that a resource is created by sending a message comprising control, organizational, and interface specification where interface specification may be for both Application Programming Interface (API) and user interface. Once a resource is created, it can accept inputs and generates outputs.

Platform resource Management Services utilizes this consistent method of creation to uniformly organize and process resources, including providing common service/resource management interfaces for individual and/or groups of resources in a seamless manner.

In some embodiments, PERCos resources have one or more unique identities (UIDs) that can be used to access the resource, including its resource interface.

In some embodiments, PERCos resources are composed of one or more resource elements. PERCos resource architecture supports a wide variety of ways of declaring resource elements and/or organizing them, such as, for example, a hierarchical organization, into compositions of resource elements. resources may also be embodied in various ways, including ways in which their representation is at least partly implicit.

For example, as illustrated in FIG. 11, An Example resource Item.

In some embodiments, PIDMX that is used by resource interface (e.g., operating session Coherence manager) to reason about the resource's relationship with other resources is grouped as part of component resource element. Whenever the resource interface needs to access its PIDMX, it may interact with its component suite. Other embodiments may have somewhat different resource elements and/or different ways of organizing them into composite resource elements. For example, there may be an embodiment in which PIDMX is its own separate resource element.

This flexible way of defining resource elements and organizing them enables a resource architecture embodiment to provide multiple resources that have the same functional capabilities but, for example, differing performance and/or location, to support differing operational environments. For example, a resource architecture embodiment may provide two resources, one for a limited platform operating environment and another for a super computing environment with powerful servers. For the limited platform environment, it may provide a version of the resource that may be configured with a minimal set of resource elements, such as an extremely light-weight resource interface comprising a kernel session and a set of UIDs of method specifications. In particular, the resource's method specifications may reside elsewhere, and the resource would access them on demand basis, using their UIDs.

PERCos resource architecture may include resources that have single or multiple resource elements in any arrangement. However, regardless of how they are organized within and/or by the resource, whether they comprise for example, only those interface elements or comprise a resource set (which may, for example, include other resources, for example, those on which the resource described has a dependency), are distributed, embedded, referenced or arranged in whole or in part in other manners, such resources are accessed, through one or more PERCos resource interfaces in a standardized and uniform manner.

For example, as illustrated in FIG. 12, An Example resource Embodiment.

PERCos resource architecture embodiments may achieve platform independence by treating all their relevant computational elements uniformly as resources. Thus different conventional operating platforms such as PERCos, Windows, OS/X, Linux, FreeBSD, and others are considered simply as Foundations (e.g., as a type of resource). As resources these Foundations may have resource interfaces and interface specifications. For example, resource architecture embodiments may not need to give any special treatment to a Foundation that represents a Linux operating system as opposed to a Windows operating system; if the specification of the Linux Foundation meets the requirements of a particular Construct, for example, “Framework, template” then it can be utilized by that Construct template.

Other platform specific features may be treated in a similarly uniform fashion by a platform independent PERCos embodiment. An authentication scheme based on a Lightweight Directory Access protocol (LDAP) implementation and an authentication scheme based on the Microsoft Active Directory implementation may be simply represented as resources by a PERCos resource architecture. If these resources implement a common interface, then they could be used interchangeably by various resource arrangements.

A PERCos implementation may further support platform independence by utilizing technologies that have support across different platform architectures. Thus a PERCos embodiment that users access primarily through a web browser could make heavy use of the HTML 5 and JavaScript technologies. Any Construct template that provides its experience to the user with HTML 5 and JavaScript would then be compatible with any user Foundation which included a web browser.

To support one-to-boundless computing, PERCos embodiments may dynamically arrange arbitrarily large number of resources in support of purpose sets. For example, consider a virtual lecture that may be attended by millions of students. The organizers of such a lecture may desire to manage the students, in order to check their pre-requisites, collect fees, provide certification, or the like. The management data structure should be scalable to deal with such large number of students. In addition, at this scale, the management data structure should be highly reliable; losing access to the billing system may cost the organizers money and create inconvenience for students who need certification.

Resource architecture embodiments may support scalability and adaptation by enabling a group of resources to be arranged and/or otherwise transformed (e.g., algorithmically related and/or ad hoc arrangements) into a single functionally more capable resource, which, in turn, can be arranged and/or otherwise transformed with other resources to create even more capable resources. This enables creation and use of resources at any chosen level of granularity so that users may experience, organize, store, and/or publish computer sessions and session elements that provide the best fit to their purpose.

Supporting one-to-boundless computing may involve a PERCos resource architecture to enable PERCos systems embodiments to interact with non-PERCos-external systems whose resources may not support basic PERCos resource properties in a manner that enables direct interaction with PERCos resources systems embodiments (for example, including PERCos resources and/or PERCos Platform resource Management Services). Such resources, when used in conjunction with a PERCos system, are called non-PERCos resources (NPR). Typical examples are legacy hardware, legacy databases, legacy software, and non-PERCos services.

The PERCos approach pushes interfacing with non-PERCos resources close to those resources themselves, rather than distributing it within a PERCos system. One aspect of this approach is that the complexity of connecting a new kind of resource to a PERCos system depends only on the complexity of the resource's native interface and the amount of “fitting” work that may be required in the transformer to implement a suitable resource interface. It does not depend at all on the size of the PERCos system, the number of kinds of PERCos resources, or the number of other kinds of non-PERCos resources that are interfaced to the system. This independence is a practical result of one-to-boundless operation.

In some embodiments, a transformer is an element that, when combined with a non-PERCos resource, provides the properties of a PERCos resource. A transformer may comprise sufficient information to identify a unique element (value) and associated resource metadata, including one or more associated resource interfaces—from within the transformer and/or from some other source. Often, the most substantive element of a transformer is a resource interface that presents a PERCos interface while accessing the non-PERCos resource using its “native” interface.

A non-PERCos resource may be associated with more than one transformer; each transformer-resource combination represents a distinct PERCos resource.

In some embodiments, Non-PERCos resources can be converted, using suitable transformers, into resources suitable for interaction and integration with PERCos resources and management systems (for example, PERCos Platform resource Management Services) and are described as informal PERCos resources.

An assimilator is an element that identifies a non-PERCos resource through name, location, and/or reference identification and enables PERCos to access it by invoking appropriate one or more transformers.

For example, as illustrated in FIG. 13, Assimilation of non-PERCos resource into PERCos environment.

A PERCos embodiment may enable comprehensive reliability by provisioning a set of health checking platform services that act to support operations, from user inputs and formulations through to operating resources and user experience. In some embodiments, each resource and associated processes may undergo processing provided by PERCos Platform Services, such as Evaluation, Testing and/or Monitoring Services supported by identity, history, persistence and/or other platform services. In some embodiments, PERCos Coherence Services may provide a combination of these capabilities in response to specifications that express reliability and/or comprise reliability metrics.

In some embodiments, resources may provide specifications detailing their reliability, expressed in the form of metrics, and in some embodiments, for example, these may be expressed in the form of Repute expressions. Such assertions may be supported, in whole or in part, by testing and verification services, including, for example, Repute on Repute.

Reliability may incorporate such techniques as redundancy, such as providing hot standbys that can replace failing resources. For example, the Byzantine algorithm is another way to provide reliability. In some embodiments, resources may be periodically monitored and/or persisted, by, for example, PERCos Platform Monitoring and/or Persistence Services, such that if a resource faults, it can restore resource(s) to its previously persisted state. For example, techniques such as those used in transaction processing systems, for example, rollback, failover, fault tolerance and the like, may also be used, as may other common techniques such as check pointing.

If a resource's component resource fails to comply with its functional specification, PERCos Platform resource Management Services can replace the failing component resource. A resource architecture also provides a uniform mechanism for substituting for missing components, responding to a wide variety of component failures, dynamically adding or removing components, incorporating legacy components, and/or optimizing component selection.

Operating agreements may incorporate appropriate service, performance, reliability and/or other specifications, and may further include specifications that instruct other PERCos Platform Services, including: Evaluation Services, Arbitration Services, Monitoring and Exception Services with appropriate further specifications (including for example, instructions, metrics, resources) as to response and initiation methods. PERCos embodiments may utilize a variety of techniques and methods to achieve the requested reliability specified by the operating agreement.

PRMS may use an embodiment of PERCos Test and Results Services to perform diagnostic tests on periodic basis. Before a resource is provisioned, a PRMS can perform the tests associated with the resource and then check that the test results match the resource's specification. In addition, even while the resource is operating, a Platform resource Management Service can perform the tests. For example, it can sample communication channels to measure their loss rates, bandwidths to ensure that the channels satisfy the needs of the contextual purpose experience session.

PERCos embodiments, through the provision and utilization of standardized PERCos resource interfaces enables users/Stakeholders through their expression of purpose, methods for effective interaction with Big Resource. Resource interfaces are considered in the section below in this disclosure.

In some PERCos embodiments these standardized resources interfaces for each resource roles-standardized interactions, provide a standardized “plug and play” capability that can be accessed by users/Stakeholders in their unfolding purpose operations.

In some embodiments, resources may have one or more standardized and interoperable Roles associated with it, which are expressed as one or more specifications based on one or more classification systems, which in some PERCos embodiments may include standardized and interoperable specifications. These specifications may be human interpretable. These Roles may, in some embodiments, be a purpose class. For example, a Participant may be associated with Role administrator, for one or more purpose operations and/or a resource Role may be a standardized PERCos embodiments Information resource.

Resources (and/or arrangement thereof) may be classified by one or more classification schema's, including, for example, PERCos standardized schemas. Roles may be associated with one or more resources comprising functional standardized and interoperable operational arrangements, such as for example, information store, processor, and the like. In some PERCos embodiments there may be one or more resource classification schema's which may also be mapped to each other and/or from classes.

Example Roles of resources may include, but are not limited to:

In some embodiments, certain aspects of Roles may be quantized and have interoperable and/or standardized expressions and/or representations. For example, novice, expert and the like may have PERCos embodiments wide definitions. These, for example, in some embodiments are user variables Master Dimensions Facets, and as such may be both the name of the Role as well as a Dimension.

Users and/or other Stakeholders may have representations across the Edge in a PERCos embodiment computational domain, called Participants, which are PERCos embodiments resources. These may have associated Roles, such as “Tech Support Guru”, “authorized Signer”, “VP Sales”, “Lawyer”. In some embodiments, Participants may also have multiple associated Roles.

Roles may have one or more profiles associated with them, including preferences, which may be applied/included in purpose operations involving Roles. Roles may be purpose Domain specific. For example, within a specific organization, there may be one or more hierarchies of Roles with associated rules and/or other specifications (for example, Rights/entitlements/tokens/capabilities and the like).

In some embodiments, resources may have one or more Roles associated with them, which are expressed as one or more specifications based on one or more classification systems, which in some PERCos embodiments may include standardized and interoperable specifications. These specifications may be human interpretable. These Roles may, in some embodiments, be a purpose class.

Each resource Role may have one or more sets of specifications describing resource characteristics and/or functionality for one or more purposes (which may include associated metrics). For example, an information resource may indicate the PERCos embodiments categories it supports.

Resources or differing complexity, functionality and/or other characteristics may be interchanged if their Roles are common, as the standardized resource Role interface provides for this interoperability. In this manner users may, for example, select differing resources to meet this purpose, such as more or less detailed information resources, processing resources, management resources and the like. Implicit purpose statements may in some embodiments, refer to resources which have commonly understood purposes, such as, for example, Hard Disks, RAM, Ethernet and the like.

In some PERCos embodiments, resources may have standardized resources interfaces for each resource roles-standardized interactions, in this manner providing a standardized “plug and play” capability that can be accessed by users in their unfolding purpose operations. Resources of differing complexity, functionality and/or other characteristics may be interchanged if their Roles are common, as the standardized resource Role interface provides for this interoperability. In this manner users may, for example, select differing resources to meet this purpose, such as, for example, more or less detailed information resources, processing resources, management resources and the like.

For example, in some embodiments, there may be one or more classification schemas associated with resource Roles, for example, an information resource classification may comprise, text book, video/audio, reference text and the like.

Such resource Role specifications may be independent of the resources that they specify, such that one or more PERCos embodiments specification frameworks, for example, PERCos embodiments Constructs such as, for example, Frameworks, Foundations and the like, may comprise sets of specifications that are arranged by resource Roles.

In some embodiments, resource Roles may include resource types which are subtypes of resource that characterize resources with useful collections of attributes in common. These types may be standardized and interoperable and may be constrained by one or more purposes, for example, constrained by Core Purpose. For example, a Role may be “Teacher College Physics”. In some embodiments, Roles may comprise sets of resources associated with one or more purpose operations, for example, the Role “Tube Audio Power Supply” expert may require that certain specific resources have been regularly accessed by that user.

Many resources may have one or more methods in their method suites, which may be used to further classify resource Roles, such as by their sets of methods, descriptive purposes, semantic ontologies (e.g. associated CPEs, metadata and/or subsets thereof), functionality, locations (local, group, external), scopes (private, limited, public), and/or accessibility (assumed, required, available, or potentially discoverable).

For example, input device, output device, channel, database, application, service, and Participant may be, in some embodiments, resource Role types, and many of them may have an extensive structure of subclasses (e.g., Keyboard, PS2 Keyboard, USB Keyboard, Ergonomic Keyboard; Display, PixelMap Display, Raster Display, Low-def Display, Medium-def Display, High-def Display), allowing description of any relevant attributes to any selected degree of precision.

Roles may be considered, in some PERCos embodiments, as a further type of identity (in addition to the identity of the resource), which may be in the form of a resource associated with one or more user/Stakeholder representations. In some embodiments, PERCos embodiments users/Stakeholders may have their associated Roles (which may be declared and/or attributed) registered, by one or more utility services, for example, sales1@xyz.com.

Roles may be formulated as schemas, which may, in some examples, be presented as classes.

In some embodiment, Roles may have associated specifications, which may include principles such as, “least privilege”, rules, rights (such as administrator), and the like.

In some embodiments, Roles may comprise pre-determined arrangements of context (preferences, purpose profiles, resources including specifications such as, for example, rules) which may be used in purpose operations where, for example, structured Role (for example, customer of type (N) for company (Y), Frequent Flyer of airline (N) and the like) interacts with user/Stakeholder purpose operations, including, for example, purpose class applications, where the interaction includes at least one pre-determined purpose.

In some embodiments, there may be PERCos embodiments defined Roles that are part of those PERCos embodiments, including, for example, Stakeholder, publisher, user, administrator, sovereign bodies, and the like.

For example, PERCos may reserve Roles such as publisher such that for a user/Stakeholder to have that Role, they may have to undergo one or more interactions with PERCos controlled resources, such as a utility to, for example, establish and validate their identity.

Contextual Roles may include one or more contextual aspects such as location, temporal, complexity, expertise and/or any Dimensions and Facets, and the like.

Contextual Roles may use session specific dynamic specifications to establish the relationship between resources and/or users/Stakeholders. In some embodiments, contextual Roles may not effectively carry persistent authority across multiple sessions and/or be represented by such information organizations as class systems.

In some embodiments, contextual Roles are “of the moment” representing that set of contextual aspects that determine the Role of Participant within unfolding experience and associated processes.

Contextual Roles may be dynamic, in that the context of the user interactions may vary as they discover resources during their purpose operations.

Within many social structures and relationships there may be social Roles which determine the relationships between the users with those Roles. For example, these may be declared such as familial (for example, Son, Daughter, Father), Follower/Leader (for example, one user 1 declares they follow user 2 or user 2 leads group of users X), Influencer/Influenced (for example, x influences y or a is influenced by b—all of which may have metrics of such relationship expressed/implied/calculated) and/or comprise associative relationships, such as, for example, friend, colleague, associate, acquaintance and the like.

The degree to which these social roles may be stated and/or inferred may be further influenced by the associated Reputes of those Roles, which may incorporate in whole or in part the Reputes of the Participant associated with the Roles.

In some PERCos embodiments, support for one-to-boundless computing through managing all types of resources—regardless of their type, internal interfaces, and/or their method of creation—may be achieved through using a unified resource interface framework. Resource interfaces can act as proxies for all interaction with other resources. An instance of a resource interface is defined by a resource interface specification, which in addition to specifying methods, which in some embodiments may be a method suite, which may include control, organization and interface specifications, comprising resource specification suite.

A resource interface representation may comprise anything from a minimal set of resource interface elements to a full complement. Depending on the embodiment and/or the operational environment, a resource interface instance may be distributed and/or some of its components may be offloaded to its resource's component suite.

In some embodiments, a resource interface on a platform that has limited resources (e.g., smart phone with limited memory), may comprise minimal small set of resource interface components. Moreover, the resource interface may store only those components that are essential for bootstrapping its operations on the platform, and offload the rest to the resource's component suite to be accessed only as appropriate. For example, if a resource interface had offloaded its metadata and its kernel session then relevant metadata information (e.g., performance characteristics of a component resource), it might obtain the information from its component suite “on demand.”

By contrast, if a resource interface is on an operating platform with ample computing power and memory, then it may comprise a full complement of components on its platform, including its metadata.

In some embodiments, a resource interface may be distributed across computing platforms or networks. For example, its method suite may be distributed so that some of its method specifications and/or implementations are stored in one platform, and the rest are stored on others. In such a case, the resource interface on one platform may serve as a proxy for components on other platforms.

Regardless of how resource interfaces are implemented, they provide their service transparently. For example, an Invoker of a resource, say R, may not know that R is operating on a platform that may require R to offload some of its resource interface components or to operate in a distributed manner; it is accessed in exactly the same way as when R is operating on a platform with an ample resources and can provide all its services using only local resources.

A PERCos embodiment may provide a variety of ways to construct a new operating resource depending on operational environment or implementations. For example, one embodiment can be analogous to the way UNIX shells spawn child shells. In UNIX, any collection of shell commands may be stored in a file, called a shell script file. A shell allows creations of new user interface for UNIX operating system by spawning a child shell and specifying a script file. In PERCos, a resource may construct a new operating resource instance by specifying a resource specification. The construction may be performed in multiple ways. For example, initially a new resource interface may be created by instantiating a resource type using one or more resource specifications. Such instantiation may create a resource whose resource interface contains a method suite instance comprising a set of methods specified by the control specifications (see FIG. 14). Subsequently a kernel session instance may be activated as part of the resource interface (see FIG. 15). At this point, the resource interface is operational and can choose to determine the location of the rest of its components, such as its communication interface suite, PIDMX, and metadata.

For example, as illustrated in FIG. 14, Part 1 of Operating resource Creation Example 1.

For example, as illustrated in FIG. 15, Part 2 of Operating resource Creation Example 1.

In some embodiments, another way of creating an operating resource is to create a resource interface including of a kernel session instance. The kernel session instance then interacts with its control specification(s) to create operating resource (Part 1 of FIG. 16). The kernel session instance can store its control specifications as part of its resource interface. It may also cache its resource interface specifications so that it can optimize the resource creation (Part 2 of FIG. 16)

For example, once kernel session instance obtains the resource interface specification, it can complete the construction of the rest of its resource interface components, such as, for example, obtaining appropriate method suite(s). It also creates the resource body comprising the method implementation suite and component suite. Caching the resource interface specification may optimize this process (see FIG. 17).

For example, as illustrated in FIG. 16, Part 1 & 2 of Operating resource Creation Example 2.

For example, as illustrated in FIG. 17, Part 3 of Operating resource Creation Example 2.

In some embodiments, resource interface acts as proxy for all interaction with resource components. In some embodiments, it handles all rule-based interactions, for example, authentication, authorization, credentials, certificates and/or other security and/or governance specified by resource components and/or specifications for use of resource and may involve resource interface maintaining such rules (for example, certificates) for the resource component(s). Another example may involve the resource interface interacting with a PERCos rules manager instance to handle one or more rule sets on behalf of the resource, including those utilized by the resource interface itself to bind to the resource components.

PERCos resources interfaces may be individually instanced and/or support a plurality of instances for resources and/or resource arrangements. PERCos resources may be implemented as, for example, a single service executable and/or as a group of service executables that act as one.

The resource interface may have one or more rules sets (including, for example, governance, authentication and authorization, or other rules and/or policies associated with it that constrain the origin, types and numbers of messages that may be sent to it), and further may have additional rules and/or policies regarding the handling of those communications (including, for example, messages). For example, a resource interface may only respond to messages from specific Participants (and/or other resources), and/or identified processes and/or communications/message types. In some embodiments this could be defined by, for example, an organization that may restrict access to one or more of its resource to only authorized employees only—i.e., those Participants that present appropriate identity credentials.

The resource interface may also manage low level call failures (for example, including implementing low level authentication and/or authorization failure recovery) on behalf of the resource Fabric instances. Persistent call failures may be notified to the requesting RSM and/or other calling resources and/or processes to which notification communications/messages that are specified.

In some embodiments, this may involve testing that includes reality integrity analysis, whereby, for example, the veracity of a video image is validated as being the real time image of the user, supporting their assertion to be who they assert.

Resource interfaces may interact with other PERCos Platform Services, as that may be required to satisfy specifications, for example, where such specifications may require invocation of platform services to achieve a specific Outcome. For example, the RI may interact with PERCos Persistence Services instance to persist that set of information that the RI is responsible for, such as, metadata and/or operational performance information. In some embodiments this may also include interaction with PERCos Coherence Services so as to reconfigure that M's component resource arrangements.

In some PERCos embodiments, resource interfaces may include one or more methods of specifying controls for the utilization and/or interaction with resources associated with resource interface. This may include both the resource elements comprising the resource and other resources with which resource may interact. For example, this may include specifications detailing responses and/or other actions to be undertaken when resource receives control specifications from other resources and processes.

In common with other PERCos specifications, control specifications may, in some embodiments, include multiple control specification elements, each with appropriate values and/or parameters and/or other specifications, such as, access, identity, rules (for example, including types of usage, such as read/write/update/edit/DRM and the like), and/or any other specifications that specify what, when and how resource and/or specifications may be utilized. Control specifications may specify cryptographic techniques and capabilities. Control specifications may be persisted, for example, through PERCos PIMS, as i-Sets.

In some embodiments, resource interfaces may provide apparatus and method embodiments for separation of those control specifications associated with interactions with the resource interface, and those specifying the associated resources and/or specifications.

Controls for the resource interface of a resource may, for example, specify when and how the resource interface for the resource may be replaced with another interface or when resource interfaces can be added, such as, only authorized invokers may add new methods, and/or only authorized Coherence managers may delete methods. Control specifications for utilizing associated resources, for example, may specify the use of cryptographic techniques and capabilities. For example, control specifications may specify that access to or interaction with certain resource elements comprising the resource be disallowed based on identify of the Participant.

Some examples of the types of control specification elements include, but are not limited to:

PERCos architecture provides for resources to receive one or more control specifications which may include specifications of authentication and/or authorization methods, rules and/or other specifications from one or more appropriate controlling resources, processes and/or PERCos Platform Services. In some embodiments, authorization may be, for example, provided using Access Control Lists (ACL), capability-style authorizations and/or other authorization implementations.

In some embodiments, PERCos resources may support one or more authorization features, within which such authorization requirements for the resources are specified. These features include for example, specifications of resource characteristics (including, for example, functions), definition of appropriate authorization indicia sufficient to enable other resources to use one or more characteristics, capabilities and/or functions of the resource, and/or authorization and authentication specifications sufficient to permit the authentication and authorization of other resources to use the authorization indicia.

In one example embodiment, a user may establish control over a resource (e.g., initialization of a new laptop computer) through the creation by user of a Participant identity for that user to exercise control over that resource. In this example, user creates a Participant identity, for example, “admin” and in so doing creates a persistent relationship of authoritative control over the resources comprising the laptop. These may then be delegated to other Participants, on terms defined by control specifications.

In some resources control specifications may be segmented to apply to only portions and/or sections of resource (and the resource elements thereof), such as a portion of a document, certain tables within a database, a fractional portion of a hard drive (say 10 GB of 1 TB). For example, in the case where resource element is a set of specifications, control specifications may specify for example, that such specifications may only be segmented such that certain elements (including sets thereof) of the specifications may be interacted with (for example, by modification) by certain designated users/resources/Processes.

In some embodiments, the appropriate authorities may be combined within a common control specification, for example, implemented as differing instances of control functions, and/or maintained as independent functions.

In some embodiments for example, rules and authorities may be specified, such that resource interface specifications may include by reference or embedding the identity of the appropriate control specifications including, for example, one or more validation mechanisms that may manipulate resource interface specifications. Alternatively, resource interface may identify control specifications and mechanisms for validating the resulting set of elements returned by control specifications. One such mechanism could enable signing the elements returned by control specifications using the identity of an authorized digital signatory. For example, in a message-based implementation, authority may be evidenced by the right to send or receive messages at a specific message-delivery address (for example, a specifically identified resource), or by the authorization to send and/or receive specific message types and/or contents.

In some embodiments, PERCos organizational specifications reference those organizations that are associated with the resource, for example, the organization of the resource elements that make up the resource and those organizations that the resource itself is a part of. For example, this includes resource arrangements and assemblies that resource is a member of, as well as class systems, Constructs, directories and/or any other organizational structure (including, for example, formally unstructured sets, such as i-Spaces (information Spaces), results sets and the like.

These organizational specifications may be formatted and/or modularized to reflect the various organizations to which resource is a party.

These interactions and communications may include references to one or more control specifications, specifications determining, for example, data input/output, utilization and access. The interface specifications may include resource Input and/or Output specifications and their associated methods, such as for fast synchronous data transfers or other performance optimized inputs/outputs.

In some embodiments, interface specifications may include one or more PERCos standardized protocols and/or any resources providing such capabilities. These protocols, for example, may be utilized for intra/inter-resource communication methods that allow one or more resources to invoke at least one method of another (including those of the resource elements comprising the resource, if applicable). In some embodiments, protocols may include sets of elements that enable creation, assignation, manipulation, extraction and/or termination of resources and/or their resource elements.

In some embodiments, PERCos interface specifications may include by reference or embed one or more interface methods, which, for example, may include communications methods and may utilize associated protocols. PERCos implementations may include one or more standardized sets of methods which may be used by resources.

In some embodiments PERCos may utilize available communication mechanism to embody one or more methods and/or protocols, including procedure call/return, inter-process communication (IPC), remote method invocation (RMI), explicit message queues, blackboards, files, streams, rendezvous, or any mixture of them, provided that all involved resources implement and/or have access to the chosen mechanism(s) for each protocol.

In some embodiments, resource interface specifications may reference one or more suites of such methods and/or protocols. These may then, for example, be associated with a resource such that another resource may use these to access the resource to achieve particular effects. In one embodiment, a process resource may support a protocol suite including of two protocols, one protocol for accessing the process locally (e.g., Unix socket) and another for accessing it remotely (SOAP message). A protocol suite may be embedded in and/or referenced by the metadata attribute of the resource, contextually determined, and/or known statically (e.g., because the element is a built-in type of the system, such as integer or string).

In some embodiments, PERCos may include one or more sets of method and/or protocol suites that are standardized and built into the PERCos system. This may both improve efficiency and avoid the possibility of infinite regress (when accessing a method and/or protocol may require accessing at least one or more further methods and/or protocols, some of which may require accessing one or more further methods and/or protocols, and so on, ad infinitum).

In some embodiments, the implementation of some or all methods and/or protocols may be optimized for at least some resources, for example, using PERCos standardized methods, protocols, protocol and/or method caching, constant propagation, code motion, currying, type analysis, and/or other techniques used for efficient implementation of programming languages.

In some embodiments, methods and/or protocols may communicate any set of data/information that PERCos resources may generate and/or receive. This, for example, may include specifications of all types, including control, organization and/or interface specifications, from single or multiple resources, Participants, and/or other processes, alerts/events, operating agreements, and/or any other PERCos and/or non-PERCos communications.

In some embodiments, PERCos Platform services may provide communications methods and protocols suites that comprise currently commonly used and available communications methods and/or protocols and/or PERCos specific communications methods and/or protocols. For example, this may include the HyperText Transfer protocol (HTTP), Structured Query Language (SQL), Rich Site Summary (RSS), Simple Object Access protocol (SOAP), Common Object Request Broker architecture (CORBA), and the like.

PERCos resources may be constructed from one or more elements and at least one PERCos resource interface. In some embodiments, resource architecture may provide a set of operations that enable resources composition and decomposition. It may provide operators such as assemble and disassemble that assembles two or more resources into a single resource and disassemble resources into component resources, if possible.

A PERCos embodiments specification expression is an item that may be interpreted as a specification. A specification is something that any item either does or does not satisfy. The items that satisfy the specification are instances of that specification.

In some embodiments, PERCos embodiment specifications comprise expressions formulated so as to specify one or more definitions of what may be required to occur when specification is resolved. There are no constraints in PERCos embodiments as to what may be specified, however, for standardization and inter-operability, PERCos embodiments includes one or more specification languages.

In some embodiments, identity is a form of specification. In some PERCos embodiments anything that can be identified can be specified, as can any resource, however specifications using no standardized terms and specifying those entities without unique identities may not be able to be resolved unless/until appropriate methods for such resolution are provided. PERCos embodiments specifications may be included in one or more specification languages.

Specification expressions may have their interpretation results determined dynamically through one or more operators applied for their use. These interpretations may be persisted. In some embodiments, there are operators, such as prescriptive and/or descriptive that may be applied to specification expressions. Such operators may be included in one or more PERCos embodiments specification languages.

For example, PERCos embodiments specification languages may include for example, but not limited to such defined terms as operators, methods, part types, elements, metrics, items, purpose, basic data types and/or other such terms that create an effective language embodiment for instantiations within one or more PERCos embodiments.

In some PERCos embodiments, specification expressions are created and/or selected by users so as to satisfy that users purpose and consequently PERCos embodiments systems may operate so as to resolve such specifications such that one or more resources capable of providing support for user experiences intended to satisfy users expressed purpose is made available and/or instantiated. In some PERCos embodiments this resolution is undertaken by PERCos embodiments platform SRO processes.

Some PERCos embodiments include contextual purpose operating environments which may be substantially based on the manipulation of specifications. The expression of purpose by users, in the form of purpose expressions supported by the purpose class systems enables users to define, iterate and/or refine these specifications through their unfolding purpose experiences leading to them achieving satisfaction of their expressed purpose.

PERCos embodiments use classes as a primary organizing apparatus and method embodiments for specifications.

In PERCos embodiments there may be multiple classifications of specifications into various types. In some embodiments these may include purpose, user/Stakeholder, resource, process, Repute, Dimension, metric and/or any other single and/or multiple schema and/or organizational models

In some embodiments, classifications may include one or more schemas and/or organizational models for specifications. In some embodiments, such classifications and/or schemas are declarative, such as, for example, purpose expression, Repute expression, rules expression and the like.

Specifications may be further typed, for example, through the degree to which they have undergone one or more processes, including those of their initial expression. For example, class specifications may be typed as “unresolved” as the specific resources have not yet been (in whole or in part) fully identified, whereas specifications that comprise resolved resources would be typed as “resolved.”

Declared specification types include for example, purpose, Roles, control, interface, organization, rules, class, Construct, identity and the like, all of which may have one or more other specifications, such as pre and post conditions applied. For example, a rule specification may have pre conditions stating one or more specific enforcement methods be applied to such specifications.

Processes types are those specifications that have undergone one or more PERCos embodiments process. For example, those specifications that have had specific processes operate upon them, such as Tests and results service, for example, resulting in “validated” specifications. Further examples may include such processes as Coherence, resulting in, for example, “cohered” specifications.

In some embodiments, specifications may have multiple types expressed, such as, for example, “resolved, cohered, validated”, which in turn may have additional specifications stating the methods (and potentially resources) involved with such type expressions.

In some embodiments, specifications may have further control specifications that determine such type processes (and potentially order thereof) that specifications may undergo. For example, such a control specification may include pre and post conditions, which specification may satisfy, such as, for example, having types such as validated and/or cohered, before further operations with and/or on specification may take place.

Specification classifications may be declared and/or processed.

In some PERCos embodiments, specifications representing, for example, purpose expressions may be either prescriptive or descriptive. In some embodiments specifications may be declared for use as prescriptive, where they represent what may be required and/or desired by those one or more users/Stakeholders and/or resources. There may be further specifications that are declared for use as descriptive, representing the capabilities, functions, use, applicability, intent and/or other characteristics associated with a resource.

In some embodiments there may be standardized organizations and/or schemas, such as templates that determine specific defined arrangements of specifications. Some examples include, purpose expressions, Repute expressions, Dimensions and metrics, identifiers, information systems and the like. In some embodiments, such classified specifications may, for example, have rules determining their suitability for such classification and potentially for use and/or dissemination of such classified specifications. In some embodiments, specifications may include dependencies on other specifications, through reference and/or embedding.

In some PERCos embodiments, specifications types may be created through declarations, for example, a user/Stakeholder may declare a specification to be a purpose expression. For example, one or more resources may declare that a specification is a control specification.

In some embodiments, PERCos templates may provide standardized and interoperable method arrangements by which, for example, Constructs and/or other resource arrangements can be dynamically arranged. For example, through the use of templates, a Construct may develop from a possibly incomplete set of specifications to an operating resource.

In some embodiments, PERCos templates may comprise specifications of one or more resource sets that may be combined and/or used dynamically in an arrangement to satisfy one or more prescriptive specifications. In some embodiments, these templates can be used, for example, to decompose a prescriptive specification into one or more finer grained prescriptive specifications. In such an embodiment, PERCos processes, such as, Coherence Services may find resources that satisfy these finer grained prescriptive specifications. A template may then assemble these resources into a suitable resource arrangement that, in whole or in part, satisfies the initial prescriptive specification.

For example, a purpose class application may be implemented as a collection of web pages that utilize, for example, JavaScript and Adobe's Flash plugin. To facilitate the process of resolving the purpose class application into an operating resource, the specification of the purpose class application may include a pointer to a template. This specification template contains instructions on how to resolve the purpose class application into an operating resource if the following resources can be found:

1. A network connection to the internet,

2. A web-browser which includes JavaScript, and

3. The Adobe Flash plugin.

In this simplified example, when a user selects this purpose class application, perhaps using a double-click if this purpose class application already exists on her Desktop, Coherence processing may try to resolve the purpose class application by looking at the users Foundation to see if the three resources described above are present. Coherence may also utilize one or more persisted specifications, such as those of the user that pertain to other Foundation resources, for example, stored as profiles, that may include such information as router, firewall, anti-virus, browser settings and if appropriate those further profiles of other Stakeholders, such as corporate policies. If the Foundation contains resources matching these specifications, then Coherence processing can use the purpose class applications template to assemble these resources from the users Foundation into an operating resource.

This example can be continued recursively. For example, if the Adobe Flash plugin is not found in the users Foundation, then Coherence can be called to provision an Adobe Flash plugin resource as part of the users computing arrangement. An embodiment may choose to include this installer in a template that produces Foundations. The assemble method of this Construct template would be responsible for installing the Adobe Flash plugin in the users computing arrangement and producing a Foundation that reflects the change that has been made to the users computing arrangement. If the user chooses to associate this new Foundation with his context, PERCos may be able to utilize the user's new Adobe Flash plugin.

Templates may be specified and/or invoked at any point in the PERCos cycle. For example, Specification, Resolution and Operational (SRO) Processes may use templates to build, evolve, refine, and/or transform resources into operating resources in a systematic, standardized and/or interoperable manner as described above.

Some embodiments provide Construct templates, which are templates that describe how to assemble Constructs and/or operating resources out of a collection of resources. In some embodiments, users can make use of Construct templates to (1) recursively build Constructs out of other resources and (2) provision and resolve resources to construct operating resources. Acknowledged Domain experts and/or users may publish their Construct templates and/or Constructs, allowing others to add, modify, and/or otherwise customize them for their own needs. For example, suppose an acknowledged Domain expert publishes a Foundation template. Others may use it to create Foundations, and/or to add to, modify, and/or otherwise customize it to describe their own Foundation templates.

Some embodiments provide Role templates, which are templates that describe how to assemble resources out of a collection of Roles. For example, a Role template might describe how to create a resource to help a user file taxes online by using a communication role, a processing role and some information roles.

In some embodiments, templates may offer dynamic opportunities to manipulate resources and/or specifications, for example, to provide differing interaction capabilities. For example, templates may supply descriptive specifications of resources before they are assembled. So in some embodiments it may be possible to compare alternative potential arrangements of resources to determine which one would best fulfill a purpose. In addition, if one of the resources in an operating arrangement of resources created by a template is unable to fulfill its operating agreements, then the template can be used to suggest alternate arrangements of resources that would satisfy the meet the same requirements. These are just a couple of examples of how templates might generate multiple differing opportunities, degrees of sufficiency, experiences, dynamic resource relationships, and the like, that are at least in part dependent on a Foundation and/or other resources.

In some embodiments, the methods of a published template are implemented, cohered, validated, tested and successfully operated to an extent that assures that, in appropriate contexts, they can be relied upon to a specified and/or asserted level.

In some embodiments, templates may have one or more associated descriptive specifications. By performing matching/similarity analysis, a PERCos system may identify one or more templates with associated descriptive specifications that satisfy a given prescriptive specification. Once a suitable template is identified, applying its Assemble method to a suitable set of resources may create a Construct that satisfies that prescriptive specification.

Templates may supply some of a Construct's resources, including purpose-specific resources, in addition to those passed in to the assemble method. All of these methods may return a failure indication if they cannot complete their work. For example, if a template is asked to decompose a prescriptive specification that it does not know how to implement, it can indicate that it could not create the associated prescriptive specifications.

ST.Compose(<DS₁, . . . , DS_k>) is a descriptive specification of

ST.Compose(<DS₁, . . . , DS_k>)⇒PS.

ST.ComposePre should satisfy the condition that if, for each i, the prerequisite specification of R_i, is PR_i, then the prerequisite specification of ST.Assemble(<R₁, . . . , R_k>) is PR.

Thus for example, a Construct template may decompose the problem of accessing a web page on a private network into two requirements: a working VPN to the private network and a browser with sufficient capabilities to view the web page. The VPN solution found may have a perquisite specification requiring a credential to access the private network and the web page may one that can only be viewed on Internet Explorer. So the composed prerequisite specification may require a Windows platform with Internet Explorer and sufficient credentials to access the private network.

Some embodiments may provide one or more templates for supported specification languages that convert individual specifications in those languages into corresponding templates.

Foundation templates are PERCos templates to assist users (including experts and Stakeholders) to specify their Foundation resources. In some embodiments, they may specify one or more standardized resource arrangement to support one or more operating Constructs and purposes based on and/or including user preferences and interfaces. They may also specify Foundation elements that users may need to provide to describe their foundational resources, such as, their operating environment, such as contextual usage characteristics, performance specifications, or other parts of the operating environment. Foundation templates may assist users with governance specifications that specify rules for supporting Foundations. For example, some Foundations may specify that only operating Constructs with desired value of Repute.

Some embodiments may utilize prescriptive and descriptive Foundation templates. A user creating a Construct or other resource may, directly or indirectly, use a prescriptive Foundation template to specify the Foundation requirements for using her new resource. For example, an embodiment might provide a purpose class application to help develop Foundations. A user writing a web application could interact with this purpose class application to specify that the Foundation may require a modern browser (e.g. a browser that can handle HTML 5 and JavaScript). The purpose class application might generate this Foundation by starting with an empty Foundation (that does contain any constraints) and applying a Foundation template that adds the modern browser. Similarly, if at a later time the user finds that his Construct or other resource may require other technologies such as Adobe Flash, the user can interact with purpose class application causing it to apply a Foundation template that adds Adobe Flash to the Foundation.

In some embodiments, by using Foundation templates in this way, the purpose class application may support interoperability and Standardization. If the Foundation templates are created by acknowledged Domain experts, then the PERCos embodiment may not get cluttered with different ways of specifying the same requirement such as “latest Oracle Java”, “Sun Java”, “Java 1.7.0_06”, “Java 7”, or the like. A standardized collection of Foundation templates may utilize a common and interoperable scheme for representing this requirement.

In some embodiments, by using Foundation templates in this way, the purpose class application may detect conflicts. For example, suppose that a user starts by specifying a Foundation of Apple iOS (e.g. she is targeting an Apple iPhone or iPad). Then if she adds a requirement for Adobe Flash, the Foundation template that adds Adobe Flash may be able to look at the existing Foundation and determine that Adobe Flash is not compatible with iOS.

Some embodiments may permit users to use descriptive Foundation templates to refine a Foundation describing their system. Thus for example, a user who has recently installed a new version of Java in her computing arrangement may have a Foundation that does not yet specify this new Java capability. This user may invoke a Foundation template that compares the users Foundation with the users computing arrangement and provide an updated Foundation that creates a modified Foundation that removes old functionality that is no longer present and includes any new features that it finds. This Foundation template might interact with the user when generating the new Foundation so that the user can override any decisions that the Foundation template makes. For example, the Foundation template might find that a certain feature appears to be missing, e.g. a graphic card capability, when this feature is only temporarily inactive (e.g. it may be restored on the next boot).

Foundations may be published as templates, in part or in whole, and further comprise specifications and/or instructions that vary their respective usage, for example, Foundation characteristic expressions (in some embodiments these may be resource characteristics specifications, as Foundations and Foundation templates may be resources), such as specialized Foundations for supporting tax preparation, video editing, and/or other PERCos process and/or operations.

Foundation templates may be extracted and/or derived from operating Foundations. Such templates may be made persistent through use of appropriate publishing services, such as PERCos Platform publishing services, over the course of operating Foundation session operations.

Foundation templates, like any other resources, can be published and/or associated with one or more purposes. They may also utilize history or other storage mechanisms to, in whole or in part, store the unfolding specifications, and such stored template specifications may then be made available to one or more process, subject to Governance, potentially for in one embodiment, publication and further distribution.

In some embodiments, purposeful templates (PT) may be used to create, build, and/or instantiate purposeful Constructs, such as, Frameworks, plugins, purpose class applications, resource assemblies, and/or other PERCos objects that can be evolved, cohered, resolved, transformed into operating Constructs.

Users and/or acknowledged Domain experts may create purposeful templates for use by other users to create, build, and/or instantiate purposeful Constructs in pursuit their respective purpose experiences.

Purposeful templates (PT) may be associated with one or more purposes and can support differing degrees of purpose generality. Some PTs may be highly general and may require users to refine them before they can be transformed into purposeful Constructs. For example, acknowledged Domain experts may provide a general purpose template that other users can customize as appropriate to arrange resources for efficient and effective pursuit of their respective purpose experiences. Suppose a professor created a highly general PT, GenMusic that enables a wide range of users, from music students and amateurs to professionals enabling them to use/build/create Frameworks for learning about classical music. A user may use this purposeful template to create and/or build a Framework that enables professional musicians to prepare for their performances.

Like other Constructs, purposeful templates can be specified at varying degree of completeness. Users may need to provide additional information, such as, additional resources before a purposeful template can be used to build/create Constructs for fulfilling purposes. For example, a purposeful template may provide specifications for providing purposes, such as, specifications for purpose expression elements, such as, Master Dimensions, user preferences, and the like. However, it may not have the structural specification to organize resources. In such a case, users who wish to use the purposeful template may need to apply a template to provide the structural information before they can use it to create new Constructs, such as, Frameworks.

Framework templates may be used, subject to governance processes, in multiple Contexts, including those for which their creator may have no knowledge and as such their specifications may be varied, through Coherence Services, to suit the applicable resources and/or Foundation arrangements.

Frameworks, plugins, purpose class applications, resource assemblies, and/or other PERCos objects may be published as templates, in part or in whole, and further comprise specifications that vary their respective usage, for example, Participant characteristic expressions, such as “Learn”/“Beginner”/“Category N”, and/or other PERCos process and/or operations.

Framework templates may be extracted and/or derived from operating Frameworks. Such Framework templates may be made persistent through use of appropriate publishing services, such as PERCos Platform Publishing Services, over the course of operating Framework session operations.

Framework templates may also utilize history or other storage mechanisms to, in whole or in part, store the unfolding specifications, and such stored template specifications may then be made available to one or more process, subject to Governance, potentially for in one embodiment, publication and further distribution.

A resonance template is a set of algorithms associated with one or more purposes for enhancing resonance (i.e., optimizing and reducing friction) of the results.

A resonance experience template may comprise a published specification template that contributes to a purpose-related operating session results in an experience that resonates with the user. For example, suppose a user is interested in learning about thin film solar cell technology. A resonance experience template may support users to obtain purpose experience that resonates most with the user. In some embodiments, a resonance experience template may support a variety of resonance templates, such as, resonance experience templates, resonance results Frameworks, and the like.

In some embodiments, resonance experience templates may support users with the optimization of the quality of purpose experience, such as, the quality of unfolding process, purpose operations, and the like. For example, suppose a user is interested in listening to a piece of music. There may be many ways (purpose experiences) for the user to hear the same piece of music. A resonance experience template may provide methods for the user to obtain most pleasant experience, where pleasantness may be due to the ease of obtaining listening experience, the medium for providing the music, and the like.

Resonance result Frameworks may enable to efficiently and effectively create, structure, build, and/or organize one or more arrangements of resources in pursuit of purpose experiences that focus on optimizing different aspects of purpose results. For example, commercial result Framework may enable building and/or creating one or more arrangements of resources for fulfilling purpose experiences that produce commercial results that resonate most with users. Suppose, for example, a user is interested in exploring in finding a decorator who can redecorate their house. A commercial result Framework may provide an apparatus and methods to structure, aggregate, organize, and/or arrange resources for producing a list of decorators who would most resonate with the user. For example, even though there are two decorators who are equally skilled and have the equivalent Reputes, the user may resonate more with one decorator's customer interaction style than the other.

In some embodiments, some or all of these associated specifications may be resources passed to a template, along with component resources, when it is invoked.

Some PERCos embodiments may provide specialized templates that assist users and/or acknowledged Domain experts in efficiently and effectively arranging appropriate resources for the pursuit and/or satisfaction of purposes. These organizations may be based upon one or more principles, which may involve standardization, Dimensions, Reputes, and/or other specification sets. In some PERCos embodiments, some templates may invoke PERCos Platform services, and/or include such invocations within the methods of the Construct.

For example, as illustrated in FIG. 18, Illustrative Example of Construct showing example of simplified Participant resource.

In some embodiments, some Constructs, such as certain purpose class applications, may have constituent specifications and resources that have been previously cohered and resolved, so that these Constructs are ready, once coupled with their Prerequisite resources (e.g., operating Foundations), to be launched as operating resources. Other Constructs may require further processing, for example, cohering and/or resolving, before they can be launched as operating resources.

Many operating systems are based on complementary notions of computational units (e.g., tasks, processes, threads) and storage or communication units (e.g., files, streams, pipes, memory). However, this distinction cannot be consistently imposed in a platform independent system. Storing and retrieving information involves computation, and computation involves storing and retrieving information. Similarly, communication may involve any or all of storing, retrieving, and computation. A distributed operating environment inherently involves communication. In a well-structured distributed operating system, requesters may not know (and may not care) where, when, and to what extent such storage, retrieval, computation, and communication take place. (Caching is a very simple example of this.) Hence, PERCos embodiments treat them all as resources.

The goal of standardization and interoperability is to ensure that each invocation of a method of a resource is properly interpreted, i.e., it carries out the relevant operations to generate and return specified results and change state as specified, and to ensure that the results are properly interpreted by the invoker.

Existing information systems largely operate as “silos,” where particular applications and tools are intimately bound to particular data formats, storage mechanisms, data locations, communication protocols, and/or access control regimes, locking in users and rendering “connecting the dots” excessively difficult if the dots happen to be in different silos. The applications supported by such systems are largely comprised of sets of specific functions that perform particular application-specific tasks. By requiring the user to choose one (or a few) silo(s), they obstruct the user's ability to organize available resources to supply customized services, shaped to the specific current user purpose(s). PERCos embodiments free users from preconfigured task silos, allowing them to employ resource capabilities and dynamic arrangements that are optimized for fulfilling specific user purposes as indicated by CPEs, context, and history.

PERCos embodiments systems may provide access to resources that have been traditionally linked in silos. Legacy silo applications can be embedded in PERCos embodiments resource arrangements, such as, for example, Constructs including Frameworks and Foundations or otherwise integrated into resources. Preferred embodiments may, over time, encourage a more flexible and eclectic approach for deploying and using tool and data resources, regardless of their silo origins.

A PERCos embodiment resource architecture may emphasizes platform independence, using each resource by invoking its methods—often independent of its implementation or location. A resource may operate on different platforms or platform variations and may produce different results for different Participants, because, for example, the Participants have access to different resources, have different rights, and/or have differing purpose specifications. PERCos embodiments systems may interface with “legacy” or other platform-dependent systems through specialized method implementations called transformers; the properties of a transformer may be constrained by platform dependencies built into the underlying resource.

By treating everything available for use in responding to a user/Stakeholder as a resource accessed by its methods, and making the association between them dynamic, PERCos embodiments provides a uniform mechanism for substituting for missing component elements, responding to a wide variety of component element failures, dynamically adding or removing component elements, incorporating legacy components, optimizing component selection, and the like.

On the computing side of the Edge, there may be multiple information organizations, comprising multiple sets of resources and/or information about those resources. In some embodiments, these information organizations may be closely coupled to the information itself, such as, for example, databases, directories and/or other information repositories. Information organizations may have purpose expressions associated with them, for example, descriptive CPE, and may be associated with one or more purpose class systems.

One key aspect of the information organization in some PERCos embodiments is the relationships of resources to each other, which happen to be independent of any of the organizational structures that they may be associated with. These resource relationships enable one or more resources to be configured into information organizations that can effectively be matched and/or manipulated to meet users internal information organizations (user classes), initially through class systems and thence through semantics, syntax, linguistic and/or other algorithmic organization constructs.

The flexibility of this approach through the minimal organizational overhead of classes provides users with the apparatus and method embodiments to arrange both their own purpose on the human side of the Edge and the computer domain results sets, so as to achieve an optimized, for that user in that context with that purpose at that time, degree of purpose satisfaction.

In some embodiments, this organization of information on the computing side of the Edge may be considered as an information matrix, comprising those organizing principles, such as, for example, classes, complimented with those results sets that users, processes and/or other methods, such as, for example, Coherence, have represented. This information matrix may then be manipulated and managed by users to suit their own purpose and/or associated perspectives. These manipulations may be derived from their initial purpose expressions, and may span multiple purpose Domains as, for example, users absorb the results and iterate their purpose in response to those results sets.

In some PERCos embodiments, these information organizations may be constructed by experts, reflecting the “best practice” and/or commonly accepted organizational structures for those purpose Domains that encompass their expertise. This may include multiple information organizations representing differing perspectives and/or presentations of resources comprising those domains.

Users may also create, manage and/or manipulate their own information organizations in manners that suit their context and/or purposes. For example, users may choose an ontology organization for a large information set, that they maintain in a cloud storage environment, and a more simple single index based organization in a constrained computing environment (for example, a mobile device).

Users may also store their information organizations for reuse by themselves and/or other users. They may also publish these organizations for use by wider user constituencies, and through, for example, Reputes may over time become to be considered as an expert in their domain of purpose publication.

In some PERCos embodiments, resource relationships may be used by processes, other resources (including specifications) and/or one or more users/Stakeholders to create information organizations that satisfy one or more purposes.

These resource relationships may comprise any specifications that express the relationships, which may, for example, include metrics, class membership, indexing, database relationships, set memberships, attributes and the like. PERCos embodiments, in dealing with the one-to-boundless also have defined relationships which may be used in a standardized and interoperable apparatus and method embodiments to support purpose operations.

In many circumstances the effectiveness of these capabilities in creating information organizations and resource relationships with high degrees of utility for the satisfaction of purpose may be determined by the degree of expertise of the users who have utilized these capabilities. For example, an expert in purpose Domain 1, may create a specific set of specifications, that when fully resolved, provide another user with limited or no expertise in Domain 1, an environment in which that user may experience an appropriate set of resources sufficient to satisfy their purpose.

PERCos embodiments provide the apparatus and method embodiments for experts to leverage their expertise to the benefit of other users and provide users with the ability to express their expertise in one or more purpose Domains.

Resource relationships may be stored and manipulated and/or published as other resources for use by one or more users/Stakeholders.

PERCos embodiments enable resource relationships to be organized in any manner one or more users may elect, however, should that election not include the standardized and interoperable capabilities outlined above, such organizations may be of little value in satisfying purpose. PERCos embodiments capabilities encourage users to utilize the standardized and interoperable PERCos apparatus and method embodiments to satisfy their purpose and provide such satisfaction expressions to their users with same or similar purpose intentions.

In some PERCos embodiments, a user has an associated information space that is particular to them, in that it may comprise the information sets generated by their interactions with PERCos embodiments resources and/or information sets. These sets of information provide users with the opportunity to manage their PERCos embodiments interactions.

In some embodiments, the organization of sets of resources and/or information by one or more experts may be represented through one or more standardized and/or interoperable PERCos embodiments apparatus and method embodiments, including, for example, class systems, Constructs, class and/or purpose applications, purpose plug-ins and the like.

Experts may select the degree to which user interactions with their PERCos embodiments representations may be controlled by one or more sets of specifications.

Experts may publish their resources, specifications and information sets.

In the computational domain, information may be organized in any manner however such organizations generally have an intention behind the organization principles for the formatting of information into a knowledge structure. For example, these may be used for knowledge storage, representation, transfer, interaction and/or other associated processes. Currently examples of knowledge structures include Logics, Databases, Directories, and the like.

Generally such current knowledge structure implementations have close associations between the information organization, the schema, and the utilization of that knowledge (often including the representations, such as, for example, forms and the like) and/or the processes for interaction with the knowledge contained therein (for example, SQL)

PERCos embodiments may provide multiple organizations of information into one or more knowledge repositories, enabling users/Stakeholders to interact with such repositories in pursuit of their purpose. In some embodiments, these organizations include class systems, purpose Domains, Repute repositories and other knowledge structures that are aligned with the purposes with which they are associated.

Currently there are a number of knowledge structures that provide general information and knowledge management systems such as for example, Wikipedia, DMOZ, Semantic web, Encyclopedia(s), dictionaries, thesaurus, any reference systems including classification schemas such as ISBN, Dewey Decimal, Library of Congress and the like. There are also specialized portals providing sets of knowledge. However none of these provide purpose metadata, nor are they organized by purpose.

In many circumstances the expression and communication of knowledge may require one or more standardized knowledge repositories and communications methods for such knowledge transfer.

PERCos embodiments may include one or more methods embodiments for both, including through one or more classes as embodiments of information organization for purpose operations, for example, providing a lossy apparatus and method embodiments for such operations.

In some embodiments, Classes, as an organization may be used to express purpose, resources, attributes, modalities, temporalities, combinators, synonyms and the like.

In some embodiments, PERCos embodiments may include one or more ontologies for purpose expressions and/or operations. Such ontologies may be created by one or more experts, which may also have associated Reputes indicating the standardized and well accepted nature of an ontology within a given purpose Domain. For example, purpose Domain ontologies may comprise those resources and/or information sets regarding those resources that are associated with one or more sets of purposes (potentially expressed in one embodiment as purpose classes), whose relationships have been specified/defined as sufficiently consistent and/or have been to be declared, by one or more users/Stakeholders to be members of a given class structure (including sub classes and/or other class relationships).

In some PERCos architecture embodiments, a key aspect is the expression of relationships among purposes, resources, users/Stakeholders and any other specifications comprising a purpose System. These relationships inherently provide the basis for multiple systems including, for example, organizational, categorical, algorithmic and the like to create and derive the rich diversity of possible experiences that may be generated as users pursuit of purpose unfolds.

Another key aspect of PERCos embodiments systems is the satisfaction, to the optimal degree possible, of users' purposes. In some embodiments this involves two primary apparatus and method embodiments for undertaking such optimizations, Repute, which identifies and expresses the quality of one or more resources to purpose, and resonance which expresses the optimal resources (and arrangements thereof) for purpose.

Management and alignment of these resource relationships may be driven by user purpose and their associated interests and expertise. However when multiple such purposes and/or resources are involved, they may be either inconsistent and/or incomplete and may be coordinated by Coherence services. Coherence services algorithmically formulate new specifications based on the totality of contextually-related specifications. An optimal Coherence embodiment does not normally require a particular source or the form of specifications. Such a bias-free architecture accommodates a broad array of differing synergistic functional subsystems.

PERCos embodiments systems may provide apparatus and method embodiments for one or more users to convey their purpose across the Edge in the form of purpose expressions and for PERCos embodiments system to manage, arrange and deploy applicable resources for user purpose with the objective of providing an appropriate purpose results set.

Throughout this process relationships between these purpose expressions, user representations and cross—Edge resources become established.

Human-understood purposes may be closely related, for example, “get” and “buy” may be understood similarly by the human. PERCos embodiments provide apparatus and method embodiments for representing relationships among purposes as well as other resources. For example, relations may be represented though class systems, Dimensions, metrics and/or shared resources. Such relationships may be declared by one or more users (including experts) and/or derived from historical information.

In some embodiments, users/Stakeholders (and associated Roles) may declare one or more sets of interests and/or expertise in various domains, which may be expressed to a greater or lesser degree and also may indicate the degree of interest and/or level of expertise.

For example, a user who has a degree in sociology, may additionally have expertise in technology, intellectual property and wine appreciation. In some situations, such a user when, for example, pursuing their wine appreciation, may wish to converse with others who have similar interests, so as to for example, satisfy their expressed purpose, of finding mineral toned Chardonnay at an acceptable price point. For this purpose they may wish to dynamically interact with other wine appreciators of a similar level of expertise, rather than depend solely on experts. In many social situations, users may not wish to have their expertise compared and/or related to experts, for fear of seeming to have no or little appreciable social value.

Experts may form committees and/or other informal or formal groups to discuss, arbitrate and/or further develop their domain expertise. In many of these cases, there may be specifications (often as rules) determining the membership of these groups. Such expert groups may undertake the development of new standards as well as maintenance and/or auditing of existing standards of the domain of their expertise.

The relationships between experts may influence the apparatus and method embodiments and methods for the publication and distribution of expertise that groups of experts have developed.

Stakeholders may have relationships amongst themselves that may be commercial or non-commercial, such as, for example, Patent Pools, distribution arrangements, delegation of responsibility and the like. In some embodiments, these stakeholder relationships may form purpose domains, for example, DVD consortium, Open Source Foundation and the like and may incorporate one or more organizational structures.

Roles may include one or more sets of specifications that determine the relationships and degree of interaction of Roles with other Participants.

PERCos embodiments may provide apparatus and method embodiments and methods for creating such dynamic social interactions based around one or more purposes (including common purpose), with appropriate expertise selection and definition capabilities, and further providing for such groupings to be formalized (and/or published), persisted and/or made into further PERCos embodiments resources.

Human, as well as computer, behavior always has context. In PERCos embodiments there are both standardized, and other, sets of contextual information which can be represented cross-Edge, by users, publishers, and/or other Stakeholders for use in and by a PERCos embodiments computational domain.

PERCos embodiments may provide apparatus and method embodiments to systematically frame and convey facets of users' purposes in contexts that can be interpreted to generate appropriate operational specifications for such purpose operations in such contexts. A PERCos embodiments system enhances human/computer evaluation, organization, management, interpretation, and presentation of contextually available resources so as to optimally satisfy users' purposes.

In some PERCos embodiments there may be one or more processes, for example, Coherence, Repute, SRO and the like that assist in dynamically resolving these contextual specifications into sets of resources that can be further resolved into operating resources forming cohesive and efficient operating sessions in pursuit of unfolding purpose operations leading to appropriate contextual user experiences.

All of which combine to provide, in some embodiments, users with apparatus and method embodiments to resolve their purpose expressions so as to generate cross-Edge experiences that in whole or in part satisfy their purpose.

A PERCos embodiment may provide a specification-driven, adaptive dynamic environment. Rather than merely supplying applications suitable for pre-identified general activity types (word processing, spread sheet, accounting presentation, and the like), a PERCos embodiments environment is designed to provide experiences corresponding to expressed contextual purposes by generating resource arrangements and unfolding executions in response to specifications including purpose expressions.

For example, PERCos embodiments environment may provide users with iterative and/or interactive sets of processes, including, for example, PERCos embodiments Platform SRO service (Specification Resolution Operational), for assisting users in specifying their Contextual Purpose expressions (CPEs) so as to generate operational specifications that may lead to satisfactory user experiences.

This rich environment may include knowledge discovery tools that users may use to discover and/or manipulate knowledge captured and published from past experiences by other users, Stakeholders and/or systems. It may also provide specification languages, services, tools, and/or utilities that users, other Stakeholders and/or systems can use to compose and/or build and/or otherwise manipulate knowledge structures. Such structures may be used to articulate and subsequently identify and/or prioritize rich, nuanced, and highly responsive specifications and their associated resolutions extracted from arbitrarily huge resource arrays for user contextual purpose operations.

In PERCos embodiments anything can be a resource. In some examples a resource may be a book, comprising chapters. In this case should a chapter be extracted from the book (described as extracting a “facet” from a resource), and given an identity, then such a “facet” would be a PERCos embodiments resource element, which can be a type of PERCos embodiments resource. Such an element could then be combined with other resources and/or associated with one or more resource interfaces to create another PERCos embodiments resource.

Facets may be created by any apparatus and method embodiments, declarative, algorithmic and/or by any other methods, limited only by resource from which Facet is extracted to support such an operation. In the example above, the information structure (chapters) provides an apparatus and method embodiments to which an extraction method may be applied. Whereas if the resource was, for example, a “black box” process (for example, a java .jar or dll), whose resource interface declared the resource as base, then a Facet could not be extracted.

In some embodiments, this degree of resource composition and ability to have further Facets extracted may be defined by appropriate resource interfaces, and as such where a resource is declared as base, with no potential to extract any underlying components of resource, and complex, where there may be potential to extract Facets from resource.

In some embodiments, where resources comprise complex arrangements, extraction of Facets may be undertaken by employing methods that involve multiple algorithmic calculations. For example, multiple candidate results sets may be processed through purpose operations, comprising multiple resources and associated information. PERCos embodiments platform services provides a Facet extraction capability, which under command of appropriate specifications (PERCos embodiments control specifications), may operate on such results sets so as to extract appropriate Facets, which may then, for example, be composited into one or more other resources, which, may in turn be utilized in further purpose operations and/or published.

3 Classes

Class, subclass, and class system are key concepts of PERCos systems. This disclosure about PERCos classes introduces and discusses some of these aspects, with a focus on their use to specify and/or manipulate purposes and/or resources.

The concept of class is important in organizing, describing, and/or reasoning about the relationships among many kinds of things, including human activity requirements and resources for responding to them. Class- and subclass-based categorization and reasoning are older than Aristotle (“All Men are mortal. Socrates is a man. Therefore, Socrates is mortal.”), and probably nearly as old as language itself. Classes are inherent to human thinking and context, and constitute a practical lynchpin of human relational perceptions of reality. PERCos embodiments augment class structures and relations beyond the capabilities traditionally provided in class-based applications such as Object Oriented Programming (OOP). Its more general relational and weighted structures facilitate, among other things, efficient approximate searching, matching, and reasoning operations.

Classes are a very broad notion, useful for a variety of purposes. That very versatility can make discussions of the uses of classes confusing, unless the uses are carefully distinguished. Later sections describe certain important aspects of PERCos systems in terms of various class systems. In some embodiments, some of these class systems may share some or all of their data structures and operations, and some class systems may contain class Subsystems of multiple types, including, for example, purpose classes, resource classes, publisher classes, and asserter classes.

It is the nature of reality that most tangible and conceptual things cannot be described comprehensively and with absolute precision. Nor is it practical to give a distinct name to each possible thing. Properly used, classes can provide powerful practical solutions to both of these problems.

The name of a class of similar things (e.g., “Human,” “Star,” “Country”) makes it possible to generally and practically refer to this collection of related items, without any need to list them all. Inclusion in a class allows the possibility that some members have further attributes making them members of one or more subclasses, to as many levels of detail as are appropriate. For example, “Human,” “American,” “Californian,” “Female,” “19^th Century,” . . . .

The usefulness of a class or attribute in discourse depends in part on the degree to which it corresponds to similarities and/or distinctions that participants recognize—in certain contexts—and the ease with which those users inherently and/or explicitly recognize their correspondences with class/attribute names. Thus a child's cosmology might consist of “Sun,” “Moon,” “and Star,” while an astronomer's might include “Star,” “Planet,” “Planetoid,” “Moon,” “Asteroid,” “Comet,” “Galaxy,” “Nebula,” “Black Hole,” or other astronomical body. Such collections of names are often organized, codified, and/or presented as taxonomies or ontologies.

An ontology may generally relax condition 2, and allow some items to belong to multiple classes that are not necessarily hierarchically related, and may also generally define relations among classes in addition to subclass/superclass.

When a name of a member is replaced by a name of a containing class, information is generally lost (e.g., “Athenian” is a less-precise reference than “Socrates,” because there are members of “Athenian,” that aren't “Socrates.”) Similarly, when a name of a class is replaced by a name of one of its superclasses, information is generally lost (e.g., there are more members of “Greek” than of “Athenian.”) Such replacements by class and/or superclass names are useful examples of lossy transformations.

In some embodiments, if a transformation loses information substantially relevant to a current purpose, it may be undesirable—we might start out, for example, with the purpose of learning about the philosophy of “Socrates,” and be given all the “Greek” philosophies instead. But appropriate lossy transformations add value by preserving essential information and discarding irrelevant information. They are among our most powerful tools for capturing, structuring, storing, searching, and otherwise managing useful summaries of information. They can help organize a vast quantity of items and their characteristics that constitute a domain of interest—if our purpose were looking for information about the army in which “Socrates” served, the class “Athenian” would probably be a better starting point than its member “Socrates.” The challenge is to find and use the right lossy transformations at the right times and in the right contexts. This is discussed in following sections. Other name replacement processes may add or otherwise enhance information.

Class lossiness corresponds to the nature of much human thinking, by serving as conceptual, impressionistic arrangements that are inherently flexible. They support co-evolution of human and computer reasoning and assist progress towards purpose satisfaction.

Traditionally, classes provide a framework for describing structures relating sets of items (or objects). Each class has a set of items that are its members (instances), which share particular attributes (fields and/or methods), but may differ in other attributes. An attribute may be referenced by names and may either have a value or be abstract (not yet specified). Methods are operations that access a member, for example, to set, modify, change, and/or extract the values of one or more of its attributes. Fields are non-method (value) attributes. Properties are Boolean fields. Within such structures, class names provide a way to identify (designate) class specifications, enabling them to be used “by reference” without repeating their full specifications.

Some classes may be statically defined, while others may be dynamic, e.g., arising in the course of a computation.

The first two forms are useful for specifying new classes; the third, for reusing existing class specifications.

A class system is a set of classes, together with at least a subclass relation over them. The classes in a class system may be related in a variety of ways. However, subclass is the fundamental relation used to relate classes in traditional class systems. A is a subclass of B (and B is a superclass of A) if all members of A are members of B. This implies that each member of A has at least the attributes that all members of B have.

The concepts of subclass and member should not be confused. TallBox might be a subclass of Box, meaning that all its members are members of Box, but this subclass would not be a member of the class Box. I.e., any member of TallBox would be a member of Box, but the class TallBox itself would not be (nor would the class Box).

In some embodiments, Class specifications need not be written from scratch: Existing classes, identified by their names, can be combined and/or extended to succinctly specify new classes. A compact way of describing a new class is to list one or more superclasses and add any further attributes that all members of the new subclass have.

For example, as illustrated in FIG. 19, An Example of a Simple Class System.

FIG. 19 represents an example class system. (I.e., we There is enough contextual information to interpret terms in sufficiently similar ways. This class system is particularly simple, but is sufficient to illustrate a number of points about class systems and their traditional uses.

Classes are represented in the diagram by gray boundaries and Bold italic class labels. Members are represented by small circles with plain font labels. A class contains the members contained in its boundary. A class is a subclass of any other class whose boundary encloses all of its members (e.g., Greek is a subclass of Man).

The reason that members are represented by circles rather than points is that, in some circumstances, members may themselves be treated as classes and extended with additional attributes to form still finer-grained classes (e.g., Socrates the Philosopher, Leonidas the King), which themselves may have one or more members.

It is important to note that a member does not generally “belong to” just one class. In this example, Pericles is a member of the classes Athenian, Leader, Greek, Man, and Being. A superclass of a class or instance is called a direct superclass if it does not contain any of its other superclasses (e.g., Greek is a direct superclass of Athenian and Spartan, but Man is not).

For example, as illustrated in FIG. 20, An Example Simple Class System, Extended with Mortal.

Now we extend the example by adding a representation of the assertion “Every Man is Mortal.” This applies to Socrates, Leonidas, Alexander the Great, et al. It is more compact and convenient than the separate assertions “Socrates is Mortal.” “Leonidas is Mortal.”, “Alexander the Great is Mortal.” . . . . But more importantly, it generalizes and scales—an arbitrary number of instances of Man could be added to this class system without also explicitly adding declarations that they have the attribute Mortal with value true. Class systems can lead to efficient structures for storing the attributes of a set of members, even when the number of attributes and the number of members are both very large.

The class Mortal, whose only attribute, Mortal, has the value true in all its members, represented by the dashed line in the preceding diagram, defines a superclass of Man. In this class system, Mortal happens to have the same members as Man, but in general “Every Man is Mortal.” merely indicates that members of the class Man have the attribute Mortal (Man is a subclass of Mortal). A slightly richer class system might include Mammal, Animal, Tree, and other subclasses of Mortal that are not subclasses of Man. (Note also that this example is atypically simple: It is seldom possible to explicitly show very many attributes within this style of class system diagram.)

A class system can be used to speed up searches for members of selected classes by first pruning candidate classes. For example, if the desired class were Mortal and Greek, then the class Mortal could be searched for a subclass Greek, which could be returned without enumerating and checking the members of either Mortal or Greek individually. Similarly, a search for objects that are not-Mortal, could reject the whole class Man without enumerating and checking the attributes of any members.

Because classification and subclassing are deliberately “lossy,” classes can also be used to efficiently search for instances that are similar, though not identical. Members of a class are similar to the degree that they share a set of attributes and attribute values, although they may vary widely in other attributes. In our example, we might expect Plato and Pericles to be more similar than either one is to Leonidas or to Alexander the Great, because Plato and Pericles are both members of Athenian and thus share all the attributes of Athenian (which are not shown in these diagrams). We might also expect all four to be more similar to each other than to Zeus or Atlas, because they are all members of Man.

The practical quality of a given class system may determine the effectiveness of its classes for lossy reasoning, searching, and/or matching. That is, “good” classes in a context may have members that seem similar to users for whom the reasoning, searching, and/or matching are done in that context, because they reflect distinctions that are recognizable and important to those users.

Traditional class system diagrams such as those described above play a role similar to that of Venn diagrams for sets. They can be an effective representation for visualizing a small class system whose representation fits neatly on a single page. Since their interpretation is topological, items and class boundaries may be moved around to shift emphasis and/or to alter their appearance. Subclass relations are easy to see in small class system diagrams.

However, traditional class system diagrams have limitations that severely reduce their usefulness, particularly in large-scale systems, with hundreds to millions of classes, and thousands to trillions of members.

An alternative way of describing a class system avoids these problems. A language of class expressions can be used, giving information relating members to classes, relating classes to other classes, or relating attributes to classes. For example, the following set of expressions (The precise syntax is not important here. There are many, many formal languages that can precisely express such information, as exemplified by the number of different Object Oriented Programming (OOP) languages) describes the same class system as the example diagram shown as FIG. 19,

Alexander the Great is a member of Man.

Alexander the Great is a member of Leader.

Alexander the Great is a member of Man.

Athenian is a subclass of Greek.

Atlas is a member of Being.

Greek is a subclass of Man.

Leader is a subclass of Man.

Leonidas is a member of Leader.

Leonidas is a member of Spartan.

Man is a subclass of Being.

Man is a subclass of Mortal.

Pericles is a member of Athenian.

Pericles is a member of Leader.

Plato is a member of Athenian.

Prometheus is a member of Being.

Socrates is a member of Athenian.

Spartan is a subclass of Greek.

Zeus is a member of Being.

This defines a mathematically precise class system, although in this example the degree of correspondence to “the real world” (or to any particular user's model of the world) may depend on the interpretation associated with the terms used (e.g., Man and Plato).

Note that the order of the class expressions is as irrelevant to such a description of a class system as the geometry of a class system diagram is to its description. This set of class expressions can be written in any order and still describe the same class system, but some orders may be easier to read and understand than others, just as some diagrams may be easier to view and understand than others.

A considerable amount of standardization of terminology is a prerequisite to reliable interoperation of separately developed class systems and/or class system components. As may be explained later, PERCos systems can provide substantial assistance in avoiding, detecting, and/or correcting such errors.

Declared class system expressions and their components (e.g., class expressions, attribute expressions, member expressions, and tokens) generally have at least two corresponding representation systems, including one that is human-sensible, e.g., letters, and one that is efficiently machine-manipulatable, e.g., ASCII characters. These representation systems are normally chosen to make translation among them straightforward.

Mathematically speaking, in some embodiments, a set of Edge class system expressions might define a theory, and an internal class system normally provides a model of a corresponding theory. In some embodiments, as a set of Edge class expressions grows and evolves, one of the tasks of Coherence processes is to check the set for consistency (to ensure the existence of a valid model), and if it finds inconsistencies, to bring them into consistency, possibly with the interactive assistance of one or more users.

User classes comprise user-identified relational composites that collectively, symbolically, and often impressionistically surface certain underlying human conceptions regarding purposes and resources. They comprise members, items that the user thinks of as “belonging together” in some context. These concepts, and the relations among them, are practical conveniences of thought within a human's mind. They may or may not correspond closely to any external (e.g., written or spoken) form, or to the user classes of any other human—or even to those of the same human in a different context. As relationally perceived concepts, they may have a variety of primary and more subtle secondary perceptual and psycho-physiological Dimensions.

Something akin to user classes is involved in most purposeful thought, and many user classes may be closely associated with linguistic constructs such as nouns and verbs.

By their nature, user classes do not have precise boundaries. This imprecision is a consequence of the nature of human consciousness, which is mostly an imprecise relational composite, particularly as it perceives and interacts with the “external” world. This imprecision is often useful. Such “looseness” can contribute to flexible and adaptive thought progression. Human dynamic relational perception and thought support and employ both lossy and flexible transformations and abstractions, including use of subclasses and superclasses, to organize wide-ranging and potentially vast collections of items.

A user class may, at least in part, effectively include:

1. Members that share what the user believes to be common attributes (intensive description), for example, “tasty food,” “hot pie,” “warm clothes,” “things that weigh less than a pound,” “run,” “learn plumbing,” “fix leak,” “travel faster than light,” “enjoy sleep,” “see movie,” “entertain,” “educate children.”

2. Members that the user selects (extensive description); the Members of the class are determined by the particular instances considered. For example: my “exercises” are “walk,” “jog,” “run,” and “bike”; my “worrying threats” are “physical assault,” “stock market crash,” “damage by earthquake,” and “destruction by hurricane”; my “favorite flavors of Jell-O” are “Lime,” “Cherry,” and “Orange”; my “favorite pets are “dogs,” “cats,” and “hamsters.”

A user class system comprises a collection of user classes, together with one or more relations, including subclass, which indicates those classes the user considers to be related in some relevant fashion. The imprecision of user classes leads to corresponding imprecision of these relations—they may generally be impressionistic rather than exact. E.g., a user may think of “Car” as a subclass of “Vehicle” (because “a ‘Car’ is generally a ‘Vehicle’”), without considering the precise boundary of either “Car” or “Vehicle,” and certainly without enumerating all the members of “Car” and testing them for membership in “Vehicle.”

This section discusses various aspects of Edge classes, suggesting ways they may be applied in PERCos embodiments. It uses examples that apply to some embodiments employing certain structures for Edge classes and related concepts. These examples are intended to clarify concepts, without limiting them, and not all examples are meant for express use in other portions of this disclosure. Some PERCos embodiments may incorporate these structures fairly directly, while others may use other concepts, other terms, and/or other definitions in functionally comparable arrangements to achieve functionally similar behavior and results.

Throughout this section, class and attribute denotes Edge class (including declared class) and Edge attribute, respectively, unless otherwise qualified.

Each declared class contains members that have been directly or indirectly declared as similar in certain Contexts. Users may use declared class and attribute names for communication—to themselves, to other humans, and/or to computer systems—by methods of expressions composed of tokens. Despite the desirability of aligning user classes and Edge classes, they normally cannot be in exact correspondence, due to the general imprecision of human thought and to aspects of human thought that that are not captured by class systems. For example, the “closest” Edge class may lack some attributes of the user class and/or possess further attributes. Such lossiness and/or supplementation in the transformation from user classes to Edge classes may be intended and useful—for example, to suppress some of the fuzziness of human thought and/or details and natural language nuances and connotations that are not material to the description of the current user purpose.

Classes are generalizing objects used to facilitate communication and computational processes for purpose satisfaction. They may express, in an efficient and practical manner, concept specifications that correspond sufficiently closely to human concepts (particularly user classes) and their organization. They are employed to enable efficient two-way communication across human-computer Edge(s), and in multi-user, multi-Edge scenarios. These generalizing objects enable users to be flexibly exposed to purpose-related information and experiences. Classes further provide practical method of efficiently obtaining purpose-related results from nearly-boundless and disparate resources.

Declared classes may be created to represent—at least in part—related user classes and are generally intended to correspond meaningfully to them. Declared classes normally reflect human concepts as practical framing for communication across the Edge. Many user classes cannot be—or at least may not be—fully and explicitly specified.

Naming classes and using them informally are important (explicit and/or implicit) elements of how humans relationally think about and describe purposes and resources. PERCos supports and reinforces such descriptions by enabling representations of Edge classes (including declared classes) to be communicated across the human-computer Edge using expressions containing tokens, for example, in expressed purposes, in resource attribute requirements, and/or in supplementary contextual information, including user preferences recorded as Participant/Role information.

The inherent imprecision of human thought normally makes correspondences between tokens and human concepts approximate, rather than exact. Correspondences between user classes and declared classes and between user attributes and declared class attributes are normally similarly approximate. If users create Edge class expressions containing declared class or attribute names they don't fully understand, this may lead to confusion about classes they specify.

A declared class meaningfully corresponds to a user class (in a context) to the extent that its specification sufficiently captures aspects of the user class relevant to the user purpose. The degree of meaningful correspondence between an Edge class and a user class is a measure of the degree to which its members and attributes correspond with the user-recognized members and attributes of the user class, i.e., the extent to which the user considers that the members and attributes of the Edge class correspond sufficiently with members and attributes of the user class in that context. PERCos enables isolating the issue of meaningful correspondence to Internalization and Externalization. Other parts of a PERCos system may then deal with precise Edge and/or internal classes, attributes, members, and class systems.

Although, for any particular user class (e.g., purpose element), there is unlikely to be an exactly corresponding Edge class, there should be a relatively small set of standardized Edge classes that correspond closely enough to be useful. For example, “Learn” might correspond closely to a declared class Learn that had subclasses such as Attend Lecture, Do Homework, and Learn Physics, but might not have subclasses precisely corresponding to “Cogitate” and “Cram.” “Ball” might correspond closely to an undeclared Edge class that is a subclass of classes Spheroidal and Toy. “Play Ball” might correspond to a declared or undeclared subclass of a declared class Play.

To represent a user class, a user should generally choose one or more declared classes that appear to correspond most closely. Names of declared classes may be chosen from available user/group/PERCos lexicons, published extensions, and/or personal extensions. The tokens used in lexicons for particular Domains may closely correspond to terms that acknowledged Domain experts have distilled out of their own user classes. Normally, the use of standardized declared classes may be crucial to interoperability among PERCos subsystems and communication among users.

A user might choose a declared class that does not correspond sufficiently to a desired user class, due to insufficient user knowledge or user error. A user-chosen declared class might thus be more general, less general, and/or otherwise misaligned with the intended user class. But even an unsatisfactory declared class has a precise interpretation as a set of members and can be mapped to a PERCos internal class.

Generally, only the user (if anyone/anything) can sufficiently understand the user's state, including the user's belief in the degree of correspondence between a user class and a declared class. User state may be reflected in user behavior, and hence partially inferred from historical information about uses of declared classes and/or biometric/environmental input. A PERCos system may assist a user by suggesting declared classes (or other Edge classes) that appear to be relevant to an inferred user state, including, for example, candidate Facets, subclasses, superclasses, paraclasses, and/or otherwise related Edge classes.

PERCos embodiments may augment the three traditional kinds of class expression (by attributes, by enumeration of members, and by name) with, for example, and without limitation, additional methods of associating pertinent context with a class expression, including specification of purpose and/or specification of user preferences. This context may be inspected, matched, and/or otherwise analyzed to affect the interpretation of the class expression. Context expressions can be important in guiding computing processes (e.g., in a session) regarding human relational understanding and meaning associated with CPEs and/or declared classes. The use of contextual elements in class correspondence, comparison, and/or matching provides PERCos systems additional efficiency and quality of results over the traditional class.

Contextual analysis may be used in both creating and comparing Edge class expressions, such as CPEs. In some embodiments, PERCos embodiments employ algorithmically combined class-based lossiness through the use of contextual highlights and generalization as a method of effectively dealing with practically boundless distributed information.

PERCos systems may also use annotated classes that attach contextual metadata to Edge classes and/or Edge class expressions that may, at least in part, influence their operational processing.

PERCos embodiments uniquely embraces and employs the inherent lossiness of classes and superclasses as a method to practically optimize both the quality of results and the efficiency of obtaining them, by exploiting relations among classes as a method of manage resources that may be large (at times enormous), diverse, and/or multi-locational. The appropriately lossiness of using classes in place of members and/or using superclasses in place of subclasses provides a method of generalizing and relating purposes and resources. These capabilities may provide profound improvements over existing search, retrieval, and semantic tools in the identification and deployment of optimally purpose-satisfying resources.

Various embodiments may employ some or all of these techniques in various combinations and orders. In some embodiments there may be one or more choices of convenience which are outlined herein.

The definitions are presented in a generally “bottom up” order. The utility of some definitions should become clearer when the defined concepts are used in later sections.

Some attribute values may themselves be classes. A reader might envision classes swimming in a boundless sea of sets.

Some embodiments use sets extensively in the description of classes, because Set Theory is one of the simplest and most fundamental tools of mathematics, and can be used to give a sound and coherent description of important aspects of classes. Similarly, differing embodiments may represent sets in differing ways, in either explicit or implicit forms. In some embodiments, some of the sets may not have any explicit representation within the system.

Most of the examples in this disclosure use English words, phrases, and grammatical categories to explain concepts and uses relating to Edge classes. This is because these are familiar to the authors, and not because there is anything about PERCos or Edge classes that is specific to English (or to any other natural language or collection of natural languages). PERCos itself is language-neutral, but embodiments are likely to convey more insight than unfamiliar ones. The embodiments described herein are only examples to explain to one of ordinary skill in the art, and not limiting. Any of Arabic, Chinese, Esperanto, Greek, Tralfamadorian, or some artificial invented language could no doubt supply embodiments that would be just as helpful—to those fluent in that language.

In some embodiments, users may communicate with the system using primarily words and phrases of a natural language, but, even in those embodiments, there need be no requirement that they use only complete, grammatical sentences. Language fragments focusing on salient aspects of their purposes may generally be the norm, e.g., “learn calculus beginner book”, rather than “I want to learn calculus at a beginning level from a textbook.”; “attend concert dead”, rather than “I want to attend a nearby forthcoming concert by the Grateful Dead.”; “learn grow ebeans home”, rather than “I want to learn to grow jellybeans at home.”

When the disclosure uses words or phrases as tokens, the disclosure may generally use this font to indicate that they are to be interpreted as tokens, and sometimes use “quotation marks” to delimit single tokens, e.g., these, tokens, “white space”, and “for example, and without limitation,” constitute four tokens.

The specification/description of elements of classes and class systems may be expressed in one or more suitable languages and/or notations, possibly including interactive elements (e.g., drop-down menus, fill-in forms) that may constrain structure. The syntax of these languages generally can take a number of forms. Each particular embodiment may support a particular selected set of such languages, notations, and/or other communication methods, which may or may not be extensible within the embodiment, and may or may not resemble those used in this document.

A token is a unit for communication across an Edge (a communicable symbol). Some tokens may be used as declared names—of attributes (i.e., attribute names), weighted or otherwise algorithmically defined sets of attributes, classes, class systems, structural elements of expressions (e.g., operands, operators, punctuation marks), and the like.

Although informal speech and writing frequently do not clearly distinguish between a representation of a thing and the thing itself it is important to be careful about this distinction when talking about classes—especially declared classes, including purposes—and to distinguish between a class expression and the class that it represents in a given context.

Tokens may be used, in one or more contexts, to represent PERCos values. For example, the Arabic numeral 14, the Roman numeral XIV, and the binary numeral 1110 may each be used, in appropriate contexts, to represent the number fourteen, which exists as an abstract concept independent of any particular representation. As another example, the operator “+”, may in some contexts represent the arithmetic operation of addition, and in some other contexts, the Boolean operation of inclusive or, and in yet other contexts, the string pattern operator one or more.

PERCos expressions are arrangements of PERCos tokens according to the rules of specific description languages. They may be used to represent context-dependent or context-independent values. For example, XIV+II and 4×4 might each, in certain contexts, represent the number sixteen. The internal representation of an expression is itself a type of PERCos value that could be declared (named). In some embodiments, an expression may also have associated metadata that is distinct from the metadata of the values it may denote. For example, the date and time when an expression was last modified is neither part of the expression, nor metadata about any of the particular values it represents in various contexts.

Communications across a human-computer Edge largely comprise expressions, but “computational meaning” within PERCos largely involves the things the expressions represent, which are internal values (e.g., interpretations of expressions in relevant Contexts). The issue of translating between expressions and values and back (internalization and externalization) is treated in more detail.

An interpretation is a mapping from values (generally expressions) to values; it may be context-dependent. In some embodiments, the interpretation of at least some structured expressions may proceed by Interpreting each token, including tokens used as declared names, operators, and/or operands, and then operating on those values (which may involve further interpretations) to compute a result.

A PERCos declared name is a (generally relatively short) expression that has been declared, in a context or set of contexts, to be associated with another expression. For example, a single token may be the declared name of a class or an attribute; this allows the token to be used in an expression in place of a literal copy its associated class or attribute expression. Some other examples include structured declared names, which may simplify references to elements of structured values (e.g., A[7].first), and declared names used to defer interpretation (possibly in a differing context, perhaps producing a differing value).

A declaration associates a declared name (a token or other expression) with a second expression (its specification) in a class definition language. The interpretation of the declared name is the same as the interpretation of the second expression. The type of the declared name (and the declaration) is the same as the type of the specification. For example, class declared names are associated with class expressions in class declarations, and attribute declared names with attribute expressions in attribute declarations.

In some embodiments, for convenience of reference, class expressions may have one or more corresponding names. Such names make it convenient to specify a class without enumerating its members or attributes; these concise specifications greatly assist in writing short, yet understandable, CPEs and their class expressions, and greatly assist practical human pattern recognition. A class name provides a concise representation of a set of class expressions in a Context: those that the name has been associated with in that context by declaration. Names should normally be chosen to be unique and distinguishable in their Context(s) of use, so the set normally has one member. In some embodiments, one or more user-chosen names for a class may be part of a class expression and/or one or more class names may be automatically generated for each class expression.

In many contexts, it is desirable for declared names to be distinct, i.e., each declared name (token or other expression) may be associated with at most one specification, and can therefore be unambiguously Interpreted. In some embodiments, a specification (expression) may have multiple declared names in a single context.

The choice of class and attribute names may affect the perceived correspondence between a declared class and a user class—due to differences in understanding of one or more of the tokens between the human or human group providing the class expression and humans assuming a user class correspondence. For example, a misunderstanding may be due to a difference in context that changes the understanding of the name. For example, “Everybody knows what point denotes.” But is the context Games, Geography, Geometry, Jokes, Pencils, Railroads, or Rhetoric?

Declared classes and attributes are often highly useful in practice, in spite of their inability to correspond perfectly to user classes and attributes. For example, the precision of declared classes may help users understand when they have been using names differently. They may also provide generalizations and simplifications that improve practicality and efficiency in the computational Context.

A token is a unit for communication across an Edge (a communicable symbol). Some tokens may be used as declared names—of attributes (i.e., attribute names), weighted or otherwise algorithmically defined sets of attributes, classes, class systems, elements of expressions (e.g., operands, operators, punctuation marks), and the like. A Vocabulary is a set of tokens.

A ref/sense is a set of tokens intended to be equivalent representations of a single conceptual unit. In some embodiments, Ref/Senses may be represented by Internal References.

These topics are discussed in more detail elsewhere in the disclosure.

Some simple examples of sets of tokens in string form that might be members of ref/senses include:

{ . . . _ _ _ . . . . . . _ _ _ . . . . . . _ _ _ . . . , SOS SOS SOS, MAYDAY MAYDAY MAYDAY}

{x, * , ., times}

{acquire, buy, purchase}

{advanced, expert}

{American, Yankee}

{beginner, newbie, novice}

{bright, brite, shiny}

{bring, carry, haul, transport}

{British, Brit}

{calculus, differential and integral calculus}

{calculus, pebble, tartar}

{calculus, predicate calculus}

A purpose class is a class comprising purposes.

An atomic attribute is an <attribute name, attribute value> pair.

An attribute bundle (item) is a set of Atomic attributes. Class members are attribute Bundles that have been explicitly or implicitly specified as belonging to a class.

Class attribute names are class expressions.

An attribute value is any value allowed by a PERCos embodiment. Some embodiments may allow classes as stored values of Fields.

A method is a kind of attribute value that comprises one or more operations to access some or all of an attribute Bundle's other attribute values, to produce one or more values derivable at least in part from those attribute values and/or to achieve one or more particular effects on attribute values of the Bundle (i.e., to generate a new attribute Bundle modified in a particular way). Methods may be specified by, for example, one or more programs, functions, sets of rules, logical expressions, and/or other descriptions of the characteristics of those values and/or effects. Normally, methods are “invoked” as an aspect of the unfolding of a PERCos process.

Fields are attributes that are not methods. In some embodiments, each field may have associated access methods (assignment and retrieval), conventionally called put and get.

A Predicate is a Field whose attribute value is restricted to be true or false.

Simple examples of attributes might have names such as height, weight, price, and currency, and values that are numbers (for height, weight, and price) or elements of a pre-established set, such as {Dollar, Pound, Euro, Yen, . . . } (for currency).

An attribute's Range in an attribute Bundle is the set of attribute values paired with the attribute's name in any of its Atomic attributes. For example, in the attribute Bundle

{<weight, 17>, <price, 345>, <weight 19>}

the Range of weight is {17, 19} and the Range of price is {345}.

An attribute name is Single-valued in an attribute Bundle if it occurs in a single Atomic attribute, and Multi-valued otherwise. In the example above, price is Single-valued and weight is Multi-valued.

An attribute bundle is Single-valued if each of its attribute names is single-valued and Multi-valued otherwise; i.e., if no attribute name is paired with more than one attribute value, the attribute bundle is single-valued.

If attribute name a is single-valued in the attribute bundle B, let v be the attribute value paired with the name a by an atomic attribute in B. In this disclosure, we sometimes use the notation B.a to represent either 1) if v is a Field, the result of invoking v's get method, 2) otherwise, v. B.a may be viewed as a “state variable” of B, and may sometimes be called “attribute a of B.” If a is a (potentially Multi-valued) attribute name in B, we sometimes use the notation, B . . . a, to represent the set of attribute values paired with attribute name a in the atomic attributes that comprise B.

A class is a set of attribute bundles, which are called its members.

The attribute name set (often shortened to “the attributes”) of a class is the set of attribute names that appear in every one of its members.

The range of an attribute in a class is the set of attribute values that are paired with the attribute name in any atomic attribute of any class member. Equivalently, it is the union of the Ranges of that attribute in all the members of the class.

An attribute-defined class is a class comprising the attribute bundles that pair a specified attribute name (the defining attribute) with true.

A Fixed attribute of a class is one that has the same attribute value for all members. For example, it might be a field named x and have the value 7, or it might be a method named clear, which, when invoked, has the effect of set-ing the value of each of a member's Fields to the value 0. Fixed Fields may omit the put method (or it may be a method with no effect). Methods themselves are commonly Fixed, but in some embodiments, some or all of them may be assigned dynamically.

Class A is a subclass of a class B (written A⊆B) and B is a superclass of A (written B⊇A), if every member of A is a member of B.

As discussed in previously, the subclass and superclass relations between classes can be tools for controllably managing and exploiting lossiness in PERCos.

Inheritance signifies that each subclass includes (inherits) all the attributes of each of its superclasses (i.e., the attribute name set of a class is a subset of that of any of its subclasses). Further, the Range of each attribute name in a class is a superset of its Range in any subclass. These two properties follow directly from the definition of subclass and superclass.

Inheritance is an important property of the subclass relation. It leads to much of the conciseness and power of Object-Oriented Programming, and provides similar aspects in the description of purposes, resources (e.g., Participants, devices, applications), and some elements of PERCos embodiments by class expressions.

The subclass and superclass relations are transitive (A⊆B and B⊆C imply A⊆C), which follows directly from their definitions.

The subclass and superclass relations define dual mathematical lattices over the space of classes, a property that may be useful in pruning searches at the class level, without examining individual members. Furthermore, as discussed later, classes can provide additional information about attributes and/or members that may be useful in describing and/or embodying PERCos.

In some embodiments, a member of a class may be modified by a PERCos process and/or by invocation of a method that assigns one or more attribute values to one or more of its attribute names. Assignment may generally operate on a member (of one or more classes), rather than on any of its containing classes. The result may remain a member of the classes for which it satisfies all symbolic, Range, and/or class Restrictions. Invoking the set method of a Field is a standard form for assignment to the member.

A replacement assignment is one that deletes from the member all atomic attributes with the same attribute name as the one being assigned before adding the new atomic attribute.

An additive assignment adds a new atomic attribute into the attribute bundle without removing any atomic attributes. Additive assignment is not generally applied to members of classes specified to be single-valued.

For example, suppose that class expression 2DIntCoord has attributes named x and y.

{<x, 3>, <y, 1>} might be a member of 2DIntCoord's class. It could be modified by replacement assignment of the value 7 to y, producing the attribute bundle{<x, 3>, <y, 7>} or by additive assignment of the value 7 to y, producing {<x, 3>, <y, 1>, <y, 7>}. The former would be a member of 2DIntCoord's class if y were purely abstract in that class. The latter could not be a member if 2DIntCoord and/or its attribute y were declared to be Single-valued.

To this point, the disclosure has treated classes as ordinary mathematical sets: at any given time, in any given Context, an item is either a member of a class or it is not—there is no middle ground. There has been considerable research on Fuzzy Sets, developing mathematical models that reflect, in part, uncertain and/or imprecise human classification boundaries, such as those involved in user classes. Fuzzy sets address some, but not all, of the problems by defining the result of testing membership in a Fuzzy set as a probability p, rather than a Boolean.

Some embodiments of PERCos may use Fuzzy sets, rather than ordinary sets, as the basis of some or all classes. Relations, including the subclass relation may also be generalized, for example, so that one class is a Fuzzy subclass of another with a probability p, rather than with a Boolean value. Using appropriate operators from Fuzzy sets as appropriate, classes can be generalized to have the properties discussed above, and be Fuzzy, too.

The use of threshold class expressions may in many instances provide a sounder and more practical approach to the problems Fuzzy Sets/Logics/classes were intended to solve, although in certain circumstances the use of Fuzzy classes may improve results.

A class expression is an expression that specifies a class (set of members)—or an element of such a specification—expressed in some class Description Language, which may include interactive elements (e.g., drop-down menus, fill-in forms) that may constrain class expression structure.

In some embodiments, a class expression may have associated metadata, distinct from the metadata of the class or its members.

An interpretation provides a possibly context-dependent mapping from values (including class expressions) to values (including classes, attributes, members, and expressions).

Purpose expressions are a subset of class expressions, and purpose expression elements are operative elements of Edge class expressions.

A class expression may have one or more associated class names, which may be single tokens or other class expressions. A class name may be used in expressions to represent the class that is the interpretation of its associated class expression. The disclosure may often shorten “the interpretation of the class expression associated with the class name X” to “class X.”

The foregoing types of class expressions may be used in any appropriate combinations to form specific descriptions of classes. These forms of class expression are similar to forms that have been used in various Object-Oriented Programming languages and/or ontology description languages, and constitute the Traditional Forms of class expressions.

In some class expression languages, a subclass expression declares that a class is a subclass of one or more specified classes.

In some class expression languages, a Fixed attribute expression declares one or more attributes of a class to be Fixed, with the interpretation that the attributes may be contained in the class's attribute name set, and each attribute name may have the same specified attribute value (or set of attribute values) in each member.

In some class expression languages, an Abstract attribute expression declares one or more attributes of a class to be Abstract, with the interpretation that the attributes may be contained in the class's attribute name set. This implies that each class member may have attributes with those names, but does not restrict their attribute values.

In some class expression languages, a symbolic attribute expression may declare one or more abstract attributes of a class to be symbolic, represented by one or more given symbolic expressions that may contain the symbolic attributes, other attributes and/or contextually relevant Dimension values. The interpretation of a symbolic attribute expression is that, in any context, each class member may have attributes with those names, whose values—together with the values of the other attributes and the Dimension values—satisfy the symbolic expression. For example, a symbolic field named r might be expressed as the square root of the sum of the squares of the attribute values of the Fields named x and yin that same member. Or the method named Mean might be specified as returning the result of dividing the value returned by the method named Sum by the result returned by the method named Count, of the containing member.

Some class expression languages may restrict symbolic expressions to equations with attribute names as their left hand sides, for example:
r=sqrt(x²+y²)

Some other class expression languages may allow more general symbolic expressions, including predicates that are not equations and/or equations with more complex expressions on the left hand side, for example:
a³+b³=c³+d³

where a and d name symbolic attributes, and b and c name Fixed attributes.

In some class expression languages, a restriction expression may declare an attribute to be restricted, with the interpretation that the range of the attribute name in the class may be included in a specified range and/or in one or more specified classes, which may be context-dependent.

The operational range of a class expression in a PERCos system is the set of classes that may be its interpretation in any context that is possible during operation.

In some embodiments, class expressions, classes, and/or members are normally packaged as resources.

A single class may be the interpretation of multiple differing class expressions. In a given context, differing class expressions can have the same result (set of members) when Interpreted, even though they may, for example, group elements differently, present them in different orders, or involve differing class and attribute names.

Unlike many non-PERCos class systems, the interpretation of some PERCos class expressions may be interpreted as differing classes in differing contexts. For example, a symbolic class expression may refer to contextual values. In some embodiments, these symbolic expressions may be explicitly conditional, for example
magnitude=if Context.CoordinateSystem=Cartesian
then sqrt(x²+y²) else abs(r)

where x and y are Cartesian coordinates, and r is the radius in polar coordinates.

Class expression AD is said to be a subclass expression of class expression BD under interpretation I in context C if AD's interpretation (a class) is a subclass of BD's interpretation. Thus the subclass relation for class expressions may be dependent on interpretation and/or context. It is context-invariant under I if for every context, I's interpretation of AD is a subclass of I's interpretation of BD. For example, this may be the case if AD contains an expression declaring BD as a superclass of AD.

Every member may be associated with a unique class that contains only itself. In some embodiments, in contexts that may require a class expression, a member expression (e.g., a member name) may be automatically converted to its associated class, and then used like any other class.

A class system comprises a set of classes and a set of relations on those classes that includes at least the subclass relation.

A binary relation is a Boolean function (predicate) that is true of a pair of elements if they are “related” for some purpose. Other relations may involve more than two classes.

Subclass and superclass are not the only useful relations between classes, members, and/or attributes. For example, a relation between two classes might hold if the two classes were “semantically and/or purpose close,” regardless of whether they shared the same attribute set or had a subclass relationship. Relations may provide additional perspectives, and/or efficiencies for processing. Relations may be used, for example, in assisting a user who is exploring an area to locate relevant purpose classes and/or other classes described using a differing set of classes or class names than the user initially used.

A member introduction is an assertion that certain items are actual members of one or more classes, or that they are Actual members of a class system (and all of its classes whose constraints they satisfy). Most embodiments allow new actual members to be introduced dynamically. An item that is consistent with a class's constraints, but has not been Introduced as a member is a Potential member of that class. (Actual member is normally shortened to member, unless there is likely to be confusion with potential member.)

A class system may be specified by a set of class expressions that declare classes and their relations, together with a set of member Introductions. A class system normally also includes all unnamed classes that may be expressed by class system expressions using its declared classes and attributes.

Some class system embodiments may include a class system's Top class (written T) is the superclass of all classes in the class system. Some class system embodiments may include the Empty class, the class with no members, which is a subclass of all classes in the class system and is sometimes called its Bottom class (written ⊥).

A class system's actual member class comprises the set of all actual members of its classes. In some class system embodiments the actual member class may be the same as the class system's top class.

A class system is static if none of its classes or attributes may be changed by processes, extensible if either or both of them may be added to, and dynamic if either or both may be added to, subtracted from, and/or otherwise modified. For efficiency, some embodiments may restrict some or all of their class systems, or portions thereof, not to be dynamic and/or extensible.

A purpose class system is a class system comprising purpose classes.

In many embodiments, class systems may be resources. Some embodiments may use multiple class systems, which may or may not have classes, attributes, and/or actual members in common.

Adding a single actual member to a class system doubles the number of possible classes in the class system. (This is actual, rather than just figurative, exponential growth.) Thus, in practice, many class systems are so huge that their full set of classes may never be explicitly written, computed, or enumerated, only the much smaller number of classes that are relevant to some process set, such as matching or searching. In addition some class systems contain an infinite number of classes.

An Edge class system expression is an expression that is part of the specification of an Edge class system, expressed in some Edge class system description language, for example, by an arrangement of a token set, by an interactive user interface, and/or by the result of a resource assimilation process. Edge class system description languages normally include one or more class description languages.

Communication to and from users and other stakeholders normally uses Edge class system expressions. Within this section, class system denotes Edge class system, unless otherwise qualified.

Class system expressions may be built up iteratively and/or recursively using such forms. Many class system expressions may include multiple forms. Various PERCos embodiments may allow various combinations of these forms, possibly with others of a similar character. These forms may enable natural, compact, and/or operationally efficient expressions for many useful classes.

In some embodiments, a class system expression may have associated metadata, distinct from the metadata of the class system or its elements.

An Edge class interpretation function—in any given context—maps a set of Edge class system expressions (including member Introductions) into a class system (e.g., an internal class system). Differing interpretation functions may normally map a given set of expressions to differing class systems. In some embodiments, for efficiency purposes, smaller class systems (i.e., ones with fewer declared classes and/or Actual members) are favored over larger ones. A combination of an Edge class interpretation Function and a set of Edge class system expressions is generally called an Edge class specification.

There may be multiple Edge class specifications that define the same Edge class system, i.e., there may be multiple ways of Specifying a class system. This reflects the fact that a set of classes and their relations can usefully be described in many different ways. Such Edge class specifications are structural variants of each other. Different structural variants may result from different perspectives on “the same things” and/or differing sets of declared classes intended to represent differing sets of user classes used for mental organization and/or purpose classes. The sets of classes and/or purpose classes that they declare may differ, and their interpretations may differ, yet they may still specify the same set of classes and class relations.

In some embodiments, a PERCos system may have one or more, possibly context-dependent, base internal class systems and one or more Edge class systems that all map into one of the base internal class systems. A class system may contain some classes that are interpretations of class expressions that use only traditional forms of class expressions and/or some classes that are interpretations of class system expressions that use one or more of the additional PERCos forms, such as those discussed in this section.

The vocabulary of a class system is the set containing each token that appears in any one or more of its class system expressions and/or is allowed in any of the embodiment's class system declaration languages, including those used as class names and attribute names.

In some embodiments, some or all class systems are resources that may be published.

Specifying attributes of a class. Some embodiments may provide additional forms of expressions for specifying constraints on a class. For example, metrics may allow additional forms of class specification, such as threshold classes.

If a weight is associated with an attribute declaration, it may be used to resolve Inheritance conflicts, for example, by Coherence processes. Some embodiments may, in some circumstances, use a simple metric for the weight (e.g., either mandatory or optional) and/or a more detailed, or even continuous, metric (e.g., a number between 0.0 and 1.0). In some embodiments, the value of a weight may be determined in the context of the attribute declaration and/or be an expression to be evaluated in the context in which the conflict is being resolved. Such expressions may be conditional and/or involve computation at the time of evaluation (in the current context).

In some embodiments, the use of metrics to weight expressions and/or classes, attributes, and/or members represented by expressions, may be used in certain forms of class specification. For example, a threshold class expression specifies that all members have values that pass a specific threshold value of a specific metric, which may be context-dependent.

The value of a metric applied to an item might be determined in accordance with a formula involving classes, attributes, members, and/or other context. For example, a weight might be associated with each of a set of base class expressions; an item's weight could be the sum (or the product, or some other function) of the weights associated with the base classes of which it is a member. If the base weights were all the same, such an additive threshold class expression would be equivalent to a combinatorial class expression.

In some PERCos embodiments, a metric's value may depend on the relative importance and/or frequency or probability of occurrence of an item, and/or its tightness of coupling, importance, similarity, nearness, matching, and/or other measure, relative to one or more given members, classes, and/or contextual elements.

Metrics and/or threshold class expressions may be standardized, at least in part, by acknowledged Domain experts to support interoperation and common understandings.

Differences among classes may also be used to specify classes. The base classes whose differences are taken may be represented by differing class expressions and/or interpretations of a class expression in differing contexts.

Specifying that a class is the asymmetric difference of two or more other classes denotes that members of its interpretation are members of the interpretation of the first that are not members of any of the others.

Specifying that a class expression is the n-symmetric difference of two or more class expressions denotes that members of its interpretation are members of the interpretations of at least one of them, but not more than n of them.

It may be useful to publish class difference expressions to allow other users and/or other stakeholders to include the differences to augment and/or to add tokens, ref/senses, class structures, classes, and or attributes to their locale, or to facilitate the harmonization (through Coherence processes) of differing lexicons and/or expression structures.

In some embodiments, combinatorial class expression simplify the expression of classes that are most easily described informally using words like “or” and “and/or.”

For a given k and n, a combinatorial class expression's interpretation is a class whose members are members of the interpretations of at least k out of a set of n base class expressions. For example, a combinatorial class expression might declare that its interpretation's members are members of the interpretations of at least six out of a set of ten base class expressions. This is somewhat analogous to the way medical diagnostic manuals may define a syndrome by saying that patients have the syndrome if they exhibit at least six out of ten listed symptoms.

For example, let k=2 and n=4, and the base class expressions be {A, B, C, D}. Then the combinatorial class's interpretation is a class whose members are those that are members of the interpretations of A and B, A and C, A and D, B and C, B and D, and/or C and D. When k and/or n are large, the notational compactness of combinatorial class expressions can supply conciseness, clarity, and efficiency.

When k=1, a combinatorial class expression is called a union class expression—its interpretation is a class including of all members of the interpretations of any of the base class expressions. Some class expression languages may provide special syntax for this useful case. An example would be specifying the interpretation of Major Party members to comprise members of the interpretation of at least one out of the two base class expressions, Democratic Party, and Republican Party. Note that this is a more restrictive specification than specifying that Democratic Party and Republican Party are both subclasses of Major Party, which would allow the possibility of there being other members of Major Party.

When k=n, a combinatorial class expression's interpretation is a subclass of each of its base class expressions. However, when k<n, a combinatorial class expression does not necessarily specify a subclass of the interpretation of any of its base class expressions.

PERCos embodiments are not restricted to a fixed set of class description languages. Some embodiments might, for example, and without limitation, allow the use of various logics and/or algorithms for the specification and/or enumerations of members of some classes.

Various logical systems (e.g., description logics) may be useful as class system description languages, or portions thereof. There has been considerable recent research in this area that might be leveraged by some embodiments. The goal is to identify forms of expression that enable efficient reasoning at the class (or class expression or class system expression) level, rather than reasoning purely or primarily at the level of individual members. The difficulties that have been encountered in this area appear to may require that great care be taken in choosing the “expressive level” of the logic: Logics that are adequately expressive often turn out to be computationally inefficient, or even undecidable; logics that are efficiently decidable often turn out to be inadequate to express all that needs to be said about some kinds of commonly-occurring class systems. Nevertheless, it appears that with judicious choices, it may be possible to do useful amounts of checking of realistic logic-based class system expressions, to assist in their development and “debugging” (to improve their conformance to user purpose).

A computed class expression is interpreted as a class whose members are determined, at least in part, algorithmically. In some embodiments, computational tests and/or other algorithmic methods may be used to determine membership and/or to enumerate the members the interpretation of a computed class expression. Context, including historical user and/or user group usage information and/or reference sources, may contribute to the interpretation of a computed class expression.

In some embodiments, restrictions may be specified to ensure that the interpretations of some computed class expressions are subclasses of the interpretations of certain designated base class expressions, as an aid to optimizing searching and matching. Computed class expressions may inherit attributes from these specified superclasses.

As with logic-based class description languages, the price of allowing completely general computed class expressions would be that, in certain circumstances, it might be difficult to reason about, check for consistency, and/or otherwise utilize, Edge class systems involving expressions in such languages, because of undecidability of important properties. If care is exercised in the class of algorithms that are allowed, or sufficient specification of the algorithms may be required, computed class expressions may provide compact specifications of useful elements of class systems that are difficult and/or impractical to specify using only traditional Forms.

Subclass and superclass are very important, but they are not the only relations between classes, members, and/or attributes that may be useful in purpose calculation, navigation, and/or exploration. For example, a relation between two classes might hold if they were “semantically and/or purpose close,” regardless of whether they fully shared the same attributes and/or had a subclass relationship. Other relations, representing, for example, “relational correspondence,” “see also,” “relevant supporting knowledge,” “comparable” (which might, in some contexts, be a broader or otherwise more useful relation than “equivalent”), or “contributing to comparable” may be useful in navigation and/or matching. Such relations may provide additional (general and/or Domain-specific) hierarchical and/or non-hierarchical perspectives on, and/or efficiencies for processing, relationships among classes, attributes, and/or members.

A binary relation is a Boolean function (predicate) that is true of a pair of elements if they are “related” for some purpose. Relations may be used, for example, in assisting a user who is exploring an area to locate relevant purpose classes and/or other classes described using a different set of classes or class names than the user initially used. For example, Learn.“Do Homework” and Learn.“Solve Exercises” or Physics. Molecular and Chemistry. Physical might be specified, in some contexts, to be in the “semantically close” relation.

A binary relation may conceptually be viewed as a matrix, where the value true indicates that the row element and the column element are in the relation. For example:

An X at the intersection of a row and a column represents “true” and a blank represents “false.” An X in this matrix says that the color named on the row is “perceptually close” to the color name whose number heads the column. For example, Magenta is “perceptually close” to Red, to itself, and to Blue-Violet. This is a representation of the well-known “color wheel.”

This table, for example, indicates that a Moon is “part of” a Planetary System, a Solar System, and a Galaxy. Such a relation is often called a “partonomy” by ontologists.

A class expression may include any number of relations. Relations may generally be defined by acknowledged Domain experts and/or through the analysis of historical patterns of use. In some embodiments, there may be provisions for users and/or groups to specify private relations for their own use, and/or to publish relations for potential use by other users and/or groups. Such relations may be standardized to improve interoperability, efficiency, and/or inter-understandability, especially when traversing the Edge class to internal class boundary. For example, an organization might publish an organization chart.

Many useful relations may be “sparse” (have a tiny minority of true elements), so various well-known sparse matrix representations and/or algorithms may be efficient embodiments. Even some non-“sparse” relations may have efficient algorithmic embodiments. For example, the “color wheel” relation can be represented by the formula
|(row−column)modulo 8|≤1

PERCos systems may use differing representations for relations. Some may have as many different representations as they have relations—or even more, using mixed representations for some particular relations. Others may use only one or a few standard representations for relations.

Relations may, in some embodiments, be defined using one or more relational description languages, which may provide various operators for specifying them.

Some embodiments may support non-binary relations, involving more than a pair of elements, for example, between (A, B, C), which represents the notion that, in a certain Context, B is “between” A and C. For example, between (Red, Orange, Yellow), between (small, medium, large), or between (Palo Alto, Menlo Park, Atherton).

A paraextension of a class is a (possibly declared) superclass of the class comprising the class and one or more of its paraclasses. For example, a declared class Fishlike, comprising Fish, Whale, Dolphin, and Porpoise, might be a paraextension of Fish.

A parafringe of a class includes members of one or more of its paraclasses that are not members of the class itself. For example, a parafringe of Fish might comprise Whale, Dolphin, and Porpoise and a parafringe of Vegetable might comprise Tomato, Cucumber, or other fruit thought of as a vegetable.

The interpretation of a class expression may be augmented by declaring additional identified items as actual members. This includes the case where the class would otherwise be empty, so a new class expression may be specified by augmenting a class expression whose interpretation is empty by an enumeration of members. In some embodiments, an Augmentation may, in certain circumstances, override subclass and superclass specifications that would contradict it; in other circumstances, the Augmentation may be propagated to superclasses, in still others, the conflicting element of the subclass/superclass relation may be removed.

Augmentations may be temporary (within a given process, time span, and/or other context) or persistent. Some embodiments may restrict or allow temporary and/or persistent augmentation.

A relaxation of a class expression overrides inherited constraints on one or more attributes with weaker constraints, thereby broadening the class expression's interpretation and defining a superclass. This includes the case of no constraint at all, in which case the attribute is effectively specified to be irrelevant in a context. This is sometimes referred to as “ignoring an attribute,” or “projecting out an attribute.” Relaxation may be useful, for example, in situations where it is possible not to use all available information—it is a controlled form of intentional lossiness—for example, to make certain processes more general, more efficient, and/or more flexible. Some embodiments may use relaxation in early stages of searching and matching in order to focus on certain other attributes (e.g., Core purpose Facets) and/or attribute Ranges while ignoring, or giving lesser weight to, others.

Relaxation may eliminate or “soften” search and/or matching criteria, for example, and without limitation, to:

1. reduce complexity,

2. improve efficiency, and/or

3. introduce greater generality for navigation and/or exploration purposes.

Relaxations may be temporary (within a given process, time span, and/or other context) or persistent. Some embodiments may restrict or allow temporary and/or persistent relaxation.

In some embodiments, a widened class expression may be specified to be interpreted as a subclass of a particular class; other embodiments may not allow such a restriction. Widenings may be temporary (within a given process, time span, and/or other Context) or persistent. Some embodiments may restrict or allow temporary and/or persistent widenings.

Widening may usefully create broader classes, particularly for navigation and exploration, that include members on the basis of one or more relations. This may avoid some of the pitfalls of taxonomies that insist on placing each item at a single place in a hierarchical description and/or ontologies that fail to recognize the “closeness” of some distinct classes, e.g., “Physical Chemistry” and “Chemical Physics,” “College Athletics” and “Professional Sports,” “Manufacture” and “Make,” “Study” and “Learn,” “Provide” and “Sell.” It may also be useful, for example, in broadening searches that fail to return sufficient results, or in assisting a user in navigating and exploring an area in which that user is not expert.

Certain particular widening relations may be indicated by, or closely bound to, certain purpose expressions, and may be selectively or automatically, at least in part, employed in the context of those expressions.

Widening is similarly useful to relaxation for “softening” search and/or matching criteria, improving efficiency, and/or productively generalizing for exploration and/or discovery purposes.

A class expression may be specified to be equivalent to another under a one-to-one name mapping (which may be optional), implying that in any Context, and with any interpretation, the interpretations of the two class expressions (after the systematic mapping of the first's names) contain exactly the same members. There need not be any structural similarities between the class expressions themselves. Since they contain the same members, they may consequently have (after mapping) the same attribute names and superclasses. Such expressions may themselves refer, for example, to classes appearing in other class equivalence expressions. Equivalence is transitive, so that if A is Equivalent to B, and B is Equivalent to C, it follows that A is Equivalent to C.

A class expression may be specified to be approximately related to another under a one-to-one name mapping (which may be optional), implying that in any Context, and with any interpretation, the interpretations of the two class expressions (after the systematic mapping of the first's names) may contain similar and/or overlapping members. There need not be any structural similarities between the class expressions themselves. Such expressions may themselves refer, for example, to classes appearing in other class equivalence and/or approximation expressions.

Specifying that a set of class expressions has bounded overlap denotes that any set of n (e.g., pair for n=2) of their interpretations has at most and/or at least a specific number, percentage, particular set, and/or algorithmically determined range of members in common. An important special case is specifying that they are disjoint, which signifies that no pair of their interpretations has any members in common.

A member introduction is an assertion that certain items are actual members of the interpretations of one or more class expressions, or that they are actual members of a class system and all of its classes whose constraints they satisfy. Most embodiments allow new actual members to be introduced dynamically. Potential members are other items that would satisfy all conditions for membership in one or more of the classes specified by a set of class system expressions, but have not yet been (and perhaps never may be) Introduced. Actual members are operatively available, whereas members of the (often infinite) set of Potential members are not yet operatively available. Introductions may be specified by explicit class system expressions (perhaps as part of interactive sessions) and/or by computational processes.

In some embodiments, a class system expression may declare a member to be an instance of the interpretations of one or more base class expressions, specifying that the member is to satisfy the constraints of the interpretations of the class expressions. Such an Introduction may specify additional attributes of the instance, beyond those specified by its base class expressions and/or provide attribute values for attributes that are not fully determined by its base classes. Instance declarations may ensure specific attribute values for all single-valued attributes of all containing classes, including, for example, those that the class expressions may have specified as abstract and/or specified as limited to the interpretation of a class expressions or to a range of values. Some embodiments may also allow multi-valued attributes in members.

In some embodiments, users and/or acknowledged Domain experts (or groups of them) may explicitly introduce members. A member description language may be part of, or closely related to one or more class expressions languages. A new, perhaps temporary and/or context-dependent, member might be specified, for example, by providing a declared class name and providing a set of attribute values for the new member.

Any Introduction of a new member to a class (or class system) is conceptually equivalent to adding a new element to its defining Edge class system, for example, declaring a new instance of an Edge class. But it may affect other Edge classes, as well, since the Edge class system may contain expressions relating classes that may require some of their interpretations to include or exclude the added member. Some embodiments may restrict class system expressions in ways that allow such propagation of changes in membership to be performed efficiently. As with several other forms of class system expressions, Introductions potentially introduce contradictions or other kinds of conflicts into a set of class system expressions, which could be dealt with as discussed herein.

Processing a collection of related introductions together (batch data acquisition) may be more efficient than processing them each separately.

In some embodiments, member introductions may contain weights associated with attribute values, which may be used in resolving any conflicts with Inherited attribute values.

In some embodiments, many actual members may be introduced into a class system by analysis of data from outside the PERCos system, for example, and without limitation, accessible databases and/or websites. Data obtained from such sources might not be in the internal form employed by the embodiment, so member assimilation may involve processing items to obtain appropriate internal representations for members. These processes may directly translate to Edge classes and associated attributes and/or be augmented or otherwise determined by member-specific contextual data, and/or, for example, by purpose expression related information.

In some embodiments, the number of possible classes in a class system with N actual members is 2N. Thus, the addition of a new actual member doubles the potential size of the corresponding class system (but not normally its operational size). This is one of the reasons why embodiments generally declare, enumerate, and/or store explicit representations of only the relatively small portions of class systems that arise during processing.

Members or expressions representing members (or sets thereof) may be resources that can be published for the use of others.

In one interpretation, “red tape” refers to “a narrow flexible strip whose color is red,” and “holds up” apparatus and method embodiments “supports.” But in another interpretation, “red tape” refers to “an excessively complex official routine,” and “holds up” apparatus and method embodiments “delays.”

This could mean “it is not true that the skies are cloudy all day,” or “it is true all day that the skies are not cloudy.” A human reader may use real-world knowledge, common sense, and/or intuition to decide whether to interpret it as meaning that the skies are never cloudy, or that they may sometimes be cloudy, but not all day.

Humans can usually deal with ambiguities in natural languages, because humans are good at resolving ambiguities and associating terms with the correct meanings using context, relational thinking, “common sense,” and their knowledge of the world. Still, a human may find it challenging to create natural language statements that may always be precisely and correctly understood, in all contexts, by other humans—let alone by computers. At a subsequent time, even its creator may no longer understand or remember how to properly interpret some statement.

Computers are not nearly as good as humans at resolving ambiguities, in part because they generally do not adequately include context. Much imprecision in descriptions and interpretations of user classes is due to user processes (in perception, emotion, and thought) that are subjective, relational, impressionistic, and/or imprecise. PERCos embodiments systems are designed, in part, to bridge between imprecision of focus and intent on the human side of the Edge, and the precision that is appropriate on the computing side of the Edge, while retaining the useful lossy characteristics of user classes.

The focus of the PERCos embodiments architecture is not attempting to “understand” what is in the user's head, but responding in ways that optimize user satisfaction through experiences and/or providing other results for satisfying expressed purposes. The PERCos embodiments architecture helps ensure that expressed purposes are supported effectively by identifying and using available resources optimal for those purposes. This is in part achieved by complementary declarations of purpose-related contextual information by both users (what they want) and publishers of resources (what they provide). Somewhat similar “parallel declarations” are currently employed in certain search engine/tagging database implementations, but these implementations fail to provide apparatus and method embodiments for effectively characterizing purpose, for providing structures to meaningfully organize, express, and employ context, and for employing class Structure generalizations that reflect relevant contextual scenarios.

Representing subclass/superclass Relations

A subclass relation specifies the set of all pairs of classes such that A is a subclass of B. A subclass relation's associated lattice may be represented in a variety of ways, including:

1. Boolean matrices,

2. lists of the subclasses of each class,

3. lists of the superclasses of each class,

4. directed graphs relating subclasses and superclasses, and/or

5. an algorithm that, at least in part, computes the relationship.

One useful approach is to declare all applicable direct superclasses as part of each class expression and to add a node (for the class) and one or more Edges (one per superclass) to a directed acyclic graph (DAG) representing the subclass/superclass lattice. This seems suitable for a practical boundlessly extensible system, and may be used in some PERCos embodiments.

Some embodiments may use a compact representation for a dynamic set of class expressions (in a context) that maintains a DAG for the subclass/superclass lattices, augmented by labeling the Edges (connecting subclasses to direct superclasses) with a description of any Fixed and/or symbolic values the subclass specifies for Abstract attributes of the superclass and any attributes and range, class, relationship, symbolic restrictions, extensions, relaxations, widenings, and/or computational declarations that the class expressions adds. This makes it efficient to collect a complete class expression (which does not depend on other class expressions, but may depend on context) by traversing the DAG from the class expression's node to the top.

Each member may be used to form a singleton class, i.e., a class containing just that member. Such a class may be used like other classes, e.g., it may be subclassed or appear in other relations. In a class system expression context that may require a class, some embodiments may interpret a reference to a member as a reference to its associated singleton class. This allows class systems to be extended to an arbitrary level of detail, without restricting the use of less-detailed class expressions and/or member Introductions.

Explicitly declared superclass expressions may be thought of as “parents” and explicitly declared subclass expressions as “children” of a class expression (In some embodiments, it may have more than two “parents.”). Transitive superclass expressions may be thought of as “ancestors” and transitive subclass expressions as “descendants.”

In a single inheritance system, each class expression may have at most one explicit superclass expression. It may inherit (share) all of that superclass's attributes (including, transitively, attributes of its superclass expression's ancestors). Early Object-Oriented Programming languages and systems limited all subclassing to single inheritance (and a few modern ones still do). Single inheritance can be very useful in limited contexts. For example, it is useful for many classification schemes, including branching taxonomies (e.g., the Dewey Decimal System, the Library of Congress classification system).

Single inheritance permits certain simplifications in some embodiments, but may make it inadequate, awkward, impractical, and/or tedious to express many natural and useful class systems. Most modern Object-Oriented Programming languages and systems allow a class to be declared as a subclass of multiple superclasses—as PERCos embodiments generally do. For example, Red Car might be declared as a subclass of both Red Thing and Car, where the declaration of Car either declared the color attribute to be Abstract or omitted it entirely. Multiple inheritance is particularly useful when the structures being described have multiple independent (or nearly independent) Dimensions (e.g., color, weight, price, material, and age, or purpose verb, purpose category, purpose location, and purpose time).

Many of the examples in this document include multiple inheritance (declaring classes with multiple superclasses), without further comment. It is generally mathematically possible (with more work, and a much more complicated set of class and attribute expressions) to obtain functionally equivalent results using single inheritance, or (with still more work) without using class inheritance at all.

Other relations between classes (e.g., paraclass, synonym, approximation) may, in many useful cases, tend to relate classes from the same and/or other class systems that share and/or inherit many attributes; however, they do not generally ensure full attribute inheritance as provided by subclass.

In some embodiments, PERCos includes two additional approaches to resolving inheritance conflicts: Multi-valued class attributes and/or Coherence Services.

Multi-valued attributes may have multiple values in a member, and may be useful when there is no operational necessity to provide those attributes to be Single-valued.

In a situation requiring a single value for an attribute that has an inheritance conflict, a Coherence process can operate to harmonize the set of class expression restricting the attribute, just as it would resolve other conflicts among specifications. In some embodiments, if one of the conflicting attribute values has been declared with a greater weight than the other(s), it may be favored. For example, class Bird might be declared with the attribute flies=true, with weight 97, and class Mammal with flies=false, weight 95; Penguin might be declared as a subclass of Bird, with, inter alia, flies=false, weight 98, and Bat as a subclass of Mammal, with flies=true, weight 99. Because of their greater weights, the attribute flies in both subclasses would override the superclass declared attribute values. Note that in a class system containing these declarations, the attribute flies may be multi-valued (i.e., {true, false}) for the classes Bird and Mammal (when Penguin and Bat contain Actual members). If flies had been declared to be single-valued in Bird and Mammal, a Coherence process might override those declarations to ensure the consistency of the class system.

Attribute resolution rules may also depend on context, including information available in other relations. Some embodiments may resolve conflicts only when the attribute value may be required (“just in time Coherence”); some embodiments may detect the possibility of a future conflict and apply Coherence earlier (“forward looking Coherence”).

This disclosure uses a notation for restricted names, which we write as multiple tokens separated by periods (“.”). A.B specifies the class named B that is a subclass of A. For example, we might use Restricted names like Sport. Baseball, Learn. “Do Homework”, or Science. Physics. Theory. Gravitation. This notation is particularly convenient for hierarchies of subclasses (taxonomies); Theory and General, for example, are likely to be informative components of restricted names for many different classes. Their use in restricted names introduces no ambiguities, even if they appear in other restricted names, or as names on their own.

If an attribute name is ambiguous (is used in multiple class expressions to name conceptually distinct attributes), we may prefix it with a name of a class in which the intended attribute occurs, e.g., Base might be disambiguated as Sport.Baseball:Base or Science. Chemistry:Base. In some embodiments, the lack of such a prefix may be interpreted as introducing a distinct new ref/sense for the attribute name, possibly depending on whether the attribute name is already ambiguous in the class system.

For interoperability and/or efficiency, PERCos systems may map Edge class systems to internal class systems, which could be largely based on Internal References (IRefs) for Ref/Senses and/or on programming and/or performance optimizations. PERCos systems may impose consistency and interoperability constraints both on the mapping processes and on their results, to ensure that knowledge structures of Internal and/or Edge classes and/or members are standardized and sufficiently consistent internally to ensure standardized interoperation of internal classes. A class expression of an internal class is a specification for determining (or otherwise identifying) its members. Typically, a substantial portion of a PERCos system's knowledge structures can be represented by internal class system expressions, internal class member Introductions, and/or combinations of the foregoing.

In some embodiments, Edge class expression may not be limited to controlled vocabularies. For example, users may be allowed to declare and use new tokens for one or more class and/or attribute names and/or in some manner use controlled vocabularies in combination with such new items. However, in general, neither the computer nor other users can reason about a declared class or attribute effectively without some reliable definition or other specification of what it represents.

For example, matching between a user-declared name and a standardized name could be problematic without augmenting processes that “align” them. If a class or attribute is to be internally interpreted and used as a basis of algorithmic reasoning across PERCos system elements, its specifications need to employ shared standardized naming schemas (each name representing “the same thing” in various system elements). Such schemas might reflect either exact correspondences and/or algorithmically-determined sufficient correspondences. Consistency of specification can be crucial to meaningful interoperation in PERCos systems. That is, computing processes that use class names and/or attribute names from differing sources may depend on the assumption that both sources use them with sufficiently similar meanings, or that names are aligned before, and/or as, information from the sources is combined.

PERCos embodiments Edge classes may depend on specifications from many sources. For example, one or more root and/or operational utilities, users, affinity groups, experts, governments, taxonomies, ontologies, and/or standards organizations may contribute specifications. Without a (relatively, completely, and/or complementary) standardized vocabulary, there is no assurance that such sources may be mutually consistent and use, where appropriate, the same token (or tokens from the same Ref/Sense) for any shared item (e.g., one might use purchase and vehicle and another might use buy and car: the system needs a basis for deciding whether these are sufficiently comparable). To ensure consistency, PERCos may map Ref/Senses to Internal References that are based on standardized Vocabularies (plus any Internal References for any Unknown tokens). Consistency and standardization constraints, generally, and/or at least for a group and/or Domain, ensure that the knowledge structures of internal classes and their attributes and members are sufficiently consistent, interoperable, and efficiently processable. Consistency and standardization may be defined, at least in part, by acknowledged Domain experts.

Internal classes are normally used in computational processes for efficient purpose fulfillment. They use mostly- and/or entirely-controlled vocabularies (of IRefs) to express interoperable classes, and to ensure that matching and filtering can be efficiently performed.

While in some embodiments, some or all internal class system expressions may be in many ways similar to Edge class system expressions, they are intended to provide a standardized representation for internal classes, attributes, members, and class systems that are functionally equivalent (individually and/or in combination) to corresponding Edge classes, attributes, members and/or Edge class systems, in a vocabulary- and lexicon-independent, interoperable manner.

Declared classes use tokens (which are mapped to Ref/Senses) as names, allowing users substantial flexibility in terminology and notation; internal classes use IRefs in standardized, but in some cases extensible, vocabularies for these purposes. For interoperability, IRefs may normally be controlled, i.e., derived from shared and normative reference sources, such as core ontologies, taxonomies, and/or standards, and/or declared by acknowledged Domain experts.

Differences in what user-chosen tokens represent can largely or entirely be handled by token Internalization, which makes a choice (or choices) among available iRefs for each token in a class expression. In some embodiments, user interaction may be used to assist in resolving some cases.

A PERCos system may or may not be able to handle multiple distinct internal class systems and/or sets of IRefs. An internal class system, or a subset thereof, can represent the concepts and priorities of a particular user or group of users, and may be partially or wholly shared among user groups. Many internal classes may be normative specifications and/or recommendations from acknowledged Domain experts and/or groups of experts. Others may be extracted automatically or semi-automatically from normative reference sources (e.g., core ontologies, taxonomies, national and/or international standards).

The effective interoperation of some PERCos embodiments can depend on the degree of mutual deployment/acceptance of at least core internal class systems and IRefs. Their interoperation with the boundless may substantially depend on the mapping of declared classes to internal classes, the incorporation of Context into that mapping, and/or the controlled extensibility of the vocabulary of IRefs.

The transformation of an Edge class expression (provided, for example, by a user) into an internal class expression may be largely based on the replacement of tokens with appropriate, disambiguated IRefs. In some embodiments, processes may combine Edge class expressions with Contextual information (e.g., preferences, historical data, governance) to derive internal class expressions.

Similarly, internal class and attribute names (IRefs) may be externalized by mapping them to appropriate tokens. In some embodiments, the choice of a token from an IRef's Ref/Sense may not be arbitrary, but may be consistent throughout an Edge class or Edge class system expression and context, restricted to the user's Lexicon, and/or to the user's prior choices from that Ref/Sense (e.g., in one or more related class or class system expressions).

The Externalizations of internal class expressions may provide normative guidance to users, publishers, and/or other stakeholders for understanding and using declared classes in standardized and interoperable ways.

An internal reference (iref) is associated with a Ref/sense. An internal vocabulary is a set of irefs. Irefs are used both to name internal classes and internal attributes. Each IRef is generally uniquely associated with a single ref/sense.

In some embodiments, some may be calculated names not intended to be presented to users. For example, a machine-interpretable internal form, unique to each ref/sense and therefore to its iref, may be generated automatically (e.g., by hashing a sorted list of the tokens in its ref/sense).

In some embodiments, a human-readable token for an iref may optionally be generated, for use, for example, in situations like debugging and lexical map development. If the same human-readable token is generated for multiple irefs, each occurrence may be distinguished by automatically extending it with a distinguishing number, other character, and/or information derived from its ref/sense, its superclasses, the session, the Participant, and/or other context.

The precise syntax and semantics of the language(s) for expression of specifications, and the particular reasoner(s) for that/those language(s) that are provided by one or more reasoning services may have substantial impact on the power and efficiency of PERCos systems incorporating them. However, they may have relatively little impact on other PERCos concepts and embodiments of other PERCos subsystems. This section briefly surveys two families of logics that appear to be suited to some of the needs of PERCos systems.

Description Logic (DL) is a family of formal knowledge representation languages that provides formal (logic-based) interpretations of classes and ontologies. This class of logics generally does not make the UNA and do support the OWA. It recognizes that knowledge structures may be evolving, decentralized, and/or incomplete.

The semantics of a DL are defined by interpreting concepts as sets of individuals (classes) and roles as sets of pairs of individuals (binary relations). Those individuals are typically assumed to be from a given domain. The semantics of non-atomic concepts and roles is then defined in terms of atomic concepts and roles. This may be accomplished by using recursive definitions similar to those used in context-free grammars.

One aspect of using Description Logics is their high expressivity combined with desirable computational properties, such as decidability, soundness, and completeness of deductive procedures. They provide methods to describe concepts formally, and there are existing tools for reasoning about classes and instances, such as instance checking (is a particular item a member of a given class?), relation checking (does a relation/role hold between two items?), peer checking (which may require an extension for purpose Equivalence), subsumption (is class A subclass of class B?), and concept consistency (is there a contradiction among a set of expressions?).

Although it is generally desirable for a logic to be decidable (i.e., each statement in the logic can eventually be proved to be true or false), in practice, mere decidability may not be enough. We need to be able to answer certain logical questions in a reasonable (not merely a bounded) amount of time. The primary ways in which members of the family differ is the operators allowed in a logical and/or the complexity of expressions. Generally adding to such raises the computational cost of reasoning using the logic, sometimes radically. But in some circumstances, the increased costs may be acceptable.

There may be situations in which it is reasonable to distinguish time from other attributes and have the ability to reason about it separately, using modal operators designed to compactly and efficiently express commonly-specified temporal characteristics.

There are a variety of Temporal Description Logics (TDLs). In some embodiments, TDLs are based on interval-based Modal Temporal Logic—in the spirit of Halpern and Shoham (1991). There are others that are combinations of standard DLs such as ALC with standard Temporal Logics, such as Linear Time Temporal Logic (LTL) and Computational Tree Logic (CTL). Such combinations are based on a two-Dimensional semantics, where one Dimension is for time and the other for the DL domain. TDLs of this kind are well-suited for capturing the temporal aspects of concepts in ontologies and classes. For example,

Some example Temporal Operators are:

⁽⁺□ C) (future universal)

⁽⁻□ C) (past universal)

In some embodiments, PERCos reasoning services might retain compact representations of all, or some portion of, versions of internal classes and members that exist during the lifetime of the system in order to support the generality of reasoning with such a Temporal Logic. However, class-based reasoning can also be performed by a non-modal reasoner when modes do not appear explicitly in expressions, so modal computational overhead might only apply when the modes are used. Extra storage overhead might be involved if an embodiment allows for possible future temporal reasoning. The added reasoning power might justify the extra cost, in some circumstances.

This section presents considerations for dealing with relationships among Edge classes and varying user and publisher perceptions and organizations of “practical reality” (relevant parts of human experience), particularly as situationally relevant, given a current context. Whether or not the structure of our universe changes over time, it is clear that our perceptions of its Dimensions and defining characteristics do change, and that individuals have differing perceptions of them. For example, many ancient alchemists viewed all substances as being combinations of just four elements: Earth, Air, Fire, and Water, whereas modern chemists recognize more than 100 elements, and consider valences as among their essential characteristics. Perceptions change with culture and differing knowledge. For example, none of the original four elements is now considered an element by chemists.

There are multiple approaches that may be used by PERCos embodiments relating Edge classes (including declared classes) and internal classes to accommodate changes and differences in ideas and perceptions about purposes and resources. However, some simple conventional approaches have severe drawbacks. PERCos approaches have important aspects that remedy the drawbacks of conventional approaches. For example, the use of variant attributes seems well-suited to expressing user perceptions and expectations and can be handled in ways that do not compromise the ability of PERCos to reason about internal classes.

One cannot expect any fixed set or scheme of classes to be optimal for organizing all available knowledge for all time, all contexts, all users, and all purposes. As context changes and as knowledge evolves and propagates, as new relationships are recognized, as differing relationships are variably embraced, as relations develop differing contextual implications, and/or as older variations fall into disuse, optimal PERCos class systems can be expected to change. Some embodiments may accommodate small, supplementary, and/or localized changes over short time intervals for small groups. Other embodiments that are optimized to accommodate larger changes with wider implications may be more appropriate for longer time intervals, larger groups, and/or evolving standards.

In the space of user classes, such changes happen naturally, in an evolutionary fashion, as users are exposed to new ideas, new evidence, and/or new experiences. The differences among the user classes of a given user at various times may generally be qualitatively similar to the differences among the user classes of various users at a given time. User class differences can be impediments to thinking and to communication among users. The intent of PERCos is not to eliminate user differences, but to provide solid grounding for consistent and effective inter-user and user-machine interaction through the use of carefully-formulated declared classes that can help to shape and regularize corresponding user classes.

Declared classes are expressly designed to facilitate efficiency and flexibility of communication, reasoning, matching/similarity, and/or filtering. Each user would like to find and use declared classes and/or attributes that closely correspond to user purposes and their associated purpose classes and/or attributes, in the expectation that, if other users do the same, similar user classes and/or attributes may tend to closely correspond to the same declared classes and/or attributes. Conversely, user classes and/or attributes that closely correspond to the same declared classes and/or attributes may tend to be rather similar.

Such close correspondences would be easier in an “ideal” world where users always had the same context and thought exactly alike, and where user classes and attributes and declared classes and attributes never changed. In an evolving and dynamic world, where differences of context and changes are omnipresent, PERCos systems face a number of very important issues that have been largely ignored by conventional class systems.

The following is a hypothetical example used for illustrative purposes only. This hypothetical example is close enough to reality to be easily recognizable, but allows examination of details that illustrate aspects of issues, challenges, and approaches, without excessive concern for real-world accuracy.

Assume that a user class “Pineapple,” a declared class whose name is the token Pineapple, and an internal class whose IRef is [[Pineapple]] are initially all in close correspondence.

Now suppose that some credible journal publishes a research article whose results seem to indicate that, for certain classes of people, certain patterns of eating pineapples can cause hormonal changes that, unless promptly treated, can cause failure of a vital organ, leading to death. An editorial in the journal proposes that, because of the danger to this population, pineapples henceforth be classified as poisonous.

Further suppose that this publication generates a split in the scientific community, with a strong group (whom we may call “poisonists”) arguing that the formerly benign Pineapple (and [[Pineapple]]) should now have the attribute value poisonous=true, and another strong group (whom we may call “non-poisonists”) arguing for poisonous false, another group who thinks that both positions are worth considering (“point-counterpointists”), and most of the population (whom we may call “neutrals”) either does not know and/or does not care about the dispute at all.

For responding to expressed purposes that depend, at least in part, on the declared class Pineapple, user interactions, and/or context might determine whether the poisonist, nonpoisonist, point-counterpointist, and/or neutral internal class should be associated with Pineapple by Internalization.

Finally, for some of the discussion below, it is relevant that Pineapple has been specified (either directly or transitively) as a subclass of Food, which has been specified as a subclass of Edible, which has the single-valued attribute poisonous false.

In such an embodiment, Edge class expressions (especially declared class names and attributes, expressed using tokens for Ref/Senses) may be used for user/user and user/PERCos communication. Edge class declarations and context could change (e.g., be edited) over time, to reflect changing user, group, and/or other stakeholder views of the subject matter. Variant, as well as static, attributes may be permitted in Edge class expressions, and weights may be associated with static and variant attribute declarations, to be resolved in a manner similar to that for inheritance conflicts.

In such an embodiment, internal classes and attributes (expressed using IRefs) could be used for class-based reasoning. To ensure soundness of reasoning, the attributes of existing internal classes would not change, although new internal classes could be added. That is, only static attributes appear in internal classes. Internal classes generally may not be seen (directly) by users, since cross-edge communication is done using Edge class expressions, i.e., each internal class expression may generally be externalized before being communicated to a user.

The internalization and externalization processes may, at least in part, depend on contextual lexical mappings between ref/senses that name Edge classes and attributes and irefs that name internal classes and their attributes, including converting variant attributes. Note that, in any given context, if an internal class expression is Externalized and then re-Internalized in the same context, the result should be that same internal class expression.

Each Edge class expression may be Internalized to a corresponding internal class that has an Internal attribute corresponding to each of its static attributes (including static symbolic attributes), plus Internal subclasses with an additional corresponding Internal attribute for each possible value of each variant attribute. In this example, variant attributes may override static attributes (unless the static attributes are declared with higher weights). Static attributes that conflict may generally be overridden (with Coherence processes making any adjustments). Furthermore, if an Edge class expression is edited to change the value of a static attribute, that attribute may automatically become a variant attribute, with its possible values including at least the values before and after the edit.

In some embodiments, when an Edge class is subclassed, its direct superclass links may be determined, and cached, so the appropriate (e.g., current) value of the attributes of superclasses can be found and used when the subclass is instantiated (member Introduction) or externalized.

In some embodiments, when an Edge class member is introduced, it may be internalized, with an additional part: If the Edge class has variant attributes, values for them may be determined, analogously to the way that abstract attributes are instantiated. Some embodiments might use current values, based at least in part, on context, which might include user history- and/or crowd-related information, user location and/or other environment information, user biometric information, other stakeholder information/input, resonance values, and/or direct user instructions. Other embodiments might use other methods.

In some embodiments, when searching for subclasses or instances of an Edge class with variant attributes, the internal subclass with the current values of the variant attributes might be used. In other embodiments, the internal class directly corresponding to the Edge class (involving only its static attributes) might be used instead. In some embodiments, the user might explicitly override a current value, and/or might be offered a choice of values, using any of a variety of methods.

When an internal class is to be communicated to one or more users, it may be externalized back to an Edge class expression equivalent to (a declared class that is the same as) the Edge class expression that was mapped to it—if the context is sufficiently similar. Note that the result might not always be a (previously named) declared class, but rather an Edge class expression containing declared class names.

In some embodiments, a variant attribute whose value in a subclass is the same as the current value in an Edge class expression might be output in the same way as static attributes. However, if the values of one or more of the variant attributes differ from the current values, the Edge class expression may be annotated according to some convention to indicate the value in the subclass. For example, if the member of Pineapple had the attribute poisonous false, but the currently associated internal class for Pineapple had the attribute poisonous=true, it might be communicated as Pineapple[poisonous=false]. A similar convention may be used for the input of variant classes and instances where the associations of the current context are to be overridden.

There are a number of functionally equivalent methods of handling variant attributes. However, this embodiment deals efficiently with situations involving many small localized changes and also with those involving larger changes that have wider implications.

Variant attributes can be freely used in declared classes without concern for generating logical inconsistencies. Internal classes and instances are always attribute-consistent. No extra restrictions on declared classes may be required to preserve the soundness of class-based reasoning.

Declared classes have a stable and understandable structure: subclass and other relations change only when users, acknowledged Domain experts, and/or groups, such as utilities, explicitly, as may be allowed, edit existing Edge class expressions and/or Edge class system, and/or add new ones. Internal classes also have a stable structure: subclassing and other relations are preserved even as Edge classes vary. Changes to reflect new Edge class expressions and/or Edge class system expressions, and/or changes in existing ones, add new internal classes, rather than changing existing ones. Neither Edge class systems nor internal class systems may require propagation of changes in relations among existing classes caused by adding variant attributes and/or changing their current values.

Class-based reasoning may be, at least in part, based on internal classes, and results may be freely cached, since internal classes neither change attributes nor vanish (even though they might cease to be associated with declared classes). Embodiments using this approach insure internal attribute-consistency, and allow pre-computation and caching of reasoning results, without having to “wall off” and/or re-compute anything but the Internalization and Externalization mappings. Multiple, mutually-contradictory Edge class systems (e.g., based on different belief systems) may freely coexist and be mapped to a common internal class system without interfering with each other, simply by using differing Internalization/Externalization mappings.

Breaking a long-established cognitive association between a user class and a declared class (such as “Pineapple”→Pineapple becoming “Pineapple”→Pineapplepoison) because of a change in variant attributes may be avoided. Variant classes and attributes may exist concurrently, provided only that the Contexts using the variants each maintain operatively separate elements of the Internalization/Externalization mappings.

Since we cannot know with certainty which attributes may be changed over an embodiment's lifetime, any Edge static attribute might later become a variant attribute. But for those that do not change, the efficiency of reasoning about classes with purely static attributes may readily be preserved.

In some embodiments, for efficiency, the set of subclasses created to represent combinations of variant attributes and/or static attributes that have become for some reason obsolete, might be “weeded,” using some or all of the methods for cache management discussed herein.

Another style of embodiment uses different methods of handling variant attributes and other Context-dependencies, which may lead to a different set of computation time and storage space trade-offs.

Some embodiments may allow the declaration of certain static attributes with weights that may prevent them from being converted to variant attributes, except, for example, when the variant attribute declaration has a higher weight.

An internal class system expression is context-dependent if it directly depends on the values of one or more contextual Dimensions and/or is affected by the values of other context-dependent elements. It is context-independent otherwise. Some embodiments may pre-compute the values of some or all of the detectably context-independent internal class system expressions, and associate these values with their expressions by, for example, and without limitation, metadata of the expression and/or a separate cache of expression-to-value mappings.

Some embodiments may also cache some or all of computed and/or pre-computed values of elements of an internal class system expression in a context in, for example, and without limitation, metadata of the expression, metadata of the Context, and/or a separate cache of mappings from expression-context pairs to values.

To reduce storage requirements, some embodiments may limit the number of cached values of internal class system expressions in contexts to a bounded number, per expression, per context, and/or overall. Such bounded caches may manage eviction of values using techniques analogous to well-known techniques used in virtual memory systems, for example, Least Recently Used (LRU) and/or First In, First Out (FIFO). If an evicted value is needed again, it may be re-computed in the same way it was originally. The re-evaluation may be less costly than the original evaluation, because it may be able to use other values that are still in the cache.

Other cache eviction methods may be used in some embodiments. For example, cache entries may be associated with the set of contextual Dimensions on which they depend. The embodiment might then choose a value to evict depending on the dependent Dimensions, including, for example, choosing one with more Dimensions whose values differ from the current context before one that differs in fewer such Dimensions.

In some embodiments, caches may be “weeded” by removing values that meet certain criteria, such as not having been referenced for a specified time interval, or having a low frequency of reference over some longer time interval.

Over time, and embodiment's set of class system expressions may evolve (e.g., be edited by acknowledged Domain experts). This may lead to an unfolding series of class systems, as attributes may be added or deleted and/or attribute values may be modified; the resulting values of declared classes may change correspondingly. The former values of declared classes may be flagged as obsolete, while retaining certain associations with the class names, which may be used, for example, for historical exploration. Such flagged classes may be uniquely identified to distinguish them from values currently associated with those class names.

When a user expresses a purpose expression for which PERCos does not have sufficient information, PERCos may evaluate the purpose expression to find a set of purpose expressions that are as “near” as possible. Consider FIG. 21. Some purpose Domains share some common purposes, whereas other purpose Domains do not share any common purpose. Suppose a user specifies a purpose expression that generalizes to a purpose class in purpose Domain PD3. Further suppose that there is no descriptive CPE associated with a PD3. In such a case, PERCos may consider PD1 and PD2.

For example, as illustrated in FIG. 21, An Example Purpose Domain Relationships.

4 Introduction to Resource Management

This section of the disclosure describes an example implementation of a PERCos resource Management Systems (PRMS) embodiment in support of a PERCos environment. PRMS provides and manages resource arrangements in accordance with purpose expressions (including CPEs) so that users may experience, store, and/or publish computer sessions and session elements that provide the best fit with their expressed purpose. PRMS provides this functionality by providing PERCos resource architecture, PERCos identity Management Systems (PERID), PERCos Information Management Systems (PIMS), and resource Management Systems. It also utilizes PERCos Platform Services, such as Reservation Services, Persistence Services, and History Services.

A scalable and extensible PERCos resource architecture embodiment enables users and/or other stakeholders to create and use resources at any chosen level of granularity.

The PERCos resource architecture enables PRMS to uniformly organize and process computer memory, databases, computational processes, networks, Participants and specifications, where uniform treatment includes providing common resource and process management interfaces for individual and/or groups of resources in a seamless manner. It enables two or more resources to be arranged, aggregated, and/or combined with a unified resource interface to create a composite resource. Composite resources, in turn, can be arranged with other resources and resource interfaces to create even more capable composite resources, ad infinitum.

PERCos identity systems (PERID) provides a framework for characterizing resources in standardized and interoperable manner to enable users/Stakeholders, Participants, processes and/or other resources to efficiently discover, organize, share, and manage all types of resources regardless of their size, complexity, diversity, location, format and/or methods of their creation. It provides a framework for reasoning about resources, such as their viability in fulfilling Purpose Statements. The framework comprises constructs for characterizing and organizing resources and a suite of services for manipulating characterizations, such as identifying, discovering, managing, sharing, and persisting.

Traditionally, information management system developers have used metadata in various forms as a system to characterize pertinent information about resources. For example, a digital photo file may have characteristics, such as its owner, its creator, its copyright and contact information, its virtual location (e.g., URL), the location where the photo was taken (e.g., Global Positioning System coordinates), the camera and lens were used to create the file, description of the photo (e.g., Grand Canyon at dusk on a mid-summer day), its file type (JPEG), and other types of metadata.

PERCos Information Management Systems (PIMS) embodiments may enable users (novice or expert) and/or other Stakeholders to describe, capture, and organize information about resources, including metadata. Such an embodiment is fundamentally extensible in its ability to represent any form of resource that may be created. Organizing resource information through the use of PIMS enables resources for user purposes to be discovered and managed more efficiently than in existing forms of resource organization, management, and identification, which do not directly support user purposes. PIMS enables resource-related information to be organized in correspondence with CPE expressions and/or elements, regardless of their location. This allows users' purpose statements to be provisioned optimally without arbitrary constraints on the location or publisher of the resources used. PERID, for example, may use PIMS to capture, organize, store, retrieve its information.

Resource Management Services embodiments provide and manage arrangements of resources in accordance with CPEs and other PERCos information arrangements. They may accept an operational specification that specifies resources as well as performance and functional requirements, such as levels of performance, quality to purpose, reliability, redundancy, confidentiality, and integrity.

Resource Management Services embodiments may interact with one or more PERCos Platform Services, such as Coherence Services, Repute Services, Governance Services, Reservation Services, and History Services to negotiate one or more operating agreements that specify the levels of services its resource would provide. For example, an RMS embodiment may interact with PERCos Repute Services to evaluate Reputes of resources to ensure that they comply with the desired levels of reputation/credibility. Evaluation may include assertions regarding some or all of a resource's performance, security, reliability and/or other operating characteristics, Repute information regarding CPEs, and/or the degree to which resources contributed to purpose satisfaction.

Resource Management Services embodiments may manage and monitor the performance of its resources to ensure they comply with their respective operating agreements. In the event a resource fails to perform, a resource Management System embodiment may take appropriate course of actions, ranging from executing corrective measures to notifying appropriate processes. A resource Management System embodiment may also interact with Coherence Services to reconfigure its resources, if appropriate. For example, unavailable resources may become available that would better fulfill purpose experience.

Reservation Services, in collaboration with PIMS and/or PERCos Persistence Platform Services, may enable prospective scheduling of resources, regardless of whether they are active, inactive, disconnected, or unavailable. It also allows resource metadata to be persistently available even for resources that are not currently available for use. For example, users may have mobile devices as part of their Foundation that may be inactive or operate disconnected for periods of time.

Reservation Services may enable users to benefit from seamless reconfiguration of their Foundation resources. For example, a user may have one or more mobile devices as part-time elements of a Foundation for periods of time, they may be inactive or disconnected. A user may arrange to reconnect disconnected mobile device(s) without limited interruption of an experience, by reserving the mobile device(s) in advance. For example, if a user might use PERCos on an office desktop to obtain a contextual purpose experience, then leave the office and still continue to obtain the experience, without interruption, on a reserved mobile device.

PERCos operating resources and/or processes may use this same capability to resume their processing after pausing by persisting parts or all of their states, such as critical data sets, their contexts or any other state.

PRMS embodiments may provide mechanisms for recording resource-related information, which includes those resources with which resource has interacted and may include information such as performance, component configurations, activities, statistics, operational results, and purpose, class, and performance metrics. This resource-related information may, in whole or in part be based on the resource's recording specification.

The information in a PERCos system embodiment may be accessed, processed, and stored using resources. The PERCos concept resource includes, among other things, “information resource,” “computational resource,” “communication resource,” and computer representations of a user action. Any specifically identifiable element that is available to be used within PERCos is a resource (even if it may not yet be locally known). Common kinds of resources include content, hardware, devices, software, services, networks, and/or Participants.

Ultimately, all resources are about information and information handling: its generation, representation, storage, retrieval, processing, and presentation. PERCos flexibly supports the organization, provisioning, and purpose-related governance of a potentially boundless collection of possible resources, normally with the goal of achieving optimal responses or response candidates to purpose expressions.

Users generally need not perceive the physical devices and processes used by resources of some embodiments of PERCos systems. Instead, users may just observe that appropriate stimuli lead to appropriate responses, with (if applicable) stated degrees of trustworthiness, security, reliability, reputation, and/or other resource properties. Most of the exceptions to this rule occur at the human-computer Edge, where perceptible physical methods are used both for intentional user outputs to PERCos and for PERCos experience outputs to users.

Resources, in general, are operatively associated with at least one resource interface arrangement. Common kinds of values that can be named include data/contents, and/or specifications for such data/contents, hardware, devices, processes, software/applications, and/or networks. Resource may be PERCos interpretable.

Resources are composed of resource elements which may be explicit or implicit. Every resource may have one or more identities and one or more resource interfaces, where some resource embodiments may defer the composition of resource interface to implementations and/or operational environments.

In some PERCos embodiments, resource elements, for example, and without limitations include the following.

An identity specifies a unique resource and operational methods of obtaining its resource elements. Each resource is named by at least one identity. (In some embodiments, a resource's identities may be one of its resource elements.) In some embodiments, the apparatus or methods to get from a resource's UID to the value of one of its resource element (which could, e.g., be a direct pointer, an association list, a hash table, an entry in a database) may depend on the resource element. Wherever a resource may be required, any of its UIDs (or designators, see below) may be used as a method to reference, embed and/or interact with it.

A PERCos resource interface Implementation may comprise one or more resource elements, which in some PERCos embodiments, includes one or more methods specification sets from a minimal set of resource elements to a full complement. Depending on the embodiment and/or the operational environment, a resource interface instance may be distributed and/or some of its components may be offloaded to its resource's component suite.

In some PERCos embodiments, a method may include at least two resource elements: a method specification and at least one method implementation, and as such is the unit of interaction with a resource. For example, it can be a method (function, procedure) that may be invoked to access a resource (e.g., to get, set, modify, control and/or delegate to one or more of its elements).

In some PERCos embodiments, a method specification says what a method invocation can request a resource to do. It is expected, and in some embodiments may be tested to, be an accurate and reliable abstraction of a method implementation.

In some PERCos embodiments, a method implementation is an instantiation of method specifications that provides programs, rules, scripts, and/or other algorithmic descriptions that determine how the method is operationalized, using elements of the resource (especially its component suite). It states how the method performs operations that respond to invocations. A method implementation may invoke methods of the same and/or other accessible resources. Different method implementations may be appropriate in different circumstances, e.g., depending on the Foundation and/or the location of the resource. A method implementation may include an operational transformer, which implements a method, at least in part, in terms of operations on non-PERCos resources.

In some PERCos embodiments, a method suite identifies methods a resource interface can respond to. Its specifications are analogous to the specification of an abstract data type in an extensible programming language. It says what operations are available and what their effects are.

In some PERCos embodiments, a method suite may also include threads of control that operate even in the absence of method invocations. Method invocations may be implemented by any of the communication protocols that the kernel sessions of both the invoking and invoked resources have in common. The choice may, for example, depend on the relative locations of the resources. resources typically share a relatively small number of standardized communication protocols (e.g., branch, procedure call, RPC/RMI, SOAP). However, other protocols designed for specialized circumstances or particular resource communication styles may be provided by kernel sessions as appropriate.

In some embodiments, a cached method is a method of a resource that has been previously determined by accessing its resource interface and/or other sources, and the result saved, for example, within one or more PERCos resource arrangements. Further invocations from such an arrangement of that cached method can be undertaken without further need to look it up in the resource interface.

In some embodiments, a resource element may be a PERCos value of any type. Frequently it is another resource, represented by its identity. Components are often used by method implementations. Any component may be shared in the creation of multiple resources. A resource can be “wrapped” with a new interface by making it the only Component of a new resource.

A kernel session is analogous to an operating system “micro-kernel;” it provides communications, interface, identity and other foundational services for embodying a resource instance. These services may be used for method invocation and reception and by method implementations and threads. It may include, by reference and/or embedding one or more transformers, which implement elements of one resource interface (which may include for example, one or more communication protocols (which may not necessarily be standardized)) in terms of one or more other resource interfaces. This may be used to interface effectively with non-PERCos resources and/or resource elements that are unable to support PERCos standardized specifications.

In some embodiments, invokers of a resource's methods may normally interact according to its method specifications and are not concerned with its components or kernel session. On the other hand, some PERCos elements, such as resource managers, may be intimately tied to the details of components and kernel sessions—but may not be at all concerned with the uses the resource is being put to.

In some PERCos embodiments, what the resource does, what kernel session services (including communication) it relies on, what components it contains, and what resources it associates with usually represent distinct decisions that can be made and specified separately.

In some embodiments, a PIDMX is a component that comprises a matrix of identities of resources with which its resource has interacted and/or may interact. It may also record designators that are created for the resource. It may be used and/or updated by the kernel session and/or by method Implementations and threads.

Resource data may comprise the data and/or computational elements contained in its component suite, on which the resource's methods may operate. Resource data embodiments may contain control elements and data (e.g., program counter, stack, task control block, queues, locks and synchronization data, exception handlers) for the resource's operations, in addition to content data.

Resource characteristics specifications may be a subset of resource data used to record characteristics of the resource (e.g., file size, date written, access restrictions, CPE and/or other purpose information, resource interfaces, provenance, historical information, and/or other contextual information) that can be used to discover, filter, compare, and/or otherwise record and analyze properties of the resource and/or its operation. Resource characteristics specifications, including sub sets thereof and associated metadata, may be embodied in specialized forms that provide methods giving such operations efficient access.

A designator is a resource that is linked to another resource via a designeeUID attribute. Designators provide, in some embodiments, the ability to manipulate information about a resource, such as to evaluate its availability, suitability, and location, so as to ascertain resources suitability for purpose. In some embodiments, it is generally “lighter weight” than the underlying arbitrary resource, so it can readily be passed around in PERCos. In some embodiments, designators may include, for example, contextual purpose information, which may provide processes using such designators with information pertinent to their purposes. A designator may contain resource characteristics specifications information and associated metadata and/or other resource data associated with the designated resource, and/or resource data (possibly including resource metadata) about itself. A single resource may have multiple designators, each potentially carrying different information, for example, different purpose information and/or different history information.

A designator may be supplied wherever a resource or identity may be needed. Designator embodiments may range from light-weight structures containing just the DesigneeUID to complete copies of the designated resource combined with substantial amounts of additional information (e.g., interaction history) about the designator itself. Designators may have special embodiments that, for example, facilitate passing them from one context to another. Designators may be sent to multiple contexts and may contain different resource Data.

In many embodiments, an identity may be the “lightest” identification of a resource, a designator is of intermediate” weight,” and an explicit <method suite, component suite, kernel session>triple may be the “heaviest” form for manipulation and distribution.

In some PERCos embodiments, designators may be derived from resource PIDMX.

As shown in FIG. 22, a “generic” resource is depicted as a Construct comprising resource element(s), associated specifications, and a PERCos resource interface. It is understood by those skilled in the art that the PERCos resource interface may also be a Construct. The figure illustrates an example of a resource based on PERCos Construct Framework specifications.

For example, as illustrated in FIG. 22, Illustrative Example of a “Generic” resource.

PERCos embodiments may span all resource possibilities, and as such supports small and simple resources, often comprising a single resource element and a resource interface with appropriate associated specifications, which in some embodiments comprises, interface specifications, organization specifications and control specifications.

PERCos embodiments may also support resources which comprise many resource elements (and resources themselves) with arrays of specifications that can offer complex functionality to one or more users/Stakeholders. These are generally created using PERCos Constructs.

PERCos resources may be compliant with PERCos Constructs, in that even a simple resource may utilize PERCos standardized Construct specifications and Frameworks.

This section considers the base construction techniques, in some embodiments, for PERCos resources. In some PERCos embodiments these constructions (and in some instances deconstruction) processes reside in templates as an adjunct to efficient and effective resource manipulations for purpose.

The resource constructions outlined here are complimentary to the PERCos Construct specifications and Frameworks, providing a flexible, scalable purpose environment, for those creating, using and manipulating resources for purpose.

PERCos resources may include “information resources,” “computational resources,” “communication resources,” and computer representations of users and their actions. Common kinds of resources may include content, hardware, devices, software, services, Participants, and/or networks. PERCos flexibly supports the organization, provisioning, and purpose-related governance of a potentially boundless collection of possible resources, normally with the goal of achieving optimal responses or response candidates to purpose specifications.

Each resource may be constructed with one or more elements (components—arrangements of tangible or virtual resources), and one or more resource interfaces, which provides methods, by which other resources may interact with the resource in an “information handling ecology.” Frequently, an arrangement of resources (and/or UIDs designating resources) is used to form a component that comprises part of a higher-level resource.

A resource may also utilize components of one or more other resources (e.g., a single disk may provide multiple partitions, a single processor may run multiple services).

When a resource is invoked, via its resource interface, it may not be relevant to the invoker whether the results are obtained from memory and/or by computation—that is internal to the invoked resource. The invoker needs to know only that results are in accordance with the resource interface specifications and any appropriate operating agreements.

Resources may be standardized, through their interfaces, to provide those processes, information and data, classes, specifications and other resource arrangements to satisfy purpose operations by users/Stakeholders. PERCos provides resource Roles which provide these standardized resources, which may be used as components in, for example, PERCos Constructs (and/or other resource arrangements), which may be published. Some examples of resource Roles includes, data/Content, specifications of such data/content, CPEs, processes/services, Participants (and associated Roles, such as, Administrator, expert, and the like), hardware, devices, software/applications, communications media (such as a 1 mbit pipe) and/or any other PERCos expressions, and/or any other non PERCos logical and/or physical elements.

Opaque resources are resources whose resource interface does not provide access its resource elements and/or components directly. This may be due to one or more sets of specifications and/or because the underlying elements do not support such characteristics. Instead, its resources elements may only be accessed/utilized through the resource interface of the resource. This may be the case where, for example, the resource elements have been assimilated into PERCos, are standardized PERCos resource Roles, have one or more requirements for such a PERCos interface.

For example, suppose PERCos needs to provide a 1 GB standardized Storage resource, (SR), for some Purpose Statement. In some embodiments, there might be some available opaque resources that have a file system interface that can be used to meet this requirement. For example, a laptop running the Windows 7 architecture may meet this storage requirement by providing a file system as a resource. Making this resource opaque helps preserve the integrity of the implementation of the resource. If a caller had direct access to the internals of the laptop resource it would give PERCos the capability of corrupting the Windows 7 operating system which probably is not consistent with the laptop owners and the Windows developers policy.

This configuration may work fine in many scenarios. However, if the Purpose Statement also includes a reliability requirement then PERCos may not have any way to make the file system resource more reliable because it is an opaque resource. In this case, PERCos may need to utilize a more flexible storage solution. One approach would be a PERCos resource that represents an array of disks. This PERCos resource includes a collection of physical disks that a caller can allocate on an as needed basis. A caller needing a highly reliable storage can allocate a collection of disks and access these disk drives directly. On gaining this access, the caller can format the disk drives, configure them as a RAID array and use this to provide a large reliable file system. In this example the PERCos resource is transparent because it provides its callers with direct access to its component resource elements (the physical disk drives).

For example, as illustrated in FIG. 23, An Example resource with access through resource Interface and a single resource element.

For example, as illustrated in FIG. 24, An Example resource with multiple resource elements, including Component resource

Transparent resources are those resources whose resource interface organizational specifications provide some degree of access to the interfaces of the resource elements (in the case where such element is a resource and has its own interface) and resource components resource interfaces. For example, consider a resource whose resource interface allows (direct and/or indirect) access to its underlying resource elements. In some embodiments, the ability to compose and/or arrange a group of resources into a single resource and allow access to underlying element and/or component resources in this manner may be essential. For example, resources that allow such access enables PERCos to provide Constructs (including, for example, Foundations, Frameworks, purpose class applications, and the like) where users and/or other resources may interact with differing resource elements and/or components depending on purpose.

In some PERCos embodiments, PERCos experts may create a Construct, using PERCos Construct templates, that includes multiple other resources. Such Constructs may, depending on users purpose expressions and their unfolding purpose operations, provide (varying degrees of) access to the underlying resources comprising the Construct (in any manner expert may specify). For example, such a Construct resource may comprise one or more of the following resource types (including other Constructs), such as, purpose class applications, operating Frameworks. This enables users to select and choose, subject to the published Construct specifications and Construct resource interface specifications, which of the resources to interact with in pursuit of their purpose. Such interactions may be through the Constructs resource interface and/or through the individual resource elements and/or component interfaces.

For example, as illustrated in FIG. 25, An Example Transparent resource.

Resource characteristics specifications (Rcs) comprise specifications that describe the characteristics of the resource. For example, this may include functionality, variables, control and/or other specification sets. Resources may have sets of resource characteristics specification that may be arranged and organized in a variety of configurations, such as a single Rcs with sections for differing purposes and operating contexts, multiple resource control specifications with a single controls specification enabling selection of appropriate sets and the like.

Resource characteristics specifications may also be standardized and interoperable, as in the example of resource Roles where the resource control specifications for resource Role may include certain standardized elements for that Role.

Rcs are by their nature, specific to the resources with which they are associated, where, for example, a common resource may have an initial resource control specifications, that specific resource may have undergone/been involved in multiple purpose operations, and as such the resource control specifications may have been modified to reflect optimizations, parameterizations and/or other manipulations the resource has undergone. Not all resources Rcs may vary in this way, some may be remain constant due to design and/or context.

Resource characteristics, in some embodiments, may be expressed in the form of i-elements using, for example, an instance of PERCos PIMS that describes resource characteristics, in whole or in part. Such specification elements may be encoded using for example, such techniques as Abstract Syntax Notation One (ASN.1), OpenID or other descriptive specification metaphors.

In one example embodiment, resource performance specifications, expressed as, for example, the upper and lower limits of resource performance, may be resource characteristics specifications (which may include, at a minimum, at least one value) with an optional set of minimum and/or maximum values defined for each resource descriptive specification elements.

Further resource characteristics may, in one example be as defined resource functional specifications, which describe and specify resources functional abilities.

In some embodiments, such resource characteristics specifications may comprise resource designators, in part or in whole.

Resource characteristics specifications may include all of the resource data, and information about the resource, including purpose and other resource relationship information.

In some embodiments, PERCos resource characteristics specifications may include one or more sets of resource functional specifications that include, for example, performance criteria and associated metrics, functional capabilities, processes definition and/or any other specifications pertaining to resource operations. In some embodiments these specifications, in whole or in part, may be made available though, for example, a designator. These functional specifications may, in some embodiments, also be queried through the resource interface, inter-resource communications and/or other methods.

Resources functional specifications comprise one or more specification elements that describe functions of a resource. Resources functional specification elements describe one or more aspects of PERCos resource abilities. In some embodiments, they may be used in operating agreements as specifications for resource management, and are provided by PERCos resources as a definition of a resource's functions.

Resource functional specifications may include differing functionalities and/or service levels, for example, indicating minimum and maximum service levels for one or more functionalities. These differing resource functionalities may be associated with one or more purpose expressions, resonance specifications, Coherence specifications and/or other resource relationships. In this manner resources may be customized, within their operating capabilities for purpose operations.

In some embodiments, PERCos may be implemented as a potentially distributed operating environment providing one or more sets of platforms including services represented as PERCos resources to enable users to express, iterate, interact with and ultimately fulfill their contextual purposes.

Each of these example platform services is described below within the resources context.

PERCos Platform services inputs and/or outputs may be operated, arranged, combined, evaluated, differentiated or in any other manner algorithmically or otherwise processed so as to operate in a manner appropriate to the resources providing specifications to them.

PERCos includes a series of specification processing services that may be invoked to process specifications so as to instantiate operating resources as specified.

Each of these processing systems includes sets of PERCos methods that may be invoked in support of specification processing.

These methods may be complimented by standard computing methods, such as Typing (static and dynamic) and validation. In addition these methods may be supported by PERCos Platform Services, such as History, Evaluation, Identity, Repute or other platform services.

PERCos resource Management Systems (PRMS) comprise multiple services that together provide a scalable distributed resource Management System capable of managing PERCos and non-PERCos resources. PRMS enables any PRMS resource to interact with any other through an interoperable, extensible and flexible resource interface. PRMS resource interface includes provision for identity, specifications, metadata and methods for interaction with the underlying resource components.

A PRMS may comprise multiple layers of resource management that may be configured to support dynamic and/or static resource arrangements. PRMS functionality may include allocation, reservation, substitution, arrangement, discovery, communications, configuration, persistence, publishing, testing, evaluation, and/or monitoring.

In some embodiments there may be specific service supporting this functionality which may include, for example, the following.

PERCos Evaluation Services may provide the apparatus and methods to evaluate one or more inputs, including specifications. These values may be used, for example, to determine conflicts, ambiguities and/or constraints between and within such inputs, in accordance with control specifications, though invocation of appropriate methods as determined by the control specifications.

PERCos Evaluation Services may operate in any configuration and/or arrangement with other PERCos resources and/or may be a component within PERCos resources and/or interact with other PERCos resources as may be required.

PERCos Arbitration Services resolve specification conflicts, ambiguities and/or constraints with inputs to the Arbitration Services. Arbitration Services resolution capabilities are defined by control specifications and may be a component within PERCos resources and/or interact with other PERCos resources as may be required.

Arbitration Services may operate on any PERCos information, including for example, specifications. Arbitration Services may comprise, for example, part of an operating session, and/or may be instructed by other PERCos process, such as Coherence management and/or resource management.

Arbitration Service instances may operate in any configuration and/or arrangement.

PERCos Monitoring and Exception Handling Services provide methods of monitoring resource operations and provide associated exception handling capabilities. Monitoring and Exception Handling Services receive output from appropriate interfaces of resource, and may consequently generate appropriate messages in response to that monitoring activity, in line with control specifications of the monitoring.

Such messages may be events, alerts, informational and/or other specifications that may be passed to Exception handling where appropriate responses are undertaken. Exception handling may utilize other PERCos resources, such as Evaluation Services and/or Arbitration services in pursuit of appropriate responses and may further interact with Coherence Services, resource Management Services and/or other PERCos Platform Services.

Exception Handling Services may be subject to control specifications, interact with resource Management and/or Coherence Services, whilst they undertake corrective, preventive or other actions that may be required to resolve situations raised by Exception Handling.

Test and Result Services (TRS) provides a service instance that may test incoming specifications so as to provide results that may validate assertions made within the incoming specifications. In many instances assertions as to a resource and/or an aspect of a resource is made by the resource provider, publisher and/or a third party attesting to one or more aspects of that resource and/or its features, functions, performance, provenance, trustworthiness, security and/or other attributes.

Persistence Services enable an invoker on behalf of a party, such as a Participant, operating session, Process, or resource, to retain the states of a resource in a manner so that the party can use them at a later date.

PERCos Persistence services may provide one or more levels of service, through, for example, negotiating an operating agreement between invoker and persistence resource provider, enabling users to select the appropriate terms of that service, including the terms of such storage, including for example, the degree of reliability, robustness, accessibility, security, temporal aspects and/or other terms of service that may be offered.

Persistence of a resource differs from publishing in that the persisted resource may not be intended and/or sufficient for use by other parties and/or may contain, for example, additional information not relevant to the use of the resource by other party.

A PERCos Information System service may comprise multiple information management capabilities, including access, storage, modification, summarization, indexing such that information associated with and/or controlled by PERCos resources may be maintained in a flexible manner independent of any specific schema.

An embodiment of PERCos Information Systems may comprise PERCos Information Management Systems (PIMS) and may include multiple information types (i-elements, i-Sets, Spaces) which may be arranged in any manner and/or may become PERCos resources. PIMS may include services for providing persistence to any PERCos resources.

In some embodiments these service may include support for PERCos classes, ontologies and/or other information organization devices and/or methods.

PERCos identity services provide a multi-Dimensional set of identity capabilities enabling PERCos resources to effectively and efficiently identify each other and confirm that identity to a sufficient degree for the task at hand.

A PERCos identity service may include identity matrix for all PERCos resources, which includes asserted and/or validated identity characteristics as well as relationships with other resources.

PERCos identity may be abstracted from other resource characteristics and consequently handled independently of the resources themselves. PERCos identity services provide methods for any specific resource to have one or more identities associated with their operations, and if relevant such relationships to be persisted.

PERCos History Services may provide services for capture, retention, access and/or manipulation of operations of PERCos resources. History Services may include maintenance of logs, audit trails, events and/or other operating process information capture and retention services.

History Services may capture resource operations including status, performance and/or any other operational characteristics in an appropriate storage devices or methods, including, for example, PIMS, which may then be interacted with by one or more appropriately entitled other resources.

PERCos Publishing Services may provide an apparatus and methods for PERCos entities to publish contextual and/or operational information so as to be available in other contexts and/or to other resources. This contextual and/or operational information may include, for example, specifications, classes and/or other resources. PERCos publishing enables PERCos information such as purpose, Repute and/or other metadata to be associated with the published resource. PERCos publishing may interact with other PERCos services, such as information management systems, utilities, storage and/or organization systems to make published resources available to appropriate distribution methods.

PERCos Governance Services may provide mechanisms and invocation methods for security, authentication, authorization, integrity and/or other policies. These policies may include authorization, authentication, privacy, capabilities, rights management, rule management and/or other policies that may be required for PERCos Governance.

PERCos Governance Services include the provision and maintenance of the internal PERCos security mechanisms and invocation of externally defined mechanisms.

PERCos Repute Service may enable users of diverse locations and background to ascertain reputation/credibility of resources and/or other elements. It enables evaluation of reputation of resources and/or other elements for a user's contextual purpose. It provides services to standardize Reputes to facilitate their interoperability. It provides metrics for evaluating the quality of Reputes. It provides an apparatus and methods to create, discover, modify, capture, evaluate and/or other operations for manipulating Reputes including theories and algorithms for inferring Reputes.

PERCos Exploration and Navigation Services enable users to explore a PERCos cosmos efficiently and effectively. In some embodiments this may be represented as purpose exploration dynamic fabric (PEDF). These services enable context-based exploration and/or navigations during unfolding purpose operations, such as discovering, identifying, drilling down, expanding and pruning.

These services may include faceting engines, reasoners, Dimension systems and purpose navigation interfaces (PNI).

PERCos Resource Management Systems may support purpose cycle operations, involving classes, specifications and operating resources. Purpose cycles involve Edge processing, purpose formulation and specification integration leading to operating sessions to support user experience. PRMS may support all of these operations, as they involve resources (including Participants, classes, specifications, software, information, Services and/or Physical devices for example). PRMS operations may be invoked from the generation of operational specifications, which in one embodiment is the output of specification integration, through for example, an SRO process.

A PERCos system provides templates and specification Constructs, such as CPEs, Frameworks, Foundations, resource arrangements, purpose classes that users, Participants, and/or other Stakeholders can use to build and/or manipulate to fulfill CPEs for obtaining arbitrarily rich contextual purpose experiences/results. In particular, users, Participants, and/or other Stakeholders can build CPEs that may require PRMS to efficiently and effectively discover and manage vast amounts of resources from multiple Stakeholders across diverse multiple networks. To facilitate this, PRMS is designed to be both hierarchical and distributed in its operation to enable each PRMS instance to manage its resources efficiently and effectively.

Resource relationships comprise those invocations, dependencies, information transfer, collaborative and/or co-operative processing and/or any other interactions between two or more resources. These relationships may be expressed in terms of the identities of the resources and/or another metadata associated with the resources including metrics, weightings, performance information, operational data and the like. These relationships may be used to establish the potential for operations with resources in one or more purpose operations, through for example, the use by one Participant of resource set (x) in pursuit of purpose (P), by another Participant in pursuit of same or similar purpose. In some embodiments, resource relationship information may be stored and managed in class structures, and may be used in the composition of Constructs to form Foundations, Frameworks, resource assemblies and/or other resource arrangements.

Within PERCos, resource relationships may be enumerated through identity, information storage schemas, operational grouping, organizational structures, specifications and/or PERCos processes such as Coherence Services. These relationships may include metrics and/or performance information, for example, expressing how well two or more resources interact within specific purpose operations and/or how well one or more resources satisfy purpose (for example, using quality to purpose metrics). Resource relationships may be expressed with any weightings, metrics, parameters and/or other specifications, including in the negative and with exclusion (such as “Never use R(x) and R(y) in the same operating session simultaneously) as well as the accretive and combinational and/or in any combination. Such relationship may be in the form of one or more ontology.

In some PERCos embodiments there may be one or more purpose operations to determine relationships between resources (and/or sets thereof). These relationships may be transient and/or persistent. For example, this may include user purpose expressions, (including CPEs), PERCos embodiments standardized expressions and/or arrangements thereof including classes, such as for example, PERCos standardized terms, such as Verbs and/or Categories, purpose metadata and/or any other information.

PERCos Identity Matrix (PIDMX), for example, provides one method of enumerating such relationships between resources and the operational purposes for which they were deployed. For example, PIDMX may be utilized as a repository for resource relationships and their associated metrics to create a dynamic mesh of interconnected purpose expressions, which may then be used, for example, on a result set, often with the objective to effectively reduce and constrain such result set to those resources most likely to satisfy users purpose expression. In some PERCos embodiments there may be multiple apparatus and method embodiments for expressing and/or enumerating resource relationships, including for example, Graphs.

PERCos PIMS, provides another example, in that those resources whose designators (i-elements) are bracketed together within an i-Set have that relationship between them expressed, and in some cases formalized.

Constructs, including Frameworks, Foundations and/or resource assemblies may also establish the relationships between resources in their specifications, in some cases explicitly and in others by type or characteristics.

Classes may be used to express resource relationships, where certain resources for example, may be of class X, and have further relationships with class Y,W,Z. These in some embodiments may comprise resource classes and/or purpose classes.

PERCos resources may also include dependency specifications where resources may have specific required dependencies and associated relationships. These may be expressed, for example, through policies and rules associated with resources and/or though other PERCos Platform Services.

PERCos provides resources to facilitate and manage these relationships in pursuit of purpose.

In some PERCos embodiments there may be one or more purpose operations to determine relationships between resources (and/or sets thereof). These relationships may be transient and/or persistent. For example, the user purpose expression “Learn Thin Film Solar” may for example, be evaluated such that “Learn”, which in some embodiments, is a PERCos verb in, for example, PERCos vocabulary(ies), PERCos class(es) and potentially PERCos class application(s), and in these examples, may have one or more relationships with the other resources (including other defined terms in, for example, vocabularies, classes, class applications, Frameworks and/or other resources). Such relationship may be in recorded in one or more ontologies.

Relationships may be based on well-known knowledge structures, such as synonyms/antonyms (for example, explore/discover/investigate/understand and teach respectively).

Resource relationship expressions may be implicit (for example, as members of the same tree in an ontology and/or as a synonym) or explicit (for example, Learn may have some degree of equivalence with discover, absorb, assimilate, check, understand or other word—which may be provided, for example, by another PERCos resource, for example, a PERCos synonym service. In some embodiments, this may be that the words are equal and may be substituted, in others, there may be some expression of degree of equivalence, such as approximates/is 80% equal to/may be substituted for/may be substituted for in circumstances “A” and/or with conditions/events “B” or the like.

In some embodiments these relationship expressions between resources (including arrangements thereof) may be enumerated as values, and, for example, may include their source resource (e.g. http://thesaurus.com/).

Resource relationships may be bi directional for example, if R2 is a Repute on R1, then R1 has the relationship for R2 of “is a Repute”, whereas R2 has a relationship with R1 of “is Subject” (of Repute).

In some embodiments, these relationship expressions may be named, for example, R-factors.

For example, as illustrated in FIG. 26, Illustrative Example of resource Relationship Embodiments.

Such resource relationships may be used in one or more calculations for purpose.

In some PERCos embodiments, an R-factor may be expressed in the form where:
−1<=R-factor=>1,

In this embodiment, R-factor=1 might mean that both Res1 and Res2 are equivalent for the CPE in the diagram above. In the same example if R-factor for Res1=0, then Res2 is not equivalent for the purpose expressed in CPE. If R-factor for Res1→Res 2=−1, then these resources can be considered opposite for the purpose expressed in CPE.

The R-factor may be expressed for any set of elements within and/or external to PERCos system.

For example, as illustrated in FIG. 27, Illustrative Example of Relationships between resources and PERCos Dimension Values.

FIG. 9 is an illustrative example of relationships between resources and PERCos Dimensions.

These R factors may be enumerated using a one or more techniques and may incorporate existing PERCos and/or non PERCos resources, such as through non PERCos resources such as Wordnet for synonyms and/or DMoz for categories, Wikipedia and the like. These R-factors may be persistently associated with one or more resources (including purpose expressions). In some embodiments, techniques may include declarative (such as by experts declaring relationship, for example, that “thin film solar” is highly correlated to, for example, solar energy), algorithmic, calculated (for example, using one or metrics, such as frequency of use, purpose satisfaction, linguistic, grammatic and the like) and/or any other techniques. In some embodiments, these relationships may be further expressed, for example, as, classes, sets, directed graphs and/or topological spaces to form a web of resource relationships that for example, may comprise context for users purpose expressions and associated purpose operations.

PERCos may, in some embodiments provide one or more apparatus or methods for users to add further detail to their purpose expressions. For example, user purpose expressions may comprise two terms, one of which is a recognized PERCos term and one which is not recognized by PERCos. Based on the first recognized PERCos term and the other term which is treated as a keyword, PERCos may then propose further terms, such as manufacturing, chemistry, economics, composition or other terms which may comprise part of an ontology (for example, expressed as a class system) which are designed to further clarify and refine the users purpose expressions. By refining the purpose, the PERCos embodiment restricts the set of resources (available and potential) that are presented in, for example, the return set, and as such are constrained to those resources having a high probability of relevance and utility to the user. In some embodiments, one or more class systems, which may include associated ontologies, may be derived, in whole or in part from evaluating user purpose expression and processing these evaluations with one or more resources, for example, as input to operating resources, so as to generate return sets, that may in turn be limited and/or varied with one or more algorithmic expressions.

Further refinement of user purpose expression and any associated results sets may be achieved, in some embodiments, through utilization of other PERCos resources, such as, Role, Repute, preferences, and/or any other apparatus and/or methods. In some embodiments, Coherence Services may operate across, in whole or in part any of the processes and/or purpose operations and resources associated therewith, to refine and/or optimize user interactions, purpose formulation, resource associations, results sets and/or representations.

Within these various processes and/or operations as, for example, users undertake their unfolding purpose operations and associated experiences, there may be an implicit categorization of result sets, which may be expressed in the form of resource metrics, where relationships of resources, both within their current arrangements (for example, as members of a set) and/or to other resources (including one or more arrangements thereof) may be expressed.

In some example embodiments, a CPE may include, “thin film solar” as the Category, which when processed by appropriate PERCos systems may be included in a results sets, for example, one that includes Wikipedia as one of the resources, that Result element comprising: (from Wikipedia):

“A thin-film solar cell (TFSC), also called a thin-film photovoltaic cell (TFPV), is a solar cell that is made by depositing one or more thin layers (thin film) of photovoltaic material on a substrate. The thickness range of such a layer is wide and varies from a few nanometers to tens of micrometers.”

This result set (and the members of the set) element may then have an R-factor associated with the CPE containing “thin film solar”. As this was a single “click” result (i.e. at the top level) and the source is Wikipedia, values can be associated with this to provide R with a value for the specification R [TFS]=(n)→http://en.wikipedia.org/wiki/Thin-film_solar

If the same CPE is, for example, sent to DMoz, then the Outcome may be:

which may be further parsed by one or more processes to provide users with results sets that comprise the following PERCos categories “Business”, Science”, “Computers”, “Regional Europe.” As the PERCos verb “Learn” was utilized, and there may likely be a taxonomy of terms associated with Learn, such as Business, Science, Computers, Location, and the like, the Result set can be further parsed and prioritized (using one or more sets of metrics) to deliver a set of selections for the user, with which they may then refine their purpose expression to more accurately reflect their user class.

In some embodiments, a PERCos environment may undertake R-process metrics on both results sets and/or users selections from those sets so that each set may have one or more purpose expressions associated with set (and members thereof) and/or R-factors between the set members.

For example, as this process continues, and results sets become further refined, including by user interactions and/or algorithmic operations, so the value of R-factor may increase to reflect the increasing strength of the purpose expressions and results sets relationships.

In some PERCos embodiments, user purpose satisfaction metrics may be included in such calculations such that R-factor values may be purpose, resource, context and/or user specific as well as, for example, standardized, interoperable and/or associated with one or more information structures and patterns and/or knowledge representations.

In some PERCos embodiments, such relationships may utilize other PERCos Platform Resource Services, such as, (PIDMX) or similar. In some embodiments, ID matrix may be utilized as repository for R-factor metrics to create a dynamic mesh of interconnected purpose expressions, which may then be used on any return set, to effectively reduce and constrain such return set to those resources most likely to satisfy users purpose expression.

In some embodiments, topological spaces may comprise a set of resources and their relationships between them, such that each resource has an associated attribute set comprising the R-factor (R-Process metric) derived from the relationship that resource has with other resources and/or classes. This may include existing relationships, such as existing directories (Dmoz and the like), where resources may be part of the same ontology and/or inferred relationships, where resource 1 (R1) and resource 2 (R2) are part of a result set (and as such they have, currently the relationship of being members of the same set) and if, for example, user then selects both resources for further operations, R-factor between R1 and R2 may become enumerated to reflect ongoing and more established relationship, such as through metrics reflecting the increasing strength of that relationship.

As user and/or other purpose operations unfold, this metric may vary (for example, increase) to reflect the further, and potentially closer (for example, as nearness) relationship between the resources. This metric may also decay (decrease), in one example over time, where at (say) Time (0) the R factor (R₁-R₂) is x, and at Time (5) the R factor (R₁-R₂) is x/10. For example, this could represent that at Time (0) Thin Film Solar (R1) and Patents (R2) were of great interest to the user, but at Time (5) (where, for example, Time is measured in years and “5” represents 5 years), this relationship has not been used by the user since Time(0), and as such an algorithmic “decay” variable is applied to R-factor such that the relationship is “weakened” to (say) one tenth of that at Time (0). This may be described as information decay and used in calculating relative nearness of resources to a given input statement.

In some PERCos embodiments there may be multiple methods of expressing and/or enumerating resource relationships. These may include graphs, classifications and schemas.

In some embodiments, graphs may be utilized to provide information structures and patterns, for example, as representations of resource relationships and/or resource metrics (for example, R-factors) In some embodiments, this may include organizations and/or structures for enumerating resources and/or information associated with resources (for example, as vertex) and processes associated with resource utilization and/or operations upon and/or by resource (for example, as edge).

In some embodiments such graphs may be used for capture, retention and/or utilization of purpose operations that are associated with users, purpose, resources, Roles and/or information and/or events. For example, a graph may comprise those resources and associated processes that satisfy a specific CPE (including purpose class), such that graph comprises one or more sets or resources and associated control specifications in an arrangement. In some embodiments, this may include multiple sets of resources arranged so as to provide alternatives for users, depending on control specifications and/or user interactions. For example, this may include ordering of resources may be in the form of Galois sets or other suitable ordering methods. Graphs may also apply, to informational strictures and patterns in whole or in part, including, for example, ontologies (including, for example, those containing verbs and/or categories) classes, class applications, Frameworks, Foundations and the like.

In some embodiments, graphs, directed, acyclic, undirected and the like may be utilized to provide structure and/or state management to arrangements of resources.

Directed graphs may be suitable for enumerating (encoding) certain knowledge structures. Thus for example, from a graph one could enumerate all those subgraphs including of edges emanating from a single vertex. These enumerated subgraphs might represent knowledge about the vertex at the center of the subgraph. Other possibilities involving graph operations also exist such as the subgraphs of all edges intersecting a particular edge and/or subgraphs generated by other algorithmic and/or other operations on the graph.

Another example instance of directed graphs may comprise Vertices as resources and edges as Repute expressions. Acyclic graphs may, for example, provide the methods so as to not have circular references in graph operations, which may be particularly useful in the case of Repute expressions. One example embodiment of such a graph might be used to link a resource and a Repute about that resource with the user/Stakeholder making a claim about the resource. Analysis of such a graph might be able to reveal cliques of users/Stakeholders who mutually admire one another but don't otherwise produce useful Reputes.

In some PERCos embodiments, there may be one or more PERCos defined schemas for resource Relationships. A schema embodiment is outlined below:

Operational specifications comprise those resolved and provisioned specifications that are sufficiently complete for the resources specified to become operating resources.

PRMS instances receive operational specifications from specification integration processes, such as PERCos SRO process (operating session manager) that represent prescriptions for fulfilling a user's formulated purpose. An operational specification has sufficient information so that the specified resources can be instantiated and/or accessed to provide the appropriate service levels, expressed in some embodiments as operating agreements. Specifications of resources can range from explicitly identified resources (e.g., Sony Laptop VGN-Z520 serial number xyz) to fungible resources (e.g., 19 gigabytes of storage space).

Operational specifications may provide a range of specifications including for example, specifications requesting resources explicitly identified by the user/Stakeholder through to a set of attributes that a resource may have.

Resources may include the user's current resource arrangements (e.g., the user's Foundations, including, for example, their personal computing devices), resources from the current operating session, and resources that may be discovered by PERCos as relevant the user's contextual purpose. Further specifications may include associated levels of service may specify a range of requirements, such as, for example, functionality, performance, quality of service, administration, security, privacy, and/or reliability.

In some embodiments, PRMS negotiates with an operating session manager instance an operating agreement that defines the levels of services that the operating session(s) and its constituent resources agrees to provide. It may interact with a PIMS instance to obtain metadata of specified resources, such as resource interfaces, functional capabilities, performance attributes, administrative requirements, control information. As defined by the resources operational specifications, to assess its ability to monitor and comply with the requested levels of service. If a specified resource is a Construct or composite resource (i.e., an arrangement of resources), PRMS may obtain information about underlying resources that constitute the resource arrangement. For example, in FIG. 2, PRMS may obtain information about the constituent components of Sony VGN-Z520, such as its NVIDIA driver. PRMS also creates an operating session for the operational specification and provisions the operating session with the specified resources.

PRMS may use a wide range of methods to discover, acquire, integrate, manipulate, provision and manage resources specified by operational specifications.

For example, one method is to acquire and provision resources specified by an operational specification in a recursive manner. In this embodiment, a top level PRMS instance receives an operational specification and decides whether or not it should acquire and provision all the specified resources by itself or should delegate some of the tasks to lower level PRMS instances. PRMS may use factors such as the location of specified resources, costs (including computational and/or financial), levels of services may be required for each specified resource (including, for example, dependencies and other resource relationships), available Foundations and/or other Constructs, and/or the size of the resource sets and the like. For example, PRMS may need to acquire specified resources from multiple organizations across multiple networks. In such a case, PRMS may decide to delegate the acquisition tasks to lower level PRMS instances, where each lower level PRMS instance would be tasked with acquiring a smaller set of resources. However, PRMS may determine that it would be more efficient for PRMS to acquire all the specified resources. Each lower level PRMS, if delegated, goes through the same decision process as PRMS.

In some embodiments, a PRMS instance decomposes an operational specification into a set of “smaller” operational specifications and assigns smaller operational specifications to lower level PRMS instances. For example, and without limitation, this could be done using a specification template that decomposes an operational specification into a collection of smaller operational specifications. A lower level PRMS instance, receiving an operational specification, also has a choice of acquiring and provisioning resources in a recursive manner or decomposing operational specifications into a set of even “smaller” operational specifications and assigning some to even lower level PRMS instances.

For an illustration of a hierarchical PRMS embodiment, consider a purpose of planning custom online courses for users. Planners of such custom online courses provide the subjects of their courses and relevant sophistication levels for each course. They may also provide one or more Reputes for each course, including, for example, Reputes of instructors, reviews of the former students, etc. They may also specify the Foundation resources, such as, a computer (desktop, laptop, etc.), Adobe flash player, a camera, microphone, or other Foundation resources.

In this embodiment, PRMS instance (prms) may, in turn, delegate the management OS₁ and OS₂ to PRMS instances, prms₁ and prms₂ respectively, where prms₁ is delegated to manage the resources on the user's computer system and prms₂ is delegated to manage the resources on the organization's server.

SRO-O processing may provision the decomposed operational specification (i.e., OS₁ and OS₂) by provisioning OS₁ and OS₂ individually. In particular, it may find a template that can provision OS₁, such as, configure the user's computer system, which in some cases may require installing software on the user's computer system, configuring the installed software to connect to the organization's server machine, and then launching the user's operating session.

SRO-O processing may similarly find a template that can provision OS₂.

Resources may be arranged into organizations with appropriate interfaces, associated resource management specifications and appropriate PRMS management processes. Resource assemblies comprise specifications of those compositions, and in some embodiments can be instanced as resource assembly instances. Generally resource assemblies are constituent components of larger resource arrangements, such as PERCos Constructs.

Resource assemblies may be specified, for example, by experts and/or publishers and may also be extracted from operating resources arrangements that are optimized for one or more purpose operations.

These arrangements may be derived from operating resources, and/or may form part of other PERCos resource arrangements such as Foundations and other Constructs. In some example implementations, Constructs and/or Foundations may be composites of resource assemblies. In other examples, resource assemblies may be dynamically created through evaluation of satisfaction of performance (for example, purpose Satisfaction, optimization of operating functions and the like) of resource arrangements. In some embodiments, such optimized resource arrangements may comprise and/or be combined to form resonance specifications.

A further example of resource arrangements is shown below, where each Framework and Foundation is composed of resource assemblies.

For example, as illustrated in FIG. 28, Illustrative Example of Operating Session Comprising Frameworks and Foundations.

PRMS may interact with a range of PERCos Platform services, such as Coherence services to cohere, replace, arrange and/or rearrange the sets of specified resources into a cohesive, frictionless (and potentially using resonance specifications) optimal and effective resource arrangement. Arranging resources into a resource arrangement includes creating a common interface for the resource arrangement as a whole.

Regardless of which methods are used, a PRMS is responsible for ensuring that the resource arrangement of specified resources complies with the negotiated operating agreement(s).

There may be conditions where some of the specified resources may not be available and/or accessible. In such a case, a PRMS may interact with PERCos Coherence Services to find replacement resources. It may also interact with PERCos Coherence Services to resolve any conflicts, inconsistencies and/or incompleteness. For example, the Participants associated with the operational specifications may not be authorized to access some specified resources.

In some embodiments, if a lower level PRMS instance is assigned with a “smaller” operational specification, (such as a sub-section of operational specifications that PRMS has segmented) then it can use the same methods as another higher level PRMS to provision its operational specifications and is responsible for providing the same functionality as a PRMS. If a lower level PRMS instance is delegated with the management of a smaller group of resources, then it is responsible for arranging the delegated resources into a resource arrangement. It is also responsible for negotiating with its superior PRMS instance a sub-operating agreement that defines the levels of services the delegated resource arrangement, as a whole, would provide. It is also responsible monitoring the resource arrangement of delegated resources to ensure that it complies with its sub-operating agreement(s).

PERCos Coherence Services provide enablement for combination, resolution, harmonization and/or optimization of multiple sets of instructions, including classes, specifications and/or resources. The Coherence Services may be invoked whenever and wherever inconsistency, incompleteness and/or ambiguity is detected. One use of Coherence Services may be to assist in the transformation of one or more user/Stakeholder purpose expressions (for example, Common Purpose Expressions) through, for example, reconciliation and integration of resonance specifications, into an optimal set of operating specifications leading to an optimal experience for purpose.

Coherence Services processes can involve specifications, resources and/or processes that resolve conflicts, ambiguities, constraints, combinations, prioritizations and/or incompleteness within specifications, resource management, resource and/or information organization and/or operations, as applicable during PERCos operations. Coherence Services may provide alternatives, constraints, extensions, manipulations, operational variations and/or substitutions for operational efficiencies, expansions, contractions, interpretations, optimizations, simulations, facilitations and/or other operational process enhancements, including reduction of friction in purpose. Coherence Services may reduce friction by harmonizing and/or resolving a set of specifications, thereby leading to superior experiences/results that integrate the interests of all direct and indirect Participants in response to specified and/or derived purposes. Coherence Services may detect and/or attempt to rectify a wide range of limitations, imperfections, and/or exceptions, including, for example, inaccuracy, lack of clarity, ambiguity, incompleteness, inconsistency, inefficiency, suboptimal selections, and/or requests for unavailable resources. Coherence Services may also overlay and/or otherwise integrate resonance purpose optimization algorithms onto user purpose expressions and/or resource purpose expressions and/or other purpose operations input to tune purpose operations to optimal purpose experiences.

For example, as illustrated in FIG. 29, An Example PRMS instance Hierarchy.

FIG. 29 illustrates a PRMS instance hierarchy in which a top level PRMS, PRMS instance₁, divides the set of resources specified by the operational specification, RF₁, into three resource groups, RF₁₁, RF₁₂, and RF₁₃, and creates three second level PRMS instances, instance₁₁, instance₁₂, and instance₁₃, and delegates the management of RF₁₁, RF₁₂, and RF₁₃, respectively to them. instance₁₂, in turn, divides its resource assembly instance into three resource assembly instances, RF₁₂₁, RF₁₂₂, and RF₁₂₃ and creates three third level PRMS instances, instance₁₂₁, instance₁₂₂, and instance₁₂₃, and delegates to them the management of RF₁₂₁, RF₁₂₂, and RF₁₂₃, respectively. Similarly, instance₁₃, divides its resource assembly instance, RF₁₃, into two resource assembly instances, RF₁₃₁ and RF₁₃₂ and creates two third level PRMS instances, instance₁₃₁ and instance₁₃₂, and delegates to them the management of RF₁₃₁ and RF₁₃₂, respectively. Each of these instances then creates a common interface for their respective resource assembly instances. Moreover, they create i-element that represents these interfaces, where the information about the resource assembly instance includes the i-set that represents to information of the underlying resources that constitute each resource assembly instance. For example, the i-element that corresponds to RF₁₁ may represent an i-set that has the information about the arrangement comprising of resources, Res₁₁₁, Res₁₁₂, Res₁₁₃, Res₁₁₄, Res₁₁₅.

Finally, PRMS instance1 is responsible for managing communication connection between RF11, RF12, and RF13. Similarly, instance12 is responsible for managing communication connection between RF121, RF122, and RF123; instance13, is responsible for managing communication connection between RF131, RF132

Resource assemblies may be constructed in top down and/or bottom up approaches, including any combination thereof.

In the event of a resource fails to comply with its service operating agreement, the resource's PRMS instance may determine the cause of the failure and take appropriate actions to rectify the failure, where such actions may be to replace the failing resource with another resource and/or notify its superior level PRMS instance.

If the failing resource's PRMS instance and its superior level PRMS instance cannot replace the failing resource with a resource that has (sufficient) functional and performance characteristics, then the superior level PRMS may need to rearrange the lower level PRMS's resource arrangement (set or group), in whole or in part, and create a new common interface for the newly arranged group. If the superior level PRMS determines that it cannot find a replacement resource, then it also may notify its superior level PRMS. This process may continue until all levels of PRMS are harmonized.

In various embodiments, a top level PRMS may reconfigure resources of its top level resource assembly instances. One reason is in response to receiving a failure notification from its lower level PRMS instances. Another reason is that its own monitoring service observed that the top level resource assembly instance is failing to comply with its operating agreement. For example, the top level resource assembly instance in the above example might fail to comply with its operating agreement because of a communication failure between RF₁₁, RF₁₂, and RF 13.

A further reason may be because the user may have changed his/her purpose expression/statement. In this example case, the PERCos processes, including SRO and Coherence, may be invoked to assess the scope of the change. In some cases, the operating session management instance may instruct the top level PRMS to pause its operations and create and/or invoke a new operating specification. A PRMS, in turn, creates a new top level PRMS to manage the new operating specifications. In the example where the users variations to their purpose expression is minor (for example, adding further Reputes as filters), operating session management instance may instruct the current top level PRMS instance to reconfigure the resources of the existing resource assembly instance. The top level PRMS may interact with one or more Coherence (and/or other PERCos Platform) services to effect the reconfigurations.

In the event that the top level PRMS instance also makes modifications, it may need to interact with a coherence service and operating session management to correct the situation. The corrective actions may result in modifying the operating specification.

In some circumstances PRMS instance may communicate through a Coherence service to identify suitable resources so as to restore compliance with operating agreements. Where specifications provided to resource management are insufficient to allow resource Management to resolve resource conditions, Coherence management services may be invoked to identify and undertake potential solution methods.

For example, as illustrated in FIG. 30, Illustrative Example of Simplified resource Management Embodiment.

6 PERCos Identity Systems

Identity in the boundless world is multi-faceted, temporally, contextually and relationally.

PERCos embodiments identity is a multi-Dimensional identity system that enables users to interact with the boundless. Each resource has sufficient identity to enable users, who also have identities to manipulate these resources in pursuit of their purpose Satisfaction.

To support one-to-boundless computing, a PERCos identity systems (PERID) provides an apparatus and methods to enable resources, including users/Stakeholders, resources, and/or other processes to efficiently discover, organize, share, and manage all types of resources and information sets associated with them, regardless of their size, complexity, diversity, location, format and/or methods of their creation. PERCos identity systems incorporate one or more identifiers enabling PERCos resources to be identified by one or more sets of such identifiers.

Traditionally, information management system developers have used metadata in various forms as a method of characterize pertinent information about resources. For example, a digital photo file may have characteristics, such as its owner, its creator, its copyright and contact information, its location (e.g., URL), the camera and lens were used to create the file, description of the photo (e.g., Grand Canyon at dusk on a mid-summer day), its file type (JPEG). These characteristics are often grouped, and metadata elements are created to represent each group. For example, one may create a metadata element to provide the film's creator, owner and its copyright and contact information. One may also create another metadata element that describes its interface, such as how to access the film. Yet a third metadata element may contain the reviews of the film.

PERID, in some embodiments, supports the provisions, through PERCos Governance services, the methods and mechanisms for expressing authentication, for example, as a graduated scale ranging from weak to strong. PERCos environments provide quantized forms of such authentication, which may include verification, veracity and/or other identity metrics. For example, PERCos identity systems may include one or more criteria for authentication, derived from indicia that may be considered, as identity expressions, as very weak (e.g. pete@dodgy.com.xy) a website in another country with DNS records that are not transparent) to those considered very strong (e.g. Government issued identity (such as a passport), one or more biometric indicia (fingerprints, Iris scans) and/or PERCos reality integrity analysis and the like.)

PERCos identity systems include for example, multiple Dimensions, such as identity strength, veracity, testing and validation, reality Integrity and/or other identity metrics, from which for example, other metrics such as authentication can be calculated and/or derived.

In some embodiments, such metrics may be quantized so as to enable efficiency, interoperability and/or other operational aspects.

PERCos may also include one or more standardized identity schemas, where PERCos Platform systems provide such for PERCos standardized resources, Constructs, specifications, processes, methods and/or other PERCos elements.

A PERCos identity element is a unique descriptive identifier/characterizer and may comprise identity data which has some degree of persistence, such as, for example, email address, physical address, government issued ID, credential affinity group membership, biometric information, brand, DOI, URI, URL, reputational and/or expertise information, purpose association, serial number, and/or MAC address.

PERCos identity elements may have multiple degrees of strength and/or other quality metrics, in that the degree to which an issuer expresses, for example, validation, authorization, currency (in terms of time, e.g. valid now, valid today, valid this month), or other terms supporting the identity.

In some embodiments, the degrees of the strength of identity elements are categorized as: none, methods, verified. They are called PIDE, PIDE with associated methods (PIDEM) and verified PIDEM respectively.

A PIDE is an identity element that does not have any associated identity specification methods.

A PIDEM is an identity element that has associated identification specification methods, such as, specifications of the issuer of the identity element and the methods associated with validation of that identity element. In one embodiment this might include the URL/URI of an identification validation service, such as an LDAP Directory or other service that may validate the ID. Other embodiments may include one or more Utility services that operate to provide one or more levels of testing, validation, underwriting, insurance and/or other methods to establish the voracity and trustworthiness of one or more identities.

A Verified PIDEM, also known as a factor, is an identity element whose assertions have been positively validated and/or verified to the degree specified in the associated identification specification methods and specifications thereof. The degree of completeness of these tests and evaluations, however, may not provide any further assurance as to the validity of the identity element, only the validity of the methods and/or specifications. For example, verification of the email address Bill.Salesman@IBM.com, only confirms that the email address is valid, not that the Participant purporting to be Bill Salesman at IBM is that Participant.

PERCos may use a variety of services to evaluate the strength of identities. In some cases, it may use one or more Test Result Service (TRS) or other testing services, for verification and/or validation of methods and/or method specifications and/or results. In one embodiment this may comprise evaluating results that are part of associated identity methods specifications, and/or invoking the specified methods to ascertain that the assertions made in the specifications are valid and/or verifiable. For example, an asserted email address XYZ@yahoo.com may be verified by sending a test email, or an asserted URL may be tested by undertaking a DNS look up, trace route, ping or other common test. TRS may undertake one or more tests in any combination.

In other cases, PERID may use processes, such as reality analysis, Reputes and/or further identity element verification and/or validation to be able to ascertain the validity of an asserted identity element. A factor may, in one embodiment, incorporate one or more weightings, values or other metadata as to the degree to which such a factor may be considered as valid and/or verified. These weightings and/or values may then be used by other processes that interact with that factor. A PIDEM may become a factor when all the methods and specifications thereof have been passed to a TRS and a complete Outcome returned.

A factor may be further validated through an issuing party providing Reputes and/or referring party providing Reputes on Reputes. In some PERCos embodiments, an untested PIDEM is considered less reliable/valuable than a factor. However, even among factors, there are degrees of strength. For example, those with high quality Reputes, such as Creds, such as those issued by recognized institutions (e.g. Banks, Universities etc.), Governments or other institutions recognized for their transparent and quality processes may be considered as higher quality, with the degree of reliability being a function of quality and veracity of associated Reputes and Reputes on Reputes.

TRS operations and/or other evaluations and/or tests that are unresolved, incomplete and/or provide indeterminate Outcomes and/or evaluation/test Outcomes that cannot be met are considered as incomplete and as such a PIDEM with which they are associated may not be considered as a factor. Those Outcomes that are incomplete, indeterminate and/or have other variations may be subject to PERCos monitoring and exception handling, where appropriate responses are undertaken.

PERCos identity elements associated with PERCos-external resource may also have methods, and/or specifications thereof, associated with them, such that for example, a storage apparatus may have methods of validating the asserted identity element, for example, an LDAP entry for a cloud resource. In some embodiments, these methods may be accessible through PERCos resource interface.

In some embodiments, all methods and/or specifications for methods associated with PERCos identity elements, may be considered to be assertions unless and/or until verified and/or validated by PERCos TRS and/or other similar processes.

A designator or a PERCos identity is said to be Simple if any of its identity elements does not have an identity specification method. It is said to be asserted if all of its identity elements are PIDEMs or factors. Finally, it is said to be verified if all of its identity elements are factors.

PERCos identity may be persistent and/or transient in one or more operating sessions, including those associated with one or more process(es). The persistence of PERCos identity may be managed, for example, through the resource itself, and/or its delegate(s) such as resource manager instance(s), through one or more PERCos Platform Persistence Services, and/or through, PIMS (including, for example, Reservation Service) and/or other PERCos processes. The degree and extent of the persistence may be an attribute of the resource interface and/or its delegate(s).

In some embodiments, PERCos identity is generally relative, in that a PERCos identity may be issued by a resource that is authorized and/or enabled to issue such identifications, such as a context identity manager, and as such, any PERCos identity is at a minimum, relative to that issuer. In particular, PERCos identity may be local to a context, and as such expressed as, for example, a tuple containing an identity element comprising operatingsession_ID and resource_ID, where resource_ID is an identifier assigned by operating session management. In some embodiments, such local operatingsession_ID may then be made available to other sessions/contexts and as such, may be assigned differing and/or additional identification characteristics by that session and further, such identifier may be registered with one or more utilities and/or registration services, such as DNS, to provide an ID that is consistent for all sessions.

Unlike many other identification systems, such as Digital Object identifier (DOI), Domain Name System (DNS), Uniform resource Locator (URL) and the like, PERCos identity is dynamic to support the dynamic nature of PERCos resources, including their inter-relationships, strength and/or provenance of PERCos identity including session and contextual identification and/or other operational dynamics and/or PERCos identity considerations.

PERID enables entities to have multiple PERCos identities (for example, usually contextual and/or session) issued to them by differing issuing resources, such that in differing contexts, a resource may provide an identity suitable for that interaction within that context, whilst maintaining other identities for other Contexts. In some example embodiments, an entity capable of supporting interactions in multiple contexts, such as a “cloud” service, may provide each context with an appropriate identity local to that context, or in another implementation may provide a set of identities, or a single identity, depending on the operations and interactions of the resources.

PERCos identity may also be associated with PERCos-external resources, through a suitable identity management service, such as PERCos Platform Identity Management Service instance (in some embodiments named as Operating Session Identity Management Services (OSIMS).

In some embodiments, PERCos and identified PERCos-external resources can have their identifications associated with suitable PERCos identity templates, which may then be processed, by for example, OSIMS to produce PERCos identity element(s). However, in some embodiments such an association may generally be undertaken through PERCos resource interface, such that the PERCos-external resource may be transparently accessed by PERCos resources, often utilizing an appropriate transformer.

PERCos identity may be associated with many types of resources. In some embodiments, for example, a user may interact with one or more PERCos resources to create a PERCos Participant, attributes and/or actor identifications. The terms on which these identities may be created and/or issued may be dependent on rules and/or policies associated with the issuing and/or creating resource. For example, this may include one or more Reality analysis, biometric or other sensor operations and associated validations.

In some embodiments, there may be one or more processes for the registration of user identity entities, such as, for example, Participants. In common with other PERCos resource registration processes (and the one or more utility services that may support such operations), Participant registration may include one or more information sets.

In some embodiments, for example, such characterizing information describes Participants for general purposes, and/or specifically associated with given Domains category and/or CPE and/or purpose class sets and/or the like, and may include, for example, specific characteristics such as age, profession, degree, location, employer, employment history, credit history, criminal history, marital status, family status, avocations/hobbies, religious and other material affiliations including, for example, their perceived levels of interest/association/attachment to any of the foregoing, for example, as expressed as any of a 1-5 level (and/or related to any other declared scalar, including those for PERCos standardized and interoperable evaluation of such information). Any Creds on the Participant as a subject could be linked, including aggregated, as to respective (e.g. theirs, a groups, others) such resource set as well as with any, or any specifically purpose related (CPE, purpose class, and/or the like related) Creds published by the Participant.

A Participant self-registration is where an individual can provide one or more sets (for example, such sets may be categorized, organized and/or purpose associated) of general data associated with themselves such as for example, age and related birth date, race, religious affiliation, profession, income, net worth, investment types, location of residence(s), place of birth, nationality, nationality of birth, education level, military service, hobbies, income avocation(s), language(s), weight, height, health (sickly, moderate, healthy), activity level (low, medium, high), strength (low, medium, high) appearance (photo(s)), personality type(s) e.g. temperament (patient, easy going, intense, critical, happy, sad, angry, obedient, obnoxious, aggressive, team oriented, individualist, competitive, hardworking, playful, interested, studios, nerdy, outgoing, reticent, religious, neat, clean and the like with any set of the foregoing, all information that may, for example, and as appropriate, be subject to assertions by others in Creds, and/or where practical, established or positioned as EFs.

In some embodiments, for example, users may select a privacy (anonymity) level, which, for example, may be based on one or more standardized and interoperable sets, that can be associated with individual types or all types, and/or where such self-published information may be revealed before or after a PSNS group has been agreed to, for example, as a requirement for participation/membership in a given group, that is a Participant has become a member of a group, for example, by proactive electronic communication assertion.

A Participant is a PERCos resource representing a user or registered group of users within a PERCos system, generally on a long-term basis that may outlive many sessions.

A Participant identity may include of all the identity characteristics and information that a PERCos system maintains about a user, including interactions with the PERCos system. This may include one or more usernames, associated passwords and/or other authenticating information (e.g., biometrics), authorizations and/or other policy controls, preferences and/or limitations, allocated and/or otherwise available resources, active and/or suspended sessions, and/or historical information.

A Role is a subset of a resource, where specific rules and/or obligations (which, for example, may be constraints and/or limitations on resource characteristics) are associated with one or more resources. For example, a Role associated with a Participant, may include expressions of expertise in a given domain, including, for example, Master Dimensions and Facets, such Sophistication (for example, Novice/Amateur/Professional/expert and the like) This may include for example, hierarchical (or other organizational arrangements), such as VP, SVP, EVP, President etc. A Role identity comprises a subset of Participant identity with additional attributes that may include one or more rule sets determining the usage of Participant characterizing information.

In some embodiments, PERCos systems may provide standardized schemas for Roles, including those for standardized resources, organizational schemas (e.g. administrator etc.), those associated with Constructs, those associated with Reputes (e.g. Repute Master Dimensions and Facets, for example, quality to purpose and the like), those associated with users expressions of their expertise in one or more purpose Domain. (Novice, Professional, and the like.)

For example, Roles may also be any named subset of a Participant, such as “raconteur”, “foodie”, “train enthusiast” or other type of Role. In some embodiments Roles may have additional attributes that comprise one or more constraints on the Participant identity.

An actor is an instantiation of an operating Participant or operating Role, and/or subset thereof, that may be used in operating sessions. For example, actors may be used for restricted roles (e.g., anonymity or pseudonymity, administration) that may exist as an embodiment of Participant and/or Roles in one or more operating sessions. Actors may or may not persist beyond a single session. An actor identity comprises the subset of Participant information that is relevant to the role of the actor.

All of which may be subject to one or more rule sets and/or processing.

Operational identities are those identities that are active in operating sessions. For example, these may comprise identity elements such as contextually appropriate identity information for sets for individuals, groups, objects, resources, services and/or any other PERCos elements arranged and/or processed within any algorithmic framework.

In some embodiments, PERCos platform identity systems instantiation in, for example, an operating session may assign identities to those resources and elements within the sessions. These identities may be transient or persistent and may be associated with further identities that elements and resources have associated with them.

These may include meta actor (multiple actors) and actor ID's.

Identities may be molded and/or adapted to one or more set of circumstances. Shared attributes may be used in differing operating sessions and/or contexts, with availability and accessibility managed through, for example, governance services and/or Coherence services.

For example, a user may in some purpose pursuits present a set of identity characteristics that respond dynamically to the unfolding circumstances of their purpose.

Operating session identities are those identities, occurring within operating sessions, that are, in some embodiments, transient and operating only within the operating session.

PERID provides resources with PIDMX to organize and maintain their identity elements. A PIDMX may be assembled by PERCos Platform Identity Services, such as, Operating Session Identity Management Service (OSIMS) through specifications and/or templates, which in one embodiment, may utilize PERCos SRO Process and may be subject to governance services, Coherence services and/or other PERCos processes.

PIDMX, that have been published as resources, may incorporate ID element filtering capabilities, such as providing access to certain elements only upon presentation of appropriate nuances, and/or making certain elements only available to specific other identities upon validation of identity and/or presence, through reality analysis and/or presentation of one or more Reputes. In some embodiments where PIDMX are resources, such interactions may be undertaken by resource interface.

In some embodiments, PIDMX templates may be a type of PERCos Construct templates.

In one embodiment a PERCos ID Matrix template may be given a unique number when instantiated by a process. For example, this unique number may be generated through the use of a random number generator and/or number sequence, where, for example, a 64 bit or greater (256 bit/2048 bit) number is generated from a random number seed or comprises part of a defined namespace. This may be part of the unique identifier for the identity matrix that has been instantiated from the PIDMX template.

In one embodiment, the process generating the PIDMX from the template, for example, an Operating Session Manager Identity Service, would request a random number generator seed and/or defined numerical namespace from, for example, PERCos utility or similar service, and such seed and or namespace may provide a range of numbers that are based on that seed and/or the applicable range or scope of the random number generator. As a consequence each PIDMX may have a unique identity through the combination of the number generated and the identity of the generator (which may itself have undergone the same process), and as such in some embodiments where boundless numbers of resources are being handled, such numbers may be 2048 bit or higher, providing a vast namespace and unique identities for each PIDMX instance.

In many further embodiments, these PIDMX identifiers may be used in combination with the identities that the PIDMX comprises to further ascertain identity characteristics.

Progressive interactions and evaluations utilizing purpose, PIDMX, and/or Reputes individually and/or in combination may be undertaken, directly or indirectly. These may be brokered through independent third party services, based on mixed and in part overlapping thresholds, governance, triggers and/or other calculated attributes and/or events and may include any mix of Participant, group, class and resource identities and/or weightings and/or other algorithmic Outcome modifiers. For example, depending on the quality of PIDMX, an alternate (extended) identity matrix for another party may be revealed, such that once a user has ascertained the ID matrix of another party is of sufficient quality/reliability or other calculated evaluation, they may choose to unfold/reveal further of their own and/or another PIDMX (and in one embodiment associated persona, or part thereof).

In some embodiments, there may be two modes, one on iterative discovery and/or availability (learn more, through discovery, through research, through accretion, through delivery (time and/or event based) . . . ) and/or unfolding resulting from one or more PERCos processes where progressive ID information and/or questions are revealed.

In some embodiments, one aspect of PIDMX unfolding may be the relationship between authentication and confidentiality. For example, in the case where a user may only disclose data to parties that he trusts, the user may want assurances that the data he sends cannot be intercepted. Fortunately, in some embodiments, a high quality PIDMX for a Participant may include enough information that a user can send data that can only be read by the Participant described by the PIDMX. In some embodiments, such an example may involve the use of a digital certificate in a PIDMX which would enable the user encrypt messages in a way that can only be understood by the Participant described by the PIDMX.

A designator for a resource is a set of specification elements, which enables other resources to interact with the resource (including for example, evaluation, access, invocation or other forms of interaction). A resource may have many designators, each designator comprising a different of the resource's specification and/or identity elements. For example, a resource may have multiple designators, ranging from a designator that provides bare minimum information about the resource to designators that provide much more complete information.

This range of designators enable potential invokers of the resource to reason about the resource using a designator that has richer set of information, such as the resource's purposes, performances, but then choose to store a minimal designator in the invoker's i-Space (local directory).

For example, as illustrated in FIG. 31, An Example of the Designator Usage.

Since identity element are i-elements (i.e., identity element class is a subclass of i-element class), composite resources can use an i-Set to represent the designators for their Component resources. For example, consider the following example composite resource that has n Component resources. The resource maintains in its local store (i-Space) the designators for each of these component resources. But rather than keeping them separately, it uses PIMS organizational construct, i-Set (iS) to create a single unit. This ability to organize the designators as a single unit is notable. First, it facilitates the sharing its component resource information with other PERCos services, such as, the resource's resource management assembly, Coherence manager, persistence manager. In addition, when the resource needs to update its Component resource (say PR 3) for whatever reason, it is simply a matter of replacing D2 with the designator of the replacement component resource in iS. Moreover, the replacement resource may be a composite resource, in which case, D3 may be replaced with an i-SET, iS2. In which case, iS is updated to be {D1, iS2, Dn} from {D1, D2, . . . , Dn}.

For example, as illustrated in FIG. 32, Illustrative Example of Accessing resources using Designators.

In some embodiments, PERCos Platform Services includes PERCos Identity Services manager (PERID_SM) which provides identity and identity management services to one or more resources, for example, in an operating session.

These managers provide an apparatus and/or methods for the issuing of identities of one or more resources as, well services related to PIDMX and other PERCos identity and identity information.

PERID_SM may be instanced to provide identity and identity services to one or more operating sessions, for example, as an Operating Session Identity Management Service which issues identity elements.

In some embodiments, Operating Session Identity Management Service enables PIDMX to be evaluated through use of specified/templates and/or patterns, wherein individual identity element data and associated weightings may be evaluated.

In some embodiments, individual and aggregate PIDMX Outcomes may considered through relationships, arrangements, organizations and/or structures that they form rather than as determinative individual elements. These arrangements/organizations/structures may then form the basis for triggers, calculations, policies and/or other interactions including being used to query and search large scale PIDMX data stores in an optimized manner.

PERID embodiments provide a suite of tools for evaluating and/or analyzing resources for such properties as their performance efficiency, security, integrity, reliability, resource usage. The suite of tools utilizes both PERCos Platform Services as well as well-known industry standards to perform their analysis. For example, for security analysis, it may use National Vulnerability Database (NVD), which is the U.S. government repository of standards based vulnerability management data represented using the Security Content Automation protocol (SCAP). This data enables automation of vulnerability management, security measurement, and compliance. NVD includes databases of security checklists, security related software flaws, misconfigurations, product names, and impact metrics.

As described herein, every resource maintains a multi-Dimensional matrix (PIDMX) that characterizes different attributes of a resource. The suite of evaluation tools may use the PIDMX of the resource to perform the analysis. For example, users can use a security analysis tool to determine the effectiveness of an on-line service (i.e., a resource) in maintaining their privacy. The security analysis tool would examine the service's PIDMX to determine if the service maintains a record of its security features and performances. If so, it can evaluate and analyze the record using well-known security analysis standards, such as NVD, to provide its results to the users.

Additionally, these tools support PERCos identity to evaluate and/or determine the strength of identity elements.

In some embodiments each PERCos resource may have one or more identities, which may be federated into one or more groups and or/formed into and/or comprise in part or in whole PERCos Identity Matrix (PIDMX).

For example, in one embodiment, a PERCos resource can be assigned a unique ID, from an appropriate identity issuing services, such as an operating session manager with such capability. This may then be registered with one or more other resources, such as resource registries so as to be made available to processes and/or resources interacting with those registries on a persistent basis. In some embodiments, there may be a hierarchy of such registries (such as DNS), where the ID is unique on a system wide basis.

Other embodiments may use the Universally Unique identifier (UUID) mechanism which, with a high degree of certainty, are guaranteed to be unique even at sustained high allocation rates of up to 10 million UUID's per second. An aspect of UUID's is that they are now in widespread usage and they can be generated without depending on any central authority. An embodiment using UUID's as an identifier may be able to obtain identifiers when assimilating many non-PERCos resources through the resources native interface. For example, disk drives and Linux file systems have native interfaces that provide a UUID. UUID's have been adopted by many organizations including Microsoft, are used on several computing platforms including Microsoft Windows, Apple OS X, Linux, Gnome and KDE and are available in a multitude of programming languages.

In some embodiments PERCos resources can be assigned one or more additional ID's, by appropriate issuing services, which, for example, may be operating session identity managers, and as such resource may use such PERCos identity capabilities, such as PIDMX to retain these identities and the associated relationships.

In some embodiments, these identities issued to resources may instantiate a specific relationship between user and resources, such as establishing a specific identity of a resource for a specific user (through, for example, their Participant resource). These relationships may then be complimented by specifications (including rules) expressing the ability of the issuer of that identity to pass control specifications to resource so as to, for example, effect control of operating resource.

For example, depending upon the context within which the resource is operating, one or more ID's can be shared using, for example, a federated ID schema. Federation of a resource's ID permits further aggregation of the abstracted ID, authentication, and authorization methods across one or more contexts. Federation of ID's also enables resources to be known within a context by a first ID, and be known by another context that is operating co-jointly with the first context using a second ID.

PERCos resources may publish PERCos specification elements that may be assembled as part of an identity matrix (for example, PIDMX) that may be used to identify these resources in aggregate and/or individually. In some embodiments, these PIDMX may be utilized as part of resource arrangements.

7 PERCos Information Management System

PERCos Information Management System (PIMS) provides an apparatus and methods for every aspect of managing any type of information (e.g. documents, multimedia, on-line, bio-metrics) that are relevant in fulfilling purposes. PIMS provides constructs for creating and organizing such information. In some embodiments, PIMS provides constructs for, for example, identifying, containing, organizing, matching, analyzing, and/or other ways of managing units of information for their potential retrieval, sharing and/or reuse at a later time. In some embodiments, PIMS may also utilize PERCos Platform Services to provide a suite of services, such as, for example, storing and/or retrieving, publishing, distributing, discovering and/or other information manipulation operations.

Included in these aspects are the following.

Each PERCos session may involve an arbitrary large number of resources from a diverse range of sources combined to assist users/Stakeholders in pursuit of their purposes. This includes an information storage and management approach that is dynamic, flexible, adaptive and that is able to scale, support multiple information organization schemas (potentially simultaneously) and provide “lossy” methods of information retrieval.

Each PERCos session may provide performance sufficient to meet the needs of users/Stakeholders and their expressed purpose(s), and as such PERCos Information Management may be capable of supporting differing performance characteristics.

Users/Stakeholders may have a set of resources that they utilize on a regular basis, such as, a resource assembly, Construct (including, for example, one or more Foundations, purpose class applications, Frameworks and the like. and further sets they may have created/arranged which are used for their specific purpose operations. For example, in some embodiments, there may be resource arrangements that are representations of the history of that user/Stakeholder and their resource sets expressed as relationships with other resources.

In particular, PIMS provides management and persistence of resources through their resource interfaces specified by their respective negotiated operating agreements. Although any identifiable unit of information may be made into a resource, for reasons of efficiency, it may not be.

In a one-to-boundless world, the lifetime of any data, by its very nature, is limited, in that writing information to a storage medium in no way assures the writer that the information may be available to them in the future as there is currently no guarantee that digital storage media may provide sufficient permanence of storage/persistence.

In some PERCos embodiments, PIMS may be implemented as set of components that may be arranged in support of users/Stakeholder purpose operations. These are described below.

An i-element is a primitive construct for characterizing and/or containing a unit of information that may be identified within PERCos for its potential retrieval, sharing, and/or reuse at a later time. i-elements may be PERCos elements and/or other information which users, PERCos systems and processes and/or other resources determine are of sufficient interest to be specifically identified.

PERCos PIMS may use i-elements to represent a wide range of information, for example, including raw (i.e., unparsed) strings of characters, formatted data, metadata, purpose expressions, resource information, (e.g., resource locations, resource arrangements, resource specifications and the like), results sets, process states and/or contexts, contents of PERCos resources and/or non-PERCos resources.

(For example, suppose PERCos receives a message from a non-PERCos process that may require further processing. PERCos may store the message in an i-element and then forward the i-element to appropriate processes.)

In some embodiments, i-elements may be used to characterize information about or generated by one or more resource interfaces bound to their specific resource arrangements. This information may include metadata about the resource and/or metadata about information processed by resource. It may also comprise specific content and/or reference to content, information, processes, resources, processes, services and/or any other resource (including elements thereof) that may be associated with and/or bound to a PERCos resource interface. For example, information may include a resource's relationship with other resources, such as the resource's dependencies as well as those resources that depend on resource. Information may also include a resource's identity information, operating agreements, control, Organization and/or interface specifications and/or any associated methods.

In some embodiments, i-elements may comprise of one or more resources resource interface(s) through either reference or embedding, depending on implementation methods and operational considerations. For example, i-elements may comprise any and all information comprising resource interface and resource, including algorithmically derived information, such as indices, summaries and/or metadata and other information made available by resource interface through publishing and/or query.

For example, as illustrated in FIG. 33, An Example of Interaction between PRMS elements.

I-elements may be created and/or generated from, for example, one or more existing traditional information sources, and/or users inputs, interactions, selections, processes and data and/or information sources such as, for example, databases, data feeds, files, data repositories and/or by undertaking a process, such as a search, which may, for example, be an i-element itself, returning a result, such as, results of the search, which may be one or a set of, i-elements.

Examples of i-element generation may include, querying a communications device, through such technologies as Bonjour to extract that devices published characteristics, which may then be treated as an i-element as may the transformation of those characteristics into a format suitable for publishing in an applicable resource directory.

Further examples may include information, data, tables, schemas or other data selections from databases and/or other applications, the i-element being the granularity at which the data becomes indivisible other than by further processing, such as a table from a database that would require further processing to extract individual data elements.

I-elements may be expressed in include any common programming formats, including their native format such as content compatible XML, MPEG4 or similar, such that degree of operational interoperability provided by the resource interface, matches operational conditions and/or coherence.

I-elements may be combined and or aggregated in any manner and are stored and managed within an i-Space. I-elements may be formed into i-Sets.

In some embodiments, designators may be implemented as i-elements.

i-Sets comprise arrangements of i-elements that create sets of information and as such are defined and managed as PERCos Information Sets. i-Sets may become PERCos resources though the creation of one or more resource interfaces for the i-Set.

i-Set(s) may have, in common with other PERCos resources, control, organization and/or interface specifications and/or associated methods, which can be inherited by i-Sets and/or set i-elements and/or provides comprehensive set operations (e.g. union, intersect, ordering, closure testing, copy/move element, . . . ). These methods may be inherited from, for example, appropriate classes associated with the i-Set and/or i-Set operations, such as purpose classes.

In some embodiments, i-Set members can be considered to be the content of the i-Set, for example, if the i-Set is a resource, then the Content can be considered as resource elements (in any arrangement). i-Set information can be manipulated by one or more sets of methods, for example, this may include i-Set information management methods, such as, add-element and delete-element and the like. In some embodiments these methods may directed by i-Set resource interface specifications. Interactions with information sets comprising the resource elements of i-Set may be provided by referencing the specifications of i-Set's resource interface.

For example, as illustrated in FIG. 34, An Example of i-Set created as resource for use by one or more users.

For example, as illustrated in FIG. 35, An Example i-Set Comprising Information (Query Results) and i-Element for resource.

In some embodiments, each i-Set is extensible to support different information management methods and/or semantics, both for the i-Set, and for any constituent i-element. Specifically, the i-Set/i-element model is designed to support a wide range of content types, and information access/use/governance models. Specifically, the local/remote, shared/private, and static/dynamic information management methods and/or semantics are supported.

In some embodiments, i-Spaces may be used as repositories for dynamic purpose operations and the information they comprise may be arranged and organized by one or more resources, processes and/or PERCos platform systems. For example, an i-Space may be organized by Reputes, Dimensions, purpose expressions, Coherence, resonance and/or other organizing principles. These organizations may become persistent and may be published as resources.

Users may create i-Spaces in anticipation of and/or response to their purpose operations and use these stores, often coupled with one or more organizational principles, which, for example, could include i-Spaces resource interface organizational specifications to organize i-Space contents in one or more manners to suit their specific purpose operations and/or the purpose operations of others.

In many common PERCos embodiments i-Spaces are published as resources, for example, for use exclusively by a specific user and in some examples, they may be created and published by users/Stakeholders and one or more processes as part of purpose operations. For example, purpose formulation processes may, through PERCos publishing services, instantiate one or more i-Spaces in support of those purpose formulation processes, where the results, computational Outcomes, method results and/or other information sets pertaining to such purpose formulations may be stored and analyzed.

In some embodiments, i-Spaces may be open or closed, in addition to the designators, resources and/or i-Sets which comprise that i-Space also being open and closed.

In some embodiments, i-Space(s) may comprise optional methods, metadata, specifications and/or attributes, including controls, information access, mapping, and/or other features of i-Space. These may be inheritable by constituent i-Sets and designators through control mechanisms which, for example, may further include ordering, filtering, persistence, distribution.

A set of i-Spaces may be represented in some embodiments, as lattices, topological spaces, metric spaces or other mathematical interpretations and/or expressions. In some embodiments, i-Spaces may be represented by topological spaces, such as Hilbert spaces, manifolds and/or other representations.

In common with other PERCos resources, i-Spaces may be publishable.

PIMS provides the architecture and mechanisms for the persistence, and associated storage, retrieval, archival, manipulation and management of the diverse range of information sets (including for example, i-elements) that PERCos may encounter. For example, PIMS can manage resource interfaces in dynamic arrangements and groupings that are encountered as Purposive operations unfold. In many cases the number, type, arrangement and locations of the resources encountered during Purposive operations may be unknown, and as such PIMS provides mechanisms for persisting this resource usage information such that it can be stored and managed.

PERCos Persistence Services may persist the state, in whole or in part, of one or more operating resources and/or information sets, such as any specifications, data, rules sets and/or any other associated information sets, generated and/or created by, for example, resources, Processes, users/Stakeholders and/or any contextual information.

In some PERCos embodiments, persistence arrangements may comprise agreements between those resources (including, for example, Participants)/processes requiring persistence and those resources, platform services and/or processes providing such persistence. PIMS can provide the methods for those resources requiring persistence to create agreements with those resources/services offering such capabilities. In some embodiments, these agreements may be PERCos operating agreements.

Persistence may be applied to any resource interfaces, resources (and/or arrangements thereof, including, for example, Constructs) and any sets of information associated with a and/or generated by those resources.

In some PERCos embodiments, persistence services are a PERCos Platform Service, which may provide both storage and the appropriate interfaces and methods for that storage. PERCos Persistence Service may also be instantiated as a standardized PERCos resource Role.

For example, as illustrated in FIG. 36, Illustration of Interaction between PIMS, Resource Services, and Persistence Services.

Users, on the human side of the Edge, have their own internal information structures that encapsulate their current thinking, including their current purpose. This information organization is described as a user class.

In some instances, users may have organizations in mind that include both syntactic and semantic elements, as well as the underlying principles of hierarchy expressed in the class, for example, a user may have a class comprising Fish (super class), Snapper (sub class of Fish), New Zealand Snapper, Mexican Snapper—both sub classes of Snapper and may have associated semantics, such as ranking their taste, degrees of freshness, amount of travel, whether they have been frozen and a wide range of other thoughts associated with their internal class structure.

This mélange of concepts, attributes, categories, verbs and other associated information does not lend itself to direct replication on the computer side of the Edge, and consequently in some PERCos embodiments, the basic class hierarchy is the information structure that is best translated across the Edge, providing a lossy apparatus and method embodiments for the user to access that information set most suitable to their purpose.

In some PERCos embodiments, user classes can be considered as ontologies, yet the degree of specificity and formality of the ontology in the users mind may be low, with inconsistency, incompleteness and/or contradictions, as the user is often formulating and manipulating their purpose and their associated variables in a dynamic manner.

Systems that enforce the user to adopt a formalized information organization may only succeed when that information organization matches the user's internal information mapping, which is only likely to occur when the user has undergone significant training as to this expression. For example, a user trained in mathematics can conceptualize their internal thoughts into mathematical expressions.

However the great majority of users does not have such formalized training and/or may have training in disciplines and domains other than that which is their current purpose. PERCos embodiments provides a lossy apparatus and method embodiments for users to express their purpose using the minimal information structure, for example, a class, which can still convey the richness of their though process through the association of attributes, semantics and syntax as the users purpose operations unfold in the form of user experience.

In many information, knowledge and/or purpose domains there may be individual and/or collective sets of bias towards one or more apparatus and method embodiments of representing knowledge and ascribing importance, priority, ordering and/or other implicit/explicit expressions of representational bias. For example, the domain of Economics.

One key aspect to the expression of information is the representation of that information within the relative context of other similar information. For example, the expression of perspective for one or more assertions, is often key to understanding the relative context, and as such is vital in evaluating those information expressions in pursuit of purpose(s).

The use of one or more Dimensions upon which to base such information relationships enables the effective contextual evaluation of this information so as to form a perspective relative to the information under evaluation and the, potentially undefined and/or unknown, perspective of the evaluator.

However, each information expression may be represented, on one or more Dimensions, in for example, the form of “point-counterpoint”, where those expressions that are in agreement, to a greater or lesser degree, with each other, are grouped together, and those with an orthogonal and/or opposing perspective are also presented together, giving the user/Stakeholder a view as to the range of assertions/information/expressions.

Although in some existing systems such information is often presented on a time base Dimension, representation on multiple Dimensions is unique.

Users may enter into one or more purpose operations with multiple perspectives and/or beliefs relating to their purpose. For example, a climate change skeptic may wish to consider only those resources that are aligned with their beliefs in this purpose domain and/or may wish to consider those opposing perspectives as well. In some embodiments users may wish to have such perspectives in the form of point/counterpoint and/or other representations.

In some embodiments, PERCos embodiments provides methods for users to express their perspectives, through, for example, Reputes as to purpose, which may be used to navigate and/or interact with resources within that purpose domain.

In some embodiments users may, for example, wish to have resources reflecting multiple perspectives returned as part of results sets, where, for example, such Repute expressions provide the organizing principles for those results sets.

PERCos embodiments provides processes and services for the capture, retention and/or extraction of information and/or knowledge. This includes, for example, PERCos embodiments Platform History Services, Evaluation Services, Tests and Results Services.

In some embodiments, historical information may be used to establish one or more profiles, including, for example, purpose profiles, resource profiles and/or profiles associated with one or more specific Roles. These may, for example, include histories of Participant behaviors as well as the resources interacted with. These processes may also operate across large numbers of users, such as crowds, enabling the identification of trends and other statistical models of the operations of large volumes of users.

8 Constructs

Constructs are combined, standardized, and interoperable arrangements of PERCos resources. Resources may be combined in arbitrarily large and complex assemblages in pursuit of purpose satisfaction. In some embodiments, Construct templates provide a method of composing a set of resources, with their own descriptive specifications, resource interfaces, prerequisites, and/or other metadata into a single Construct resource, with its own descriptive specifications, resource interface, prerequisites, and/or other metadata. In some embodiments Constructs comprising one or more component resources may be created by other methods.

PERCos resources, including Constructs, may be classified according to their intended uses, which may involve operational considerations that are distinct from user purposes, called Roles. In some embodiments, the basic PERCos Roles include Foundation, Framework, resource manager, purpose class application, plugin, template, transformer/assimilator, and administrator. Some embodiments may provide methods of adding further Roles. Roles may be organized in classes. In some embodiments, purpose classes and Role classes may co-exist in a single class system; in others, they may be represented by two separate class systems.

This disclosure describes how a PERCos Construct environment and Role class system can support effective and efficient pursuit of purpose fulfillment.

Constructs are combined, standardized, and interoperable arrangements of resources that provide efficient and effective granular modular structures enabling users to organize and manage unfolding purpose operations. A Construct environment may provide methods of arranging and/or transforming sets of resources into Constructs, and may support Constructs at multiple levels of granularity, ranging from those comprising a few simple resources, for example, a lookup table, to those that are arbitrarily large, heterogeneous, and complex, for example, a large networked system, comprising multiple computers, operating systems, applications, networks, and interfaces.

A set of resources may be combined to form a Construct by PERCos processes, such as Platform Services, including Coherence Services. Constructs enable users to effectively operate and manage potentially complex arrangements of resources in pursuit of their purposes. Some embodiments may provide methods for users to provide and/or share Constructs and/or Construct templates with other users. Some embodiments may include unified and standardized devices and methods to describe resources, including Constructs.

Some Constructs may be expressly optimized to fulfill one or more purposes in a purpose-responsive environment. In some embodiments, acknowledged Domain experts and/or users may declare additional Constructs for their own use and/or for publication for use by others. Constructs may also be created by publishers and/or Stakeholders to provide specific resources for one or more purpose operations.

Constructs enable users to efficiently and effectively discover and/or create resource arrangements that can be evolved, resolved, cohered, and/or transformed into operating Constructs in support of the pursuit of their purpose(s). A Construct may utilize, specify, and/or reference one or more of resource Roles that specify certain common interface specifications. For example, “Windows 7 and higher” is a Role that provides common specifications for standardized and interoperable resource interfaces, that (when provisioned with appropriate Prerequisite resources) support operations supplied by Windows 7 APIs. A Framework may specify a prerequisite for Role “Windows 7 and higher.”

Some Constructs may be associated with Construct templates that enable Constructs to be decomposed and composed for their evolution, resolution, coherence into more detailed, specific, focused, capable, and/or tailored Constructs.

Constructs may also support a wide range of purposes, from those that are highly general, such as “Explore Mathematics,” to those that are more specific, such as “Purchase Fishing Lures for Bass in Lake Tahoe.” A purpose class application, for example, could support a general purpose class, such as “explore all of western music.” Another could support a more specialized purpose, for example, “analyze the Beethoven piano sonata Waldstein.” A Construct may support multiple purposes. For example, a purpose class application may be associated with multiple purpose classes.

Some PERCos embodiments may organize Constructs so that users/Stakeholders (including publishers and/or acknowledged Domain experts may efficiently and effectively arrange appropriate resources for their pursuit and/or satisfaction of purpose through, for example, purpose and/or resource classes. These organizations may be based upon one or more organizing principles, which may include standardizations, such as Dimensions, Reputes and/or other specification sets.

Constructs may provide, in whole or in part, purpose unfolding operations, such as purpose formulation (e.g., support users/Stakeholders in their expression of purposes by providing navigation and/or exploration and/or other associated interactions), specification, resolution and operational processing, and the like. Constructs may be specified to varying degrees of completeness for providing user purpose experiences.

Constructs may have differing degrees of generality and complexity. Like other resources, they may be classified according to their Roles, as in the table below

A resource assembly is an aggregation of compatible resources for providing one or more capabilities within specified and/or constrained circumstances and is associated with one or more resource managers. Resource assemblies are often employed as building blocks (sub-assemblies) for PERCos Constructs.

In one-to-boundless computing, there may be a wide range of purposes. Purposes can be of varying generality, from those that are highly general, such as “Explore Mathematics,” to those that are much more specific, such as “Purchase Fishing Lures for Bass in Lake Tahoe.” Purposes can be of varying complexity and completeness. Some may be elaborate and/or poorly formulated; others simple and well formulated. Some purpose specifications may be directly satisfied by one or more existing Constructs (e.g., a purpose class application).

PERCos systems support this wide range of purposes by providing a PERCos Construct environment that is flexible and scalable. For example, a user might have the purpose “obtain a high-level overview of trigonometry,” which could be fulfilled by retrieving an article from Wikipedia. A Construct for fulfilling a class of such purposes might be created by straightforward application of a standard specification template. However, other Constructs may be more complex, elaborate, and/or more narrowly useful. For example, a high school student who is applying to colleges might want to explore which colleges would be most personally suitable. The student might be interested in majoring in engineering, but might not know which of its fields would be most exciting, or the varying career opportunities of the fields. A Construct for fulfilling this purpose would be less straightforward. It might enable the student to first explore all sub-disciplines of engineering (e.g., chemical engineering, electrical engineering, civil engineering). It might then allow the student to explore which colleges are best fit in a selected field of engineering.

Available Constructs may be used in combination, since each constitutes a resource.

For example, as illustrated in FIG. 37, Illustrative Example of Construct Types including comprising resources.

In some embodiments, PERCos resource architecture, being scalable and extensible, supports creation of Constructs that are of arbitrary granularity, from simple resource and resource interface combinations (potentially with associated specifications) to combinations of Constructs and potentially PERCos embodiments themselves. The appropriate granularity of Constructs may be tailored to users/stakeholders selection criteria, such that users/stakeholders may effectively and efficiently create, manipulate, manage and/or interact with the Constructs in pursuit of purpose.

In some embodiments, Constructs, in common with other resources, can be arranged/aggregated into Compound Constructs into a more capable and powerful Construct. Constructs, such as Frameworks can also be nested in a hierarchy.

In some embodiments, Construct environment may have constraints and rules associated with each Construct type to ensure their interoperability. Users and/or acknowledged Domain experts may request enforcement of these constraints and rules.

This design embodiment of Construct environment may allow users to associate a wide range of Reputes with Constructs. Constructs may have the Reputes of their publishers. In addition, users who use a Construct may also assign Reputes, such as its usability, suitability, efficiency, and the like. In such instances, users may also provide their own Reputes along with the Reputes they assign to the Construct.

Users who wish to use a published Construct may evaluate the Construct's Repute to assess its suitability in fulfilling they purpose experience.

Purpose class applications can also be type of purposeful Constructs. Users/Stakeholders and/or other acknowledged Domain experts may create, publish and distribute them.

In addition, groups of users/Stakeholders may create their own customized Construct types. One or more users/Stakeholders may complete Constructs, such as for example, Foundations, Frameworks, purpose class applications, that may be specified in varying degree of completeness by other users/Stakeholders by for example, editing/adding/deleting, evolving, cohering, resolving, transforming and/or in other ways manipulating such Construct specifications, subject to any rules and/or governance associated with such Constructs.

A Foundation is a declared specification of an arrangement of cohered sets of assumed resources and/or resource Roles that provide operating environments for one or more other PERCos purpose operations. Foundations, in general, may comprise those resources that are assumed for many common operations, for example, computation, storage, and/or communication. In some embodiments, Foundations may include one or more sets of specifications that comprise weighting profiles which in whole or in part specify adaptive resource arrangements based on some specific resource arrangement.

Foundations may include specifications, processes, weighted profiles, preferences, governance requirements, availability, and/or other considerations for finding and/or otherwise evaluating, prioritizing, ranking, and the like. Resources and/or other candidate resources, including for example, other Constructs, including, for example, Foundations and/or Foundation building blocks (for example, resource assemblies that are designed to be Foundation sub-assemblies, such as a network stack, security system and the like).

Such specifications may be represented at least in part as associated schemas and/or metadata, which may describe additional specifications and/or other information related to performance, efficiency, acceptability, trustworthiness, complexity, reliability, evaluation, commercial acceptability, and/or any other performance information.

Foundations, in certain embodiments, can provide specifications for resources residing in the tangible domain, such as a hard drive. A Foundation can also specify Edge processes and cross-Edge data, such as, additional specifications that may be required for operation, possibly including software. It may also include assimilation specifications (e.g., transformers) for incorporating non-PERCos resources.

Foundation specifications may specify hierarchically which hardware, operating system arrangement, virtual environments, and/or other platforms are useful for its successful operation. For example, a high layer Foundation might describe standardized sets of resources that can generally be used for multiple purpose operations, consistent with their declared Roles. Such higher layer Foundation may describe resources abstractly, by their contextual usage characteristics, performance specifications, and the like. A lower layer Foundation in contrast might require specific resources, such as particular assimilated non-PERCos resources and/or particular hardware.

A Foundation can be packaged into a resource, and/or as a portion of one or more resources. Such one or more resources can be associated with one or more CPEs. A Foundation may include one or more arrangements of resource Relationship specifications, and when resolved, form operating Foundations capable of supporting one or more purpose operations.

A Foundation is generally associated with at least one purpose expression, and in some embodiments may retain (through reference and/or embedding) one or more relationships with those Constructs and/or other resource arrangements (for example, Frameworks) with which Foundation has been utilized.

For example, as illustrated in FIG. 38, An Example Foundation Construct Template.

Foundations may be hierarchical. For example, a high layer Foundation may describe resources abstractly, such as their contextual usage characteristics, performance specifications, and the like, which in some embodiments may be in the form of resource Roles. Whereas a lower layer Foundation may be designed and deployed for specific resource constructions, such as for example, assimilating non-PERCos resources into an operating session. Ontologies may describe sets of Foundations and relationships, including for example, one or more Foundation relationships in regards to Contextual Purpose expressions and/or related information.

These Foundations may then be declared as such and may retain the information sets generated and/or incorporated as part of their specifications.

In some embodiments, there may be standardized Foundations, which may be, for example, comprised of and/or be resource Roles, which can generally be used for one or more purpose operations.

A Framework is a declared specification arrangement that provides an operating scaffolding for a purpose session having an associated one or more CPEs. A Framework may have as Prerequisites one or more Foundation specifications that contain operational information germane to operating a session. A Framework provides scaffolding representing one or more users', Participants', and/or Stakeholders' specifications that, after suitable processing, may be launched as an operating Framework corresponding to those specifications.

A Framework may be specified at varying degrees of completeness. A Framework may unfold through Coherence processes resolving it and other relevant purpose specifications and/or metadata (resource metadata such as content metadata, platform preferences and rules, corporate and/or societal preferences and/or rules, or other forms of resource metadata). It is said to be sufficiently complete from a user standpoint, if such processing is sufficient to enable it to be launched as an operating Framework. It is said to be said to be sufficiently complete operationally if it is cohered and resolved.

Purposes fulfilled by Frameworks may also be of varying degree of generality. Some Frameworks may fulfill highly general purposes, such as, learning about Electronics, whereas others may fulfill specific narrow purposes, such as learning about repairing brakes on a specific type of cars.

Users may create Frameworks by using Framework specification templates to create Frameworks.

Component Frameworks are declared, purposeful specification arrangements that normally function as building blocks in the formulation of Frameworks. In some embodiments, such component Frameworks, may be either embedded or referenced as part of one or more Frameworks. Such component Frameworks, may comprise resources that are purpose specific (often highly specialized purposes), such as resources that provide a scaffolding for interactive operational environments (experience) for one or more users to undertake purposeful interactions and/or operations. Component Frameworks may include one or more user interfaces (UIs) and/or other interaction capabilities.

Component Frameworks may have one or more purpose associations that range from very narrow and specific to very broad purposes. A component Framework might be associated with a single purpose with a single mode of interaction, such as a measurement instrument for a single type of measurement. Another component Framework might be associated with a general purpose of providing visualization of data in Graphical formats. Yet another might constitute a general-purpose Web browser.

Component Frameworks may specify specific Foundation Roles as prerequisites to ensure that they have sufficient resources to meet their specifications, for example, their operating agreements.

Frameworks may be converted into component Frameworks and be included in other Frameworks and/or component Frameworks. In some embodiments, this may involve the use of a Framework-to-component Framework template.

For example, consider a Framework F that provides information about scholarships or financial aid to college students. It can be converted into a component Framework and included in a Framework, G, that enables high school seniors identify optimal colleges for their needs, such as providing them best engineering education within their financial disposal. For example, G may allow students to take the results from his/her exploration of the engineering fields and use the results to explore different colleges/universities. G may also provide a component Framework that enables the student to specify his/her preferences for presentation of various results.

In some embodiments, component Frameworks may be used to specify specialized interactions, such as an environment that supports users' use of avatars which represent users. These avatars may include one or more specifications of users, for example, preferences, which when combined in one or more User interaction representations presents a specific avatar with specific characteristics. This may be used, for example, by users when they are not physically available to interact.

In some other examples, some users may favor graphical representation of one or more results sets, whereas other users may favor oral representations, and in some embodiments, a PERCos operating session may include one or more component Frameworks that support various user preferences.

Component Frameworks may be nested. Component Frameworks may be combined and arranged by Frameworks to provide expanded and/or extended multi-level contextual purpose experiences of arbitrary complexity.

A PERCos Plugin is a declared Construct that, when incorporated into other resources, provides functionality specified by the associated specification. Plugins can be incorporated into both PERCos resources, such as, purpose class applications, Frameworks, etc. as well as non-PERCos resources, such as, browsers (e.g., Firefox, Internet Explorer, Safari), third party applications, and the like. For example, when a Plugin is incorporated into a browser, it may provide the browser to resource interfaces to PERCos systems.

A purpose class application is a type of Construct that is an arrangement of specifications and/or operating resources. In some embodiments, when installed on a user's Foundation resources, provides the user with purpose experiences and/or result sets corresponding to one or more purpose expressions. Purpose class applications may support a wide range of users, from those who have precise knowledge to retrieve information, to those who don't know how to describe with sufficient precision for retrieval, to those users who may want to discover new, interesting, and/or useful experiences and/or resources in domains that they don't fully understand.

A transformer is a declared Construct that, combined with a non-PERCos resource, provides the properties of a PERCos resource. I.e., contains information to identify a unique element (value) and associated resource metadata, including one or more associated resource interfaces—from within the transformer and/or from some other source. Often, the most substantive element of a transformer is a resource interface that presents a PERCos interface while accessing the non-PERCos resource using its “native” interface.

Transformers enable PERCos systems to interface with “legacy” or other platform-dependent systems through specialized resource interfaces called transformers; the properties of a transformer may be constrained by platform dependencies built into the underlying resource.

An assimilator is a declared Construct that identifies a non-PERCos resource through name, location, and/or Reference identification and enables PERCos to access it by invoking appropriate transformer.

In some PERCos embodiments, Constructs may include one or more PERCos Platform Services, such as History, Coherence, Evaluation, Monitoring and Exception and the like. These services may be components of resources comprising Constructs and/or may be resources comprising Constructs.

In some PERCos embodiments, Platform Services and resources may comprise Constructs which are combinations of more basic PERCos resources. For example, PERCos Information Services may comprise PERCos Evaluation, Arbitration, Identity, Persistence, History and Monitoring and Exception Services in combination with the specific resources, specifications and associated managers for information Management.

In some embodiments, PERCos Platform Services may be extended through construction of additional platform services from specification templates. Generally this may be embodiment specific and often be intended to create a Foundation suitable for specific purpose operations.

In some embodiments, a PERCos platform comprises sets of Constructs (resources and services) that are intended to provide appropriate functionality to support purpose operations. Each of these is described further in the resource, Coherence, and operating systems documents. In some embodiments, a platform may supply one or more PERCos Foundations with differing characteristics.

FIG. 39 illustrates a PERCos Platform Services embodiment, where a Service may be a Construct that comprises a combination of other Services.

For example, as illustrated in FIG. 39, Illustrative Example of PERCos Platform Services.

9 PERCos Resource Management System

In some embodiments, PRMS may be instanced to manage one or more operating resources, and may operate in any arrangement, called resource Management assemblies. In some embodiments, resource Management assemblies are dynamic suites comprising PRMS services and managers, such as, Resource Services, resource Manager Services, resource Reservation Services, and the like. Resource Management assemblies may be configured, arranged, and organized dynamically in a diverse manner. For example, during its operation, a resource Management assembly may add/remove/update any of its services and/or managers. Resource Management assemblies may be distributed and/or hierarchical. In some embodiments, resource Management assemblies are also resource assemblies, comprising resource managers and associated services, methods, information sets and where appropriate other resources.

In some PERCos embodiments, services and/or managers in a resource Management assembly, in common with other PERCos platform services, may receive one or more control specifications from one or more other resources (including those expressing control over such managers), and then undertake the specified management of those resources under management.

In some embodiments, a resource Management assembly (RMA) receives operational specifications from, for example, operating session manager(s) that may operate upon one or more specifications for fulfilling user's contextual purpose (for example, expressed as CPE). In some embodiments, operational specifications have sufficient information so that specified resources can be instantiated and/or accessed to provide the appropriate service levels.

Specifications of resources can range from explicitly identified resources (e.g., Sony Laptop VGN-Z520 serial number xyz to generic resources (e.g., 19 gigabytes of disk space). To support boundless computing, RMA may be able to efficiently and effectively discover and manage vast amounts of resources from multiple locations/arrangements/organizations across multiple networks. Consequently, resource Management assemblies are designed to operate hierarchical, peer-to-peer, superior-subordinate, distributed, and/or in any combination thereof, to enable each resource Management assembly instance to manage its resources efficiently, effectively, and if appropriate, across multiple networks for one or more users/Stakeholders.

In some embodiments, RMA's may make extensive use of PIMS. For example, PIMS may be used to create arrangements of resources, such as resource assemblies. For example, a resource, R1, may comprise resource elements E1, E2, and E3 with associated methods M1, M2, M3, and M4 (in this example M1 and M2 are associated with E1, M3 with E2 and M4 with E3 and as a consequence their identities are associated with those of the respective resource elements and additionally Ie4 is the assignation to the method set comprising all four methods). An RMA may invoke PIMS to assign i-elements Ie1, Ie2, and Ie3 for E1, E2 and E3 respectively and may also associate an i-element Ie4 for R1. This composition is illustrated by FIG. 40, in which for example, E3 has been validated using PERCos platform Test and Results Service.

For example, as illustrated in FIG. 40, An Example of PIMS Structure for resource R.

Suppose during an operating session, RMA detects (through, for example, an instance of PERCos Platform and Monitoring Services instantiated by RMA) that E2, a resource that provides M3 is failing to comply with its operating agreement. In this example, RMA can replace E2 with an equivalent resource element, E4 that may also provide M3. RMA may then, creates an i-element Ie6 and assigns it to E4. PIMS enables this replacement to be performed seamlessly. When, for example, another resource invokes M3, R1's i-element table seamlessly directs the request to E4.

RMA's use PERCos Identity System (PERID) throughout their operations. For example, they interact with PERID to obtain information to discover optimal resources for fulfilling operating specifications as well as negotiate operating agreements. For example, an RMA interacts with PERID to obtain which resources provide the functionality it needs, such as, the ability to store 1 GB of information. It may also interact with PERID to further refine its resource selection process, such as evaluating the dependencies of candidate resources. For example, suppose there are two resources that provide the same functionality but differing dependencies. The RMA may evaluate the respective dependencies to choose the resource whose dependencies can be satisfied more effectively. For example, the RMA has more reliable network connection to one resource than the other resource. In such a case, the RMA can satisfy one resource's network bandwidth requirements more effectively than the other's.

In some embodiments, when an operating resource fails to comply with its operating agreement, an RMA may use, if possible, the failed resource's PIDMX to determine the functionality of the failed resource and identify a replacement resource. RMAs may also use PIDMX to maintain historical performance information that other RMAs may use in the future about resources.

In some embodiments, the distribution span and hierarchical depth of RMA may depend, in whole or in part, on the set of resources requested and/or identified by operational specifications. In particular, PRMS considers factors such as the locations of the resources, levels of services that may be required for each resource, and the number of resources, to determine the depth and the span. For each operational specification, an RMA creates one or more operating sessions and provisions those sessions with appropriate resources that are specified by the operational specifications.

In some embodiments RMAs negotiate with operating session managers and/or other authorized resources and/or processes to create operating agreements that define levels of service that the operating session provides. RMA may interact with their respective information management systems, such as PERCos Information Management System (PIMS) to obtain information on specified resources, such as resource interfaces, resource characteristics specifications (representing resource capabilities), performance attributes, administrative requirements, control, organizational and/or information specification so as to assess and enable the monitoring and compliance of operating sessions with the negotiated levels of service.

If a specified resource is a resource comprising multiple resource elements (i.e., an arrangement of resources), a resource management assembly may obtain information about the component resources that constitute the arranged resource. For example, suppose Sony VGN-Z520 is a computer laptop comprising several resource elements including its NVIDIA graphics. In such a case, a resource management assembly may obtain information about the component resources of Sony VGN-Z520, such as its NVIDIA driver to determine whether or not the resource management assembly may provide the desired level of video image processing.

After receiving operational specifications, RMA may compliment, refine, extend, optimize or in other manners manipulate these operating specifications, through, for example, interactions with Coherence, resonance and/or other processes. This may include using PERCos Platform resource Discovery Services to search one or more various resource directories for available resources that match provided specifications. This example refinement may further include negotiating cost and/or performance terms with third party resource providers, identifying primary and alternative resources on the basis of resource characteristics including functional capabilities, availability, cost, and/or other factors. In some instances, highly specific resource specifications may be provided to RMA, through expert provided resonance specifications. In such cases, refinement methods may not be required, unless, for example, such resource is not available and alternate resources need to be substituted.

RMA may also negotiate with third-party (e.g. external to those resources managed by RMA) resource providers for resources on behalf of operating sessions. Negotiated resources may include other RMA and/or arrangements of resources (for example, Constructs). In some cases, RMA may require an operating agreement that includes non-repudiable stipulation for remedies for compliance failures. For example, RMA may negotiate an operating agreement with a storage service to provide 1 GB of storage. If the storage service fails to provide the service, then the operating specifications may stipulate the compensations for the cost of finding alternate source for the storage.

In some embodiments, RMA may negotiate its own management and control specifications that specifies its own management and control operations, notification requirements, publishing specifications, persistence requirements.

In some embodiments, after RMA reaches an agreement with its operating session managers, it may construct and send one or more operating agreements embodying the agreed specifications to its operating session managers and/or potentially other resources and/or associated processes, such as Coherence managers.

The operating agreements may also be published, although in some embodiments, the publication may occur at the conclusion of RMA operations, particularly if those operations were deemed to have been successful. RMA may store the operating agreements, and any derived and/or segmentations of the operating agreements, through, for example, PIMS, in an i-Space or similar store.

Operating agreements may be packaged as resources in their own right and consequently have resource interfaces and may, for example, include designators and/or i-elements that may be part of one or more i-Spaces and/or other information stores. Such i-element(s)—and/or i-Sets, may be utilized by other RMA and/or other processes to uniquely identify the operating agreements.

In some embodiments RMA may use information management systems (e.g., directory services, PIMS etc.) to identity potential resources for fulfilling resource specifications. Some embodiments may use PERCos Information Management System where directories may be i-Spaces. In other embodiments, the information management system may comprise lists of directories that may be pre-populated with well-known resource and resource assembly directories, and/or resource managers may use their current list of directories to find additional directories.

In some embodiments, resources may have associated specifications that specify one or more purposes for which resource is well suited. These specifications may include references to other sets of resources, which when combined provide effective purpose operations. Resonance specifications may include sets of resources and their associated RMA's that optimize purpose experiences.

Some resources may be non-PERCos resources, in which case RMA, may invoke one or more PERCos methods, including PERCos transformers, to transform them into PERCos resources.

In some embodiments RMA, may support the expansion or refinement of purpose expressions and/or other group and query expressions. For example, this may include expansions of one or more resource specifications to fulfill resource requirements. These RMA may also, for example, be directed in such undertakings by specifications provided by one or more resonance and/or Coherence Services.

RMA supports requests for allocations and/or reservation of resources. If resources are available for allocation, then RMA allocates it to the specified operating session. However, some resources may not immediately available for use. For example, a mobile device that is part of a Foundation arrangement is disconnected at the time of the request and is not available. Providing capability to access features of this device even while it is disconnected provides functionality to PERCos. Other examples include on-demand resources that are made available “just-in-time”, and failover resources that operate in “cold spare” mode, where the resource is provisioned but not started until needed.

Resource management assemblies may use a range of methods to satisfy an operational specification. One resource Management assembly embodiment, for example, map decompose operational specification into a set of “smaller” operational specifications, for example, and without limitation by using specification templates, in such a manner that the set of sub-operational specifications collectively produce the same purpose results as the original operational specification. This method for provisioning the specified resources may be continued in a recursive manner.

A resource management assembly, receiving an operational specification, selects the method based on factors such the location of specified resources, levels of services that may be required for each specified resource, and the size of the resource set. For example, suppose the specified resources are from multiple organizations and located across multiple networks. Further suppose that the organizations have widely different administrative requirements for the use of their respective resources. In such cases, the resource management assembly may divide the resource sets into smaller resource sets and delegate the management of the smaller resource sets to other resource management assemblies. It may then establish relationships with them, some in peer-to-peer relationships and others in subordinate relationships.

Part of delegation process includes negotiating a sub-operating agreement that the delegated resource management assembly may comply with. For example, suppose a resource management assembly decides to delegate the provisioning of one or more sets of resources (which may include, for example, Foundations, Frameworks and/or elements thereof) as part of the operating session. In such a case, the resource management assembly and the delegated resource management assembly may negotiate the levels of service that such resources may provide to ensure the fulfillment of the purpose expression.

Delegated resource management assemblies have the option of performing their respective task in a recursive manner. A delegated resource management assembly may determine that it is not able to perform its delegated task for some reason, such as, not having sufficient resources to perform the task. For example, the task may require that the delegated resource management assembly use an encryption service and/or encryption key, to which it does not access. In such an embodiment, the delegated resource management service notifies its delegator resource management assembly. If the delegator resource management assembly is not the originating resource management assembly then it, in turn, notifies its delegator resource management assembly. If the delegator resource management assembly is the originating resource management assembly, then it notifies the operating session managers, which may in turn interact with the user to refine/modify the purpose expression.

Resource management assemblies are responsible for managing their respective set of resources to ensure that they satisfy their respective sub-operating agreement. As with resource provisioning, resource management assemblies may perform the management task in a recursive manner. A resource management assembly may divide the provisioned resources into a group of smaller “resources” and delegate the management of each group to another resource management assembly.

Each resource management assembly, accepting the management task, monitors those resources under its responsibility. If a resource faults for whatever reason, the resource management assembly determines and performs the corrective actions, such as finding replacement resources and/or notifying appropriate process.

From time to time, resource management assemblies may need to reconfigure the resources under their management. One reason may be that they received a failure notification from one of their delegated resource management assemblies. Another reason may be that its own monitoring service observed a faulting resource, where a resource is said to be faulting if it is failing to comply with its operating agreement.

Yet a third reason may be that its user has changed their purpose expression. In this case, the PERCos SRO processes may be invoked to assess the scope of the change. In some cases, the operating session manager may instruct the originating resource management assembly to pause its operation and provide a new operational specification. The originating resource management assembly, in turn, may also need to assess its methods for fulfilling the new operational specification. If the scope of the change is minor, it may reconfigure/rearrange the operating resources of the existing operating session. The affected resource management assemblies may interact with a Coherence Service to affect the reconfiguration/rearrangement.

Finally, in some embodiments, resource management assembly may continuously interact with coherence services to cohere, replace, and/or rearrange the set of specified resources into a cohesive, optimal and effective resource arrangement. For example, a coherence service may determine availability of more optimal resources. In such a case, it may instruct the resource management assembly to reconfigure its “resource arrangements” to replace the less optimal resource with the more optimal resource.

For example, as illustrated in FIG. 41, An Example of PRMS Interaction with Operation Session and Coherence Manager.

PERCos embodiments Resource Services provide methods for management of PERCos and/or non PERCos resources. Resources Services include interfaces to other PERCos systems, such as, Constructs, Coherence Services and/or operating sessions, to enable those systems to interact with resources managed by the RS. Resource Services are PERCos Platform Services that may be invoked and/or instanced by other PERCos resources, including PERCos Platform services and Constructs. RS uses service level specifications of resources in negotiating operating agreements in fulfillment of operational specification, with processes, such as operating session managers.

In some embodiments, resources can provide a specified and defined level of service. The specifications for these service provisions may include, for example, performance metrics, functional capabilities, processes definition and/or any other specifications pertaining to resource operations. In some embodiments these specifications, in whole or in part, may be made available though, for example, a designator. These specifications may, in some embodiments, also be queried through the resource interface, inter resource communications and/or other methods.

These specifications may be included within resource characteristics specifications, resource control specifications, resource interface specifications and/or may be associated with resource as an independent specification set (which may be either an element or a resource).

Resources service level specifications comprise one or more specification elements that describe functions, operating parameters, dependencies, methods and other associated information describing and/or defining one or more aspects of PERCos resource abilities. In some embodiments, they can be used in operating agreements as specifications for resource management to use, and can be provided by PERCos resources as a way of describing the resource's functions.

Resource service level specifications may include differing functionalities and/or service levels, for example, indicating minimum and maximum service levels for one or more functionalities. These functionalities may be associated with one or more purpose specifications (for example, descriptive CPE) of resource.

PERCos resource Manager Services implement operating agreements and elements thereof, which may contain specifications for the creation of operating resource assemblies. In some embodiments, operating resource assemblies may comprise specific instances of a specified arrangement of operating resources and their associated management mechanisms. The specifications of resource assemblies can include provisions of resource assembly isolation, external interfaces, operating agreement failure notifications, and/or exception handling.

The Resource Instance Manager (RIAM) Service provides for the instantiation, pre-use testing, and/or shutdown of those resources that are not “always on”, but are started and stopped before and after each use. An example of such a resource is one that is configured to “wake on network”.

An RIAM may for example, monitor one or more time sources, such as the current/local time (in some embodiments, using for example, instances the common CRON services), and in compliance with appropriate specifications, may start and/or “awaken” specified resources. This may include the provision of appropriate specifications (including, for example, rules sets), methods and/or any other information that may be required for resource to be ready for operations. For example, these initialization materials may include previous state information, specifications (including, for example, rules sets, which may comprise one or more authentication and authorization specifications and/or indicia) and/or other resources and/or information.

In some PERCos embodiments, RIAM may then optionally validate, through for example, PERCos Tests and Results Services and/or though prior invocation, and ensure that the resource is operating. RIAM may then notify appropriate controlling and/or designated other resources, the state of operating resource. For example, if a resource is unable to operate effectively then one or more failure state schema, and associated methods and/or processes, may be invoked by one or more managing resources, including RIAM, which may then, for example, initiate remedial action, and/or notifies the appropriate exception mechanisms.

In some embodiments, when a resource is no longer required to be operating, RIAM and/or other controlling resources may cause operating resources to be shut down. In addition, if resources may require persistence services, for example, to persist state, RIAM may invoke appropriate persistence services, such as PERCos Platform Persistence Services.

FIG. 42 illustrates an embodiment illustrating the relationships within PRMS that is managing multiple operating resource assemblies. In this embodiment, operating session managers communicate with Resource Services to allocate and provision appropriate resource arrangements to satisfy the operating specification. Resource Services determine the availability of resources and negotiate operating agreements with their respective operating session managers. If a resource service and its respective operating session manager cannot reach a satisfactory agreement, the operating session manager may generate an exception and notify to its SRO processes to request a revised operating specification. For example, the operating specification may have specified the use of an explicit resource, which may not be available.

For example, as illustrated in FIG. 42, An Example resource Management System.

Operating session managers may also interact with Coherence Services through their respective operating session Coherence manager. Resource Services potentially also may interact with their associated Coherence managers either indirectly by routing through their respective operating session managers (e.g., resource svc 2-3) or directly (e.g., resource svc 1) depending on implementation methods, though generally it is anticipated that direct communication between Resource Services to Coherence managers may be on an exception basis. In one embodiment, all communications may utilize the PERCos Messaging Services.

A resource service may instantiate one or more operating resource manager services (RMS 1-6), which are instances of RMS. Operating resource manager services are responsible for managing the creation and implementation of operating resource assemblies in order to provide a set of operating resources with a defined service quality to support the operating session and operating specifications. They also provide resource discovery/looking, function matching, allocation, reservation, optimization, and state management for resources of the operating resource assemblies.

Every operating resource manager service supports the management of the exception handling aspects of operating resource assemblies where changes may be required in the defined resource operating agreements/specifications that specify the operations of operating resource assemblies.

Operating resource manager services may continuously manage resource availability, including utilizing discovery services to find alternate and/or new resources that were not originally available. They may then interact with their respective coherence services to modify (“recohere”) their current operating agreement(s) to optimize and/or otherwise modify such specifications and/or operations.

In some embodiments, an operating resource manager service may be responsible for maintenance related activities of its operating resource assemblies, including such as updating reservations, refreshing rule sets (for example, credentials). It may interact directly with PERCos resources, and/or interact with one or more PERCos Platform Services for reservations, persistence, history, in pursuit of resource support.

In FIG. 42, operating resource assembly 1, comprising RES 1-3, is jointly managed by operating resource manager services RMS1, RMS2, and RMS3. Operating resource manager service RMS 4, tasked with managing RES 4-7 creates operating resource assembly 2 and operating resource assembly 3 and delegates their management to operating resource manager service RMS 5 and operating resource manager service RMS 6 respectively. It also creates operating resource assembly 4 comprising resource operating resource assembly 2 and operating resource assembly 3 and manages it.

As illustrated by this embodiment, each operating resource assembly may be made as arbitrarily complex or as simple as may be envisaged, and in some embodiments specific arrangements may form Constructs, such as operating Frameworks which may incorporate such operating resource assemblies.

Resource Services and resource manager services may be hierarchically managed by other portions of the resource management subsystems.

PERCos resource convention may require resources to support PERCos resource management interfaces and support for PERCos resource management paradigms. PERCos resources may be persistent or transient, or may be provided with either persistent and/or transient modes of operation.

PERCos resources may also be aggregated on a transient or persistent basis. These may take the form of resource assembly specifications, Constructs (including Foundations) and/or any other resource arrangements. Some resources may be associated with specific arrangements, where the resource grouping may represent all or part of the Services associated with and/or bound to a particular device. For example, a resource grouping on a mobile device may include all the services that may be required to support, say, a Java application, but may not include core CPU/communications or other device functional abilities.

PERCos resources may also be clustered, in transient, persistent and/or arranged groups where such services may offer similar functional abilities, or form a grouping that in aggregate offers an end to end service. For example, a PERCos resource may implement a distribution service that provides a user with a service from ingesting the content, processing the content, distributing the content, and subsequently using that content.

10 Resource Services (RS)

PERCos Resource Services provide an apparatus and methods for management of PERCos and/or non PERCos resources. Resources Services include interfaces to other PERCos systems, such as, Constructs, Coherence Services and/or operating sessions, to enable those systems to interact with resources managed by the RS. Resource Services are PERCos Platform Services that may be invoked and/or instanced by other PERCos resources, including PERCos Platform Services and Constructs.

In one embodiment, Resource Services negotiate an agreement for one or more resource operations, for example, in the form of an operating agreement, with PERCos system elements, such as, operating session managers. Resource Services then communicate the negotiated operating agreement to other PERCos processes, such as, their operating session Coherence managers. Resource Services are responsible for resource providing the agreed operations, and include monitoring and exception handling PERCos Platform Service instances so as to be able to identify any variations and/or failure states. Depending on the nature of the agreement Resource Services may have with their respective operating session managers, they may be able to substitute resources, vary resources and/or in other ways to ensure that the Resource Services meet the agreed obligations.

Once a resource Service instance has agreed an operating agreement with an operating session manager, it hands to one or more resource Manager Services the specifications and obligations for the creation of operating resource arrangements (including resource assemblies). These arrangements can include specifications of the operating service levels that may be required under the operating agreement.

For example, as illustrated in FIG. 43, An Example of resource Service Interaction.

Resource Services, resource manager services, and/or resources may create and/retain relationships with one or more reservation services, which are instances of PERCos Platform Reservation Services, so that any manager, service, and/or resource that becomes unavailable, can be communicated with by other PERCos system services, such as associated operating session managers, coherence manager and/or other resource managers, some of which may not be aware of the state of the unavailable resource, manager, and/or service.

Resource Services, in some embodiments, provide a common resource management interface and interaction layer for the PRMS to interface and interact with PERCos-enabled resources, legacy services, and devices, and to manage them as part of a resource assembly.

Resource Services may interact with, for example, PIMS, for provision of data storage, for example, an i-Space for RS operations, History Services, Persistence Services and/or other services and processes as may be required by the RS to support RS operations.

Resource discovery manager may operate to group and query expansion of resource specifications so as to refine resource specifications and/or define specific resources from one or more general/abstracted specifications in collaboration with resource Analyzer.

In some embodiments, a resource service manager may interact with appropriate PERCos resource directories to identify suitable resources. For example, users may maintain directories of those resources that are available to them (for example, their laptop) and/or have been used previously by them (for example, cloud service X), have been recommended by others (through, for example, Repute and/or other recommendations), and/or are offered on commercial terms (for example, the Amazon Elastic Compute Cloud (Amazon EC2) and the like).

PERCos resources can have a single identity, or can have a plurality of identities, any of which can be federated into one or more groups and or/formed into PERCos Identity Matrix (PIDMX).

For example, in one embodiment, a PERCos resource can be assigned a unique identity, from an appropriate identity issuing services, such as “PERID_SM.” This identity may then be registered with one or more resource Registries so as to be made available to processes and/or resources interacting with those Registries. In some embodiments, there may be a hierarchy of such Registries (such as DNS), where the identity is unique on a system wide basis. In other embodiments, the identity may be multi part, such that the uniqueness is established through a combination of resource identity, issuing authority, time, location and/or any other factors.

In some embodiments, resource registries may be distributed across multiple other resources, creating a web of related resources through their identities, which may for example, be stored in each resources PIDMX, with one or more master designators enabling this set of resources to be interacted with as a single resource arrangement.

In another example embodiment, a PERCos resource can be assigned one or more additional identities, by appropriate issuing services, which may be operating session identity managers, and as such resource may use such PERCos identity capabilities, such as PIDMX to retain these identifications and the associated relationships.

In some embodiments, these identities issued to resources may instantiate a specific relationship between user and resources, such as establishing a specific identity of a resource for a specific user (through, for example, their Participant resource). These relationships may then be complimented by specifications and rules expressing the ability of the issuer of that identity to pass control specifications to resource so as to control resources operations.

For example, depending upon the context within which the resource is operating, one or more identities can be shared using a federated identity scheme. Federation of a resource's identity permits further aggregation of the abstracted identity, authentication, and authorization methods across one or more contexts. Federation of identities also enables resources to be known within a context by a first identity, and be known by another context that is operating co-jointly with the first context using a second identity.

PERCos resources may publish PERCos specification elements that may be assembled as part of an identity matrix (for example, PIDMX) that may be used to identify these resources in aggregate and/or individually. In some embodiments, these PIDMX may be utilized as part of resource arrangements.

In some embodiments, Resource Services may instantiate one or more resource Service managers, which are controllers for resource Service operations and/or resource assemblies. resource Service managers interact with resource Manager Services to instantiate resource assembly instances, and then oversee operation and management of each instance until such time as the instance is dismantled, made non-operational and/or persisted through direction by a controlling PERCos process.

In some embodiments, resource discovery manager provides for discovery of resources in support of resource requests, for example, using PERCos resource information (including designators and/or other metadata) and/or non PERCos techniques, such as Bonjour, Plug and Play and the like. resource discovery manager, in some embodiments, can be a PERCos Platform Service which may be invoked by one or more other resource to process specifications in which resource characteristics in have been specified, and consequently to undertake appropriate processing to identify suitable resources that may be available to meet those expressed specifications. This may include interactions with other resources, such as PERCos Reservation Service, to establish the availability of resources.

In some PERCos embodiments, resource discovery manager may leverage PERCos class systems to identify resources suitable for one or more purposes. The resource discovery manager may use the resource characteristics specifications of a set of resources which are associated with a purpose class, to find other similar and potentially suitable resources for presentation as a results set or candidate results set. This processing may be undertaken by Coherence Services to identify “shadow” resources in case of resource faulting, or may be part of other processing associated with Facet services or other purpose related activities whereby users, for example, through use of PERCos navigation and exploration services have opted to widen their results sets.

Resource discovery manager may use multiple methods to discover suitable resources, and this may include “lossy” techniques, to find resources that in whole and/or in part satisfy the specifications. Resource discovery may also interact with Coherence Services to evaluate the potential of one or more resources and/or combinations thereof to meet the specifications. Resource discovery may also provide modified versions of specifications for resources to the originating process, to provide variations to those specifications based on what may be available (including when such availability may be possible), so as to enable invoking resource to evaluate the potential options for resources to meet specifications.

Resource discovery manager may operate to group and query expansion of resource specifications so as to refine resource specifications and/or define specific resources from one or more general/abstracted specifications in collaboration with resource Analyzer.

In one embodiment resource discovery manager may interact with appropriate PERCos resource directories to identify suitable resources. For example, a user may maintain a directory of those resources that are available to them (for example, their laptop) and/or have been used previously by them (for example, cloud service (X)), have been recommended by others (through, for example, Repute and/or other recommendations) and/or are offered on commercial terms (for example, Amazon EC2 and the like).

Resource discovery manager may, in one embodiment, operate with processes involved in operating agreement negotiations to ascertain and identify those resources that may be required to meet operating agreements (and/or sub agreements thereof).

In some embodiments, PERCos specifications may undergo both segmentation and composition. These operations are supported by one or more methods, and in some embodiments, may involve use of one or more templates, incorporating such methods. These methods may in part be based on evaluations of such specifications by one or more resources and/or processes, and include purpose, user/Stakeholder, resource and/or other context specific operations. In some embodiments, control specifications may be provided for these operations.

In some embodiments, PERCos Platform Services includes resource Analyzer Service which evaluates resource specifications to identify resources and/or resource arrangements that provide functionality that meets (in whole or in part) and/or exceeds that specified by one or more specifications. Specifications analyzed by resource analyzer service include, for example, and without limitation, control, organization and/or interface specifications, and may come from RS, i-Space(s), resource Directories and/or other resource information sources.

These specifications may include one or more purpose expressions and/or other specifications provided by other resources, PERCos Platform Services or other processes. Resources that meet these specifications may be sets of resources (and specifications thereof) and/or arrangements may be existing (including as, for example, Construct specifications and/or templates), favored and/or have one or more histories or other performance information that makes them particularly suitable.

In some embodiments, the resource Analyzer Service may operate within the context of resource assembly, where resource selection is, in whole or in part, determined by resources ability to effectively interoperate with other resources in a specific arrangement to provide specified functionality.

In some embodiments, resource Analyzer may be implemented as an instance of PERCos Evaluation and Arbitration Services with appropriate control specifications for selection and analysis of resources, through, for example, evaluation of their specifications (which, for example, may include their designators, resource characteristics specifications, history, PIDMX and/or other associated specifications).

Resource Analyzer Service embodiments may divide arrangements of resources to identify the underlying resources and determine the interfaces for the underlying individual resources. In such an embodiment, resources may monitor at the individual level (and potentially at the aggregate level as well), depending on the characteristics of the arrangement. For example, in the event of a single resource failure, appropriate processes may replace the faulting resource.

The resource Analyzer Service may calculate, using one or more metrics, performance, reliability, purpose metrics, location, values, including costs (either in financial or other measurement), and/or other metrics available to it, possible selections and arrangements of resources and/or resource fabric instance's specification in order to optimize at least one aspect the Resource Services and/or resource fabric instance with respect to some metric. Each resource Analyzer Service embodiment may simultaneously perform these operations using a plurality of models and metrics.

In some embodiments, resource Analyzer Services may be invoked by Coherence Services to undertake analysis of specifications, so that Coherence Services may select optimum resources for purpose operations.

PERCos platform rules management instances may be utilized to provide, with appropriate control specifications, those services that may be required for chain of handling and control, authorizations, authentications, credential and/or other sets or rules that govern the resource.

For example, many resource credentials are provided in “wrapped” form, others are provided as device-specific authorizations, in which interaction occurs between the rules manager and for example, lower level devices using device-specific credentials. Rules manager manages each of these credentials and manages recovery from credential-based failures.

Resource rules manager may use PIMS systems to store rules sets (and/or elements thereof) where appropriate.

In some embodiments, a PERCos Platform Services history manager provides a storage and/or retrieval mechanism for PRMS and resources operating under such management. The information that History manager may manage includes Resource Services and/or resource Construct/resource assembly instance performance, including Resource Services configurations, activities, statistics, operational results and/or one or more performance metrics. The history manager's operating and interface specifications may be provided as part of an operating agreement that can be passed to the Resource Services at instantiation time. In one embodiment, history manager may provide one or more publishing specifications that identify resources, materials to publish, and the rules (for example, credentials). In some embodiments, an instance-specific publishing mechanism(s) may be specified, using, for example, PERCos Platform Publishing Services.

In some embodiments, an RS interface can be instance of PERCos resource interface.

In one implementation the RS interface may provide interfaces to one or more operating sessions, Coherence managers, Reservations Services, History Services, PIMS and/or other PERCos Platform Services.

In some embodiments, RS communications with other processes may be synchronous and/or asynchronous, with varying degrees of sophistication in communications methods and handling to address such implementation considerations as communications failures.

For Example, one such failure may be the loss of communications with operating session Management, where processes for notifications and/or messages from operating RS to operating session management may not be able to be delivered. In some embodiments, communications methods such as, PERCos messaging protocol, includes techniques for anticipating such conditions. For example, RS may be aware of the communications failure (by messaging service providing such exceptions), and may follow instructions provided to that RS from the operating session (through control specifications provided by Coherence Services and/or other resources) to address this situation. This may include specifications to effect an orderly shutdown of the RS operations, potentially using a Reservation Service and or PIMS service to store a reference to the RS, should the operating session or other recovery process attempt to contact that RS and/or utilize PIMS to place the RS in whole or in part into a persistent store, such as a “snapshot,” maintaining state of the Resource Services and/or attempt to contact one or more other process identified within the operational specification and operating agreement supplied to RS.

In many embodiments, the PERCos specifications may be in the form of the PERCos communications (such as PERCos messages), there can be specific post conditions that may direct RS and/or other Process associated with operational specifications as to the appropriate actions for those process to undertake in the case of a communications and/or other events including failure. In other embodiments, the PERCos Monitoring and Exceptions Services (PM&E) may additionally comprise further specifications that detail one or more recovery techniques and associated specifications in the case of the failure of one or more processes and resources.

In one embodiment, the RS may be considered as a “black box,” in that the RS manages an arrangement of resources to an incoming operational specification, reporting exceptions back to the operating session management and/or other processes up the chain of control. In one example, in a simplest form, RS may reports items like “Section X of the operating agreement [N] was violated by failure of resource “67” at time “11.22”, with parameters “ABC123.” In a further example, RS might notify operating session management such that “Section Q of operating agreement [N] violated performance term [47] with parameters [6123XX] with no reported resource failure.” In these and similar cases, there may have to be variations in the operating agreement, resources, RS or other resource management processes, which in some circumstances may require a new operating agreement to be agreed and entered into or varied.

11 Resource Management Services

Processes and operations of an embodiment of resource Management Services may be implemented by a number of PERCos platform resource Management Service elements. As resource Management Services interact with many PERCos platform and system elements, the processes and operations of the embodiments are considered from the perspective of PRMS. Resource Management Service elements are grouped into a resource Management Dynamic Fabric (RMDF) which may operate distributed and/or functionally organized (e.g., hierarchically) to enable resource Management System operations in a one-to-boundless manner.

As illustrated by FIG. 44, an RMDF embodiment may comprise one or more resource Management Service elements, including RMDF managers, in any arrangement including resource Management Network arrangements. An RMDF may also include one or more instances of PERCos platform services, such as, Monitoring and Exception Handling Services, Coherence Services, Evaluation and Arbitration Services, Test and Result Services, Operating Session Management Services, and the like in support of purpose unfolding. An RMDF may also include other templates and/or statements/specifications that may be required to interact with those managers, involved in provision of those instances of PERCos resources, services, information and/or objects that are specified by its operational specifications and consequent resource management operations in support of purpose unfolding. An RMDF may also interact with storage and organization structures, such as classes, ontologies, taxonomies and the like, and may use one or more sets of metrics in operations.

For example, as illustrated in FIG. 44, An Example RMDF Configuration.

RMDF embodiment may be dynamic in that one or more elements of a RMDF instance may change, adapt, be substituted, and/or be varied in support of its operations as instructed and/or managed by resource Management Dynamic Fabric manager.

An embodiment of PERCos resource Management Service elements may include, for example, without limitation, the following:

In some PERCos embodiments an RMDF may use communication protocols including one or more formats, specific semantics and/or syntaxes optimized for efficient Coherence communications, that enables inter- and intra-resource management service communications. For example, as FIG. 45 illustrates, for some purposes, PRMS embodiments may instantiate multiple instances of RMDF, where some instances may form peer-to-peer relationships, whereas others may form supervisor-subordinate relationships. In this example, RMDF 1, RMDF 2, and RMDF 3 form peer-to-peer relationships with each other. RMDF 3 also forms a peer-to-peer relationship with RMDF 4. In addition, RMDF 2 has superior-subordinate relationships with RMDF 21 and RMDF 22 and RMDF 3 has a superior-subordinate relationship with RMDF 3.

For example, as illustrated in FIG. 45, An Example RMDF Relationship.

The communication protocols used by RMDF may include one or more sets of metrics to support resource management operations, including metrics specifically designed and optimized to enable high efficiency real-time resource management operations.

FIG. 46 illustrates an embodiment of the grouping of PERCos resource system elements and services. In this embodiment, resource system elements are grouped into 6 arrangements. One arrangement, labeled RS, comprises 9 elements. An arrangement, labeled PRS, comprise elements that interact with physical and logical resources, including non-PERCos resources.

For example, as illustrated in FIG. 46, Simplified Illustrative Example of PERCos resource Systems and Service Grouping.

For example, as illustrated in FIG. 47, An Example resource Management Assembly Configuration.

One or more operating resource Manager Service instances provide operations for managing and monitoring operating resource assemblies. Each operating resource Manager Service instance, which is an instance of PERCos Platform resource Manager Service, performs its own operations in accordance with its control and management specifications. In doing so, it may manage those operating resources comprising each operating resource assembly, including adjusting and configuring resources as appropriate to ensure that its operating resource assembly complies with its operating agreement.

For example, in some embodiments, an operating resource Manager Service instance negotiates operating agreements for resource operations with other PERCos system elements, generally an operating session manager, and may communicate this agreed operating agreement to associated operating session Coherence manager(s).

For example, operating resource Manager Services are responsible for ensuring that their operating resources provide the operations/functionality/information specified by their respective operating agreements. The operating resource manager service uses PERCos Platform Monitoring and Exception Service to identify any variations and/or failure states. Depending on the nature of its operating agreement with the operating session manager, the operating resource manager service may be able to substitute resources, reconfigure resources, and vary resources.

For example, as illustrated in FIG. 48, Example resource Management Assembly Configuration.

12 Resource Manager Services (RMS)

PERCos resource Manager Services implement operating agreements and elements thereof, which may contain specifications for the creation of operating resource assemblies. In some embodiments, operating resource assemblies may comprise specific instances of a specified arrangement of operating resources and their associated management mechanisms. The specifications of resource assemblies can include provisions of resource assembly isolation, external interfaces, operating agreement failure notifications, and/or exception handling.

Resource Manager Services are instanced by the Resource Services and are provided the resource interfaces and specifications to instance and manage operating resource assemblies. In some embodiments, Resource Manager Services manage each operating resource assemblies on a “services by operating agreement” basis. In such a case, a resource manager service may be handed one or more operating agreement elements and provided with a set of operating resources to manage. For example, an operating agreement element may identify a defined set of operating resources, the appropriate service and/or performance characteristics, and any operating resource management specifications, which may be expressed in total as an agreed common specification, including resource recovery methods (on failure in whole or in part), and/or arbitration from service delivery failures (among other things).

In some embodiments, where high levels of service availability are mandated, redundant services may be identified and made available, both in “hot” and/or “cold” start forms, such that the operating resource assembly may undertake resource Substitution in accordance with its operating agreement. This may involve the use of PERCos Platform Services such as Evaluation and Arbitration Services and/or Test and Results Services to ascertain the sufficiency of resources for substitutions in the case where such resources are not specifically designated in the operating agreement module.

Monitoring and exception handling of a resource may be handled by the resource's resource Manager Service, by other resource Manager Services that are peer to the resource's resource Manager Service or the RS instance that is associated with resource Manager Service, depending upon the type of exception and the defined exception handling from the instancing specification.

In some embodiments, resource Manager Services embodiments may include a resource assembly manager and those associated PERCos Platform Service instances, including monitoring and exception handling service instances that may monitor operating resources to ensure compliance with their respective operating agreement modules. This may also include one or more resource Repositories, such as resource Directories, and may include PIMS, Persistence Services, History Services and/or other resources to support RS operations.

For example, as illustrated in FIG. 49, Illustrative example of resource Assembly.

In some embodiments, resource Management Services (RMS) may undertake communications with other RMSs, and/or other Resource Services with which an operating resource assembly instance may need to communicate in order to facilitate management of the current operating resource assembly instance. These communications may be performed in any arrangement, such as peer-to-peer, hierarchical control, grid, matrix, or any other architectural arrangement of Resource Services, resource Manager Services and/or resources. In some embodiments these communications occur through instances of the PERCos Communications (including Messaging) Services and comply with PERCos messaging specifications. Such communications arrangements may be specified in advance and/or undertaken dynamically, and may be managed and/or under control of resource assembly manager.

The resource assembly manager implements resource assembly instances. In some embodiments resource assembly manager receives specifications in the form of operating agreement(s) from RS, which may include specifications of resources to be assembled, (such specifications ranging from the specific to t