Common errors in the learning journals


Most of the errors noted below are requirements that were not respected. Everyone (except one) has made mistakes related to each of the section below. Hence, I will not point out where in your learning journals you have made the kinds of mistakes that are listed below.

Some of the submitted journals are very short. Most journals focus too much on the chapters in the book; many repetitions with my summary and unfortunately often incorrect interpretations or representations of things that I already represented in my summary! There are a lot of worthy and easier to summarize material in the lecture notes of the first three modules. I have made a 3-page summary of these lecture notes in 2 hours (I'll give it after everyone has submitted his/her final version). In these lecture notes, the lists and the stuff in bold characters are indications of things worthy to be summarized. Also remember to focus on relations from the processes and between the various processes! What must be done in WFM, and how? The more (direct or indirect) relations between the represented concepts, the better (otherwise, it is not really an "organized" summary). Again, this applies to everyone.


1. Bad names for relations

  1. Use of plurals, as in "tools".
  2. Use of verbs, as in "involves" (considering the way relations should be read/interpreted, using verbs does not make sense).
  3. Use of an uppercase for the first letter, as in "Specialization".
  4. Use of "_" before "of", as in "part_of" (instead of "part of").
  5. Use of space within a relation name, as in "previous task".
  6. Use of synonyms to relations I used, as in "performer" (instead of "agent") and "component" (instead of "part" or, in case of a collection, "member").
  7. Use of inadequate relation names, as in "formal_definition" with a destination that is not a formal definition.
  8. Use of very puzzling relations, e.g. "practice_of" and "concept" (what does it mean to say that "a workflow has for concept 'workflow_is_founded_on_...'" or that "an algorithm has for concept 'different algorithms are used ...'"?); in these two examples, "informal_definition" should probably be used instead.
  9. Typos, as in "specilazation" instead of "specialization" (I have seen lots of typos in relation names, concept names and strings; one more sign of carelessness in doing this exercise, and carelessness will be penalized).


2. Bad names for concepts

  1. Use of plurals, as in "improvement_rules".
  2. Use of incomplete/implicit names, as in "primary" (primary what? "primary_process" as in the summary I gave, was probably the intended concept, but since I already gave it, this should not have been repeated), "tactical" (tactical_management), "rhythm" (process_rhythm), "last_in_first_out" (I let you make this one explicit), "once_and_done" (not a concept), "Automation", "stand-alone", "embedded", etc.
  3. Use of abbreviations, as in "admin_methodology".
  4. Use of an uppercase for the first letter, as in "Automation".
  5. Re-invention of name, as in "work_flow" (use "workflow" as in my summary or declare "work_flow" as a synomym).


3. Bad syntax in strings

  1. Use of "_" (to connect words) within quoted strings, as in "the_act_of_..." (why doing so since the quotes already group the words).
  2. Beginning a string by an uppercase and ending it by a dot, as in "The workflow ... .".
  3. Use of "?" instead of double quotes (or single quotes) for around a string (this is likely to come from a bad conversion of a Word document into HTML).


4. Other syntax errors

  1. Use of ";" instead of "," (note: ";" is used only at the end of all relations from a concept).
  2. Absence of the ending ";".
  3. Use of ":" directly after a concept.
  4. Use of "," (instead of spaces) between relation destinations.
  5. Use of unknown syntax as in
      business_process_reengineering
        tools: information_technology_(automation,_informational,_sequential,_tracking,_analytical,_geographical,_integrative,_intellectual)
      (what could that mean?).
  6. Use of a concept without associating at least one relation to it;  on this matter,
      time_signal //"A time milestone or alarm that is reached fires enactment"
      should have been represented as:
      time_signal informal_definition: "a time milestone ...".
  7. New: section titles not isolated from the representations (the representations should be within the HTML tags "PRE" but the section titles should not be within those tags, otherwise a machine would try to interpret these titles as if they were representations and would generate a syntax error).


5. Bad content

  1. Repetitions of stuff from my summary, as in  workflow  acronym: WF  and  triggering  object: trigger.
  2. Wrong relations, as in  work  synonym: process  and  case  result of: work  (here, the notions of "work" and "case" have been mis-interpreted and/or incorrect relations have been used; in the summary I gave, work, case and process are not connected or not directly connected); other examples:  workflow  tool: WFMS  (this should actually be  WFM  tool: WFMS  but it is already in the summary I gave) and  management  performer: WFMS  (once again, this should be:  WFM  tool: WFMS ).
  3. Use of the "part" relations with a destination that is not of the same kind (process, physical entity, etc.) as the source, as in  process_improvement  part: critical_success_factors  (since process_improvement is a process and CSF is not, this part relation is meaningless); I have seen this kind of error quite often! Another example not to follow is:
     assigning_a_task  part: location (??) technology (??);  
    ("??" is used for privacy issues; by the way, the author' initials should rather be in lowercase).


6. Bad indentation

  1. Relations not indented (there should be at least 2 spaces before a relation name).
  2. Use of only one space between different destinations for a same kind of relation, as in
     business_process_redesign
       element: price (??) product (??) service (??)
     Note about this example: "parameter" is better to use than "element", although ontologically and formally this is also incorrect; I have not found a better formal representation in this simple notation; with this notation, using an annotation, as in "//...(??)", is the best way to represent this case but I accept that use of the relation "parameter".
  3. Use of a space between a relation name and ":".
  4. Lines too long: lines should be wrapped (with the correct indentation) so that this file can be printed correctly with a 12 point font in a preformated area (those that do not use the HTML tag "PRE" are invited to do so); this means at most 80 characters per line; however, identifiers (names, URLs) should NOT be cut in half by spaces as this would lead to a meaningless representation.
  5. If there is enough space for two relation destinations on a same line (with the correct indentation), put two rather than one.
  6. Do not have your browser create indentation using plenty of nbsp characters; instead, use what in HTML is called "preformatted text" (HTML tag "pre" or "xmp"; in other words, a chunk of text where spaces are not ignored by the browser).
  7. New: Use of tabulations instead of normal spaces (once again, the use of tabulations often results in bad indentation when the file is copied or opened by another editor that the one it has been created with).