On motive ici une approche conceptuelle structurée tdkg qui partage quelques traits communs avec une algèbre.
Objectif :
1.
Sémantique : mettre au cœur de la
représentation les concepts clefs de l’utilisateur
2.
Réduction dimensionnelle / compression
3.
Désambiguation
4.
Polymorphisme
On distingue les niveaux 0,1,2,…, < est la relation d’ordre
associée.
Le 1. force l’utilisateur à définir les ‘features’ clefs qu’il souhaite voir constituer l’ossature sémantique de sa représentation conceptuelle. Dès lors il se contraint à ne plus utiliser que ce ‘petit’ nb de features pour sa représentation. On a bien-sur ce principe en théorie des types (en informatique) : on a le type entier ℕ, les fonctions de ℕ->ℕ, les fonctions de 2 variables ℕ->ℕ->ℕ, etc. dans notre notation ℕ_ℕ_ℕ).
On retrouve une capacité générative/compositionnelle dans toutes les langues : géo_graphie, re_con_struction, auto_nomie, anthropo_logie, camion_citerne, etc. En générale il y a un ordre : a_b \( \ne \) b_a
Dans tdkg on trouve par exemple : cloud
< N_(comput + storage_data)
Idéalement on aimerait pouvoir avoir ab <
a_b, comme dans ab = ‘artificial intelligence’. Bien entendu c’est impossible
la plupart du temps (et c’est bien la raison d’être de tdkg!). typiquement
intelligence recouvre plusieurs sens en anglais, et de nombreux mots du jargon
technophile ont le même sens que artificial : virtual/ai/autonom, comme dans ‘virtual assistant’. De ce fait, même si a et b sont des
concepts typés de tdkg, dc a :A, b :B, on aura pas en général ab
< a_b. si on a effectivement ab < a_b, c’est parce que le sens de a et b
dans ab correspond au sens de a_b, comme par exemple dans tdkg: renewable
energy < renew_energy.
Le 2. passe par une structuration de type a_b_c pour les
concepts haut niveau, où a :A (‘a de type A’), b :B,… Il est clair
que si #A = n, #B=m, etc, on a accès à un ensemble de concept de taille n*m*…
Le choix des set A, B, doit être fait avec soin et
correspondre à la représentation cherchée. Dans tddic on distingue des niveaux
d’innovation, et de ce point de vue on a un ordre A>B>… par exemple dans
N_storage_data on considère que storage ‘opère’ sur data, et N sur storage_data.
N est une fonction abstraite qui correspond à ‘parallélisation / coopération à l’échelle’.
Le 3. doit être un soucis constant, à mi-chemin entre granularité/pouvoir
expressif et compression ; ex : supply chain < supply_chain ?,
artificial intelligence < artificial_intelligence ? Chain et
intelligence (en anglais) recouvre chacun plusieurs sens, il convient de lever
les ambiguïtés dès le niveau 1.
Le 4 permet d’aller au-delà des contraintes très fortes des structures
d’arbre (ex : Gics, Revere). Dans tdkg on a par exemple cloud
< (N_comput , N_storage_data). Cette propriété très utile est bien entendu présente
dans un graphe.
Au total cette structuration permet de garder le
polymorphisme d’un graphe mais d’avoir une forte structure qui facilite
considérablement l’utilisation par rapport à un graphe.
Examinons qq exemples, partant du niveau 1.
formal_language_natural_language [computational linguistics] :
(formal_language)_(natural_language ) la notion de computational dans ‘computational
linguistics’ n’est pas forcément inintéressante, mais ici nous privilégions la
notion de formalisation. Si nécessaire, on peut (en utilisant la possibilité de
polymorphisme), ajouter comput_language.
artificial_intelligence_tutoring [intelligent tutoring
system]: intelligence dans tdkg est au sens du français intelligence, et non
au sens d’information /renseignement. tdkg conserve artificial et le distingue d’automat.
chemical reaction_elec_hydrogen [electrolysis] : ici chemical
reaction est une relation qui lie réactant et produit de la réaction chimique :
elec -> hydrogen. Dans tdkg les concepts elec et hydrogen sont des
concepts importants de sustain, et on voit tout l’intérêt de substituer à
electrolysis le ‘produit’ : elec_hydrogen.
