Philippe A Martin
email: philippe.martin@univreunion.fr

Jérémy Bénard
email: jeremy.benard@logicells.com

Directly Deriving Binary Relation Types From Concept Types, especially Process or Role Types

Keywords: Knowledge sharing/normalization/matching, best practices, relation type generation

This article proposes an ontology design pattern for leading knowledge providers to represent knowledge in more normalized, precise and interrelated ways, hence in ways that help the matching and exploitation of knowledge from different sources. This pattern is a knowledge sharing best practice that is domain and language independent. It can be used as a criteria for measuring the quality of an ontology. This pattern is: "using binary relation types directly derived from concept types, especially role types or types of process". The article explains and illustrates this pattern, and relates it to other patterns and general ontology quality criteria. It also provides an ontology for automatically deriving relation types from concept types (e.g., those from lexical ontologies such as those derived from the WordNet lexical database). This derivation helps normalizing knowledge, reduces having to introduce new relation types and helps keeping all the types organized.

Introduction

Ontology Design Patterns (ODPs) are "modeling solutions to solve a recurrent ontology design problem" [START_REF] Presutti | Content Ontology Design Patterns as Practical Building Blocks for Web Ontologies[END_REF]. Many ODPs have been found, e.g., about 160 are currently registered in the "ODP catalog at http://ontologydesignpatterns.org" which, in this article, will now be referred to as "ODPC". However, the thousands of ontologies (UML schemas included) that exist are still poorly interconnected and heterogeneous in their design. It is then difficult for people and automated agents to compare or match such independently created knowledge representations (KRs, e.g., types or statements) to know if some KRs are equivalent to others or specializations of others. Thus, it is difficult for people and automated agents to search, align, aggregate -and, more generally, relate, infer from or exploit -KRs or ontologies.

In other words, there is a need for ODPs specifically aimed for knowledge sharing and, more precisely, for solving the problem of leading knowledge providers to create more matchable and reusable KRs. As later detailed, this implies leading them to create more precise, normalized, well related and easytounderstand KRs. In order to be adopted, these ODPs should also be easy to follow and easy to use as criteria for automatically measuring the quality of an ontology, to help developing an ontology or selecting ontologies to reuse. Finally, the ODPs -or, at least the knowledge sharing ODPs -should be well interrelated by semantic relations to help people i) know about them and their advantages, and ii) select those they want to commit to. Then, tools can check or enforce these commitments.

This article proposes such a knowledge sharing focused ODP -which is also a best practice (BP) -and relates it to other ones, via specialization relations and "gradual pattern" relations. This BP, which in this article will now be referred to as ABP, is: "using binary relation types directly derived from concept types, especially role types or types of process". No ODP catalog appears to include ODPs similar to this one or to any of its parts. Like most BPs, it is domain and language independent and it can be used for any dataset. The sections 2, 3 and 4 explain, formalize and illustrate the different parts of ABP. Section 5 relates them to other ODPs and thereby also gives more rationale.

Using Binary Relations

ABP starts by advocating the use of "binary relations" (e.g., "properties" in RDF and OWL). In this article, types that are not relation types (RTs) are refered to as "concept types" (CTs; "classes" in RDF and OWL). The terms "individual" or "concept individual" will be used for things that are not types nor relations.

Since ABP is language independent, this article uses a general terminology, one compatible with those for Conceptual Graphs and RIFFLD [START_REF]RIF Framework for Logic Dialects (2nd edition)[END_REF], the W3C Framework for Logic Dialects of the Rule Interchange Format. For its formal textual examples, this article uses RIFFLD PS, the Presentation Syntax of RIFFLD. Indeed, this notation is both expressive and rather intuitive. In the examples, RT names begin by "r__" and function names begin by "f__". Logical rules are used since RIFFLD is used and since this shows the direction the implications are expected to be used. However, in each case, a logical equivalence could also be used instead.

Following ABP does not prevent using nonbinary RTs as long as definitions or rules are also provided to enable the automatic translation of "KRs using nonbinary RTs" into "KRs using binary RTs". Table 1 illustrates such rules for various kinds of use cases (only the third row is also about the focus of Section 3: deriving a RT from a CT).

One reason why such rules are useful for knowledge sharing is that binary relations can be "compared" while relations of different arities generally cannot (two types or KRs are "comparable" if and only if an equivalence or specialization relation between them has been directly stated or can be inferred). Thus, KRs using binary relations can be ordered by generalization relations, typically, implications. This is more difficult with KRs using relations of different arities, thus reducing possibilities for knowledge matching or inferences. E.g., as illustrated by Table 1, many "directly uncomparable" relations of different arities can be translated into binary relations of type r__list_of_surrounding_entities (which uses a list). Then, they can be "compared".

Table 1. Examples of how to define a given RT with respect to other types (the RIFFLD PS notation is used in the nonhighlighted parts; variables begin by "?"; ":" means "<=")

If you wish to (re)use nonbinary RTs, as in r__spatial_entity_between_3_other_ones ( Jack Joe John Mary ) Exists ?X ( r__spatial_entity_between_2_other_ones (?X Joe John) ) , instead of using binary RTs, as in r__list_of_surrounding_entities ( Jack List( Joe John Mary ) ) Exists ?X ( r__list_of_surrounding_entities ( ?X List( Joe John ) ) ) , then provide ways to translate the 1st ones into the 2nd ones, e.g., Forall ?A ?B ?C ?D ( r__list_of_surrounding_entities ( ?A List( ?B ?C ?D ) )

: r__spatial_entity_between_3_other_ones ( ?A ?B ?C ?D ) ) , since it is then much easier to make inferences, e.g., ?X = Jack and the above 3rd statement specializes (hence implies) the 4th

The above approach also works for contextualizations, e.g., r__listofsurroundingentities_attime ( Jack Joe John DDay ) can automatically be translated into the binary relation r__list_of_surroundingentities ( Jack_at_DDay List (Joe_at_DDay John_at_DDay) ) This cannot be specified in RIF PS but something similar can be: Forall ?A ?B ?C ?time_T ( Exists ?A_at_time_T ?B_at_time_T ?C_at_time_T ( And ( r__list_of_surrounding_entities (?A_at_time_T List (?B_at_time_T ?C_at_time_T) ) r__extended_specialization (?A ?A_at_time_T) r__time ( ?A_at_time_T ?time_T ) r__extended_specialization (?B ?B_at_time_T) r__time ( ?B_at_time_T ?time_T ) ) : r__listofsurroundingentities_attime (?A ?B ?C ?time_T) ) )

