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