Representation operators

These are the basic construction operators for representations. The abstrac-tion and reificaabstrac-tion operaabstrac-tions map physical resources to their representaabstrac-tion in the repository and produce new resources from derivation (see figure 5.2).

Model mapping operations create new representations in other models. This category of operators is represented in the repository with basic implemen-tations. We did not implement all the possible representation operators that are required to import, export and transform all types of knowledge resources within the repository.

Resource(language) Resource(model) i : abstraction

e: reification

σ : derivation

Figure 5.2: Resources representation and derivation operators

5.1.1.1 Abstraction

Also called import, this operator is the constructor for representations of knowledge resources within the repository. It takes as input a resource, expressed in given language or format and generates a representation of its content according to a given representation model.

It is not always necessary to preserve the entire content of a resource when imported [Seidenberg & Rector 2006]. In particular, if the representa-tion model is less expressive than the original resource model, it is obvious

that some knowledge will be lost in the transformation process. For in-stance, importing an OWL ontology into the WordNet-like model (described in section 4.2.4) will result in the loss of the semantics expressed in complex axioms. However, the aim of the repository is not to faithfully represent resources, it is to create versions or views (derivations) of these resources within different models in order to optimize their usage for knowledge en-gineering tasks. Thus, the content representation model must be chosen according to the operations to perform and the functions to fulfill by the resulting resource.

We denote by i_R,M the import operation that produces an instance of a resource R in the resources repository and by creating the content of the resource represented according to a content representation model M. This operation can be followed by an other operation that produces a derivation of the resource in a different content representation model. For example an ontology can be imported in the OWL or DL representation model and then another ontology represented in the Concept_Hierarchy model can be derived from it.

Let M the set of content representation models available in the reposi-tory.

The signature of the abstraction operator is of the form:

i_R,M :Resource→M ∈ M R→rM

Where r_M is the instance of the resource R in the repository represented using the content representation modelM.

5.1.1.2 Reification

We denote by e_R,M,S the export operation that transforms a derivation of a resource represented in the repository by an instancer expressed in a model M into a physical resource in an external file of a specific syntax S. Reifi-cation is generally used at the end of a process (sequence of operations) to produce a new resource. It may also be used within a process that requires the application of some external operators. In this case resources represen-tations must be reified, exported, processed and re-imported.

This operator can have as much implementations as the possible combina-tions from the representation languages in the repository (for example OWL, UML, DL, Graphs, etc.) to the possible required formats (txt, xml, rdf, ttl, n3, etc.). Since abstraction may not preserve the content of a resource, the compositione_R,M,S(i_R,M(R₁))does not necessarily yield the initial resource R1. However, it is possible, and desirable, that iR,M(eR,M,S(r2)) =r2 holds

(r2 is the representation of a resource R2 using a content representation model M).

LetRbe the set of resources already imported in the repository,Mthe set of content representation models available in the repository and S the set of syntax languages that are supported by the exporting operators.

The signature of the reification operator is of the form:

e_r,M,S :r∈ R, M ∈ M →R:Resource, S∈ S (r, M)→R_M,S

WhereRM,S is a physical resource R exported from the repository and rep-resented using the content representation modelM and one of its associated syntax representations S.

5.1.1.3 Resources translation (from a model to another)

This abstract operator is used to create new representations (views) of a resource using a content representation model (the resource is already rep-resented in the repository). For instance, a resource imported from UML class diagram could be represented in the repository using the content rep-resentation modelClass_Association, then a derivation of this resource can be represented in the Concept_Hierarchy content representation model (by dropping all the associations except part-of and subClassOf).

A translation creates a new instance of a resource, which is required to be associated to the original instance. This operator requires a usage of a model mapping as a parameter to perform the transformation of the resource. A model mappingµM1,M2 is a set of correspondences between the elements of a content representation model M₁ and another content representation model M₂. The mappingµ_M2,M1 is not required to be the inverse ofµ_M1,M2.

Many tools and approaches propose converters between content rep-resentation models. For instance, from SKOS to OWL or OWL to SKOS many tools¹² and mappings are available [Juppet al. 2008, Van Assem et al.2006]. In this research work, we created some convert-ers for the specific use cases that we implemented (explained in the following sections and chapters) but we assume that enough tools for converting con-tent representation models are available. The important fact is to be able to integrate and represent them in the repository, which is the case. Otherwise, if we create a new content representation model it should have at least one implementation of the abstraction operator and one implementation of the reification operator.

1http://www.heppnetz.de/projects/skos2owl/

2http://mowl-power.cs.man.ac.uk:8080/owl2skos/

LetR be the set of resources already imported in the repository,Mthe set of content representation models available in the repository andµthe set of mappings between these models represented in the repository.

The signature of the translation operator is of the form:

d_R,M1,M2 :r1 ∈ R, M₁ ∈ M, µ_M1,M2 ∈µ→r2 ∈ R, M₂ ∈ M (r₁, M₁)→(r₂, M₂)

It is not always necessary to preserve the entire content of a resource when deriving a new representation of it (this can be compared to generating a view in the relational approach). In particular, if the second representation model is less expressive than the original representation model, it is obvious that some knowledge will be lost.

Inner SET mapping Inter SET mapping

Representation Models

SET_i Representation Models

SET_j

Figure 5.3: Classes of resources translation operators

Knowledge representations formalisms have different levels of expressiv-ity. We define two classes of translation operators (see figure 5.3). The class of inner set mappings, which are translations within the same level of ex-pressivity (We can also qualify this as a translation from one vocabulary or namespace to another without loosing in terms of expressivity). The second class of translation operators transform the resource within a new represen-tation model that has a different level of expressivity than the first model, which leads to transforming the descriptions of the resource’s content.

An example of approaches for extracting and transform-ing knowledge from multiple resources is the methodology of [Villazón-Terrazas et al.2010a]. The author proposed a pattern based approach for re-engineering non-ontological resources into ontologies (see figure 5.4).

The API and guidelines of transforming “Non-Ontological resources”

into ontologies are directly relevant to be considered and integrated to

create a set of standard operators for importing resources such as the-saurus, classification schemes, lexicons and other resources as defined in [Villazón-Terrazas et al. 2010b]. modelled using a Path Enumeration model

Figure 5.4: An approach for reusing “Non-Ontological” resources [Villazón-Terrazas et al. 2010a]