Similarly, if you wish to use RTs representing types of processes, as in r__landing ( Joe Omaha_Beach DDay ) r__defining (Joe Square) , instead of using classic primitive binary RTs, as in Exists ?landing ( And ( ?landing # landing // "?i # ?t" <=> instanceOf (?i ?t) r__agent(?landing Joe) r__place(?landing Omaha_Beach) r__time(?landing DDay) ) ) Exists ?defining ( And ( ?defining # defining r__agent (? defining Joe) r__object (?defining "square") ) ) , then provide ways to translate the 1st ones into the 2nd ones, e.g., r__directly_derived_relation ( Landing r__landing ) r__directly_derived_relation ( Defining r__defining ) Forall ?rel ?process ?agent ?time ?place ( And ( r__agent (?process ?agent) r__place (?process ?place) r__time (? process ?time) ) : And ( ?rel ( ?agent ?place ?time ) r__process ( ?rel ?process ) ) Forall ?rel ?process ?agent ?object ( And ( r__agent (?process ?agent) r__object (?process ?object) ) : And ( ?rel ( ?agent ?object ) r__directly_derived_ relation ( ?process ?rel ) ) ) , since it is then much easier to make inferences, e.g., for the statement in the next line, a match for ?X is Joe Exists ?A ( And( r__agent (Landing ?A) r__agent (Defining ?A) ) )

A related reason is that they make more information explicit. Normalizing, precising and supporting knowledge comparability have strong relationships (cf. Section 5).

In practice, with a KR language (KRL) allowing "contexts" and sets or lists, it is easy to avoid the use of relations with arity greater than 2. A "context" (aka "contextualizing statement") is a metastatement specifying restrictive conditions for the contextualized statement to be true, e.g., via temporal relations or modalities. Although RIFFLD PS is not restricted to firstorder logic, it lacks a construct for expressing contextualizations in simple ways, as in KIF [START_REF] Genesereth | Knowledge Interchange Format, Version 3.0, Reference Manual[END_REF] for example. However, the second row of Table 1 shows how simple contextualizations can still be represented -albeit in a rather cumbersome way -using binary relations. To that end, this example uses an adaptation of the ODP named "Context Slices" in ODPC [START_REF] Welty | Context Slices[END_REF]. It relies on introducing "concept individuals within a context" and relating them to their context as well as to their contextindependent counterpart. This is an alternative to the more common approach of reifying a statement and asserting a relation between the reification and the context. With the reification based approach, handling contexts is a bit more difficult when simple KR management tools are reused and extended. Both approaches lead to rather lengthy statements and are adhoc since they require extensions to inference engines to fully handle them correctly. Therefore, for the purpose of knowledge modeling and sharing -as opposed to knowledge exploitation which comes after and may require converting the knowledge into KRLs of reduced expressiveness but which can be handled efficiently -a BP is to i) use a KRL that handles contexts (or use more adhoc concise constructs), and then ii) provide or use rules for translating into the various ways to represent contexts in other KRLs. The same idea applies for the many ODPs that deal with the problems of translating "KRs using high expressive constructs" into "KRs using lower expressive constructs" (e.g., in ODPC, there are many ODP for translations into OWL or from OWL).

It should also be noted that the practical absence of "necessity to use nonbinary relations" is compatible with formal proofs that "besides unary and binary relations, there must exist at least one ternary relation to generate all possible relations" [START_REF] Correia | The Teridentity and Peircean Algebraic Logic[END_REF].

There is no claim here that the idea of "translating nonbinary RTs into binary ones or directly using them" is original. Yet, it should be an ODP for various reasons: i) it is useful, ii) some claims seemingly about the necessity of using nonbinary relations are actually claims about the need for constructs supporting different kinds of contexts (e.g., [START_REF] Zarri | Representation and Management of Narrative Information: Theoretical Principles and Implementation[END_REF]), and iii) this best practice is often ignored by -or unknown to -users of KRLs allowing nonbinary relations.

Deriving Relation Types from Concept Types

ABP advocates the use of -or specifications of translations into -binary RTs "directly derived from CTs". A CT may have multiple "directly derived RTs" if they have "un comparable" signatures (i.e., if none specializes another one). The third row of Table 1 illustrates a way to directly derive a (binary or not) RT from a CT using a rule and a relation of type r__directly_derived_relation. The first two rows illustrate the definitions of nonbinary RTs mainly with respect to binary RTs. This is useful as a intermediary step: the final step -deriving these last binary RTs from a CT (e.g., named "List_of_surrounding_entities") -is not illustrated in Table 1.

When genuine definitions or rules are manually given for each derived RT, as illustrated in the third row of Table 1, the advantages of the approach (over directly using RTs without defining them) only come from the existence of this definition. It makes some information explicit and ensures that every distinction in the (subtype) hierarchy of RTs is also included in the CT hierarchy. This last point is important for two reasons. First, it avoids that some knowledge providers develop distinctions only in the RT hierarchy while others develop distinctions only in the CT hierarchy, thus leading to (automatically) undetected redundancies within a shared knowledge base or in different ontologies. Second, it ensures that any distinction can be used -without loosing knowledge representation and matching possibilities -with both its CT form and its RT form. More possibilities come from the CT form since i) unlike RTs, CTs can be quantified in many different ways (e.g., "3 landings", "all landings" or "8% of landings" can only be described via the CT "Landing", not the RT "r__landing"), ii) it is easier to organize CTs (by subtype relations) than RTs, and iii) the number of used or reusable existing CTs is much greater than the number of used or reusable RTs.

These advantages come for free when the RTs are automatically derived from CTs. Furthermore, doing so permits a system to i) hide the automatically derived RTs in the RT hierarchy (which is then easier to read and grasp), or ii) not actually create them at all. This second option was used in the knowledge server Ontoseek [START_REF] Guarino | Ontoseek: Contentbased Access to the Web[END_REF] and is used in the shared/personal knowledge base server WebKB (www.webkb.org; [START_REF] Martin | Collaborative knowledge sharing and editing[END_REF]). In Ontoseek, any type derived from the nounrelated part of the lexical ontology Sensus could be reused as a CT or a RT. WebKB also reuses a lexical ontology derived from WordNet but only allows the subtypes of certain types to be reused as RTs. This is defined by specifications that users can adapt. More precisely, this is defined by relation signatures which are directly associated to certain toplevel CTs. Table 2 illustrates the approach and then gives rules that would actually generate the derived RTs (the next section complements this framework by giving an ontology of the CTs these rules can be applied to). These rules permit to formalize the framework. They rely on the functions f__type_name and f__denotation_of_type_name which are identical to the KIF functions name and denotation formalized in the documentation of KIF [START_REF] Genesereth | Knowledge Interchange Format, Version 3.0, Reference Manual[END_REF]. In WebKB, no such rules are executed: when a CT is used in places where RTs are expected, WebKB simply checks that one of the signatures associated to the CT is respected and acts as if the relevant derived RT was actually used. Thus, in WebKB, there is no need to use the actual names of the virtually derived RTs: the CT names can be used directly. As in the framework described by Table 2, signatures are inherited along subtype relations between CTs and an error is generated if a CT is associated to two signatures that are "comparable". This approach and ODP seem original.

Table 2. Rules for automatically deriving a binary RT from a CT (and, if needed,doing so for all its subtypes) based on a kind of signature associated to this CT (note: in these examples, the types created by the authors of this article have no prefix to indicate their namespace). ABP advocates the derivation of CTs, "especially role types or types of process". The third row of Table 1 illustrated this for processes. In this article, "process" refers to a "situation" (something that occurs in a real/imaginary region of time and space) that is not a "state", and hence that makes a change. These conceptual distinctions come from the Situation Semantics [START_REF] Barwise | Situation Theory and its Applications[END_REF] and are the basis of John Sowa's first toplevel ontology [START_REF] Sowa | Conceptual Graphs Summary[END_REF]. There are reused in this article for at least the following reasons:

