To what extent and in what contexts is Conceprocity really useful?
21.1Research into the Working Model of knowledge workers 21.1.1The personal working model of the author
I as the author of this paper am currently undertaking doctoral research into a phenomenon which I have named the Working Model. This research, and in particular the use of Conceprocity in modelling the working model, is discussed in the conference paper (Gregory and Macgilchrist, 2014). The paper presents an overall Conceprocity model of this particular Working Model. It suggests that two major components of a working model are the Personal Work System PWS and the supporting Personal Information Management System PIMS.
I am continuing to work to refine this initial personal working model. This will have two forms, an as-is – current map – and an as-ought – what I would like to achieve. These models will be based on the PhD journal which I have now maintained for three years.
21.1.2The personal working model of other knowledge workers 21.2Modelling the content of academic articles
I have previously used G-MOT to analyse complex scientific articles and will in future use Conceprocity to do so.
21.2.2By final year Masters students
In the first semester of the academic year 2013/4, a small element of the overall assessment of a module entitled IS505E Principles of E-Commerce PEC required each student to select a different academic article concerning e-business and/or information systems. A short teaching session in one class introduced students to the basic usage profile of Conceprocity, at that time entitled CAPRI. In a later session, students were then introduced to the more advanced usage profile, at the time called CAPRICE.
21.3Action learning by students
A small number of students were asked to identify a short-term solution to improving their personal information management and to document that experience, including the production of a Conceprocity model.
21.4Consequent improvements to Conceprocity
In part as a response to student experience, it was decided to completely revamp the usage profiles in Conceprocity. Capri has been replaced by CIAOPEA. Caprice has been replaced by TROPICPEA.
The core Information Systems course in a French business school had for several years used an evolving combination
21.6Modelling action-oriented knowledge 21.6.1Doing a PhD 21.6.2Modelling people’s Working Models
§22A critical evaluation of Conceprocity and some suggestions for future work 22.1The tentative nature of these initial conclusions: further research proposed
Conceprocity is a semi-formal visual knowledge representation language which enables and encourages the modeller to be more precise in defining, bounding and relating conceptual and procedural knowledge. It is in effect a means to constrain and enhance natural language expression and thereby to increase the precision of the meaning which the modeller needs to express. To the extent to which two modellers can agree upon a Conceprocity model, it is also a means to establish and to verify communication of ideas and concepts.
Certainly, Conceprocity is not without its weaknesses. It is arguably an error to permit so much generality of expression in a single modelling approach. The counter-argument is that usage profiles permit a more restricted representation and are therefore less likely to give rise to cognitive overload in users and readers. I would also point out that in knowledge representation schemes such as UML, it is necessary to learn a wide range of different – sometimes annoyingly so – representations. This problem is even starker in the area of conventional structured analysis, where a simple notion such as process is represented in different, overlapping and confusing ways – contrast data flow diagrams, event process chains and use case diagrams.
Because Conceprocity has been built using the Lucidchart diagramming system, it will be very easy to change the formalism in directions suggested by the readers of this article. For this and many other reasons I would strongly welcome critique and suggestions for improvement.
22.2Metrics
A potential disadvantage of moving away from the simple concept and relationship approach to concept mapping which most concept maps (and mappers) employ is to make it slightly more difficult to create metrics. Whereas (Friedman and Smiraglia, 2013) can present concept maps simply as nodes and arcs, Conceprocity maps include more basic notions – both nodes and arcs have type - and will therefore be slightly more difficult to analyse programmatically.
I hope to be able to carry out some quantitative assessment of Conceprocity models and modelling based on the IS505E PEC experience. This is dependent on being able to carry out some software-assisted analysis of Conceprocity models stored in XML format. This is perhaps a student project or an internship possibility for a software engineering student from a software engineering school.
22.3More fundamental difficulties and objections
We have largely accepted as a given the notions put forward by (Paquette, 2010) which are themselves based partly on the UML thinking of (Booch, Rumbaugh and Jacobson, 2005). Paquette’s thinking also derives in large part from cognitive science; this influence pervades his book and in particular informs chapter 6 on taxonomies of problems and generic skills.
In section §4 above, we suggested that existing visual representation formalisms have emerged largely from the computer science and software engineering communities. It is instructive to reconsider the origins of formalisms such as Entity Relationship models, modern structured systems analysis, conceptual graphs (John Sowa (Sowa, 2000, 1984) following Charles Pierce), the object modelling technique and the successor Unified Modelling Language UML. These are all representation approaches which have been built primarily for the analysis and architectural design of complex software systems. In Conceprocity as it currently stands we have designed and presented a visual representation system which, following (Paquette, 2010, p.xiv), we wish to be usable by educational specialists and learners who are not computer scientists. It is at the same time general and powerful enough to represent the structure of knowledge and learning/working scenarios.
Paquette goes on to say:
“We present three major steps starting with (1) informal visual modelling for the educated layperson, to help represent interesting knowledge. We then (2) move onto semi-formal modelling to help define target competencies and activity scenarios for knowledge and competency acquisition by learners and workers. Finally (3) we present the more formal visual models (Ontologies) that can be used by software agents to ensure execution of knowledge-based processes on the semantic web.” [(Paquette, 2010, p.xiv) slightly amended for clarity.]
Thus G-MOT supports three dialects, one for general use, one for instruction design and one for ontology building. Similarly Conceprocity distinguishes usage profiles (see Table ) within a single visual representation language.
Recall that notion is the name given in Conceprocity to the modelling meta-concepts of concepts, procedures, actors, principles, events and relationships. See sections 3.3 and 3.4. A possible alternative word for notions is meta-concepts, that is, concepts about concepts. We now wish further to address the issue of whether Conceprocity has chosen the right notions. In section §4 we discussed why Conceprocity distinguishes concepts, procedures and principles. Here we consider the nature of concept mapping itself and the relationships permitted in Conceprocity.
22.3.1What is concept mapping anyway?
Much of the literature surrounding concept mapping comes from the field of enquiry known as knowledge organisation which is largely situated within the discipline known as library information science. (Hjørland, 2009) holds that information science and knowledge organization cannot avoid relating to theories of concepts. Knowledge organizing systems (e.g., classification systems, thesauri, and ontologies) should be understood as systems organizing concepts and their semantic relations. Different theories of concepts have different implications for how to construe, evaluate, and use such systems. Based on what he calls “a post-Kuhnian view” of paradigms, Hjørland argues that the best understanding and classification of theories of concepts is to view and classify them in accordance with epistemological theories (he emphasises empiricism, rationalism, historicism, and pragmatism). Different views of concepts are associated with different worldviews and epistemologies which tend to compete with each other. The historicist and pragmatist understandings of concepts are in his view the most fruitful views; he outlines the importance of historicist and pragmatic theories of concepts for information science. For him, the concept is a socially negotiated construct that should be identified by studying discourses (Hjørland, 2009). This view of concept theory has been labelled socio-constructivist.2
(Friedman and Thellefsen, 2011) discuss knowledge organisation systems and the emergence of concept theory and semiotics in that connection. For them knowledge organisation as a domain has as its focus the order of concepts, both from a theoretical perspective and from an applied perspective. It is therefore important to understand the meaning of a concept found in text and in visual maps. Whatever the epistemological stance one adopts, it is evident that the meaning of a concept is that which was intended by the originator of that concept in accordance with her own particular epistemological stance.3
Thus when (Friedman and Smiraglia, 2013) attempt a synthesis of the existing theory concerning concepts and concept mapping they do so within the tradition of library information science and in particular they identify “knowledge organisation systems”, based on earlier work reported as (Friedman and Thellefsen, 2011).
22.3.2Relationships in Conceprocity
Some concepts refer to data. The E/R Entity Relationship model of (Chen, 1976) has informed in particular Conceprocity’s thinking about associations, cardinality, ordinality and multiplicities. See section 10.3.5
The ideas of aggregation, generalisation and specialisation were introduced by (Smith and Smith, 1977) and later informed the design of UML and G-MOT. However, it is difficult to discern a single source of inspiration for the conceptualisations underlying UML. Specifically, UML does not possess a meta-model; nor does G-MOT. See section 10.3.3
Composition and part-whole relationships are the subject of mereology (which is separate from the concept of topology). (Guarino, 1995) give a fuller introduction. See section 10.3.4.
22.3.3Conceprocity: Design issues which are not yet fully resolved
In its current guise, Conceprocity recognises various structural relationship types. These are:
Association Aggregation Composition Specialisation / Generalisation Regulation Precedence Input-Product Instantiation
Are there other structural relationship types beyond those already recognised in Conceprocity?
Is there (for example) a relationship type is-a-model-of in the relationship concept-A is-a-model-of concept-B?
Given that knowledge types share common characteristics with UML classes, but that knowledge is not at all the same thing as data: What interpretations can we validly give to the relationship types which Conceprocity recognises? Thus, what is inheritance?
Note here that the semantics of inheritance are debated within the programming community. See for example: (Cook, Hill and Canning, 1990) who suggest that in typed object-oriented languages the subtype relation is typically based on the inheritance hierarchy. They therefore put forward a new typed model of inheritance that introduces polymorphism into the typing of inheritance. They call for the uniform application of inheritance to objects, classes and types. The resulting notion of type inheritance allows them to show that the type of an inherited object is an inherited type but not always a subtype. This more general view of inheritance is I suggest not only sensible but also what most human users would expect when reading a Conceprocity model in which one concept is a specialisation of another.
Similarly, is multiple inheritance meaningful for Conceprocity concepts? Certainly, it is possible to show it in Conceprocity.
How in Conceprocity do we best represent the subset and overlapping sets which are well summarised by Venn diagrams?
The G-MOT editor continues to have strengths not possessed by Conceprocity; these include XML import and (better) export, explicit support for the OWL Web Ontology Language, and copy with reference between diagram levels. The latter would ideally be generalised in Conceprocity…
Conceprocity does not yet possess easy means to produce and maintain a dictionary of the objects it contains, nor any metrics.
Share with your friends: |