Formalizing, Organizing and Evaluating Cooperation Related Tasks, Instruments, Rules, Best Practices and Evaluation Measures ______________________________________________________________________________________________

Dr Philippe A. MARTIN

Table of Contents (to hide/reveal titles of 3rd/4th level subsections, click 3rd or 4th)

0. Introduction, General Definitions (incl. Abbreviations)

0.1. Purpose and Approach

Purpose. In this $doc, `cooperation' refers to the interaction of `Agents' (people, organizations, animals, software agents, ...) for increasing the satisfaction of their `Preferences', e.g. their goals. A competition may be seen as a cooperation where the goal of each of the agents is to win other the other ones. One possible meaning of "collaboration" is that of a cooperation between agents interacting toward a same goal. In this document, such sub-notions are not relevant: the only purpose is to compare, categorize and formalize different tasks and supports to cooperation, and only those that are related to information sharing or exploitation. This is why i) the next section focuses on information sharing and its supports, and ii) the section after the next section focuses more on information exploitation and its supports.

Approach. To compare, categorize or formalize tasks and their supports, criteria and (formal) knowledge representations (KRs) are used.
These KRs are structurally isolated from the rest of the document in order to be easily automatically distinguished from it. Thus, this document can be seen as a static knowledge base (KB), i.e. a static file that stores KRs, and it can be used as an input static module for a bigger KB. The parts of the documents that are not KRs can be seen as informal ways to annotate, explain, index or modularize these KRS. Conversely, some KRs may be seen as ways to precise the meaning of some informal parts.
At each level of the structure of this document, each section ending by "0." introduces or defines the notions needed by all its subsequent sections, hence not the notions which are specific to sections of a lower level and thus defined in the first of these sub-sections.
Textual parts in a smaller font, including in KRs, are not important for understanding notions in other sections.

0.2. Short Informal Introduction to Knowledge Sharing (KS) and Knowledge Representations (KRs) (Then This Document Defines its Notions in a Formal or Semi-formal KRs)

0.2.1. Some Preliminary Informal Definitions About KS/KRs

Agent: (group of) person(s) or software.
Information: knowledge or data.
Knowledge: abbreviation for "knowledge representations" (KRs) which is defined below.
Data: information not viewed/exploited as KRs (even if they happen to be KRs).
KRL: abbreviation for "knowledge representation language", a formal or semi-formal logic-based language used for creating KRs.
Information repositories: either dynamic (i.e. accessible via a software handling queries) or static (i.e. static files), and either shared (i.e. created by several agents) or personal.
Database (KB): collection of data.
Knowledge base (KB): collection of KRs.
Ontology (KB): KB containing only relations between types, i.e. only full/partial definition of types ("relation" and "type" are defined below).
Ontology-like KB: KB containing mostly relations between types.

Information sharing: i) creation (by one or several agents) of information – or information repositories – that can be accessed by these agents or other ones, or ii) direct communication of information by an agent to another agent.
Knowledge sharing (KS): representation, storage and sharing of KRs.
OKS (Ontogical Knowledge Sharing / Ontology-oriented KS / Ontology-like KB sharing / Ontology sharing): representation, storage and sharing of ontology-like KBs.
Like information sharing, KS is cooperating. This article focuses on ontology based cooperation. Creating KRs for ontology sharing has different constraints that creating them for a particular application. E.g., for ontology sharing, the more expressive the used KRL the better:

for a particular application, a KB built for ontology sharing purposes can be reused even if the application does not need particular expressive KRs or cannot handle them since these KRs can be filtered out or partially translated into KRLs of lower expressiveness;
for ontology sharing, any expressiveness restriction in the used KRL may lead knowledge creators not to represent some important information or represent them in various informal or incorrect ways, and this may prevent some applications to deliver some results or will lead some applications to deliver incorrect results.

0.2.2. External document About KRLs in General, And FL in particular: Definitions, Conventions, Notation And Abbreviations

The content of this external document must be understood before reading the rest of the present document. The above hyperlink opens in a new window so that you can access its content quickly when reading the present document.

0.2.3. Parsing Commands For This Document

The KRs or commands in this document are embedded within special HTML tags – specifically, <KR> and </KR> – to distinguish them from the informal text. Since parsers like the FL parser can then ignore the informal text, this document can be considered as an input/backup/presentation file for some KRs about cooperation.
This file is currently not (an input+backup+presentation file for) a part of the Multi-Source Ontology (MSO) but reuses parts of its top-level.

Parsing commands for this document:

no default shared KB; //create a new private KB: do not add the next KRs to the default shared KB import http://www.webkb.org/kb/it/theKB_categs.html //import the top-level of the MSO no redundancy warnings; //do not warn about redundancies (e.g. with parts of the MSO) default creator: pm#en; //each KR (e.g., each relation) and each identifier that does not have an // explicitly represented creator (e.g. each identifier without prefix) // - are implicitly created by "pm" ("pm" is an abbreviation for // "phmartin3_@_gmail.com" as defined in the MSO top-level), and // - each of these identifiers are in English and their definitions given // by "pm" are compatible with at least one common meaning of these // identifiers in English (at least according to "pm") assumption: unique_name //what is not related by equal relation may be assumed different open_world; //what is not specified may still be true

0.3. External document: Upper Ontology

0.4. Rules: Default Generic Ones, Attributes, etc.

0.4.0. Terminology (should, must, may; cf. also 0.3.[1.2.3] and 0.3.[3.4.1])

/* In this document, the following keywords – whichever their capitalization – are to be interpreted as described in RFC2119: "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY" and "OPTIONAL". https://tools.ietf.org/html/bcp14 https://www.rfc-editor.org/info/rfc2119 */

0.4.1. Default Generic Rules For Particular Kinds of Things

"To achieve a particular state (e.g. a state with particular attributes), an Agent must use a tool (method, instrument) that permits to reach this state". OKS => ... rwx spec-c for old terms <=> spec-c for old+new terms <=> spec-c for old+new phrases + corr for contrad <=> new term/phrase not implicitly redundant/contrad by spec <=> maximal org/inf/checking/comparability wrt. spec and KRs minimal org to permit to permit a) no loss of organization; b) each term addition can be at its most precise place) (but duplic/map of parts of the spec hierarchy still possible) ***without this unique place, 1) people are not guided to put at unique place can put objects at different places**** 2) comparability is at the heart of all inferences

0.4.1.1. For Processes

must have all participants represented must maximize participant cooperativeness and adequation to goal and versatility/flexibilility (it should not matter ...) with graceful degradation

0.4.1.2. For Instruments

ali abdourazak, valerie hareaou, B. leger

0.4.1.3. For Agents

Optimally-cooperative_agent attribute: only an At-least-optimal_cooperativeness, agent of: only a ^(Process attribute: an At-least-optimal_cooperativeness).

0.4.2. Attribute Expressing or Valuating the Following of a Rule

0.4.2.1. Valuating the Percentage of Objects Following an ODR-NG

ODR-G-R_attribute_derived_from_an_ODR-NG_relation //declared in Section 0.3.[3.2.2] .(ODR-NG_checked_relation ?ODR-NG_checked_relation, ?ODR-NG_input_relation, ?objectType) ?as /^ Ratio-based_information_sharability, := [?as value: div_( cardinality_( { (^o1 member of: (the KB ?kb i_attr: ?as), type: ?objectType, ?ODR-NG_checked_relation: {?ODR-NG_input_relation,?kb,?objectType,?kb}) } ) cardinality_( { (^o member of: ?kb, type: ?objectType ) } ) ) ].

0.4.2.2. Valuating Rule Following wrt a Maximum

0.4.3. Attribute Expressing Aggregations of Rule Followings (general rule: aggregation of ++/^ should be ++/^; cf. 0.3.[3.4])

the evaluation of something (technique/software/KB/...) should be ++/^ //positively correlated to / increase with having * the ++/^ from the number of relations(possibilities) that it provides: - ++/^ if proved to be better than others, and more than - ++/^ if statistically preferred more than others

0.4.3.1. Valuating wrt Priorities Over Rules

0.4.3.2. Aggregations Rule Following wrt a Maximum

Completeness_with_respect_to_a_world_or_a_specification_for_something_useful //0.3.[3.2.2] \. Representation-completeness_with_respect_to_a_world Completeness_wrt_specification-or-constraints

1. Information Sharing Objects

1.1. Introduction

1.1.1. Information Sharing&Representation Processes and Some Relations From Them

Here are some subtasks, subtypes and instruments of information sharing.

