This structured discussion on notations for knowledge representation summarizes advantages and disadvantages of using notations for KR and related tasks: Knowledge Exchange, Knowledge Sharing, Knowledge Retrieval, etc. See the Structured discussion page for details on the goals and notation of structured discussions. (Note: when a statement is hyperlinked (hence, displayed in blue), follow the link to see or add arguments or counter-arguments). This discussion begins by more general statements on verbose/graphic data/knowledge interchange format since the arguments and objections are then inherited (along specialization relations) by some statements on notations and KRLs.
"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);
"a KRL (Knowledge Representation Language) can have an XML notation" extended_specialization: "a KRL should have an XML notation" (pm), argument: ("the data model of a KRL can be stored into a tree-based structure" argument: - "a graph-based model can be stored into a tree-based structure" (pm) - "the data model of a KRL has to be graph-based" (pm) )(pm); "a KRL should (also) have an XML notation" specialization: "the Semantic Web KRL should have an XML notation" (pm), argument: "an XML notation permits a KRL to use URIs and Unicode" (fg, objection: ("most syntaxes can easily be adapted to have object identifiers using URIs and Unicode" argument_by_authority: "this was noted by Berners-Lee" (pm) )(pm)), argument: "XML can be used for knowledge exchange or storage" (fg, objection: "XML is useless or detrimental for knowledge representation, exchange or storage" (pm)), argument: "a KRL may have various notations in addition to an XML-based notation" (pm, objection: "the more notations there are the less one of them is going to be commonly adopted for knowledge exchange" (pm)), argument: "not using XML for a notation implies that a plug-in has to be installed for each syntax" (pm, objection: "XML tools need to be complemented for the semantics of the knowledge representation to be handled" (pm), objection: "installing a plug-in is likely to take less time than always loading XML files" (sowa)); "the data model of a KRL has to be graph-based" argument_by_popularity: "this is acknowledged by about everyone" (pm), argument_by_authority: "this is acknowledged by the W3C" (pm); "XML can be used for knowledge exchange or storage" argument: - "an XML notation permits classic XML tools (parsers, XSLT, ...) to be re-used" (pm) - "classic XML tools are usable even if a graph-based model is used" (pm); "classic XML tools are usable even if a graph-based model is used" specialization: "classic XML tools work on RDF/XML" (pm); "XML is useless or detrimental for knowledge representation, exchange or storage" argument: ("using XML tools for KBSs is a useless additional task" argument: "KBSs do not use XML internally" (pm, objection: "XML can be used for knowledge exchange or storage" (fg, objection: "it is as easy to use other formats for knowledge exchange or storage" (pm), objection: "a KBS (also) have to use other formats for knowledge exchange or storage" (pm))) )(pm), argument: "XML is not a good format for knowledge exchange or storage" (pm); "XML is not a good format for knowledge exchange or storage" argument: - ("XML-based knowledge representations are hard to understand" argument_by_popularity: "this is acknowledged by about everyone" (pm), argument_by_authority: "this is acknowledged by the W3C" (pm) )(pm) - "a knowledge interchange format should be easy to read and understand with a simple editor, by trained people" (pm);
"the Semantic Web KRL should have an XML notation" specialization: "the Semantic Web KRL should have an XML syntax but a graph-based model" (pm); "the Semantic Web KRL should have an XML syntax but a graph-based model" specialization: "RDF should have the current RDF/XML syntax", argument: ("this is for flexibility and normalization reasons" argument_by_authority: "this was noted by Berners-Lee" (pm))(pm), argument: "classic XML tools re-usable even if a graph-based model is used" (pm), negative_consequence: "XML and RDF/XML are partially redundant standards" (pm), objection: ("a subset of XML can be used for representing knowledge" example: "EARL, MPV, RSS" (pm))(pm); "RDF should have the current RDF/XML syntax and model" objection: "the current RDF/XML syntax is arbitrary and hard to understand" (pm), objection: ("the current RDF/XML syntax leads the user to make knowledge representation errors" argument: "the current RDF/XML syntax does not support schema validation languages" (pm, objection: "OWL provides schema validation constructs" (fg, objection: "for expressive knowledge, RDF/XML+OWL (even OWL-full), often leads to ad-hoc/biased/un-reusable representations" (pm))) )(pm), objection: ("the current RDF/XML model is inefficient compared to an XML one" argument: "RDF/XML parsers are 5-20 times slower than XML parsers" (pm) )(pm); "classic XML tools work on RDF/XML" corrective_restriction: "classic XML tools can exploit the tree structure of RDF/XML but ignore its added semantics" (pm, example: "classic XML tools do not take into account the fact that RDF/XML has multiple equivalent serialisations" (pm)); "for expressive knowledge, RDF/XML+OWL (even OWL-full) often leads to ad-hoc/biaised/un-reusable representations" argument: "many common aspects regarding sets and meta-statements can only be represented in an ad-hoc way" (pm), argument: "OWL is a low level language ontology and hence permits things to be represented in many more incomparable ways than when higher levels languages are used" (pm), example: "see http://www.webkb.org/doc/model/comparisons.html" (pm);