Table 1 gave examples of how a rule can define a RT with respect to a CT. This had to be done for each RT. Here, the approach is simpler. The derived RT does not have to be explicitly defined. Its signature is directly associated to the CT via a relation of type r__signature_for_derived_binary_relation or a function of type f__derived_binary_relation.

Thanks to their definitions, the derived RT is automatically created (see the next paragraph in bold characters). A CT may have different RT signatures associated to it, as long as the signatures are "un-comparable" (i.e., as long as none specializes another

• They are rather intuitive and generalize other well known types, e.g., Perdurant from Dolce [START_REF] Borgo | Ontological Foundations of DOLCE. Handbook on Ontologies[END_REF] is subtype of Process. • They are very adequate for the signatures of thematic relations [START_REF] Carnie | Syntax: A Generative introduction[END_REF], e.g., r__agent, r__recipient, r__cause, r__instrument. Such types can actually be seen as particular toplevel types of relations from a process. • In this article, a "role type" (e.g., Agent, Experiencer, Recipient, Cause, Instrument) is a CT which is defined -or could be defined -as being the range of a thematic RT. This informal definition of a role is a bit more general than what is usually thought to be a role type [START_REF] Mizoguchi | Ontological Analyses of Roles[END_REF] but here it is sufficient: process and role types (as defined here) can be used for deriving CTs into binary RTs. • Thematic RTs or their subtypes can also be used for defining most RTs. Thus, doing so normalizes KRs. • Most statements implicitly or explicitly refer to a process. Representing it, either directly (and then using thematic RTs or subtypes of them) or via RTs directly derived from a process, strongly normalizes KRs. Not doing so, which unfortunately is the case in most ontologies, amounts to loosing precisions and many KR comparison possibilities. Fig. 1 compares CTs usable for directly deriving a binary RT with other types. The common supertype of these CTs is Thing_usable_for_directly_deriving_a_binary_relation. Only its subtypes can be used for deriving binary RTs; this includes types for processes and roles. Fig. 2 illustrates subtype relations between such derived RTs. Fig. 3 displays common toplevel types for relations from a process, most of which are thematic RTs. Fig. 3 reuses toplevel types shown in Fig. 1. All the types in these figures are part of the "MultiSource Ontology" (MSO [START_REF] Martin | Correction and Extension of WordNet 1.7[END_REF]) which is accessible and cooperatively updatable via WebKB. Hence, the names in these figures are names accessible via this server. However, these figures have not previously been published.

The MSO includes more than 75,000 categories (mainly types) and relates them by more than 100,000 relations. It categorizes WordNet types (and their instances) as well as types from various toplevel ontologies (DOLCE included) with respect to the types shown in Fig. 1 or specializations of them. More precisely, about a hundred of toplevel WordNet types and some more specialized WordNet types were manually set as subtypes of those in Fig. 1 or specializations of them. Thus, in the subtype hierarchy of the MSO for "things usable for directly deriving a binary relation", there are currently more than 4800 process types, 2900 role types ("things playing some role"), 650 types of "attributes or qualities or measures" and 240 types of "description content/medium/container". This makes more than 8600 types usable for creating Legend: i) the arrow represents a supertype (subClassOf) relation, ii) by defaut, each subclass set is here a subclass partition, hence its "{disjoint, complete}" UML annotation is left implicit, ii) for namespaces, XML shortcuts are used but type names created by the authors of this article have no prefix, iv) "wn" refers to WordNet, v) "(*)" is the RT signature for any set of arguments, vi) for readability purposes, the boxes around classes (concept types) are not drawn. relations without having to declare new RTs. The 4800 process types can also be used directly with "relations from a process". Finally, the types shown in Fig. 3 for these relations can (implicitly or explicitly) have for subtypes types derived from the 2900 role types. To sum up, the proposed approach and the MSO permit people and automated agents to create KRs that are well normalized, interrelated and comparable. Furthermore reusing the approach and content of the MSO to extend other ontologies is eased by the fact that i) the MSO relates, generalizes and specializes types from various other ontologies, and ii) it can be complemented online via WebKB.

In Fig. 1, the types named Relative_thing and Mediating_thing come from John Sowa's second toplevel ontology [START_REF] Sowa | Knowledge Representation: Logical, Philosophical, and Computational Foundations[END_REF].

To show how rules can be used to associate a signature to a CT and thereby to a derived RT, examples in Table 2 used a process type and the type of "things usable for deriving a binary relation with it as destination". Similar rules can be used for other types of "things usable for deriving a binary relation". Fig. 2 shows how the various relations types -derived or not from CTs -can be related by subtype relations. Organizing relations of different arities is permitted by the use of "*" in the relation signatures: it refers to any number of arguments. In Fig. 2, a signature is shown as an ordered list of commaseparated arguments, within parenthesis. Both KIF and RIFFLD allow relations with a variable number of arguments. However, unlike in KIF, there is no special construct in RIFFLD PS for definitions, hence for signatures. Legend: same as in Fig. 1 plus i) "(*)" is the RT signature for any set of arguments, and ii) because of space restrictions, the name of one of the types is cut in two. ODPC includes the DOLCE+DnSUltralite ontology [START_REF] Gangemi | DOLCE+DnSUltralite, RDF+OWL ontology at[END_REF] as "content ODP" as well as smaller "content ODPs" extracted from it, e.g., "ActingFor" and "AgentRole". Its DnS (Descriptions and Situations) part includes some types which can be seen as subtypes Legend: same as in Fig. 1 plus i) arrows with dashed lines are relations like UML associations, i.e., the source is universally quantified and a cardinality (aka multiplicity) is associated to the destination; here, each cardinality is either "0 to many" or "1 to many", and is left implicit; and ii) comments are enclosed within "/*" and "*/"; "e.g.," is used for introducing subtypes. of those in Fig. 3. It proposes many relations types which could be -but, it seems, are not -derived from process types, e.g., RTs with names such as "actsFor", "conceptualizes" or "defines". Yet, some of its CTs have been aligned with OntoWordNet [START_REF] Gangemi | Restructuring Wordnet's TopLevel[END_REF]. Thus, the ontology and approach proposed in this section (and the previous one) could be used to extend DOLCE+DnSUltralite. This would support more KR comparison possibilities.

Relating to other ODPs

To be adopted, knowledge sharing ODPs should be well interrelated by semantic relations to help people know about them and the criteria or advantages they fulfill, and thus select the ones they want to look for or commit to. Then, tools can check or enforce these commitments, or then retrieve ontologies satisfying them. Thus, ideally, ODPs should at least be organized into categories related by specializations and exclusion relations, as in the hierarchy presented in Fig. 1. However, this is not easy. The most organized of current ODPC or BP repositories [START_REF] Povedavillalón | Reusing Ontology Design Patterns in a Context Ontology Network[END_REF] seems to be ODPC. It organizes its ODPs into a specialization hierarchy with a first level of six categories. Each of them has 0 to 3 sublevels. These six categories and their current content are:

• Content ODP: 101 ontologies, some having only a few types.

• Reasoning ODP: no ODP has yet been submitted in this category.