Information-sharing_related_process \. e{ (Information-sharing_per-se \. ne{ (Information-repository_creation-or-update object: 1..* Information_repository, \. (Information-repository_export output:1..* Information_repository) ) (Information_communication object: 1..* Information) }, predecessor_situation: Information-sharing_predecessor-task ) (Information-sharing_predecessor-task \. e{ (Information_collecting part: 0..* (Information_retrieval part: 1..* Information_comparison) ) (Information_creation part: 0..* Information_import 0..* Information_copy 0..* Information_merge ) } ) (Information-sharing_in_its_general_sense part: Parts_partition { 1..* Information-sharing_per-se 1..* Information-sharing_predecessor-task } ) } e{ (Knowledge_sharing_related_process object:=> only KR, \. (Scalable_knowledge-sharing_related_process ?p = Scalable_information-sharing_related_process, :=> [ [?p output: an Information_repository ?ir] => [?ir type: Knoexus] ] ) (Data_sharing object:=> only Data) }, object: 1..* Information, instrument: 0..* Information_repository.

any Information-Technology_task //e.g. accessing/exploiting KRs attribute: 0..* IT-task_attribute, //e.g. Accessibility, Security, Performance input: 1..* Description_instrument, instrument: 1..* Description_instrument, //e.g. (the Software of) a Web_server output: 1..* Description_instrument.

Interestingly, most of the evaluation of Information Sharing processes can be reduced to the evaluation of the description instruments and containers they use.

To understand these objects and their relationships, see Section 3 of the external document "Upper Ontology"). Here are the main kinds of description instruments:
- representation models (logics, programming models, language model components, data structures) and abstract elements following them;
- representation notations and abstract+concrete elements following them.
Here is an example of relations between various description ojects (in this example, the default quantifier 'any' for relation source nodes is left implicit).
^"content-representation of John's car" descr_instrument: 1..* (^"abstract elements representing John's car" descr_instrument: 1..* (^"concrete elements used for representing the abstract elements representing John's car" descr_container: 1..* ^"description container that includes concrete elements used for representing the abstract elements representing John's car" ) ).
The description content itself, once represented via description instruments, can be refered to from the result via converses of description_content relations. By doing so, most notions related to knowledge sharing can be represented only as description instruments or containers, which eases knowledge representation and evaluation about knowledge sharing (e.g., description content oriented or process oriented versions of these notions do not have to be represented too).
This explains the order of the next sections: 1.2 Description Content, 1.3-1.5 Description Instruments, 1.6 Description Containers.

1.1.2. Information Sharing&Representation General Rules

1.1.2.1. ODR-NG "For OKS, information accessibility should not depend on the description instrument (model, notation and presentation) and container used for representing/storing them"

1.2. Description Content for OKS (Ontological Knowledge Sharing): the More Complete (with Better/Preferred relations → Precise, Organized, ...), the Better

Knowledge-content_sharability /^ Description-content_sharability Knowledge_sharability, \. (Knowledge-content_completeness \. (Knowledge-content_comparability-or-uncomparability annotation: " 'comparability-or-uncomparability' is cumbersome but makes it clear that the case 'not known to be comparable or uncomparable' is excluded " ) ). //the next function is not directly related to (subtypes of) sub#comparable-or-uncomparable_via // and defines attributes based on its arguments: object_comparability-or-uncomparability_to_other_objects .(?objType, ?relTypes, ?comparability_relation, /*optional*/?kb) -% ?a /^ ODR-NG_attribute Knowledge-content_comparability-or-uncomparability, annotation: //next line: cf. Section 0.4.2.1 "from any ODR-NG_attribute, a sibling ODR-G-R_attribute can be derived", :=> [ [ [?kb != Undefined, !type: Type] :=> [any ^(?objType attr: ?a, member of: ?kb) ?comparability_relation: {?relTypes,?kb,?objType,?kb} ] ] [ [?kb type: Type] :=> [any ^(?objType attr: ?a, member of: a ?kb ?aKB) ?comparability_relation: {?relTypes,?kb,?objType,?aKB} ] ] [ [?kb = Undefined] :=> [any KB ?anyKB [any ^(?objType attr: ?a, member of: ?anyKB) ?comparability_relation: {?relTypes,?kb,?objType,?anyKB} ] ] ] ]. //application examples are in the next subsections ODR-NG_checked_relation .(?x, {?relTypes, ?kb, ?objectType, ?inKb}) \. comparability_relation.

1.2.0. Methodology For Genericity And Organization

delay choices but accumulate/share as many constraints possible, ASAP non-constraints (non-restrictive choices), so genericity !predef interesting_for(?thing,?agent)=> must be accessible_by(?thing,?agent) complet pour la spec, les sous-parties and/part/subtype partition informal lists should be partitioned/organized Every type should be in at least one partition <= "" Most important constraint: 1 place to add anything in the existing network, i.e. partition-complete for every rel. In knowledge engineering, object-oriented paradigm (UML, OCL) has also interesting features that can be used in knowledge representation to avoid inconsistency problems. Postdoc "Qualification of semantic models using constraints verification" Ouassila Labbani Narsis ouassila.labbani@u-bourgogne.fr Christophe Nicolle cnicolle@u-bourgogne.fr Distributed Knowledge and Artificial Intelligence Laboratory (CIAD: Laboratoire Connaissance et Intelligence Artificielle Distribuees) - EA7533

1.2.1. OKS - Completeness wrt. Particular Relations (esp. transitive ones) and Their Negations [menus]

Click here for an article explaining the interests of the ODRs of this subsection.

1.2.1.0. ODR-G-NR "For OKS, the more (asserted or negated) relations between the objects of a KB (esp. transitive relations), the better"

1.2.1.1. ODR-NG "For OKS, from each object and each declared/transitive/definable-with/specialization relation type usable as relation type usable for a relation from this object, there should be an "(un-)o_comparability/connectability via this relation type" to "each / at least one other object" (+ that defines a partition / is in a knoexus / ...) with, when required, i) at least 1 destination set that is complete and/or disjoint for this relation, and ii) a minimal/full differentia between the destinations in/from each destination set"

1.2.1.1.1. Functions

object_comparability-or-uncomparability_to_other_objects //defined in Section 1.2 .(?objType, ?relTypes, ?comparability_relation, /*optional*/?kb) -% ?a \. (object_comparability-or-uncomparability_via_special_relation-destination-sets .(?objectType, relTypes, //the next comparability rel. type is defined in Section 1.2.1.2.3: comparable-or-uncomparable_via_special_rel-destination-sets_and_for ?cmp_rel, ?kb) -% ?a := object_comparability-or-uncomparability_to_other_objects _(?objectType, ?relTypes, ?cmp_rel, ?kb) ) (object_comparability-or-uncomparability_to_each_other_object .(?objectType, relTypes, //the next comparability rel. type is defined in Section 1.2.1.2.3: comparable-or-uncomparable_to_each_other_object_via-and-for ?cmp_rel, ?kb) -% ?a := object_comparability-or-uncomparability_to_other_objects _(?objectType, ?relTypes, ?cmp_rel,?kb) ).

1.2.1.1.2. Example Attributes

object_comparability-or-uncomparability_via_special_relation-destination-sets //fct defined above .(?objectType, relTypes, comparable-or-uncomparable_via_special_relation-destination-sets_and_for ?cmp_rel, ?kb) -% ?a \. //example attributes (this subtype link implies that an attribute is a kind of 0-ary function): (object_comparability-or-uncomparability_to_other_objects_via_at-least-1-spec-partition ?a := [?a = object_comparability-or-uncomparability_to_other_objects _(Type,cSpec,comparable-or-uncomparable_via_at-least-1-spec-partition_and_for, (the KB ?kb member: (the object i_attr: ?a)) )] ) (^"object_comparability-or-uncomparability_to_other_objects via_at-least-1-closed-set-of-subtypes" ?a := [?a = object_comparability-or-uncomparability_to_other_objects _(Type,cSpec, comparable-or-uncomparable_via_at-least-1-closed-set-of-subtypes_and_for, (the KB ?kb member: (the object i_attr: ?a)) )] ). object_comparability-or-uncomparability_to_each_other_object //fct defined in Section 1.2.1.2.1 .(?objectType, relTypes, comparable-or-uncomparable_to_each_other_object_via-and-for ?comparability_relation, ?kb ) -% ?a \. //examples: (^"object_comparability-or-uncomparability_to_other_objects via specialization relations in the KB that includes the object" ?a := [?a = object_comparability-or-uncomparability_to_other_objects _(Type,gSpec,comparable-or-uncomparable_to_each_other_object_via-and-for, (the KB ?kb member: (the object i_attr: ?a)) )], = (^"Attribute for an object from which the number of specialization relations or their negations is maximal in the KB (which is nice since such relations are important for inferencing, are commonly exploited by inference engines)" = ^"Attribute for an object wrt which detected comparable-or-uncomparable objects (→ detected redundancies or contradictory beliefs) can be either avoided or related and then managed via these relations" ) ) (^"object_comparability-or-uncomparability_to_each_other_object via specialization relations in any knoexus that includes the object" ?a := [?a = object_comparability-or-uncomparability_to_other_objects _(Type,gSpec,comparable-or-uncomparable_to_each_other_object_via-and-for, (any ^(Knoexus member: (the object i_attr: ?a))) ) ] ) (^"object_comparability-or-uncomparability_to_each_other_object via definition_member relations in the KB that includes the object" ?a = Knowledge-content_definability-or-undefinability, := [?a = object_comparability-or-uncomparability_to_other_objects _(Thing,definition_member, comparable-or-uncomparable_to_each_other_object_via-and-for, (the KB ?kb member: (the object i_attr: ?a)) )] ). /* more direct definitions (→ not using the generic function object_comparability-or-uncomparability_to_each_other_object): equivalent_or_definable-with \. p{ equal_or_equivalent definable-with } p{ (comparable-to_via_subtype_relation \. p{subtype supertype equal_or_equivalent} ) (definable-with_but_not_comparable-to /^ definable-with) }. uncomparable-to_via_subtype_relation := !comparable-to_via_subtype_relation, //reminder: '!' is the open-world not \. p{ (uncomparable-to_via_subtype_relation_and_not-definable-with /^ !definable-with) (uncomparable-to_via_subtype_relation_but_definable-with /^ definable-with) }. */

