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
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
- Use of plurals, as in "tools".
- Use of verbs, as in "involves" (considering the way relations should be
read/interpreted, using verbs does not make sense).
- Use of an uppercase for the first letter, as in "Specialization".
- Use of "_" before "of", as in "part_of" (instead of "part of").
- Use of space within a relation name, as in "previous task".
- 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").
- Use of inadequate relation names, as in "formal_definition" with a destination
that is not a formal definition.
- 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.
- 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
- Use of plurals, as in "improvement_rules".
- 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.
- Use of abbreviations, as in "admin_methodology".
- Use of an uppercase for the first letter, as in "Automation".
- 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
- Use of "_" (to connect words) within quoted strings, as in "the_act_of_..."
(why doing so since the quotes already group the words).
- Beginning a string by an uppercase and ending it by a dot, as in
"The workflow ... .".
- 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
- Use of ";" instead of "," (note: ";" is used only at the end of all relations
from a concept).
- Absence of the ending ";".
- Use of ":" directly after a concept.
- Use of "," (instead of spaces) between relation destinations.
- Use of unknown syntax as in
(what could that mean?).
- 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 ...".
- 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
- Repetitions of stuff from my summary, as in
workflow acronym: WF and
triggering object: trigger.
- 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 ).
- 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
- Relations not indented (there should be at least 2 spaces before a relation name).
- Use of only one space between different destinations for a same kind of
relation, as in
business_process_redesign 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".
element: price (??) product (??) service (??)
- Use of a space between a relation name and ":".
- 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.
- If there is enough space for two relation destinations on a same line (with the
correct indentation), put two rather than one.
- 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).
- 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).