• Structural ODP: 1 in the "architectural ODP" category (BPs about the structure of an ontology, e.g., the use of subtype partitions, i.e., unions of disjoint types as in Fig. 1) and 13 in the "logical ODP" category (translations between constructs from KRLs of different expressiveness). • Correspondence ODP: 12 in the "Reengineering ODP" category (metamodel transformation rules to create ontologies from structured but less formal and semantic sources) and 13 in the "Alignment ODP" category (they are examples of RTs between two elements from different ontologies). • LexicoSyntactic ODP: 20 linguistic structures for extracting KRs or displaying them (as with a controlled language). • Presentation ODP: no submission of ODP has yet been submitted in this category about the usability and readability of ontologies. It has two subcategories: "Annotation ODP" and "Naming ODP". These categories are not exclusive. An ODP can be placed in several of them. E.g., the ODPs listed in the sections 2, 3 and 4 seem to be architectural ODPs as well as logical ODPs and, for some of them, also Content ODP (like DOLCE+DnSUltralite is). The ODPs in Section 5 are Naming ODPs but are also related to structural ODPs.

Since there are multiple categorization possibilities, different persons will search or add a same ODP in different categories, thus leading to less relations between the ODPs and more undetected redundancies (as noted in the previous sections). This structure also does not lead ODP providers to collaboratively build a finely organized hierarchy or graph of ODPs. Such a structure could be obtained by formally representing each ODP as a process, using a same base ontology, e.g., the MSO (hence with the types shown in Fig. 1 and Fig. 3 as toplevel types). Most of the subtype relations between ODPs could then be automatically calculated. Although this approach would scale well, such a formal and homogenous representation would be a huge work and would require quite motivated ODP providers.

Furthermore, relations to criteria and advantages would still probably not be sufficient since relating ODPs to criteria -or process representing these criteria -is difficult. Therefore, for the ODPs advocated in this article, another approach has been adopted: i) manually setting subtype relations between ODPs (represented as process types when this was possible, and ii) using positive "gradual pattern" relations. Fig. 4 is the result.

These last relations represent rules of the form "the more X, the more Y" ( [START_REF] Ayouni | Mining closed gradual patterns[END_REF] gives a formalization). Arrows with dashed lines are positive "gradual pattern" relations. E.g., the dashed arrow from "keeping the types organized" to "avoiding undetected redundancies" can be read "the more 'keeping the types organized' is achieved, the more 'avoiding undetected redundancies' is achieved".

This last particular rule refers to the idea that was mentioned again two paragraphs ago and which could be rephrased as: "the more a KR (type or statement) has a 'unique place' [START_REF] Dromey | Scaleable Formalization of Imperfect Knowledge[END_REF] in a hierarchy of KRs, the less chances there are that another person will add an equivalent KR in another place". E.g., as opposed to subtype hierarchies, taxonomies relate objects (terms, documents, ...) with relations which are neither typed nor formal. Thus, people use these relations for representing subtypes, parts, instances, agents, etc. This leads to hierarchies that are difficult to search and that often have redundancies. When subtype partitions are used, this is far less the case. This is also far less the case when the hierarchy is automatically built based on the definition of each type. Like subtype relations, gradual pattern relations are typed and transitive. Hence, if used correctly, each KR in them can have a "unique place" [START_REF] Dromey | Scaleable Formalization of Imperfect Knowledge[END_REF], even when such relations do not form a partial order. Indeed, there is no partial order when some relations are bidirectional (there are some bidirectional relations in Fig. 4). However, gradual pattern relations permit less automatic checking possibilities than subtype partitions.

Given the explanations provided in the previous sections, the relations in Fig. 4 should now be understandable. The use of gradual pattern relations between ODPs or BPs is original. The direct setting of subtype relations between them also seems original.

Conclusion

Knowledge sharing is difficult. It implies satisfying many criteria -and following various BPs -which, as Fig. 4 showed, are interrelated. To provide such BPs and ways to follow them, this article focused on the idea of deriving RTs from CTs and showed its relationships to various BPs or ODPs for knowledge modeling and sharing. Some of these BPs or ODPs were already known, several were original. In this domain, most BPs can actually be seen as ODPs. E.g., [START_REF] Povedavillalón | Reusing Ontology Design Patterns in a Context Ontology Network[END_REF] lists the W3C repository of BPs (guidelines, ...) as an ODP repository.

This article also provided various kinds of ODPs. According to the categories of ODPC, these are architectural, logical, content and naming ODPs. However, given their interrelations and the focus on derivation mechanisms, it is also true that this article focused on one ODP.

The proposed BPs and ODPs are applied to -and supported by -the MSO (more than 75,000 categories) which is accessible and updatable via the WebKB shared knowledge base server. Together, they help people and automated agents create KRs that are more normalized, interrelated, comparable and understandable. Furthermore, the multisource nature of the MSO would help applying the proposed content ODPs to other ones such as DOLCE+DnSUltralite.

Finally, the following of the proposed BPs can easily be tested, interactively (as within WebKB) or via SPARQL queries on an ontology (e.g., it is easy to test if each RT is defined with respect to one CT). This makes these BPs usable as criteria for selecting ontologies. This work will be extended by relating knowledge sharing techniques, BPs and criteria (including security related criteria, although represented as processes), via specialization relations and gradual pattern relations, positive ones as well as negative ones ("the more X, the less Y"). The focus will be on representing various approaches to knowledge sharing, e.g., those based on formal documents, those based on collaborative editing within a shared ontology server and those based on knowledge exchange between ontology servers. Thanks to their organization by specialization relations and positive/negative gradual pattern relations, the various kinds of ways to share knowledge and their respective advantages and drawbacks should be clearer.

"using RTs directly derived from CTs" "keeping the RT "using precise statements" hierarchy small" "using binary RTs" "avoiding undetected redundancies" "keeping "using binary "using types "using normalized RTs directly primitive organized" statements" derived "using (hence from CTs" process binary) "using "using types"

RTs precise and easytounderstand "using binary normalized statements" RTs directly "following the statements" derived from CTs, graphbased "using well related and especially role types reading easytocompare statements" or types of process" convention" Legend: same as in Fig. 3 except that arrows with dashed lines now represent positive "gradual pattern" relations (they are explained in the previous page); relations inherited via subtype relations are left implicit (e.g., like those inherited by "using precise and normalized statements"). Fig. 4. Supertype relations and "gradual pattern" relations between the ODP advocated in this article (cf. the name in italic bold characters) and related ODPs.

Fig. 1 .

 1 Fig. 1. Slightly adapted UML representation of a subtype hierarchy to compare the type Thing_usable_for_directly_deriving_a_binary_relation with other types.

Fig. 2 .

 2 Fig. 2. Subtype hierarchy of some relation types derived from subtypes of the concept type Thing_usable_for_directly_deriving_a_binary_relation with other types.

Fig. 3 .

 3 Fig. 3. Examples of common types of relations from a process; most of them are thematic RTs.