1.2.1.1.3. Comparability Relations

comparable-or-uncomparable_via_special_relation-destination-sets_and_for .(?x, .{?relTypes, ?kb, ?objectType, ?inKb}) /^ comparability_relation, := [ [?x (^r member of: ?relTypes): {1..* ?objectType ?d} ?ds ] ]_[description_content-or-instrument-or-container: ?inKb], \. (comparable-or-uncomparable_via_at-least-1-spec-partition_and_for := [ [?x (^r member of: ?relTypes): Spec-partition {1..* ?objectType ?d} ?ds ] ]_[description_content-or-instrument-or-container: ?inKb] ) (comparable-or-uncomparable_via_at-least-1-closed-set-of-subtypes_and_for := [ [?x (^r member of: ?relTypes): Closed_set_of_specializations_for_a_same_thing {1..* ?objectType ?d} ?ds ] ]_[description_content-or-instrument-or-container: ?inKb] ). comparable-or-uncomparable_to_each_other_object_via-and-for .(?x, .{?relTypes, ?kb, ?objectType, ?inKb} ) = either_equivalent-or-connected-to_or_different-and-un-connectable-to_via-and-for, /^ comparability_relation, := [ [^y member of: ?kb, != ?x, type: ?objectType] => [?x comparable-or-uncomparable_via: .{?y,?relTypes} ] ]_[description_content-or-instrument-or-container: ?inKb], \. (connected_or_un-connectable_to_each_other_object_via-and-for .(?x, .{?relTypes, ?kb, ?objectType, ?inKb}) := [ [^y member of: ?kb, != ?x, type: ?objectType] => [?x directly-connected_or_un-connectable_via-and-for: .{?y,?relTypes}] ]_[description_content-or-instrument-or-container: ?inKb] ) (comparable-or-uncomparable_to_each_other_object_with-minimal-differentia_via-and-for .(?x, .{?trRelTypes, ?kb, ?objectType, ?inKb}) := [ [^y member of: ?kb, != ?x, type: ?objectType] => [?x comparable-or-uncomparable_with-at-least-minimal-differentia_via-and-for: .{?y, ?trRelTypes} ] ]_[description_content-or-instrument-or-container: ?inKb] ).

1.2.1.1.4. Helper Relations

comparable-or-uncomparable_via-and-for .(?x, .{?y, ?relTypes}) := [ [^r member of: ?relTypes] => [?x comparable-or-uncomparable_via: .{?y, ^r}] ], \. (connected_or_un-connectable_via-and-for .(?x, .{?y, ?relTypes}) := [ [^r member of: ?relTypes] => [?x connected_or_un-connectable_via: .{?y, ^r}] ] ) (comparable-or-uncomparable_with-at-least-minimal-differentia_via-and-for .(?x, .{?y, ?relTypes}) := [ [^r member of: ?relTypes] => [?x comparable-or-uncomparable_with-at-least-minimal-differentia_via: .{?y,^r}] ]). comparable-or-uncomparable_via .(?x, .{?y, ?r}) //at least weakly (un-)comparable //def. generalized from those of core-specialization_exclusion and part_exclusion in // Section 0.3.[2.1] := [ OR_{ [?x equal_or_equivalent: ?y], //e.g.: ?x = ?y, ?x <=> ?y [?x connected_or_un-connectable_via: .{?y, ?r}] } ], \. (connected_or_un-connectable_via .(?x, .{?y, ?r}) := OR_{ [?x ?r: ?y], //e.g.: ?x \. ?y, ?x part: ?y, ?x |. ?y [?x ?r of: ?y], //e.g.: ?x /^ ?y, ?x part of: ?y, ?x |^ ?y [?x !?r: ?y], [?x !?r of: ?y] } ) //reminder: `!' is open-world_not (strongly_comparable-or-uncomparable_via .(?x, .{?y, ?r}) := [ [?x comparable-or-uncomparable_via: .{?y, ?r}], [ [?x !equal_or_equivalent: ?y] => OR_ //warning: the next line is ok with gSpec but not (exactly) with cSpec_excl { [ [^ix type: (^sx ?r of: (?x type: Type)), //e.g.: ?x cSpec_excl: ?y != (^iy type: (^sy ?r of: ?y)) ] => [ [?ix != ?iy] [?sx != ?sy] ] ] [ [^ix cSpec of: (^sx ?r of: (?x !type: Type)), //e.g.: ?x part_excl: ?y != (^iy cSpec of: (^sy ?r of: ?y)) ] => [ [?ix != ?iy] [?sx != ?sy] ] ] } ] ] ) (comparable-or-uncomparable_with-at-least-minimal-differentia_via .(?x, .{?y, ?r}) //generalization of genus&partial-differentia via subtype relations := "?x is comparable-or-not_to ?y and either ?x = ?y or they differ by at least 1 relation of a type != ?r" [ [?x comparable-or-uncomparable_via: .{?y, ?r}] [ [?x !equal_or_equivalent: ?y] => OR_{ [ [?x (?r2!=?r): a ?z] [?x not ?r2: a ?z] ] [ [?y (?r2!=?r): a ?z] [?x not ?r2: a ?z] ] } ] ] ).

file:///home/phmartin/public_html/cours/ws/km_tr.html#meta-ontology

1.2.2. OKS - Completeness wrt. the World That Is Represented: the More Complete (→ Precise, ...), the Better

Completeness_with_respect_to_a_world_or_a_specification_for_something_useful //0.3.[3.2.2] \. Representation-completeness_with_respect_to_a_world Completeness_wrt_specification-or-constraints

1.2.2.0. ODR-G-NR "For OKS, the more objects (relations, ...), the better"

