Conceprocity is cloud-based and essentially multi-user. It also provides implicit support for the notion of usage profiles. A usage profile is a named usage of Conceprocity.
The various usage profiles require few or no extensions to the Conceprocity basic notation which is richly expressive.
It is possible and desirable to start with a beginners’ profile “simple concept mapping for beginners”, in which the only available relationship is Association and no use is made of principles, and only then to move on to typed relationships and principles. Particularly in this profile, we place strong emphasis on the use of sketches, icons and images. We have chosen to give the name CIAOPEA to this simple usage profile. CIAOPEA stands for concepts, actors, procedures, relationships, images. By way of contrast, we identify the full usage profile as TROPICPEA, Concept / Actor / Procedure / Relationship / Image / Logical Operator / Principle / Event.
Table Conceprocity Usage Profiles
Model type
|
Name
|
Purpose
| |
|
Simple concept mapping for beginners
|
Conceprocity CAPRI
|
Concepts Actors Procedures Relationships Images. Makes use of a deliberately restricted range of Conceprocity notions. In particular, the only relationship type supported is Association. In order to give more expressiveness, this profile permits Association relationships to be named.
|
Knowledge mapping
|
Conceprocity TROPICPEA
|
Very general with the full range of Conceprocity objects, Concept / Actor / Procedure / Relationship / Image / Logical Operator / Principle / Event. In this profile, relationships should not normally be named. Instead, the nature of the two notions linked by a typed relationship should normally provide full context sufficient to make the meaning of the relationship clear. Where this is not the case, Conceprocity permits commentary / notes.
Typical uses include: self-observation, research design, representing knowledge as-is and as-ought, demonstrating understanding, documenting a body of knowledge and design of teaching, learning and evaluation. In the context of teaching, it is sensible to use such knowledge maps as the “advance organiser” or signposting originally suggested by (Ausubel, 1963). This usage profile is also suitable for the representation of algorithms and of heuristics.
|
Use case diagrams
|
Conceprocity Use Case
|
Conceprocity use case diagrams are generally similar to UML UCDs but they are extended to show the interaction between an actor and a use case as a specific interaction element. This is done because such interactions normally need to be implemented, sometimes as form and subform hierarchies, sometimes as webpage hierarchies
|
Event-driven process chains
|
Conceprocity EPC
|
Conceprocity event process chain diagrams are generally similar to ARIS EPC diagrams but they are optionally extended by incorporating a specific Data swimlane. The data swimlane is populated by concepts, which may subsequently be implemented as data tables, data views, specific file-types or by webpages. The value of the data swimlane is that interactions between it and other (non-data) swimlanes enable the modelling of the data flows (dataflows) that would otherwise require specific dataflow diagrams (DFDs)
|
E/R Data models
|
Conceprocity E/R
|
Conceprocity Entity / Relationship diagrams follow the conventions established by (Chen 1976) and subsequent work. However, ordinality, cardinality and multiplicity are shown in the Conceprocity / UML style because this is more expressive than Chen’s notation
|
A notion similar to that of usage profile does exist in G-MOT. One usage profile that exists in G-MOT which has no direct equivalent in Conceprocity is that of an ontology builder and the automatic generation of OWL language statements from the ontology model which is so built.
20.3Conceprocity conceptual data structures
In any knowledge representation scheme, it will normally be necessary also to represent data. Table is an attempt at a synthetic view and positioning of Conceprocity within the spectrum of conceptual data structure CDS, here following (Völkel and Haller, 2009) :
Table Conceptual data structures and their associated metadata
-
Technique
|
Metadata
|
Expressiveness, precision and recall
|
Spreadsheets
|
Pragmatic – the meaning of the data is not explicit, but is partially expressed in the natural language semantics of column and/or row headings; and partially in relationships expressed as formulae between cells
|
Potentially very expressive and frequently imprecise or even contradictory. Charting permits visually-arresting representations of some of the underlying data.
|
Relational databases
|
If the data is normalised (Codd, 1971; Date, 2003), then the column headings name sets of atomic (non-divisible) data items. This is deliberately constricting, because human-readable metadata, in the form of a natural language description (name) for each attribute, can be exploited by users as they enquire from the data, enabling precise answers to questions they have. These names can be extended by a data dictionary (which, however, is often not accessible to the end-user of the data in the database).
|
Deliberately very restricted expressiveness. All data is constrained to appear as tables to permit generality and precision of subsequent querying. The results of queries are themselves virtual tables constructed from the original input data.
|
Outlining and Outliners
|
The relative positioning of the items in a hierarchy groups and classifies data; and associates meaning with each group and sub-group. The addition of a grid, as in the products Ecco and InfoQube – see (Gregory, 2010) - permits further structuring and expressiveness.
|
Hierarchies themselves are cognitively powerful or not depending on the prior training of the user.
|
Mindmaps
|
The relative positioning of the items in a diagram groups and classifies data; and associates meaning with each branch and sub-branch. An image is (potentially) associated with each branch or sub-branch
|
Visually very powerful, the user perceives both structure and meaning. Querying is very imprecise or non-existent.
|
Concept maps (Novak and Cañas, 2008)
|
The relative positioning of the items in a diagram groups and classifies data; and associates meaning with each branch and sub-branch.
|
Visually very powerful, the user perceives both structure and meaning. Relationships are distinguished from concepts. Querying is very imprecise or non-existent in current implementations.
|
XML, RDF and OWL
|
The meaning of an XML document is described in an associated Data Type Definition (DTD) or Schema. The RDF Schema carries this forward.
|
XML-based approaches potentially combine the strengths of outlining and of relational database. Because XML is both a language and a meta-language, it is possible to define specialised languages such as OPML.
Generalised query languages for XML data are emerging. RDF makes possible the expression of simple forms of knowledge (as opposed simply to information), and supports processes like:
-
User-specified keyword classification of information structured in accordance with user design
-
Rule-based auto-classification
-
Tagging
|
Conceptual graphs or conceptual structures
|
These are discussed in section §5 above.
|
Tbs
|
Conceprocity maps
|
The relative positioning of the items in a diagram groups and classifies data; and associates meaning with each branch and sub-branch. An image is (potentially) associated with each branch or sub-branch. Each object has a type, as does each relationship (link). Appropriate use of hierarchy enables encapsulation.
|
Visually very powerful, the user perceives both structure and meaning. Querying is currently non-existent but because objects are semantically classified it would be relatively straightforward to construct a dictionary for each Conceprocity map and a lexicon (index) across multiple maps.
The latter in a cloud context might permit the emergence of shared ontologies, especially if the maps are constrained to conform to RDF and OWL standards. The latter is not yet proposed for Conceprocity but has been achieved with extensions to the similar G-MOT approach. See (Paquette, 2010)
|
First order logic and Horn clauses
|
|
Expressiveness and precision very high; readability and visual appeal very limited (although these can be enhanced by the use of libraries which create visualisations from Prolog statements). Querying is very general and strong logical inferencing capabilities are offered
|
Share with your friends: |