are rules that permit such derivations. Furthermore, the derived RTs have the same subtype relations as the CTs they derive from. However, to keep things simple, it is here assumed that no RT with the same name as the derived RT has previously been manually created. The RT name is created by taking the CT name, lowering its initial and prefixing it with "r__". The functions f__denotation_of_type_name, f__type_name, f__cons, f__cdr, f__lowercase used below are identical to their counterparts (without the prefix "f__") in KIF.

  ).

	r__signature_for_derived_binary_relation ( Father List ( Animal Male ) )
	//-> derives the RT r__father that has for domain an Animal and range a Male
	Forall ?t ( r__signature_for_derived_binary_relation ( ?t List ( Thing ?t ) )
	:-?t ## thing_usable_for_deriving_a_binary_relation_with_it_as_destination
	//"?st ## ?t" <=> subtypeOf (?st ?t); this rule derives the expected RT for each subtype of
	// Thing_usable_for_deriving_a_binary_relation_with_it_as_destination
	Forall ?t ?r__t ?t_domain ?t_range
	?t_supertype ?r__t_supertype ?t_sup_domain ?t_sup_range (
	And ( rdfs:domain (?r__t ?t_domain )	rdfs:range (?r__t ?t_range )
	?r__t = f__denotation_of_type_name
	( f__cons ( f__lowercase ( f__car ( f__type_name ( ?t ) ) )
	f__cdr ( f__name ( ?t ) ) )
	?r__t # ?r__t_supertype
	:-And ( ?t # ?t_supertype
	?r__t_supertype = f__ derived_binary_relation
		( ?t_supertype
		List ( ?t_sup_domain ?t_sup_range ) ) )
	)
	:-?r__t = f__ derived_binary_relation ( ?t List ( ?t_domain ?t_range ) ) )
	Forall ?t ?t_domain ?t_range (
	Exists ?r__t ( ?r__t = f__ derived_binary_relation ( ?t List ( ?t_domain ?t_range ) ) )
	:-f__signature_for_derived_binary_relation ( ?t List ( ?t_domain ?t_range ) ) )

Forall ?t Exists ?r And ( ?r = f__ derived_binary_relation ( ?t List ( Agent Object ) ) Forall ?agent ?object And ( r__agent (?t ?agent) r__ object (?process ?object) ) :-?r (?agent ?object) ) :-?t ## Process //-> derives the expected RT for each subtype of Process Here


domain: math info

text:
Philippe Martin
email: philippe.martin@univ-reunion.fr

Jérémy Bénard
email: jeremy.benard@logicells.com

Ea2525 Lim

Creating or Using various Knowledge Representation Models and Notations

Keywords: knowledge representation, importing, translation, exporting and sharing

There are many knowledge representation (KR) languages (KRLs), i.e., many KRL notations and KRL abstract structure models. They suit different needs. E.g., knowledge modeling and sharing require expressive and concise KRLs to support and ease the entering of precise knowledge. Many KRLs are more suited to knowledge exploitation with computational tractability constraints. Current KR-based tools -including KR translators -allow the use of only one or few KRLs, and hardly allow their end-users to adapt these KRLs to their needs, e.g., the need to exploit even ad hoc KRs. Indeed, some systematic ad hoc usages can be automatically interpreted. Finally, it is difficult to compare KRLs and KRs according to criteria or KRL related best practices. The approach presented in this article addresses these problems by answering an original research question: "can KR import or export methods be specified in a generic way and, if so, how can they and their resources be specified?". The approach is based on an ontology of KRLs, hence on KRs about KRLs. It is here named KRLO. It has three original features: i) it represents very different KRL abstract models in a uniform way, ii) it represents KRL notations, and iii) it specifies methods for importing and exporting KRs, and hence also translating them. This article presents principles and uses for this approach. We have built Javascript functions and tools that import and export KRs by exploiting KRLO and a parser generator. For these tools to use new KRLs or KRL presentations, their end-users can add or adapt specifications in KRLO. Other tools can use these tools or functions as Web services or modules. No translator between each pair of KRLs needs to be written. At least for export purposes, KRLO can also be exploited via inference engines for OWL2 or Datalog, or via simple path retrieval mechanisms, e.g., via SPARQL queries.

Introduction

KRLs are languages enabling to represent information in logic-based forms -knowledge representations (KRs) -within knowledge bases. KRs are exploited by inference engines or, more generally, knowledge management (KM) systems, e.g., for precision-oriented knowledge sharing, retrieval or management and for problem solving. The word "KRL" has three meanings. First, a KRL abstract model, e.g., RDF+OWL2 or MOF. Such models are not those of model-theoretic semantics. Second, a KRL notation, i.e., a concrete model or syntax, e.g., Turtle or MOF-HUTN. Third, a combination of the last two, e.g., RDF/XML (i.e., "RDF linearized with XML" abbreviated using "/" as often done by the W3C -World Wide Web Consortium), RDF+OWL2QL/Turtle and MOF/MOF-HUTN. From now on, the word "model" refers to "KRL abstract model". Many KRLs exist. Each suits some constraints or preferences. E.g., for modeling and sharing complex information, experienced KR designers are likely to prefer high-level KRLs. In this article, "more highlevel" means i) "more concise", i.e., requiring "less constructs", and ii) more "normalizing", i.e., better "helping to represent information in automatically comparable ways". Higher-level KRLs are also more expressive. From high-level KRs, lower-level ones can be derived. Ideally, there would exist KRL translators to let KM tools use any knowledge base and, ideally, these tools would let their users select and adapt any KRL they wish for entering and displaying knowledge. This is still far from being the case. There are few KRL translators and most translate only between few notations associated to one standard model, e.g., the translators based on the OWL API [START_REF] Horridge | The OWL API: A Java API for OWL ontologies[END_REF]. Furthermore, these KRLs are not high-level, as illustrated in Section 2 and by [START_REF] Guizzardi | On the importance of truly ontological representation languages[END_REF], and these tools do not translate between some different ways these KRLs are used [START_REF] Beek | A web observatory for the machine processability of structured data on the web[END_REF] (Färber et al, 2015).

To solve those problems and enable KM tool developers to avoid the lengthy task of implementing import, export or translation features from/to every model and notation, i) we have created KRLO, an ontology of KRLs, i.e., we have created KRs representing KRLs and helping to represent or exploit KRLs, and ii) we have developed Javascript functions and tools exploiting this ontology. KRLO has at least two original features: i) it represents -and enables people to represent -very different models in a simple and uniform way, and ii) it includes specifications for notations. KRLO and its associated tools solve the following original research problem: can generic "KR import or export methods" be specified and, if so, how can they and their resources be specified? Here, "generic" means "usable for any specified KRL". Since KRLO is only about KRLs, it can help aligning or merging ontologies only if they use different KRLs. Because of space restrictions and the target audience -i.e., KM interested people, not KR focused researchers -this article is a synthesis article: it describes principles and gives examples. The content of KRLO, its associated Javascript tools and an extension of this article are accessible from http://www.webkb.org/kb/it/o_knowledge/o_KRL/. WebKB-2 [START_REF] Martin | Towards a collaboratively-built knowledge base of&for scalable knowledge sharing and retrieval[END_REF], a shared ontology server, enables Web users to extend our version of KRLO and hence share their extensions of it. Alternatively, people may copy KRLO onto their computers and adapt it to their needs. In the context of a collaboration with us, they can also do so with our tools. Section 2 introduces KRLO and its associated tools. It also gives examples of KRL translations, thus of KR imports and exports. Section 3 introduces the principles of our approach. Section 4 presents our validation methods, the kinds of use cases for our approach, and comparisons to other works.