Absolute-number-of-internal-relations_based_information_sharability /^ Internal_information_sharability Not-ratio-based_information_sharability, \. p{ (Absolute-number-of-lexical-relations_based_information_sharability //Text LexicalRel: (k < 2**avgNbOfLetterByWord)*nbWords ) (Absolute-number-of-non-lexical-relations_based_information_sharability //StructuralRel=!LexicalRel: nb_direct-or-indirect_subsection-relations ) } p{ (Absolute-number-of-relations-in-ontology-part_based_info_sharability ) (Absolute-number-of-relations-in-fact-based-part-relations_based_info_sharability ) }. /* DB/KB A-box: LexicalRels: k*(nbIDs + nb_type+name-relations) actual: nb_direct-or-indirect_type-relations_from_individuals + nb_direct-or-indirect_non-type-relations_between_individuals potential: min: nb_type-pos/neg-relations_from_individuals max: pos/neg-relations_from_individuals_wrt_actual+derived_rel_definitions (incl. imported ontol. minus the numbers for the imported ontol.) T-Box LexicalRels: k*(nbIDs + nb_name-relations) actual: nb_direct-or-indirect_relations_between_types potential: min: nb_type+subtype(+part)-pos/neg-relations_between_types max: nb_pos/neg-relations_between_types_wrt_actual+derived_rel_definitions (incl. imported ontol. minus the numbers for the imported ontol.) */

1.2.2.1. ODR-NG "For OKS, each term should be from a (proto-)'knoexus' (Section 1.6.7) and hence the KB should be a knoexus or the new terms should be defined in a (proto-)knoexus"

decision should be in a knoexus for accountability

1.2.3. OKS - Completeness wrt. Representation Meta-models: the More, the Better

1.2.3.0. ODR-G-NR "For OKS, the more distinctions from representation meta-models or fundational ontologies are re-used (when possible), and the more explicit the representation commitments are), the better"

1.2.3.1. ODR-NG "For OKS, at least well-known distinctions (e.g. those from common 'fundational ontologies' such as Onto-UML) should be followed (cf. "(+ that ...)" in Section 1.2.1.1 to enforce that)"

http://oscaf.sourceforge.net/ :nepomuk DOLCE, ... schema.org

1.2.3.2. ODR-NG "For OKS, in a private/shared KB, the commitment that each knowledge provider has chosen to follow should be formally specified, e.g. via global constraints or author-specific constraints"

1.2.4. Examples of Global Constraints For ODR-NGs

1.2.4.1. Example of global constraint for checking that a relation type declared as mandatory is used whenever the relation signature permits it: "If a relation type ?rt has for type Mandatory_out-relation-type and is source a leaf_objectType relation with destination a type ?destLeafType then each object instance of the domain of ?rt and not instance of ?destLeafType should have an ?rt relation" (+ the counterpart constraint for Mandatory_in-relation-type should also be specified)

1.2.4.2. Example of global constraint for checking that if a relation of a particular general type is used, this relation actually has a more specialized type: "If a relation has for type a type ?rt source of a mandatory_more_precise_type relation with destination a type ?rt2, then ?r must also be of type ?rt2"

1.3. Description Instruments for Representation Models: the More Organized and Translatable, the Better

eval: for any Description Content, the most high-level() yet translatable way, hence Normalizing e.g. p{...} instead of OR_{...}, numerical quantifiers, sets (!binrel) shortcuts for important distinctions, e.g. natural type, gSpec. ...

1.3.0. Panorama: Non-symbolic, Symbolic But Unstructured, DB-like, KB-like

Moved to Section 3.2.6 (Composite Information Objects) of d_upperOntology.html.

`Composite-information-object_not_structured_by_any_semantic_relation attr: a 0-10pc_fit Description-instrument_completeness' <= `...//to do; //inclure l'estimation de connections avec DB, KB, ...' //state what the presence of relations (and freedom to create them) eases/permits Identifiability every Main_object has an (inverse_functional) identifier (Immobilier identifier: Spatial_identifier) (Identifier \. Spatial_ientifier \. GPS_coordinate) Integrability //every Main_object is part of a Knoexus Also for publications ? {minConsist: making sense (contextualized, no contrad" *=/+(betterFor) Inference*=Accessib minCompleteness: *=/+(betterFor) InfoAccessibility min2sentence: integrable: formal intersentential rel, "should"should=*better\.fct min2CT: excl, spec, sig, part / atLeast1otherRel(DiffFromSpecExclSig)ToAnyOther(viaParent+siblings) min3RT: def/CT min4ontol: DOLCE, ... } {minUser,minKB,minInterKB} "\." \. excl{"*=" "\_"(corrSpec/nonImgenSpec/ \_. \.. + accessibility -* decentralization + ontology/organization + normalis. SEE BPs As explained in the criteria article, the def. of criteria chrc rel (e.g., correctness) (of the evaluated object) is the primitive //"correct_stuff"" cannot be defined * increasing accessibility \. increasing expl.relations = reducing impl.redundancies \. normalizing \. standardizing replacing adj by nouns := transforming info so that accessibility_degree increases * reaching accessibility = transforming info so that it has 100% accessibility_degree part=* using a standard using nouns @ accessible_info gSpecOrpart:=* (x gSpecOrpartOf: standard/normalized/concise_stuff) @ accessibility_degree:= % of parts being standard/normalized/concise_stuff * (i1 chrc: accessibility_degree) \. (i2 chrc: accessibility_degree) @ "\. for accessibility":= more for all criteria /^ accessibility criteria (Relatedness|comparability|org|understandability|precision //Accuracy Timeliness |irredundancy|1place|!arbitrary|!linearity //conciseness

1.3.1. Programming Language/Instruction/Code Abstract Models

1.3.1.1. Top Kinds of Instructions and Programming Languages

Moved to Section 3.2.2.1 (Programming Languages) of d_upperOntology.html.

1.3.1.2. "For (better/optimal) checking and reuse purposes, any code should be automatically translatable into a declarative code (→ programs should be translatable into pure functions → any function should return 1 and only one result → no exception handling → only the 1st parameter of a function should be modifiable → this parameter should be the environment or have access to it)"

1.3.2. Programming Language/Instruction/Code Concrete Models

1.3.3. OKS - Lexical: Identifiers, Names, Informal Definitions [menus]

1.3.3.0. ODR-NG "For OKS, any identifier should be translatable into an http URI that gives open licensed linked data (ideally, access to a knoexus entry point) for what is identified, in at least one RDF-compatible standard language and/or one that at least one Web service can translate into such languages"

//specialization of Tim Berners-Lee's four principles for Linked Data // and of the 5 principles of Linked Open Data works with 1.2.2.1. ODR-NG "For OKS, each term should be from a (proto-)'knoexus' ... and 1.6.7.1. "Every container should be a view on its underlying KB and should give access to it"

1.3.3.1. ODR-NG "For OKS, any object should have at least one identifier that is in English and that does not use characters other than a-zA-Z0-9-_"

1.3.3.2. ODR-NG "For OKS, any object should have at least one identifier marked as "definitional", i.e. informative enough (hence long enough) for a person not to have to seek the definition of the object to understand its meaning (note: if the identifiers is written in FE-for-identifiers, the definition can also be automatically generated from this identifier)"

1.3.3.3. ODR-NG "For OKS, the words composing an identifier should be automatically retrievable in a dictionary (→ the used language, word aggregation method, and possibly dictionary, should be made explicit if there is an ambiguity)"

1.3.3.4. ODR-NG "For OKS, the initial of any identifier of any individual should rather be in uppercase"

1.3.3.5. ODR-NG "For OKS, any relation type identifier initial should rather be in lowercase"

1.3.3.6. ODR-NG "For OKS, any identifier of any subtype of Class (that is not Thing) should rather include "_class" or "_type" at its end"

1.3.3.7. ODR-NG "For OKS, any concept type for a non-attribute should have at least one identifier that is a nominal expression"

1.3.3.8. ODR-NG "For OKS, only a process type may have an identifier based on a verb"

1.3.3.9. ODR-NG "For OKS, only an attribute may have an identifier based on an adjective or adverb, and only if the attribute has a definition based on a measure wrt. a unit"

1.3.3.10. ODR-NG "For OKS, the type of any object informal definition should be made explicit: "Definition via an informal lambda/kappa-abstraction" or "Definition via relations expressing necessary and/or sufficient conditions" (the second form requires to repeat the name of the defined object and to quantify this object; thus, whenever possible, this form should be avoided to normalize the informal definitions and make them easier to read and write)"

1.3.4. OKS - Use of Collections (and hence of Plurals)

1.3.4.1. ODR-NG "For OKS, to avoid the quantification of collections (and then identifiers in the plural), any collection type should be subtype/supertype of (a type equivalent to) Collection and, when true, of Collection_of_objects_with_the_same_type

1.3.4.2. Corrolary ODR-NG: any subtype of Collection_of_things_with_the_same_type should have a definition stating the type of its members and should not be instantiated/quantified"

1.3.5. OKS - Translation Rules Between Particular Kinds of Abstract_language-element (Information_object)

1.3.5.0. ODR-NG "For OKS, the same canonical representation should be used for equivalent type declarations

1.3.5.1. "from a non-binary relation to a binary one using a list as second argument"

1.3.5.2. "Different structures for Meta-statements"

1.3.5.3. "frames and binaries relations from a same source"

1.3.5.4. "different structures for numerical quantifiers"

1.3.5.5. "some kinds of definitions and some uses of universal quantification with implication or equivalence relations"

1.3.5.6. "... Description instrument ... Function ... Denotation level ..."

1.3.6. OKS - Definitions and Derivations (e.g. When Translation Rules Are Insufficient)

1.3.6.1. ODR-NG "For OKS, any non-binary relation type not handled via a translation rule should be defined wrt. a binary relation type"

Non-binary_relation_type \. p{ (Non-binary_relation_type_defined_wrt_a_binary_relation_type ?nbrt := [any ?nbrt <=> [a Thing ?rt: a Thing] ] ) (Non-binary_relation_type_not_defined_wrt_a_binary_relation_type attr: no PM_scalable_sharability __[<=_ "no Non-binary_relation_type_not_defined_wrt_a_binary_relation_type is comparable with a binary_relation_type" }. @@ PM_scalable_sharability <= comparable_with "between any two objects, a relation of one of the following types or their converses, or the negation of such a relation, should be asseted or inferred" "for knowledge sharing purposes, the less instances (and subtypes) of Non-binary_relation_type_not_defined_wrt_a_binary_relation_type there are, the better" <=_ "a Non-binary_relation_type_not_defined_wrt_a_binary_relation_type is not comparable with "

1.3.6.2. ODR-NG "For OKS, any relation type should be fully defined wrt. a concept type (and preferably generated based on a concept signature)"

"the less subtypes of Relation_type_not_defined_wrt_a_concept_type there are, the better for knowledge sharing purposes; for a PM_scalable_sharability, there should be none" \__ [Relation_type_not_defined_wrt_a_concept_type ?r := [?r derived_relation_type of: 0 Concept_type], attr: a ^(PM_scalable_sharability_increasing_quality type: 0pc_fit) ], <=| "". /* ^\++ (Normalization \. ("using primitive (hence binary RTs)" /^ "using binary RTs", ^\++ ("using process types" + \. ("using binary RTs directly from CTs" /^ "bin RTs", \. "using binary RTs directly derived from CTs, especially role types or types of process" ) ) "following the graph-based reading convention" ) ) ), \. ("type organization" ^\++ ("RT hierarchy small" ^\++ ("using RTs directly from CTs" \. ("using binary RTs directly from CTs" /^ "bin RTs", \. "using binary RTs directly derived from CTs, especially role types or types of process" ) ) ) ). It should not matter that CT are used instead of RTs one term is used instead of equivalent others proc used instead of proc results (-* criteria, 1kb) proc used instead of criteria (see privacy below) */

1.3.7. OKS - Phrase Kinds: Contexts, ...

1.3.7.1. "Context relations should only be ..."

phrase_contextualizing_object-that-is_not-a-phrase ) //Section 0.3.[2.3] phrase-contextualizing_phrase) //Section 0.3.[2.3.1] pm#corrective_extension (pm#description ,pm#description );

1.3.8. OKS - Phrase Additions (→ Beliefs, Edition and Versioning) [menus]

1.3.8.1. "In a KB, a phrase addition should be a. avoided if instead relations to existing non-phrase objects can be added, and otherwise, b. as precise as possible but not decomposable into 'and-related phrases', c. at least semi-formal if of type Phrase_that_cannot_be_successfully_contradicted (i.e. of type Axiom_or_definition, Own_preference or Own_observation), and otherwise d. linked to existing phrases via relations which, by decreasing order of preference (when alternative representations are possible), should be of type - generalization_adding_information, specialization_adding_information or instantiation, or - corrective_phrase (corrective_generalization, corrective_specialization, corrective_exclusion or correction_via_an_alternative), or - logic-argument (formal-or-informal_proof or ^"logic-argument that is not a formal-or-informal_proof but still the destination of an implication"), or - logic-objection (logic-argument negating the source phrase), with the added constraint that corrective relations must be supported by logic-argument relations (and hence that an inference engine may automatically decide whether a phrase is Successfully-supported_and_uncontradicted-or-unsuccessfully-contradicted)"

/* Examples:

"..." <= "..." _[author: ...], //logical argument; must include comparisons/valuations on criteria -<= "..."_[a: ... ], //logical objection; should include comp./valuations on criteria \__ "..." _[a: ..., //specialization; the author still agrees with what he specializes <= "..." _[a: ...] ], c\_ "..." _[a: ..., //corrective_specialization (corrective_restriction) <= "..." _[a: ...] ], c_/ "..." _[a: ..., //corrective_generalization <= "..." _[a: ...] ], cExcl "..." _[a: ..., //corrective_exclusion (corrExcl) <= "..." _[a: ...] ].

*/ semantic_generalizing-phrase_not_inferred_using_this_source .(?p1, ?p2) //introduced in Section 0.3.[2.3.4] and the end of Section 0.3.[2.3.1] \. ^"given rule or a definition (e.g. a supertype relation) enabling generalizations" non-generated_semantic-generalizing-phrase p{ (corrective_generalization \. (corrective_implied_generalization /^ truth_preserving_generalization, annotation: "if an agent adds a generalization ?p2 implied by a phrase ?p1 already existing in a KB, the agent's reason can only be that it/(s)he does not believe in ?p1" := [?p1 truth_preserving_generalizing-phrase: ?p2, phrase_not_inferred_using_at_least_this_source: ?p2] ) non-corrective_generalizing-phrase }. semantic_specializing-phrase_not_inferred_using_this_source //end of Section 0.3.[2.3.1] \. p{ (corrective_specialization \. (corrective_implied_specialization /^ truth_preserving_specialization, = corrective_restriction, annotation: "if an agent adds a specialization ?p2 implied by a phrase ?p1 already existing in a KB, the agent's reason can only be that it/(s)he does not believe in ?p1" := [?p1 truth_preserving_specialization: ?p2, phrase_not_inferred_using_at_least_this_source: ?p2] ) (non-corrective_specializing-phrase \. geneImplicationInv ) }.

1.3.9. OKS - Phrase Evaluation

1.3.9.0. (Successfully/...) Supported/Contradicted/Believed/... Or Not, ...

Argumentation_framework = Set_of_relation_types_exploitable_by_an_argumentation_semantics Set_of_relation_types_exploitable_by_an_argumentation_evaluation_function, /^ Set, \. (Argumentation_framework_with_at_least_one-1st-order_attack_relation_type = At-least-Dung_framework, \. Dung_framework_only ne{ (At-least-Dung-like_framework_with_at_least_one_1st-order-support_relation_type = At-least-bipolar-1st-order_argumentation_framework, \. Bipolar-1st-order_argumentation_framework_only ne{ (At-least-bipolar-1st-order-plus-weights_argumentation_framework \. (Bipolar-1st-order-plus-weights_argumentation_framework_only = Quantitative-and-bipolar-only-argumentation_framework QBAF-only ) ) (Argumentation_framework_with_definable_attack_and_support_relation_types = At-least-abstract-dialectical_argumentation_framework, \. e{ Abstract-dialectical_argumentation_framework_only Mine } ) (At-least-bipolar-1st-order-plus-votes_argumentation_framework = At-least-extended-social_argumentation_framework, \. Mine ) (At-least-bipolar-Nth-order_argumentation_framework \. Mine ) } ) (At-least-Dung_framework_plus_ignorances = Partial-argumentation-framework ) At-least-Dung_framework_plus_preferences-or-values At-least-Dung_framework_plus_probabilistic-values (At-least-Dung_framework_plus_weights = Quantitative_argumentation_debate_framework QuAD, \. At-least-bipolar-1st-order-plus-weights_argumentation_framework ) (At-least-Dung_framework_with_Nth-order_attack_relations \. At-least-bipolar-Nth-order_argumentation_framework ) (At-least-Dung_framework_plus_votes = Social-argumentation-framework, \. p{ Dung_framework_plus_votes_only (More_than_Dung_framework_plus_votes \. At-least-extended-social_argumentation-framework ) } ) } ). Argumentation_related_attribute /^ Phrase_attribute, //nothing new; just a general index \. e{ Argumentation_based_mutually-consistent-set-of-phrases_attribute //evaluation pre-step Attribute_on_argumentation_based_mutually-consistent-set-of-phrases_attribute Argumentation_based_phrase-evaluation_attribute Property_of_argumentation_based_phrase-evaluation }. Argumentation_based_mutually-consistent-set-of-phrases_attribute \. (Conflict-free_semantics = Conflict-free_labelling, \. (Stage_semantics \. Stable_semantics) (CF2_semantics = ???, \. (Stage2 \. Stable_semantics)) (Admissible_semantics \. (Complete_semantics \. Ideal_semantics Grounded_semantics (Preferred_semantics \. (Semi-stable_semantics \. Stable_semantics) ) ) ) ). Attribute_on_argumentation_based_mutually-consistent-set-of-phrases_attribute \. Admissibility Reinstatement Rejection I-maximality Allowing_abstention Crash resistance Non-interference Directionality Cardinality. Argumentation_based_phrase-evaluation_attribute //accepted / rejected = Argumentation-semantics_applied_to_a_particular_phrase, // := Argumentation_semantics .(Phrase, Argumentation_network, Argumentation_framework, ...) -% pc \. (Acception-or-rejection_attribute_for_a_phrase \. p{ (Credulously_justified = Not-full-rejection_value-for-a-phrase, \. p{ (Skeptically_justified = Full-acceptation_value-for-a-phrase, \. (Logical-full-acceptation_value-for-a-phrase = Successful-logic-support_value-for-a-phrase, \. Undefeated ) ) //but no support required for Undefeated (Defensible \. Undecided ) } ) //me: takes supports (not just attacks); not gradual, not ... (Unjustified_even_credulously = Overruled No-acceptation_value-for-a-phrase Full-rejection_value-for-a-phrase Logical-full-rejection_value-for-a-phrase Successful-logic-attack_value-for-a-phrase Successful-logic-contradiction_value-for-a-phrase, \. p{ Provisionally_defeated Defeated_outright//maybe last 2 are here } ) } ) ne{ (Phrase_attribute_expressing_how_the_phrase_is_attacked //contradicted \. p{ (No-attack_value-for-a-phrase \. Undefeated) (At-least-some-attack_value-for-a-phrase ?a := ^(Attribute attr of: an attacked_phrase), \. (At-least-some-logic-attack_value-for-a-phrase ?a = At-least-some-logic-contradiction_value-for-a-phrase, := ^(Attribute attr of: a Logically-contradicted_phrase), \. (Successful-logic-contradiction_value-for-a-phrase := ^(Attribute attr of: a Successfully-contradicted_phrase) ) ) ) } ) (Phrase_attribute_expressing_how_the_phrase_is_supported \. p{ No-support_value-for-a-phrase (At-least-some-support_value-for-a-phrase ?a := ^(Attribute attr of: a Supported_phrase), \. (At-least-some-logic-support_value-for-a-phrase ?a := ^(Attribute attr of: a Logically-supported_phrase), \. (Successful-logic-support_value-for-a-phrase ?a := ^(Attribute attr of: a Successfully-supported_phrase) ) ) ) } ) }. Property_of_argumentation_based_phrase-evaluation = PoAbPE, \. p{ (Purely-logical_property_of_argumentation_based_phrase-evaluation \. jd#Self_contradiction jd#Independence //or "instance:"? ) (Non-purely-logical_property_of_argumentation_based_phrase-evaluation \. jd#Argument_equivalence //near purely logical but structural, not inferential jd#Non-attacked_equivalence (jd#Weak_void_precedence \. jd#Void_precedence) pm#Amgoud12-14-weakening-like_property //more attacks decrease value pm#Amgoud3-strengthening-like_property jd#Attack_versus_full-defense jd#Quality_precedence jd#Ordinal_equivalence (PoAbPE_dependant_of_non-0-or-1-number-of-attackers-or-supporters //boolean \. jd#Counter-transitivity jd#Defense_precedence jd#Cardinality_precedence jd#Addition_of_defense_branch jd#Addition_of_attack_branch Amgoud14#Counting_attackers Amgoud3#Counting_supporters ) (PoAbPE_dependant_of_the_length_of_an_attack-or-defense_branch \. jd#Increase_of_an_attack_branch jd#Increase_of_a_defense_branch ) ) } (Baroni#Group_property_1_of_argumentation_based_phrase-evaluation = Baroni#GP1, := "The strength of an argument differs from its base score only if the argument is the dialectical target of other arguments, i.e. the strength is equal to the base score if the argument is not the dialectical target of other arguments", \. (Baroni#P1 = Amgoud12-14#Maximality) (Baroni#P2 = Amgoud3#Minimality) (Baroni#P3 = Amgoud15#Stability) (Baroni#P4 = Baroni9#Equation4) ) (Baroni#Group_property_2_of_argumentation_based_phrase-evaluation = Baroni#GP2, = pm#Amgoud12-14-weakening-like_property, := "In the absence of supporters, if there is at least an attacker then the strength of an argument is lower than its base score", \. (Baroni#P5 = Amgoud12-14#Weakening) (Baroni#Group_property_3_of_argumentation_based_phrase-evaluation = Baroni#GP3, = pm#Amgoud3-strengthening-like_property, := "In the absence of attackers, if there is at least a supporter then the strength of an argument is greater than its base score", \. (Baroni#P6 = Amgoud3#Strengthening) (Baroni#Group_property_4_of_argumentation_based_phrase-evaluation = Baroni#GP4, := "If the strength of an argument is lower than its base score then the argument has at least one attacker", \. (Baroni#P7 = Amgoud12-14#Weakening_soundness) ) (Baroni#Group_property_5_of_argumentation_based_phrase-evaluation = Baroni#GP5, := "If the strength of an argument is higher than its base score then the argument has at least one supporter", \. (Baroni#P8 = Amgoud3#Strengthening_soundness) ) (Baroni#Group_property_6_of_argumentation_based_phrase-evaluation = Baroni#GP6, := "Arguments with equal conditions in terms of attackers, supporters and base score have the same strength", \. (Baroni#P9 = Amgoud12-14#Equivalence) (Baroni#P10 = Amgoud12-14#Neutrality) (Baroni#P11 = Amgoud3#Equivalence) (Baroni#P12 = Amgoud3#Dummy) (Baroni#P13 = Amgoud15#Bi-variate_equivalence) (Baroni#P14 = Amgoud15#Neutrality) (Baroni#P15 = jd#Non-attacked_equivalence jd#NaE, := "All non-attacked arguments should be equally acceptable.", //=?? ; me too if no attack + no support \. (jd#Argument_equivalence = jd#AE, e: jd#SC, //me too //here? := "If there exists an isomorphism between the ancestors' graph of two arguments, then they are equally acceptable" ) (jd#Ordinal_equivalence = jd#OE, := "Suppose that two arguments, x and y, have the same number of direct attackers; if, for each direct attacker of x, there exists a direct attacker of y such that the 2 attackers are equally acceptable, then x and y are equally acceptable too", \. (jd#Counter-transitivity = jd#CT, //pb??: = Baroni#P33 ?? := "If the direct attackers of y are at least as numerous and acceptable as those of x, then x should be at least as acceptable as y", e: jd#SC, \. AND{CT,OE}) ) ) //:=?? (Baroni#Group_property_7_of_argumentation_based_phrase-evaluation = Baroni#GP7, := "A strictly larger set of attackers determines a lower strength", \. (Baroni#P16 = Baroni9_20prop12#Equation2) (Baroni#P17 = Amgoud7_13_8th5#Void_precedence jd#Void_precedence = jd#VP, //me too := "A non-attacked argument should be strictly more acceptable than an attacked argument", e: jd#*DB, \. jd#Strict_counter-transitivity ) //pb??: for Baroni, SCT is below, not here (Baroni#P18 = Amgoud11#Weak_void_precedence jd#Weak_void_precedence, //=?? \.above?? := "A non-attacked argument should be at least as acceptable as an attacked argument" ) (Baroni#P19 = Amgoud12#Triggering) (Baroni#P20 = Amgoud14#Counting) (jd#Defense_precedence = jd#DP, \. AND{jd#CT,jd#SCT}, //:=? := "If arguments x and y have the same number of direct attackers, and if x is defended at least once whereas y is not, x should be ranked higher than y", \. (jd#Distributed-defense_precedence //??: \. ; + "that" in next line := "A defense where each defender attacks a distinct attacker is better than any other" ) ) (jd#Quality_precedence = jd#QP /*, e: jd#CP*/, := "If x has a direct attacker strictly more acceptable than any direct attacker of y, then x should be strictly more acceptable than y" ) (jd#Addition_of_attack_branch = jd#+AB, //here?? := "Adding an attack branch to any argument decreases its level of acceptability", \. (jd#Cardinality_precedence = jd#CP, e: jd#+DB jd#QP jd#SC, :="If x has strictly more direct attackers than y, then x should be strictly less acceptable than y" ) ) ) (Baroni#Group_property_8_of_argumentation_based_phrase-evaluation = Baroni#GP8, := "A strictly larger set of supporters determines a higher strength", \. (Baroni#P21 = Baroni9_20prop13#Equation3) (Baroni#P22 = Amgoud3#Counting) ) (Baroni#Group_property_9_of_argumentation_based_phrase-evaluation = Baroni#GP9, := "A higher base score gives a higher strength", \. (Baroni#P23 = Amgoud14#Proportionality) (Baroni#P24 = Amgoud3#Coherence) ) (Baroni#Group_property_10_of_argumentation_based_phrase-evaluation = Baroni#GP10, := "A weaker set of attackers determines a higher strength", \. (Baroni#P25 = Baroni#Strict_counter-transitivity_7_13_8th8, = (jd#Strict_counter-transitivity = jd#SCT, e: jd#SC jd#*DB, //SCT here?? := "If jd#CT is satisfied and if the direct attackers of y are either strictly more numerous, or strictly more acceptable than those of x, then x should be strictly more acceptable than y" ) ) (Baroni#P26 = Amgoud12#Boundedness) (Baroni#P27 = Amgoud14#Reinforcement) ) (Baroni#Group_property_11_of_argumentation_based_phrase-evaluation = Baroni#GP11, := "A stronger set of supporters determines a higher strength", \. (Baroni#P28 = Amgoud3#Boundedness) (Baroni#P29 = Amgoud3#Reinforcement) ) (AND{Baroni#GP6,Baroni#GP7} \. (Baroni#P30 = Amgoud12_5prop6#Monotony) ) (AND{Baroni#GP6,Baroni#GP7} \. (Baroni#P31 = Amgoud3#Monotony) ) (AND{Baroni#GP6,Baroni#GP8} \. (Baroni#P32 = Amgoud8#Theorem7) (Baroni#P33 = Amgoud7_13#Counter-transitivity) ) (Baroni#Balance_principle_of_argumentation_based_phrase-evaluation /^ Baroni#GP1 Baroni#GP2 Baroni#GP3, \. (Baroni#Strict_balance_principle_of_argumentation_based_phrase-evaluation /^ Baroni#GP4 Baroni#GP5 ) ) (Baroni#Monotonicity_principle_of_argumentation_based_phrase-evaluation /^ Baroni#GP6, \. (Baroni#Strict_monotonicity_principle_of_argumentation_based_phrase-evaluation /^ Baroni#GP7 Baroni#GP8 Baroni#GP9 Baroni#GP10 Baroni#GP11 ) ) jdAndBaroni#Independence := "The ranking between two arguments x and y should be independent of any argument that is neither connected to x nor to y" ) //?? Amgoud#Bi-variate_independence Amgoud#Bi-variate_directionality Amgoud#Bi-variate_monotony Amgoud#Bi-variate_reinforcement Amgoud#Resilience Amgoud#Franklin Amgoud#Anonymity (jd#Self_contradiction = jd#SC /*, e: jd#CT jd#AE jd#SCT jd#CP*/, := "An argument that attacks itself should be strictly less acceptable than an argument that does not" ) (jd#Attack_versus_full-defense = jd#AvsFD, e: jd#CP, \. AND{jd#VP,jd#QP}, := "A fully defended argument (without any attack branch) should be strictly more acceptable than an argument attacked once by a non-attacked argument" ) //:=?? (jd#Addition_of_defense_branch = jd#+DB, := "Adding a defense branch to any attacked argument increases its level of acceptability", \. (jd#Strict_addition_of_defense_branch /*, e: jd#VP jd#SCT*/, := "Adding a defense branch to any argument increases its level of acceptability" ) ) (jd#Increase_of_an_attack_branch := "Increasing the length of an attack branch of an argument increases its level of acceptability" ) (jd#Increase_of_a_defense_branch := "Increasing the length of a defense branch of an argument decreases its level of acceptability" ) (jd#Total := "All arguments can be compared in terms of argumentation evaluation value"). //as me !AND{jd#AE,jd#SCT,jd#+DB}. /* (NaE //Non-attacked Equivalence (NaE) //me too \. (AE e: SC) //Argument Equivalence (AE) //me too (OE //Ordinal Equivalence (OE) \. (CT e: SC, \. AND{CT,OE)) ) ) //Counter-Transitivity (CT) (VP e: *DB, //Void Precedence (VP) //me too \. (SCT e: SC *DB) ) //Strict Counter-Transitivity (SCT) (DP \. AND{CT,SCT}) //Defense Precedence (DP) (QP /*e: CP*/) //Quality Precedence (QP) (SC /*e: CT AE SCT CP*/) //Self-Contradiction (SC) (AvsFD e: CP, \. AND{VP,QP}) //Attack vs Full Defense (AvsFD) (+AB //Addition of an Attack Branch (+AB) \. (CP e: +DB QP SC)) //Cardinality Precedence (CP) (+DB /*e: CP,*/ //Addition of a Defense Branch (+DB) \. (*DB /*e: VP SCT*/) ). //Strict Addition of Defense Branch (*DB) !AND{AE,SCT,+DB}. */

1.3.10. OKS - Choices Between Alternative Representations

1.3.10.1. "Between alternative representations, the most high-level (concise, expressive, normalizing) should be chosen"

connected-graph-based

1.3.10.2. ???

1.4. Description Instruments For Representation Notations

1.4.1. OKS - Notations

1.4.1.1. ODR-NG "For OKS, any input should use a formal notation that is high-level (concise, expressive, normalizing)"

1.4.1.2. ODR-NG "For OKS, the used notations should offer various kinds of multi-line comments including a recursive one"

1.5. Description Instruments For Presentations

1.5.1. OKS - General Rules About the Used Input/Output Presentations (incl. menus)

1.5.1.1. ODR-NG "For OKS, any output/dynamic/generated presentation should be a fully+dynamically customizable view on the DB/KB (+ if the results of a process are displayed, the steps of this process) and hence should permit the reader to * see/access + copy (no image without alt) all wished relations from/between 1/several wished objects, * choose the used language: - syntactic aspects (KRL model+notation) - structural aspects (linearization, indentation, ...) - lexical aspects (content ontology, language, abbreviations), * choose each presentation detail of each displayed object (color, font, place in window/frame/menu, ...) in a style model (e.g. CSS), event model and, if needed to support the style model, a structural model (e.g. XML, HTML)"

1.5.1.1. presentation instr (server): + should allow annot and stores them in a knoexus* a window shoud never truly forbid to go elsewhere a network of DEs should not be uniquely divided into an hypertext fixed network: the DEs should for example be aggregatable into one document with a TOC a true sequence of DEs (hence a list, not one that does not branch depending on choice) should not be uniquely divided into a forced temporal sequence (e.g. as with forms for collecting data: tests, polls, insurance, ...) the DEs should for example be aggregatable into one document http://semweb.pro/semwebpro-2018.html#p12 12h00 Un navigateur pour le web des donne'es Nicolas Chauvat Logilab https://www.cubicweb.org/card/demo explanatory+safe IA rel/fct explication == rel/fct decomposition, not the concatenation of leaf rel/fct http://www.w3schools.com/tags/ref_colorpicker.asp aqua: #00FFFF http://www.w3schools.com/html/html5_syntax.asp http://www.w3schools.com/html/html5_migration.asp http://www.w3schools.com/html/html5_browsers.asp http://www.w3schools.com/html/html5_semantic_elements.asp G svg events javascript http://tutorials.jenkov.com/svg/scripting.html#event-listeners http://srufaculty.sru.edu/david.dailey/svg/intro/partf_b.html http://svgjs.com/docs/event.html G svg event javascript drag http://interactjs.io/ !!! G svg event javascript drag graph http://bl.ocks.org/cjrd/6863459 Interactive tool for creating directed graphs via d3.js http://jgraph.github.io/mxgraph/javascript/examples/grapheditor/www/index.html http://jasonrowe.com/2012/05/10/svg-movable-node-graph/ G directed graph editor javascript svg http://bl.ocks.org/rkirsling/5001347 http://www.w3schools.com/angular/angular_directives.asp http://www.w3schools.com/jquery/jquery_animate.asp !!!! http://www.w3schools.com/jquery/jquery_dom_add.asp !! http://www.w3schools.com/jquery/jquery_ref_traversing.asp http://www.w3schools.com/jquery/traversing_each.asp http://www.w3schools.com/jsref/dom_obj_event.asp <object> trancludes f(w.add{[int,2],??),...) get+set(attr,value) -> handle erreurs+versions/trace/undo macros if old value must be freed/decremented, do it pragma specifying if string is special or not: sh"oo*", pm"oo**" or bnf"o(o)*" SVG et HTML5 http://jeremie.patonnier.net/post/2010/07/26/SVG-et-HTML5-font-bon-menage-avec-Firefox

1.5.1.2. ODR-NG "For OKS, any input/static/predefined presentation should be coherent with the parameters of a view (on the DB/KB) which - permits its interpretation in a fully formal way, - maximizes clarity for an expert in the used language, - permits its regeneration from the DB/KB and thus its comparison with a new content of the DB/KB"

ODR-NG "For OKS, menus should have at least one default presentation that follows an ontology" menu translation/constraints organized via sem/struct/pres

1.5.1.3. ODR-NG "For OKS, presentation/menus should take into account the user's profile+context/constraints (knowledge, handicap, language, taste, hardware, network, ...) to maximize his/her preferences or the default positive criteria (efficiency, easiness, understandability, ...)"

no crossing line readable \. understandable every action should have an undo no obligation to go back = change context = memory / cognitive overload If (continuous total / partial) order, then always zoomable/aggregable hence no quantity limit

1.5.2. OKS - Rules About Formal/Semi-formal Presentations

1.5.2.1. "???"

1.6. Description Containers (hence about Knowledge Servers, Multi-authoring, Distribution, ...): the More Generic (wrt. Features, Exploited Description Instruments, Users' Preferences), the Better

eval: full exploitation of all Description Instruments

1.6.1. Panorama of Description Containers

Moved to Section 3.3 of d_upperOntology.html.

1.6.2. Security (General Considerations)

//incl. Right-to-Correct-Data) Byzantine fault: Any fault presenting different symptoms to different observers Byzantine failure: The loss of a system service due to a Byzantine fault in systems that require consensus Byzantine fault tolerance mechanisms use components that repeat an incoming message (or just its signature) to other recipients of that incoming message. https://en.wikipedia.org/wiki/Blind_signature A traditional RSA signature is computed by raising the message m to the secret exponent d modulo the public modulus N. The blind version uses a random value r, such that r is relatively prime to N (i.e. gcd(r, N) = 1). r is raised to the public exponent e modulo N, and the resulting value r e mod N {\displaystyle r^{e}{\bmod {N}}} r^{e}{\bmod N} is used as a blinding factor. Accountability incl. via achat, e.g. animal killing decision should be in a knoexus for accountability

1.6.3. Communication Containers

1.6.4. Static File

transclusion iframe //if vertical scroller acceptable; still best sol with HTML https://www.w3.org/TR/html5/single-page.html#the-iframe-element https://stackoverflow.com/questions/5867985/full-screen-iframe-with-a-height-of-100 https://www.w3schools.com/tags/tryit.asp?filename=tryhtml_iframe

1.6.5. Mono-server Private KB

server side apache local: http://192.168.1.73/ www.digitalocean.com/community/tutorials/how-to-install-the-apache-web-server-on-ubuntu-18-04

1.6.6. Mono-server Shared KB

1.6.7. Multi-server (Multi-KB) Shared Virtual KB

1.6.7.1. "Every container should be a view on its underlying KB and should give access to it"

//free domain names: knoexus.online knoexus.co knoexus.site knoexus.org ? Via "Multi-author Virtual|Federated KB" Servers @@ the translator could also be a preprocessor that, according to preferences, extracts compatible statements in a MSO/knoexus @@

1.6.7.1. "Every (proto-)knoexus should ...""

Knoexus /^ KB_with_explicitly_represented_commitment, := "any knoexus ?k of an object ?co (called a commmitment object of ?k) is a loss-less, non-redundant, consistent and internally-complete 'shared-KB server' (alias publically-updatable semantically-organized Web resource) that also i. describes ?co as being one of its commmitment object, using the relation ..., ii. is "restriction-less wrt ?co", i.e. for any information ?i that implies ?co ?k must (accept to) store ?i, iii. is "KR referentially-complete wrt other knoexus on the Web", i.e. for any information ?i2 that ?k does not store, that ?co implies and that implies the commmitment object of another knoexus ?k2, there must be a semantic relation path from ?k to ?k2 (possibly via other knoexus) from ?co to ?k2?k must (accept to) store ?i, iii. is "KR complete wrt the Web and its ?co" i.e stores any public Web KR that implies its ?co, iv. is optionally "restriction-less wrt wrappers for it ?co" i.e. optionnally accepts and run code extracting such information from the Web), and v. allows semantic navigation and at least some semantic querying on its KB", \. Knoexus_of_knoexus := ^(Knoexus object: any 2..* Knoexus); proto-knoexus

1.7. Security of Information Objects

1.7.0. In General

1.7.0.0. Definitions

Process \. (Process_reading-or-updating-or-executing_at_least_1_information_object \. c{ (Process_reading_at_least_1_information_object = ^(Process input: 1..* Information_object) ) (Process_updating_at_least_1_information_object = ^(Process updated_input-or-output: 1..* Information_object), \. c{ (Process_creating_at_least_1_information_object = ^(Process created_output: 1..* Info_object) ) (Process_modifying_at_least_1_information_object = ^(Process intrinsically-modified_input-output: 1..* Info_object) ) (Process_deleting_at_least_1_information_object = ^(Process deleted_input: 1..* Info_object) ) } ) } ) (Process_with_at_least_1_security_attribute \. (Process_respecting_an_action_control_policy \. (Fully_secure_process ?p := ^"Process that 0. is available, reliable, tolerant to faults, gracefully degrading, ..., 1. checks in a secure manner that its inputs+agents+recipients and predecessor+sub processes are secure (authentic, confidential, non-repudiable yet confidentiality/privacy-respecting, up-to-date, validated/sanitized wrt. al their sensitive aspects, ...), and 2. modify/output (enough/timely/...) information in a way that permit other processes to perform such checks; for confidentiality/privacy purposes, this should take into account what readers of these outputs may infer from them (content, place, time, ...) given what they can already know (e.g. about the inputs)" ) ) ) //enough: redundancy, cooperation, checking support, ... (Securing_process \. Authenticating Security-attribute_checking Confidential_message_sending ). attr_type .(Thing ?o, ^(Type type of: Attribute) ?at) := [?o attr: an ?at]. type_with_supertypes_and_attribute-types _({1..* Type} ?ts, {1..* Attribute} ?ats) -% Type ?ot := [?ot type: ?ts, attr_type: ?ats). Action_control_policy = ACP, /^ Phrase_authorizing-or-not_some_actions_on_some_possessions, //Section 0.3.[3.2.4] descr_instrument of:=> a Process_reading-or-updating-or-executing_at_least_1_information_object derived_relation-type: (acp (Thing ?x, ACP ?acp) :=> [?acp descr_instrument of: "what the author of the ACP allows as actions on the info_object to which the ACP is associated"] ), :=> [any ^(Thing ?x acp: (an ACP object: 1..* Thing ?x)) descr_instrument of: [an authorization object: [1..* Process_reading-or-updating-or-executing_at_least_1_information_object object: ?x] ] ]. any Process initiator: 1..* Agent ?initiator, agent_instrument: 0..* Agent ?agent_instr, input: 0..* Thing ?input, output: 0..* Thing ?output.

1.7.0.1. ODR-NG "For security purposes, any software environment should permit agents to state pre/post-conditions/processes about particular kinds of actions on particular objects they own, and then perform these statements. More precisely, anything that can execute/control/check processes making actions ?a (e.g. read/receive-from, write/send-to, execute) on/to things ?t (e.g. agents or information objects/containers such as data structures, variables or files) should 1) before the execution of ?a 1a) collect (directly or via a trusted process) the trustable ACPs (Action Control Policies/rules) directly or indirectly associated to those things and/or actions (e.g. given their types, owners, etc.; incompatible rules should be handled as errors, as noted in 1d below), 1b) check that its inferencing capabilities are sufficient to execute the rules of the trustable ACPs in a complete and consistent way, 1c) for each action ?a, fetch trustable and up-to-date information (about ?a and its participants: agents, inputs, outputs, ...) to check if the trustable ACPs allow ?a or to select relevant methods for ?a (→ pre-conditions/selections/actions for ?a), 1d) perform the pre-conditions/selections/actions within time limits required by the ACPs and then the possible error handling associated to the pre-condition checks (by default, if a check fails or another error is detected, ?a should not be performed, the parent process should be informed of the error and the user should receive a message explaining what went wrong and what are the allowed methods - instantiated to the current situation - to remedy to that), 2) execute (or allow the execution of) ?a if the pre-conditions/selections/actions are successful, 3) perform the post-conditions/actions (e.g. integrity/confidentiality/tracability checks on received objects) and then the possible error handling associated to the post-condition checks"

Action: access+usage effet de bord, reveler existence via error/affichage E/S politique contre politique incompatibe/priority performance: pre-test sequence d'operations � different momments gener? calculateur dans un domaine de confiance 1b examples soft env knows materiel ? generer la 1.7.0.? sur 1b any ^(Agent ?a agent_instrument of: (a Process ?p process_participant: (1..* Thing ?x acp ?r_acp_pa: 0..* ACP ), acp ?r_acp_pr: 0..* ACP ) ) should be initiator of: (a Collecting_of_trustable_and_relevant_ACPs input: {any Thing ?r_acp_pa, any Thing ?r_acp_pr}, output: ({0..* Trusted_relevant_ACP_relations} ?trACPrs part: {0..* Pre_condition} ?trACPrs_preconditions {0..* Post_condition} ?trACPrs_postconditions ) {0..* Good_error_message} ?acpCollectionErrors ), should be initiator of: (an Exploitation_capability_checking input: {?a, ?trACPrs}, output: 1 Exploitation_capability_status ?exploitabilityStatus {0..* Good_error_message} ?exploitabilityErrors), should be initiator of: (a Collecting_and_matching-or-executing_process_participants_with_ACPs input: {?trACPrs_preconditions, ?p}, output: 1 Execution_status ?p1Status {0..* Good_error_message} ?p1MatchingErrors ), should be initiator of: (a Execution_or_error-display input: {?p,?acpCollectionErrors,?exploitabilityErrors, ?p1MatchingErrors }, output: 1 Execution_status ?executionStatus {0..* Good_error_message} ?mainExecutionErrors ), should be initiator of: (a Execution_or_error-display input: {?trACPrs_postconditions, ?p, ?mainExecutionErrors}, output: 1 Execution_status ?p2Status {0..* Good_error_message} ?p2MatchingErrors ). any ^(Agent agent_instrument of: (a Process ?p initiator: 1..* Agent ?initiator, input: (0..* Thing ?input trusted_relevant_ACP ?r_read_acp: 0..* ACP ?acpOfInput) intrinsically-modified-or-deleted_participant: (0..* Thing ?m trusted_relevant_ACP ?r_write_acp: 0..* ACP ?acpOfModified) trusted_relevant_ACP ?r_exec_acp: 0..* ACP ?acpOfProcess ), trusted_relevant_ACP ?r_exec_acp: 0..* ACP ?acpOfAgentInstrument ) should fetch info required by the ACPs, check that they are secured, understand and execute them, should haveBeen/be initiator of: (a read_allowed_checking input: ?r_read_acp) (a modif_allowed_checking input: ?r_write_acp) (a exec_allowed_checking input: ?r_exec_acp*), should execute ?p only if all previous acp checking/executions ok

1.7.0.2. ODR-NG "For accessibility+dependability+security, ideally, any process should (when needed) 0. satisfy any subset of non-conflicting attributes from Quality_increasing_accessibility_and_dependability_and_security selected by a user (e.g. availability, reliability, tolerance to faults, graceful degradation); 1. adapt to the environment of the users (e.g. in terms of network, memory and computing possibilities); 2. permit agents to keep their data on the device they wish instead of asking these agents to put these data on a distant platform (cloud, ...); this may involve a peer-to-peer based solution"; 3. perform checks in a secure manner that its inputs+agents+recipients and predecessor+sub processes are secure (authentic, confidential, non-repudiable yet confidentiality/privacy-respecting, up-to-date, validated/sanitized wrt. all their sensitive aspects, ...); 4. modify/output (not) enough/timely/... information in a way that permits other processes to perform such checks (and report conflicts); for confidentiality/privacy purposes, this last point should take into account what readers of these outputs may infer from them (content, place, time, ...) given what they can already know (e.g. about the inputs)"

point 2 above: couvre action permise par crypto ; volume IRM cloud dans model ou logique applicative ? to what does this refer to ? 0: danger why doing it ? how renforce secu? secu prime sur gracefully degrad, et tolerant to faults d_securing_for_Yves.html BulusuPhD2019.pdf ZHIOUAbefThesisSecuGuidelines.pdf ZHIOUAthesisSecuGuidelines.pdf SEI CERT Oracle Coding Standard for Java MSC62-J. Store passwords using a hash function rwx-protected_function //execute/send and read/reveive \. Flashing_function Ontology-Based Access Rights Management Michel Buffa, Catherine Faron Zucker http://www.w3.org/2001/04/20-ACLs kagal ontology finin joshi REI acp revocation integrity: find if data retrieved generate proof apd data tracability validity duration proof

1.7.0.3. ODR-NG "For security purposes, any process author (user/process) should 0. specify the selected criterias/best-practices/methodology/certifications of this process and its sub-processes and environment; 1. specify all the pre/post-conditions/processes necessary to satisfy the selected security criteria; 2. statically/dynamically check that the selected security criteria are (to a particular probability degree) satisfied (by the information flows)"

* (statically that info flows will be (probably) secure acc. to) selected criterias/best practices/methodo/certifications of his process (incl. env) on 1.7.0.2 or architectural criteria/principles e.g. - Bulusu p75 (sauf certaines dynamic rules for network) - all for zhouia; p.89(prog),94(augm.dependencyGaph),p.95(pLTS) Bulusu p75 rule of integrity via access control