Modèles à base de frames
6.1 Systèmes à base de frames
Le concept de frame a été proposé par Martin Minsky au milieu des années 70 [73]. Il a ensuite donné lieu à la création de plusieurs dizaines de systèmes à base de frames, dont les principales familles sont basées sur SRL [43], KL-ONE [14] et UNIT Package [88]. Ces propositions, bien que basées sur des principes similaires, se sont appuyées sur des choix très différents et souvent incompatibles [58]. Cette hétérogénéité a motivé la spécification d’une API (Application Programming Interface) commune similaire à ODBC (Open Data Base Connectivity) pour le monde des bases de données relationnelles : OKBC (Open Knowledge Base Connectivity) [24].
La description détaillée des différences de chaque système n’étant pas pertinente dans le cadre de cette étude des modèles d’information, nous nous contenterons de décrire le modèle générique sur lequel se base OKBC.
6.1.1 Frames, slots et facettes
La notion de frame peut être vue comme une autre façon de nommer les entités. Cependant, comme dans le modèle RDF où les instances et les classes sont des « ressources », une frame peut aussi bien décrire une entité qu’un ensemble d’entités. Ces deux concepts ayant des caractéristiques différentes, nous distinguons deux catégories de frames : les instances (ou individus) et les classes. Appelons E l’ensemble des frames1,I l’ensemble des instances et C l’ensemble des classes du système. Nous avons alorsE = I ∪ C.
Les données concernant les frames sont représentées par des slots. Chaque frame est ainsi associée à un ensemble de slots qui lui sont propres, appelés own slots. Chacun d’entre eux décrit soit une propriété
1
Nous préférons utiliser E (pour entité) pour éviter toute confusion avec l’ensemble F des facettes que nous allons introduire plus loin.
d’un frame, soit une association binaire entre deux frames. AppelonsS l’ensemble des slots du système, nous avons alors la fonction partielle :
∀s ∈ S, s : E 6→ 2E∪V (6.1)
oùV représente l’ensemble des valeurs des types de base et 2E∪V représente l’ensemble des parties de
l’ensembleE ∪ V .
Les slots sont à leur tour décrits par des facettes. Chaque couple (frame, own slot) est ainsi associé à un ensemble de facettes qui lui sont propres, appelées own facets. Les facettes permettent de décrire les
slots d’une frame. Nous pouvons les utiliser pour ajouter un commentaire ou une valeur par défaut, mais
elles sont surtout utiles pour exprimer des contraintes. Une facette peut, par exemple, restreindre le type des valeurs d’un slot aux instances d’une classe précise (facette :VALUE-TYPEdans OKBC). Appelons F l’ensemble des facettes du système, nous avons alors la fonction partielle :
∀f ∈ F, f : (S, E) 6→ 2E∪V (6.2)
On notera que les slots et facettes peuvent être réifiés en tant que frames, ce qui permet de décrire les propriétés des relations qu’elles représentent.
Les systèmes à base de frames ont aussi la particularité de permettre l’attachement aux slots de procédures, appelées dæmons, pour déclencher des actions quand on y accède. Des dæmons peuvent notamment surveiller les événements d’ajout, de suppression, de modification de la valeur d’un slot, ou encore la création d’une frame avec ce slot. Ce mécanisme permet de réagir aux changements d’état du système et de l’adapter à des besoins particuliers.
6.1.2 Classes
Une classe est un ensemble de frames qui sont appelées ses instances. Une frame peut être instance de plusieurs classes. Une classe étant un type particulier de frame, nous en déduisons qu’elle peut elle- même être instance d’une classe (dans ce cas,I ∩ C 6= ∅). Appelons cI l’ensemble des instances de la
classec.
Comme tous les modèles étudiés jusqu’ici, ceux à base de frames permettent de faire des spécialisa- tions / généralisations et proposent dans ce but les notions de super-classe et de sous-classe. Si l’on note ≺ la relation de spécialisation, nous avons alors : c1 ≺ c2 ⇔ cI1 ⊆ cI2.
Outre les own slots et leurs own facets, une classe peut recevoir des template slots et leurs template
facets. Les template slots d’une classe permettent de décrire les own slots que toutes ses instances doivent
avoir, ainsi que les template slots que toutes ses sous-classes doivent avoir. Les template slots permettent ainsi de représenter les propriétés de types que nous avons introduites en section 3.2.
Les équations 6.1 et 6.2 sont valables pour les deux types de slots et facettes. Pour les différencier, nous nous proposons d’utiliser les assertions suivantes :
CHAPITRE 6 — Modèles à base de frames 63
∀(s, e, v) ∈ (S, E, E ∪ V ) own(s, e, v) ⇔ s est un own-slot de la frame e et a pour valeurv
∀(f, s, e, v) ∈ (F, S, E, E ∪ V ) own(f, s, e, v) ⇔ f est une own-facet du own-
slot s pour la frame e et a pour valeurv
∀(s, c, v) ∈ (S, C, E ∪ V ) template(s, c, v) ⇔ s est un template-slot de la classec et a pour valeur v ∀(f, s, c, v) ∈ (F, S, E, E ∪ V ) template(f, s, c, v) ⇔ f est une template-facet du
template-slots pour la classe c et a pour valeurv
L’instanciation et l’héritage se traduisent alors par :
template(s, c, v) ⇒ ∀i ∈ cI, own(s, i, v)
template(f, s, c, v) ⇒ ∀i ∈ cI, own(f, s, i, v)
c1 ≺ c2∧ template(s, c2, v) ⇒ template(s, c1, v)
c1≺ c2∧ template(f, s, c2, v) ⇒ template(f, s, c1, v)
Il n’est pas nécessaire pour un slot d’avoir une valeur pour exister : dès qu’une facette a une valeur pour un couple (slot, frame), nous considérons que la frame possède le slot. Cette particularité permet notamment de définir des templates slots au niveau des classes tout en permettant aux instances d’avoir des valeurs différentes. Nous retrouvons ici l’héritage classique de propriétés :
∃v1 ∈ E ∪ V |template(s, c, v1)
∨∃f ∈ F, ∃v2∈ E ∪ V |template(f, s, c, v2) ⇒ template-exists(s, c)
∃v1∈ E ∪ V |own(s, c, v1)
∨∃f ∈ F, ∃v2 ∈ E ∪ V |own(f, s, c, v2) ⇒ own-exists(s, c)
template-exists(s, c) ⇒ ∀i ∈ cI, own-exists(s, i)
c1 ≺ c2∧ template-exists(s, c2) ⇒ template-exists(s, c1)
6.1.3 Conditions suffisantes et nécessaires
Contrairement aux modèles de la famille E/A pour lesquelles l’appartenance d’une entité à une classe est déclarative, les systèmes à base de frames peuvent s’appuyer sur des conditions. Nous distinguons dans ce cadre deux types de classes dans OKBC : les classes primitives et non-primitives.
Les valeurs des template slots et facettes associées à une classe non-primitive sont considérées comme spécifiant des conditions nécessaires et suffisantes pour qu’une frame soit instance de cette classe. La classe DOCUMENT, en particulier, pourrait être une classe non-primitive définie par un auteur et un contenu. Savoir qu’une entité a un auteur et un contenu suffit pour conclure qu’il s’agit d’un document.
En revanche, les valeurs des template slots et des facettes associées à une classe primitive, sont consi- dérées comme spécifiant seulement des conditions nécessaires à l’appartenance à la classe. Typiquement, les classes représentant des « choses naturelles » sont des classes primitives. Une base de connaissances peut spécifier beaucoup de propriétés d’une personne par exemple (nom, adresse, etc.), mais ne contien- dra généralement pas de conditions suffisantes pour conclure qu’une entité est une personne.
6.1.4 Du général au particulier
OKBC a été créé non pas comme un système à base de frames à part entière, mais comme une interface d’accès commune aux systèmes à base de frames existants ou à venir. Ainsi, le modèle décrit ci-dessus se veut suffisamment général et flexible pour être capable de représenter différents formalismes. Chaque système à base de frame a ses particularités et restreindra généralement les opérations four- nies par OKBC. Protégé-2000 [77], par exemple, utilise une démarche plus proche des modèles tradition- nels dans le cadre d’un système dédié à l’acquisition de connaissances. Ainsi, une part de la généricité du modèle de OKBC est sacrifiée au profit d’une plus grande simplicité d’usage : une frame doit instancier une classe et une seule, un own slot est toujours dérivé d’un template slot (il est impossible d’attacher un
slot directement à une instance), etc.
6.1.5 Conclusion et limites
Si les modèles à base de rôles héritent d’une partie des concepts de la famille E/A, les modèles à bases de frames ont, quant à eux, été développés dans un cadre beaucoup plus indépendant.
Leur expressivité est très bonne. Ils n’offrent pas de structures complexes, mais ils permettent en revanche de définir un type par de simples conditions d’appartenance. Les contraintes y sont également plus riches, autorisant une modélisation plus fine du domaine.
D’autre part, provenant de la communauté intelligence artificielle, l’approche frames s’est plus concen- trée sur les aspects dynamiques et d’inférence que sur la capacité de traitement de données applicatives. Cela a permis à ces systèles de disposer d’une flexibilité plus importante que les modèles de la famille E/A. En revanche, s’ils peuvent aisément modéliser des domaines et leurs contraintes, ils ne sont pas adaptés à la modélisation et au traitement d’importants volumes de données (ex. : bases documentaires). En effet, ils travaillent généralement uniquement en mémoire vive et sauvegardent leurs données ponc- tuellement sous forme d’un fichier. Ils sont donc limités très rapidement par la quantité de mémoire disponible.