Examples of content and uses of KRLO

IKLmE, a model to define complex constructs

To define some of its types, KRLO first specifies IKLmE: "IKL model and Extensions based on it". IKL [START_REF] Hayes | IKL guide[END_REF]) is a KRL designed for interoperability: it has the classical First Order Logic (FOL) semantics but still permits the use of many constructs of Higher-Order Logics (HOL). E.g., IKL gives a well-defined semantics to meta-statements that are contexts, i.e., "statements specifying conditions for their embedded statements to be true". Using the primitives of IKL, IKLmE also defines types helping to represent complex statements. Thus, as Table 2 will illustrate, IKLmE can be used to complement any model for representing KRs that require HOL-like FOL-compatible constructs. E.g., IKLmE defines different kinds of meta-statements and numerical quantifiers. IKLmE answers the following research problem: how to represent common HOL constructs using only a small set of binary relations. To complement RDF, the W3C proposes the OWL2 ontology which declares types for constructs belonging to various description logics (w3.org/TR/owl2-profiles). However, before IKLmE, no model ontology existed for HOL-like constructs.

Methods in KRLO and associated tools

KRLO specifies a generic method for importing KRs in a given KRL and another one for exporting KRs in a given KRL. These method specifications are logic-based and thus could potentially be exploited by inference engines. Tools doing so could let their end-users dynamically adapt method specifications, not just KRL specifications. However, at least for KR parsing, these tools would likely be very slow. Thus, we have not yet validated this part. Instead, we have implemented these methods in Javascript. The resulting functions and tools can be used as Web services or modules in other tools.

Translation examples

Table 1 illustrates translations on a simple statement: its expressiveness is covered by OWL2-QL (w3.org/TR/owl2-profiles). It includes two "links", i.e., "triples or property instances" in RDF terminology (w3.org/RDF), "binary relations" in some other graphbased KRL terminologies [START_REF] Sowa | Conceptual Structures: Information Processing in Mind and Machine[END_REF] and "binary predicates" in FOL. For readability purposes, link type names begin by "r_" and are in italics, and we use the terminology, normalization conventions and basic link types of [START_REF] Sowa | Conceptual Structures: Information Processing in Mind and Machine[END_REF]. E.g., the names of the concept types -i.e., in FOL, the types of elements that can be linked by predicatesbegin by an uppercase and are nominal expressions. Thus, links of the infixed form "X r_y Z" or of the prefixed form "r_y (X, Z)" can be read "X has for r_y Z", while a link of the form "X r_y of Z" can be read "X is r_y of Z". The FE [START_REF] Martin | Knowledge representation in CGLF, CGIF, KIF, Frame-CG and Formalized-English[END_REF] notation makes this reading explicit. The FL [START_REF] Martin | Towards a collaboratively-built knowledge base of&for scalable knowledge sharing and retrieval[END_REF] notation enables the writing or presentation of any number of KRs as a connected graph, with links in prefix, infix or postfix forms. In Table 1, "FOLwDef" refers to "FOL with definitions". With the first four notations, FOLwDef is indicated as model since these notations have the syntactic sugar to support it and since using it leads to higher-level KRs than using link types from OWL2-QL. Four of the notations are mainly prefixed: Peano-Russel, KIF (Knowledge Interchange Format; logic.stanford.edu/kif/kif.html) and OWL_Functional-style (w3.org/TR/owl2-syntax). The others are mainly infixed. Table 1 uses Turtle (w3.org/TR/turtle) since it is close to JSON-LD (json-ld.org) and reused in SPARQL (w3.org/TR/sparql11-update). English: By definition (of the term "bird"), any bird flies and has at least a wing.

FOLwDef. / Peano-Russel ("/" means "linearized with"):

Bird =def ∀ b ( Bird(b) => ∃ f,w Flight(f) ∧ Wing(w) ∧ r_agent(f,b) ∧ r_part(b,w) )
FOLwDef. / FE: any Bird is r_agent of a Flight and has for r_part a Wing. UML_model / UML_concise_notation: About this notation. The arrow "->" is for a super-type (subClassOf) link. For other links, the arrow " " is used with an associated link type and a destination cardinality when this one is different from 0..*, i.e., 0-N. For concision purposes, boxes around classes (types) and associations (links) are not drawn.

Table 2 uses a more precise statement, still derived from the traditional "(All) birds fly" example. Indeed, not all birds can fly nor constantly fly. Some notations such as FE can directly represent complex statements. For other ones, when some constructs are missing -e.g., in Turtle, those for contextualization and generalized quantification -link types from IKLmE can be used as illustrated in Table 2: see the links of type r_ctxt, r_value or r_quantifier. Via RDF reification and named graphs [START_REF] Carroll | Named graphs, provenance and trust[END_REF], some W3C models support certain kinds of meta-statements but none of them support "contexts" as above defined.

Principles of our approach

Distinguishing and relating potentially useful top-level KRL element types

Existing KRLs were designed with many different viewpoints and assumptions. The toplevel of KRLO organizes types useful for representing KRLs into a well-integrated whole. It already includes over 900 types, organized via alternative or complementary partitions and other semantic relationships. Each KR being a description of something, and each description having a "semantic content" and an "instrument", KRLO first distinguishes and relates types for these notions. For uniformization purposes, KRLO only offers types for description instruments plus one relation type to link them to their description content counterpart types. The distinction between description content and description instrument is not made in other ontologies of KRLs. However, SBVR -the ontology of the OMG (Object Management Group; omg.org) for "Semantics of Business Vocabulary and Business Rules" (omg.org/spec/SBVR/1.0) -has some types specific to each of these categories. Then, KRLO represents types for languages, i.e., models and/or notations, and for language elements. It distinguishes abstract elements (AEs) from concrete elements (CEs). A CE is a notation element, e.g., an infix or prefix representation for an AE. An AE may be i) a formula, i.e., something denoting a fact, ii) an abstract term -i.e., something denoting a logic object -e.g., a value, a variable and a function call, or iii) a symbol, e.g., one for a quantifier, variable or constant. References -e.g., variables and function callsare defined to be usable only where the AEs they refer to can be used. Each particular model is a selection and specialization of some of these AE types. E.g., models not allowing meta-statements do not include types for references to formulas. This specialization based approach enables people to organize types for models, notations and AEs, and to compare them. This also reduces the amount of specifications to write.

Representing abstract structures in a uniform function-like way

In KRLO, for uniformization purposes, the structure of an AE is represented like the structure of a function, i.e., as an operator with an optional set of arguments and a result. Hence, in KRLO, the most important relation types usable as primitives for linking AEs are named r_operator, r_argument and r_result. The first two are subtypes of r_part. Thus, the structure of a relation is defined to include as operator a relation type, as arguments a list of AEs and as result a boolean. E.g., the structure for the relation "r_part (USA Iowa)" has as operator r_part, as arguments USA and Iowa, and as result True. Similarly, the structure of a quantification statement is defined to include as operator a quantifier, some arguments and as result a boolean. A function is defined to have a type as operator, some arguments and a result. A variable or an identifier is (partially) defined to have as operator a name, as arguments an empty list of AEs and as result an AE of a certain type. Being an operator is only a structural role that different kinds of elements may have. Representing the structure of a formula is not asserting it. In RDF, this is the difference between asserting a statement and reifying it. [START_REF] Euzenat | The 'family of languages' approach to semantic interoperability[END_REF] view "translating between AEs" as applying one or several procedural or declarative "translation operators", each satisfying a "translation property". In KRLO, each AE type definition relating it to another AE type by a logic "equivalence" or "implication" link can be exploited as a translation operator: the translation properties are the logic "equivalence" or "implication". E.g., KRLO currently proposes equivalences or implications i) between non-binary relations and binary ones, ii) between different structures for meta-statements, and iii) between some kinds of definitions and some uses of universal quantification with implication or equivalence relations.

