Optimizing Social Software Design with Conceptual Graphs


Published on

Collaborative communities are complex and rapidly evolving socio-technical systems. The design of these systems includes the communal specification of communication and information requirements, as well as the selection, configuration, and linking of the software tools that best satisfy these requirements. Supporting the effective and efficient community-driven design of such complex and dynamic systems is not trivial.
To represent and reason about the system design specifications we use conceptual graph theory. We do so because the knowledge representation language of choice must be rich enough to allow the efficient expression of complex definitions. Also, since design specifications derive from complex real world domains and community members themselves are actively involved in specification processes, a close mapping of knowledge definitions to natural language expressions and vice versa is useful. Finally, the representation language must be sufficiently formal and constrained for powerful knowledge operations to
be constructed. Conceptual graph theory has all of these properties.
We explore how conceptual graphs can be used to:
1. model the core elements of such socio-technical systems and their design processes.
2. specify communication and information requirements and match these with social software functionalities.
We illustrate these design processes with examples from a realistic scenario on building a knowledge-driven topic community on climate change.

Published in: Technology, Education

Optimizing Social Software Design with Conceptual Graphs

  1. 1. Optimizing Social Software System Design with Conceptual Graphs Aldo de Moor CommunitySense the Netherlands WWW.COMMUNITYSENSE.NL LIRMM, Montpellier, June 5, 2009
  2. 2. Outline <ul><li>Social software: from tools to systems </li></ul><ul><li>Scenario: topic communities </li></ul><ul><li>A conceptual model of functionality matching in collaborative communities </li></ul><ul><li>The functionality matching process </li></ul><ul><li>Discussion and conclusions </li></ul>
  3. 3. Social software: so many tools…
  4. 4. Tools in socio-technical context Tool system Mass-media Governments Social system “ climate change policy making” ? Corporations NGOs Institutes Subject matter experts Citizens Journalists
  5. 5. Collaborative communities <ul><li>Examples </li></ul><ul><ul><li>Research communities, knowledge management teams, innovation platforms, environmental campaign networks </li></ul></ul><ul><li>Communities </li></ul><ul><ul><li>Strong, lasting interactions </li></ul></ul><ul><ul><li>Bonds between members </li></ul></ul><ul><ul><li>Common space </li></ul></ul><ul><li>Collaboration characteristics </li></ul><ul><ul><li>Common goals </li></ul></ul><ul><ul><li>Effective/efficient communication </li></ul></ul><ul><ul><ul><li>Perform/coordinate work </li></ul></ul></ul><ul><ul><ul><li>Community governance structures/processes </li></ul></ul></ul><ul><ul><ul><li>Sense of community </li></ul></ul></ul><ul><ul><li>Common space: Internet + face-to-face </li></ul></ul>
  6. 6. Tool systems <ul><li>Tool system </li></ul><ul><ul><li>the system of integrated and customized information and communication tools tailored to the specific information , communication , and coordination requirements of a collaborative community </li></ul></ul><ul><li>No standard solutions </li></ul><ul><li>Socio-technical systems design </li></ul><ul><ul><li>Collaborative communities need to evaluate the functionalities in their unique context of use </li></ul></ul><ul><ul><li>Understand the purpose of the technologies in this context </li></ul></ul><ul><ul><li>Adopt a process view </li></ul></ul>
  7. 7. Tool system functionalities <ul><li>Functionality </li></ul><ul><ul><li>A set of functions and their specified properties that satisfy stated or implied needs </li></ul></ul><ul><li>Functionality levels </li></ul><ul><ul><li>System </li></ul></ul><ul><ul><ul><li>Course system </li></ul></ul></ul><ul><ul><li>Tool </li></ul></ul><ul><ul><ul><li>Blackboard </li></ul></ul></ul><ul><ul><li>Module </li></ul></ul><ul><ul><ul><li>Announcement </li></ul></ul></ul><ul><ul><li>Function </li></ul></ul><ul><ul><ul><li>Post announcement </li></ul></ul></ul><ul><li>Focus: Interfaces, info objects, info/comm processes </li></ul>
  8. 8. Usage context: goals <ul><li>Goals: activities, aspects </li></ul><ul><ul><li>Sense of purpose, drive people and processes, evaluation criteria </li></ul></ul><ul><li>Activities </li></ul><ul><ul><li>Operationalized goals: processes with concrete deliverable as outcome </li></ul></ul><ul><ul><ul><li>E.g. writing a call for papers, making a group assignment </li></ul></ul></ul><ul><ul><li>High-level workflows, interested in potential functionalities, not implementation details </li></ul></ul><ul><li>Aspects </li></ul><ul><ul><li>Abstract goals cutting across processes and structures </li></ul></ul><ul><ul><ul><li>E.g. legitimacy, interactivity, effectiveness, efficiency </li></ul></ul></ul>
  9. 9. Usage context: actors <ul><li>“ The user” does not exist </li></ul><ul><li>Many stakeholders , with their own needs, interests, and goals </li></ul><ul><li>Actor roles increasingly important </li></ul><ul><ul><ul><li>responsibilities in workflows </li></ul></ul></ul><ul><ul><ul><li>access to functionalities and information resources </li></ul></ul></ul><ul><ul><li>E.g. Role-Based Access Control paradigm </li></ul></ul>
  10. 10. Actor role typologies <ul><li>Currently mostly technology-focused </li></ul><ul><ul><li>Administrator, Facilitator, Member,... </li></ul></ul><ul><li>Need to become much more contextualized </li></ul><ul><ul><li>Customized responsibilities and access rights </li></ul></ul><ul><li>Examples </li></ul><ul><ul><li>Workflow-based </li></ul></ul><ul><ul><ul><li>Author, Reviewer, Editor, ... </li></ul></ul></ul><ul><ul><li>Organization-based </li></ul></ul><ul><ul><ul><li>Secretary, Manager, Team Leader, ... </li></ul></ul></ul><ul><ul><li>Domain-specific </li></ul></ul><ul><ul><ul><li>Env. Protection Agency, Corporation, NGO, ... </li></ul></ul></ul>
  11. 11. Usage context: domain <ul><li>Major influence on evaluation processes and tool system functionalities </li></ul><ul><li>Still ill-understood </li></ul><ul><li>Determinants </li></ul><ul><ul><li>Structure and size : e.g. distributed, centralized, small, large </li></ul></ul><ul><ul><li>Setting : academic, corporate, gov, non-gov </li></ul></ul><ul><ul><li>Financial : resources for customization or off-the-shelf software only? </li></ul></ul><ul><ul><li>Political : certain software choices mandatory/prohibited? </li></ul></ul>
  12. 12. The ESSENCE project
  13. 13. Scenario: Topic Community Socio-Technical System
  14. 14. Scenario: activities <ul><ul><li>Select relevant concepts and their entries in the knowledge system </li></ul></ul><ul><ul><li>For each discourse topic, conduct a discussion among relevant stakeholders, resulting in a consensus position </li></ul></ul><ul><ul><li>Disseminate the consensus position to the general public </li></ul></ul>
  15. 15. Why conceptual graphs? <ul><li>Rich enough for efficient expression of complex knowledge definitions </li></ul><ul><li>Close link to natural language </li></ul><ul><li>Powerful knowledge operations </li></ul>
  16. 16. STS concept type hierarchy
  17. 17. Effective tool functionality axioms <ul><li>A functionality component can enable one or more functions </li></ul><ul><ul><li>The Compendium Create Node -module allows a user to create an issue, position, argument… </li></ul></ul><ul><li>Different functionality components can have partially overlapping functionality </li></ul><ul><ul><li>Both Compendium and Wikipedia allow users to create links </li></ul></ul><ul><ul><li>Only Compendium allows to visually map debate, only Wikipedia to collaborative edit text </li></ul></ul><ul><li>All community members involved in a functionality requirement must have at least one enabling functionality component </li></ul><ul><ul><li>An editor needs to be able to create links. Both Compendium and Wikipedia support this. </li></ul></ul>
  18. 18. Enabled functionality <ul><li>Any function enabled by some functionality component for a particular actor role </li></ul><ul><li>Example </li></ul>
  19. 19. Required functionality <ul><li>Functions in their usage context as defined by the activity for which a function is used and the actor role involved </li></ul><ul><li>Example </li></ul>
  20. 20. Assigned functionality: support-mapping <ul><li>A function supporting a functionality requirement </li></ul><ul><li>Example </li></ul>
  21. 21. Assigned functionality: Required implementation <ul><li>A constraint that a certain functionality requirement is supported by a specific tool </li></ul><ul><li>Example </li></ul>
  22. 22. Functionality matching process <ul><li>Create a knowledge base of socio-technical system specifications </li></ul><ul><li>Propose a change to the specifications </li></ul><ul><li>Perform the match </li></ul><ul><ul><li>Formulate matching criteria </li></ul></ul><ul><ul><li>Calculate the match </li></ul></ul><ul><ul><li>Interpret the results </li></ul></ul>
  23. 23. Scenario: functionality matching <ul><li>Proposed specification change </li></ul><ul><li>Matching criteria graphs </li></ul><ul><ul><li>Expressed in terms of functionality mappings </li></ul></ul><ul><ul><li>Often a sequence of graphs to be projected, joined… </li></ul></ul>
  24. 24. <ul><li>Proposed specification change </li></ul><ul><li>Succesful match </li></ul>Functionality matching example
  25. 25. Functionality matching steps (1) <ul><li>Determine set of potentially enabling functionalities Ef pot for selected functionality requirement fr </li></ul><ul><ul><li>Function-concept fr projects into that of ef i </li></ul></ul><ul><ul><li>Actor-concept ef i projects into that of fr </li></ul></ul><ul><li>Determine the set of relevant required implementation mappings RI </li></ul><ul><ul><li>Activity-concept ri projects into that of fr </li></ul></ul>
  26. 26. Functionality matching steps (2) <ul><li>Determine set of acceptable enabling functionalities Ef acc for selected functionality requirement fr </li></ul><ul><ul><li>Ef pot minus those ef i where none of the ri  RI has a tool-concept that projects into that of ef i </li></ul></ul><ul><li>Select one or more acceptable enabling functionalities from EF acc </li></ul>
  27. 27. Conceptual structures in practice
  28. 28. Discussion <ul><li>Basic concept type hierarchy </li></ul><ul><li>Basic functionality mappings </li></ul><ul><li>Socio-technical system reference models for different types of communities </li></ul><ul><li>Quality aspects, e.g. legitimacy, efficiency </li></ul><ul><li>Modeling standards, e.g. BPMN/BPEL </li></ul><ul><li>Role of other CG operations, e.g. join? </li></ul><ul><li>Implementation in CG tools </li></ul>
  29. 29. Conclusion <ul><li>Collaborative communities require systematic socio-technical system design </li></ul><ul><li>Functionality mappings capture dependencies between usage context and tool system </li></ul><ul><li>Conceptual graphs can be useful in optimizing this design process </li></ul><ul><li>Towards integration in collaboratory/testbed development </li></ul>