"a data interchange format should be easy to read and understand with a simple editor
by trained people"
opposition: "a data interchange format is for data exchange between machines and
hence does not have to be read directly by people" (pm),
specialization: "a knowledge interchange format should be easy to read and
understand with a simple editor, by trained people" (pm),
argument: "any argument for using XML or any other textual notation
rather than a binary format" (pm),
objection: "any argument for using a binary format rather than XML or any other
textual notation" (pm);
"a knowledge interchange format should be easy to read and understand with
a simple editor, by trained people"
argument: ("it may be cumbersome or inadequate to have to call
translators/viewers/editors from some programs"
argument: ("having to use translators/viewers/editors when writing or
reading emails is cumbersome or impossible"
argument: "this is obviously true when reading/writing
emails through a text-only interface (telnet,
ssh, putty, simple mailers, etc.)" (pm)
)(pm)
)(pm),
argument: "developing/debugging translators/viewers/editors for a knowledge
interchange format is much easier if the format is easy to read" (pm),
argument: "documents about the translation from/to the knowledge interchange format
are easier to write if the format is easy to write" (pm),
argument: "flexible translators/viewers/editors are difficult to program" (pm),
argument: "a translator/viewer/editor good enough for all users, kinds of knowledge
or purposes may not be available or freely available" (pm),
argument: ("a good notation and a good text editor are often more convenient to use
than XML/graphic/... editors"
objection: ("no linear (textual) representation can scale up"
opposition: "for people's understanding purposes, only
a concise linear (textual) notation may
scale up" (pm)
)(fg),
objection: "textual representations are mastered only by developers
or other technical people" (fg,
objection: "graphic-based representation are not better 'mastered' by
non-technical people than textual representations" (pm),
objection: "textual representations does not prevent the use of
tools (structured editors, graphic viewers, etc.) but
XML-based/graphical-based representations force the
use of additional tools" (pm))
)(pm),
argument: ("for various reasons (e.g. to avoid the numerous issues related
to translations), people have/tend to write directly in the
knowledge interchange format"
argument_by_authority: "the authors of KIF regret not to have
understood this earlier and come up with
a more intuitive notation" (pm)
)(pm);
"for people's understanding purposes, only a concise linear (textual),
notation may scale up"
argument: ("graphic notations are not concise enough to be scalable
for people's understanding purposes"
example: "natural languages are not graphic" (pm),
example: "most programming languages are not graphic" (pm),
example: "flow charts have been abandonned in favor of pseudcode
because they were far less practical/scalable" (pm),
argument: "scalability for people's understanding purposes requires
as much information as possible to be seen without having
to scroll or browse" (pm)
)(pm);
"scalability for people's understanding purposes requires as much information as
possible to be seen without having to scroll or browse"
argument: - "scalability for people's understanding purposes requires many quick
comparisons of information" (pm)
- ("synthesis/comparison of information not accessible at a glance is
tedious and limited"
example: "having to browse through a translation dictionary to
understand the words of sentences in a foreign language
make the sentences much harder to understand than if
the translation of each word or sentence is given after
each word or sentence" (pm)
)(pm);