Representing concrete specifications using functions, not predefined types

In KRLO the structure of each AE is known. Thence, the presentation of a given AE in a given notation can be specified by composing the presentation of each part of this AE. For textual notations, this composition is often a simple ordering -e.g., in a prefix, infix or postfix way -plus syntactic sugar to delimit some parts. E.g., assume that each AE "?ae" of type "aet" has an operator "o" of type "ot" and two arguments "x" and "y" respectively of types "xt" and "yt", and that for such AEs their CEs in the notation "nt" are the form "ot [x ; y]". Then, with KRLO and FL, the specification for such CEs is: aet ?ae rc_spec: fc_spec_( List( fc_OP_from_(?ae,nt), "[", fc_ARGS_from_(?ae,nt,";"), "]" ), nt, ""); The "c" in the above names means "concrete". Links of type rc_spec relate AEs to specifications of their concrete presentation. Function names begin by "f". Functions are used for concision. Functional relations could be used instead. fc_spec returns a specification for the presentation of an AE in the notation given in its second parameter, i.e., "nt" in the above example. fc_spec concatenates sub-specifications, e.g., those returned by fc_OP_from and fc_ARGS_from. fc_OP_from returns a presentation specification for the operator of its first parameter. fc_ARGS_from does the same but for the arguments of its first parameter. Since these arguments constitute a list, the first parameter of both fc_spec and fc_ARGS_from refers to a list. The third parameter of these two functions specifies the separators to use between the presentation of the elements in this list. Optional spaces are the default (hence the "") and ";" indicates that ";" must be used as separator in addition to optional spaces. Thus, such presentation specifications may be as recursive and flexible as concrete grammars, in addition to being based on AEs and semantic links between them. As an example of flexibility, it is possible to specify that the presentation of some AE parts should be optional or omitted. Inheritance is exploited: a presentation specification is associated to an AE type only if the specification provided by its supertypes is not sufficient. This implies that each specification is a default one: the destination of rc_spec has the numerical quantifier or cardinality "0..1". Thanks to default presentation specifications in the top-level of OKRL, inheritance provides at least one presentation specification for each AE. For each notation, there should not be two direct rc_spec links from AEs of a same type: this relationship is functional. Instead, to specify two alternative kinds of presentations for the AEs of a type "t", two subtypes of "t" must be made explicit and each one associated to a different kind of presentation. Finally, subtyping two types that would provide two alternative specifications must be prevented. Our tools check all this. In the first version of KRLO, instead of using the above described presentation specification method, we began to create and exploit an ontology for the main prefixed, infixed or post-fixed forms that can be used for CEs. The resulting set of "predefined types" for CEs proved unmanageable: there were too many "type names to understand" and "parameters to use" for people to easily read or write such specifications.

Defining types of KR importing and exporting generic methods

The above described uniform representation of AEs and CEs enables the creation of generic methods for importing or exporting KRs. Both kinds of methods take at least a notation type as parameter. KRLO includes some specifications for such methods, along with types for specifying default options, e.g., regarding spaces and indentation. We implemented such methods in Javascript.

Here is the outline of the default generic export method in KRLO. Given an AE, a target model, a target notation and, optionally, a set of translation properties, the method generates a CE for this AE by i) recursively navigating the parts of that AE, ii) selecting and applying the relevant AE translation operators on each of these parts when the target model requires it and if KRLO provides the links to do so, iii) accessing and applying the relevant presentation specification associated to each translated or original part, and iv) concatenating the resulting CEs. This export method satisfies the given translation properties: equivalence or implication. It is complete with respect to what is expressed by KRLO since there is one rc_spec relation for each AE in a given type of notation. KRLO is only for purely declarative KRLs: it does not represent nor take into account any inference strategy. E.g., the default export method may generate rules in an order that leads to infinite loops if they are used with a Prolog inference engine.

Validation, use cases and comparisons

4.1 Validation by round-tripping KRLO and our tools are validated together by ensuring that, for each KRL represented in KRLO, translating KRs to any other KRL of KRLO (complemented by IKLmE if necessary) and translating back the results lead to the original KRs, except for optional white space. For each KRL, the first test is actually simpler: importing and exporting a file of KRs must lead to the same file, except for optional white space. "Each KRL" means "each possible pair of model and notation". The first input file is generated to include at least an instance of each AE type of the tested KRL. Then, the other tests use real-world files in this KRL, especially files from major ontology repositories, e.g., Ontohub (ontohub.org), DBpedia (dbpedia.org), Wikidata (wikidata.org) and YAGO3 (datahub.io/dataset/yago). Finally, KRLO itself is translated from FL to the target KRL -complemented by IKLmE if necessary -and back. Currently, given the implementation stage of our tools, we have not tested all the features of all represented KRLs, only those related to the pairing of the FL, Turtle and JSON-LD notations with RDF+OWL2Full or IKLmE models. However, more features are actively implemented.

Use cases and first comparisons

The next three sub-sections illustrate the kinds of use cases that our approach for importing and exporting KRs can better support than other approaches since i) it relies on an ontology, ii) this one homogeneously represents and relates KRL models, and iii) this ontology includes specifications for notations.

Easing the implementation of tools exploiting KRs written in many KRLs

In WebKB-2, using C++ and a Lex&Yacc-like parser generator, we implemented KR import and export features for several KRLs. For each new KRL, this took several months owing to a lot of hard-to-factor new code and the combinations of an ever increasing number of options. Thus, this was not a scalable approach. Such implementation tasks can be eased by a programming environment generator like Centaur [START_REF] Borras | CENTAUR: the system[END_REF] or, for KR translation purpose, the use of rule based languages such as those of ODE [START_REF] Corcho | A Layered Declarative Approach To Ontology Translation With Knowledge Preservation[END_REF] or QVT (Query/View/Transformation; omg.org/spec/QVT). E.g., Centaur proposed declarative languages for specifying concrete grammars, abstract grammars and rules mapping them. Based on them, Centaur could generate structured editors, parsers, type checkers, interpreters, compilers and translators. However, the above cited rule based languages and those of Centaur are low-level and execution oriented, not modeling oriented: they do not ease the creation and exploitation of ontologies [START_REF] Guizzardi | On the importance of truly ontological representation languages[END_REF]. Thus, with them, as with procedural code, i) small changes in KRL features often lead to important changes in the code, and ii) translations use the direct mapping approach, i.e., from one language to another, between AEs or CEs. This is still not a scalable approach for handling many KRLs.

Enabling end-users of tools to adapt KRLs or the presentation of KRs

Even though we designed FL to be high-level, when modeling knowledge, we often had to extend it for creating or presenting high-level KRs and thus also ease our task. End-users of tools other than our own can do so only in limited ways. E.g., even though the Model Driven Engineering tool BAM (Feja et al, 2011) was designed to handle several KRL models and notations, its meta-model is predefined, not ontology-based; hence, for model and notation extension purposes, BAM only proposes macros and informal annotations. End-users of tools other than our own also cannot adapt a KRL to ad-hoc ways it is used. Yet, if KRs created by a person or generated by a tool systematically include a same incorrect or ad hoc usage pattern with a certain KRL, the specification of this KRL can often be extended for the pattern to be correctly interpreted. Such extensions would enable people to exploit or better exploit existing resources. E.g., [START_REF] Beek | A web observatory for the machine processability of structured data on the web[END_REF] reported that only 37.6% of Datahub resources for Linked Data are fully machineprocessable. Several tools propose rule based and/or style-sheet based transformation languages for RDF, e.g., SPARQL Template [START_REF] Faron-Zucker | STTL: A SPARQL-based Transformation Language for RDF[END_REF]. These tools enable their users to specify how RDF AEs may be presented, e.g., in a certain notation, in a certain order, in bold, in a pop-up window, etc. However, these tools and languages were not meant to use ontologies for models or notations: they are RDF-based and require the use of a new stylesheet for each target notation. It seems that no ontology other than KRLO includes specifications for notations, hence that no tool other than our own exploit such specifications. Most current KRL translators are for notations usually associated to RDF or OWL, e.g., EasyRDF (easyrdf.org/converter) and those based on the OWL API. Unsurprisingly, their Web interfaces or APIs propose very few options to parameter their import and export of KRs.

Comparing and evaluating KRLs or KRs according to criteria or best practices

This requires a homogeneous ontology of KRLs. Evaluating the structure of KRs also requires a tool that can parse them and i) perform commands on AEs for these KRs, or ii) export these AEs, i.e., their structures, in a given target KRL. This last case, which is possible too with our tools, enables the use of another inference engine to check KR structure related criteria or best practices. This may for example be useful for selecting KR resources or checking the skills of students in KM.

Other works based on an ontology of KRLs

The main ones are described below. Unlike KRLO, the ontologies of such works are only about AEs of one or few particular models, and do not represent AE structures in a uniform way. They were only meant for translating models, not notations. Ontolingua (Gruber, 1993) also was for translation purpose but did not represent models, even though it included definitions for types similar to those of OWL2. [START_REF] Euzenat | The 'family of languages' approach to semantic interoperability[END_REF] used XSLT (the Extensible Stylesheet Language for Transforming XML documents; w3.org/TR/xslt) to implement about 40 translation operators or relations between AEs from 25 description logics. The LATIN (Logic Atlas and Integrator) Project (2009-2012) [START_REF] Codescu | Project Abstract: Logic Atlas and Integrator (LATIN)[END_REF] represented translation relations between different logics. LATIN has been exploited via HETS (Heterogeneous Tool Set; hets.eu) or MMT (Meta-Meta-Theory; uniformal.github.io). Both HETS and MMT handle various logics and inference engines for reasoning purposes, e.g., OWL and HOL logics. Neither export knowledge in KRLs different from the ones they were imported with. Via DOL (Distributed Ontology modeling Language; omg.org/spec/DOL), the OMG proposes a meta-KRL for i) specifying particular kinds of translation relations between KRL models, and ii) using several KRLs in a same DOL document. HETS can handle DOL. ODM 1.1 (Ontology Definition Metamodel; omg.org/spec/ODM), an OMG specification of 2014, uses UML for representing four KRL models: RDF, OWL, CL and Topic Maps. Between AEs of these models, it sets some semantic relations such as generalization or equivalence relations. It gives some direct mappings between AEs of different models but via QVT rules, hence not in ways that can be directly used by inference engines. Since direct mappings are used instead of few types as primitives for defining and relating the various AEs, the heterogeneity of the various models is not eliminated.

Conclusion

This article has shown that it is possible to specify generic "KR import or export methods" by specifying and exploiting a homogeneous ontology of KRL abstract models and notations such as KRLO. At a high-level, this article has also shown how this is possible and why this is interesting. Only declarative KRL translation was addressed: neither the content of KRs -i.e., their information not related to the used KRLs -nor particular inference engine methods were taken into account. No "minimal translation" between logics has been specified: IKLmE is used as a complement whenever the target KRL lacks some needed expressiveness. No method exploiting the "KR import or export methods" has yet been specified or implemented, e.g., no method for "structured editing of KRs", "ontology design pattern checking" or "KRL expressiveness detection". Finally, KRLO is currently focused on few KRLs. However, KRLO was designed for scalability and specifying or extending a model or a notation in KRLO does not require much more time than specifying or extending the notation of a KRL with a classic concrete grammar. The company employing the second author of this article has begun incorporating the results of our work in some of its software products for them to i) collect and aggregate knowledge from knowledge bases, and ii) enable end-users to adapt input and output formats to their needs. In the immediate future, we shall continue extending and validating KRLO and our tools to handle more KRLs. The next step is to handle some KR query languages, starting with SPARQL, and to complement our notation ontology by a presentation ontology with concepts from style-sheets and user interfaces. Then, still for KR importing and exporting, we shall exploit KRLO with SPARQL and MMT.

FOLwDef

  Bird r_agent of : 1..* Flight, r_part : 1..* Wing; FOLwDef. / KIF: (defrelation Bird (?b) := (exists ((?f Flight)(?w Wing)) (and (r_agent ?f ?b) (r_part ?b ?w) ) ) ) OWL2QL / OWL_Functional-style: SubClassOf ( Bird ObjectIntersectionOf ( ObjectSomeValuesFrom ( :r_agent :Flight ) ObjectSomeValuesFrom ( :r_part :Wing ) ) RDF+OWL2QL / Turtle: Bird owl:subClassOf [ rdf:type owl:Restriction; owl:onProperty r_agent; owl:someValuesFrom Flight ]. Bird owl:subClassOf [ rdf:type owl:Restriction; owl:onProperty r_part; owl:someValuesFrom Wing ].

Table 1 :

 1 Representation of a purposely oversimplified English statement in different KRLs.

Table 2 :

 2 Representation of a relatively precise statement, using contexts and a numerical quantifier, with a high-level notation and then a lower-level one. On March 21st 2016, John Doe believed that in 2015 and in USA, at least 78% of adult healthy carinate birds were able to fly.IKLmE / FE: ` ` ` ` `at least 78% of Adult_healthy_carinate_bird can be r_agent of a flight´ r_place USA´ r_time 2015´ r_believer JohnDoe´ r_time 2016-03-21´.

	English: IKLmE / Turtle: [r_value [r_value
	[r_value [r_value
	[r_value [r_value [r_agent_of [a flight] ]; rFe_ctxt [r_quantifier "78to100pc";
	r_type Adult_healthy_carinate_bird] ]; r_ctxt [r_modality Physical_possibility]
	]; r_ctxt [r_place USA] ]; r_ctxt [r_time 2015]
	]; r_ctxt [r_believer JohnDoe] ]; ]; r_ctxt [r_time 2016-03-21] ] .