Plan
1.0. Préambule
1.1. Informations : données / connaissances
1.2. Répertoire d'informations (BD/BC, SGBD/SGBC, ontologie, Web 3.0, ...)
1.3. Gestion|ingénierie des connaissances, SGC, SGBC, SBC
1.4. Systèmes d'information
1.4.1. Sous-parties
1.4.2. PGIs (Progiciel de Gestion Intégré | Progiciel d'Enterprise Resource Planning)
1.4.3. Fonctions de PGIs et processus "métier"
1.4.4. PGIs - Périmètre intérieur et extérieur
1.4.5. PGIs - Mise en œuvre et inconvénients
1.4.6. PGIs - Marché
1.4.7. PGIs - Intérêt d'étudier les PGIs
Ce document est un support Slidy.
Pour aller de page en page, utilisez la barre d'espace ou les flèches,
comme dans Powerpoint.
Vous pouvez aussi utiliser les menus "help?", "contents?" et "restart?"
ci-dessous à gauche
dans le bandeau inférieur de cette fenêtre.
E.g. (latin: exempli gratia) :
"par exemple".
i.e. (latin: id est) :
"c'est-à-dire".
/ : "ou". // : "ou bien".
| : (quasi-)"alias" (entre 2 termes, dans le contexte où ils sont définis).
Ce cours est organisé comme une suite intuitive de définitions.
Ceci facilite
- une description plus précise et complète des concepts et de leur inter-relations
- la recherche, compréhension et mémorisation de ces concepts et inter-relations.
Note : d'autres cours contiennent aussi beaucoup de définitions mais souvent de
manière moins explicite.
Information : données ou bien (représentations de) connaissances (RC)
(mais la sémantique d'une RC peut ne pas être prise en compte et donc
une RC peut être recherchée/traitée comme si elle
n'était qu'une donnée).
Données [data] : information non
organisée ou de manière non "explicite",
i.e., non formellement ou sans relation sémantique, e.g., "12", "froid", "employé".
(Représentation de) connaissances (RC) [knowledge (representation)] :
information organisée par des
relations sémantiques
(i.e., des relations entre des sens de mots, e.g., les relations de
spécialisation, sous-partie,
localisation spatiale/temporelle, ...),
ayant une interprétation dans une logique.
Ces relations permettent à des logiciels d'effectuer des inférences logiques.
Langage|formalisme de RC (LRC) [knowledge representation language (KRL)]:
langage permettant d'écrire des
"représentations de connaissances".
Exemple de RC très simple (formule logique positive existentielle
conjonctive)
représentée avec différents LRCs (avec explications orales) :
En : Tom (a man) owns a red hat and a bird. //"English" is not a KRL LP : ∃?h ∃?r ∃?b hat(?h) ∧ red(?r) ∧ bird(?b) ∧ owner(?h,Tom) ∧ color(?h,?r) ∧ owner(?b,Tom). KIF : (exists ((?h hat)(?r red)(?b bird)) (and (instance man Tom) (owner ?h Tom) (color ?h ?r) (owner ?b Tom))) CGLF: [man: Tom]- { <-(owner: *)<-[hat: *h]->(color)->[red: *]; <-(owner)<-[bird] }. FL : Tom instance of: man, owner of: (a hat color: a red) (at least 1 bird); FE : The man Tom is owner of a hat that has for color a red, and is owner of a bird. FL-DF: man --(instance)--> Tom <--(owner)-- a hat --(color)--> a red ↑ \--(owner)-- a bird FL-DF: man --instance--> Tom <--owner-- a hat --color--> a red ↑ \--owner-- a bird instance owner color FL-DF: man -----------------> Tom <-------------- a hat -------------> a red ↑ \ owner \--------------- a bird
Exercice (de contrôle ;
après réponse aux questions éventuelles des étudiants)
:
- un schéma de base de données est-il une RC ?
Généralement non car un schéma ne représente généralement pas de relation sémantique entre les objets (e.g., entre ceux représentés par des tables et ceux représentés dans leurs colonnes).
Règles de base pour la représentation de connaissances
(règles à suivre dans tous vos exercices de modélisation) :
1. Une relation binaire de type ?rt (e.g., 'subtype' or 'part')
depuis un nœud source ?s (e.g., 'feline' or 'at least 80% of car')
vers une destination ?d (e.g., 'cat' or 'at most 100 wheel') se lit :
" ?s has/have for ?r ?d ". E.g. :
`feline > cat´ (i.e., `feline subtype: cat´) se lit
"feline has for subtype cat"
(ou "the type feline has for subtype the type cat"),
`at least 80% of car part: at most 100 wheel´ se lit
"at least 80% of cars have for part at most 100 wheels".
Ce dernier exemple peut aussi se lire :
"at least 80% of instances of the
type car have for part
at most 100 instances of the type wheel". Enfin,
conformément à la règle 7 ci-dessous,
`car part: at most 100 wheel´ se lit
"any (instance of) car has for part at most 100 (instance of) wheel(s)".
2. Si ?r est suivi de "of" (pour inverser la direction de la relation),
il vaut mieux lire
" ?s is/are ?r of ?d ".
E.g., `cat < feline´ (i.e., `feline subtype of: cat´)
se lit
"cat is subtype of feline" et
`at least 51% of wheel part of: a car´ se lit
"at least 51% of wheels are part of a car".
3. `?st subtype of: ?t´ (alias, `?st < ?t´) est équivalent à
`any ?st instance of: ?t´,
i.e., ` `?i type: ?st´ => `?i type: ?t´ ´
(3ème paraphrase, informelle cette fois :
"?st est sous-type de ?t ssi toute instance de ?st est aussi instance de ?t").
4. `?t > excl{?st1 ?st2}´ <=> `?t > ?st1 (?st2 exclusion: ?st1)´
(informellement :
?st1 et ?st2 sont sous-types de ?st et ne peuvent avoir ni sous-type commun,
ni instance commune).
5. Si le nœud destination d'une relation est source/destination d'autres relations,
il faut isoler ce nœud destination et ses autres relations avec
des parenthèses (comme
dans l'exemple du paragraphe
précédent) pour que l'interpréteur du langage puisse
savoir que ces autres relations sont sur le nœud destination et pas le nœud
source.
Similairement, dans une notation textuelle, lorsque 2 relations de même source se
suivent, il faut les séparer par un symbôle (en FL, c'est la
virgule ; voir les exemples).
6. Les noms utilisés dans les nœuds relation/source/destination doivent
être des
noms communs/propres (jamais d'adjectif, verbe, ...)
au singulier et en
minuscules (sauf pour les noms propres s'ils
prennent normalement des majuscules).
7. Les relations qui ne sont pas entre types et/ou des individus nommés
(i.e., pas les relations sous-type/instance mais la majorité des relations)
doivent préciser comment les nœuds source et destination
sont quantifiés
Exemples de quantificateurs : "a" (i.e., "there exists a"),
"any" (i.e., "by definition, each"),
"every" ("by observation, each"), "most" (i.e., "at least 51%"), "at most 20%",
"0..20%", "at most 20", "0..20", "between 2 and 3", "2..3".
Toutefois, si le quantificateur du nœud source est 'any'
- i.e., s'il s'agit d'une définition -
celui-ci
peut être omis : c'est le quantificateur par
défaut pour un nœud source.
Pour le nœud destination, 0..* est le quantificateur par défaut.
Donc :
`car part: wheel __[any->0..*, 0..*<-any]´
=> (`any car part: 0..* wheel´ <=>
`car part: 0..* wheel´)
Lorsque c'est possible, il vaut mieux rendre les quantificateurs explicites.
C'est toujours possible pour des RCs isolées ou en mettant les
quantificateurs
dans les contextes associées aux nœuds relations au lieu de les mettre dans
leurs nœuds sources/destinations.
8. Si vous hésitez entre 2 relations dont une seule est transitive,
choisissez la transitive.
Sinon, si vous hésitez entre 2 relations, choisissez la plus
basique|générique (et
utilisez des nœuds
concept adéquats pour ne pas perdre en précision).
À propos des relations de spécialisation (inverse : généralisation)
D'un type (terme formel) ?t à une instance ?i :
instance (inverse: 'type').
Équivalente à la relation 'member' entre l'ensemble des instances de ?t et ?i.
D'un type ?t à un sous-type ?st : subtype|> (inverse: 'supertype'|<).
Toute instance de ?st est (aussi) instance de ?t".
L'ensemble des instances de ?st est inclus dans l'ensemble des instances de ?t.
Toute relation associée|"depuis/vers" toute instance de ?t est aussi associée à
toute instance de ?st (dans les langages O.O., c'est la notion d'héritage :
l'ensemble des caractéristiques individuelles|non-statiques de ?t est inclus
dans
celui de ?st ; c'est l'inverse pour les instances).
Exercice :
comment représenter des caractéristiques "non-héritables"|statiques ?
//By using 'instance' instead of 'subtype'. E.g. :
transitive_relation_type instance: (ancestor > direct_parent);
//Do NOT write this: transitive_relation > ancestor;
// SINCE THIS would imply: transitive_relation > direct_parent;
// which IS FALSE ('direct_parent' is not transitive)
D'un mot (terme informel) ?t à un mot plus spécialisé ?st (i.e.,
ayant moins de
sens différents et/ou dont les sens sont plus
précis|informatifs|contraints) :
informal-subterm|.> (inverse: .<).
E.g.:
fr#"ville" .> (fr#"capitale_de_pays" .> (fr#"Paris" .> fr#"Paris_avant_1789"))
D'un mot ?m à un type exprimant un de ces sens :
meaning|.> (inverse: name|.<). E.g.: fr#"Paris" .> pm#Paris.
D'une instance à une instance contextualisée dans le temps/espace/... :
.> (inverse: .<). E.g.: pm#Paris .> pm#Paris_avant_1789.
D'une phrase formelle à une spécialisation logique :
<=|> (inverse: =>).
E.g.:
`a cat with place a piece_of_furniture´
> `the cat Tom with place a chair that has for color a red´
D'une phrase (formelle/semi-formelle/informelle) à une spécialisation lexicale
(possiblement plus formelle, jamais moins) : .> (inverse: .<). E.g.:
"birds fly" .> (`any "bird" is agent of a flight´
.> `any bird may be agent of a flight´).
D'une phrase à une correction spécialisante: corrective_specialization.
E.g.:
pm#` mp#"birds fly"
corrective_specialisation:
pm#"any non-handicaped flying_bird is able to fly"
´
Rappels (du cours de GL) à propos des entités/types/logiques d'ordre 0/1/2.
Entité du 1er ordre: élément d'information pouvant être mis dans une variable,
e.g., une fonction en C (donc, en C, une fonction peut prendre en paramètre une autre fonction ; elle
est alors une "fonction d'ordre supérieur").
Contre-exemples en C++ : un attribut, un type (de fonction/variable/...).
Plus vos modélisations (dont vos programmes) utilisent des entités de 1er ordre
(ou lieu d'entités d'ordre 0), plus elles seront génériques et donc facilement
extentibles, paramétrable, (ré-)utilisables, ...
Pour cela, il vous faut donc utiliser des langages de haut niveau (-> expressifs et concis),
e.g., un langage fonctionnel d'ordre supérieur et/ou une logique d'ordre supérieur
(cf. ci-dessous).
Type (d'ordre 1, 2, ...): élément d'information qui peut avoir au moins une instance,
e.g., pm#cat (qui pour instance pm#Tom_the_cat), pm#Type qui a pour instance pm#cat et le
type de relation '>'.
Individu (ou "type d'ordre 0"): élément d'information qui n'est pas un type,
e.g., pm#Tom_the_cat et `pm#mammal > pm#cat´.
Type du 2nd-ordre: type ayant pour instance un type du 1er ordre, lequel a pour instance un individu (catégorie ne pouvant être instanciée).
Logique d'ordre 0 (alias, logique propositionnelle):
logique n'ayant pas de variable (quantifiée).
Logique d'ordre 1 (alias, logique des prédicats, un type de prédicat étant assimilable à
un type de relation unaire ou non, ou encore à un type de concept ou un type de relation):
logique ou seuls les individus (explicitement nommés ou anonymes) peuvent
être quantifiées (et donc mis dans des variables),
e.g., la définition suivante est une "phrase du 1er ordre" nécessitant une logique du
1er ordre.
En : the relation "ancestor" is transitive since the ancestor of an ancestor is an ancestor. LP : instance(Transitive_relation,ancestor) <= ∀?x ∀?y ∀?z (ancestor(?x,?y) ∧ ancestor(?y,?z)) => ancestor(?x,?z) KIF : (<= (instance Transitive_relation ancestor) (forall (?x ?y ?z) (=> (and (ancestor ?x ?y) (ancestor ?y ?z)) (ancestor ?x ?z) )) )
Logique d'ordre 2..* (alias, logique d'ordre supérieur): logique où les types (de
concept/relation/quantification) peuvent être quantifiés,
e.g., la définition suivante est une "phrase du 2nd ordre" et nécessite une logique du second ordre
car elle comporte un quantificateur universel sur des relations.
En : ?r is a transitive_relation ?r iff ?r(?x,?y) and ?r(?y,?z) implies ?r(?x,?z) LP : ∀?r transitive_relation (?r) <=> ∀?x ∀?y ∀?z ( ?r(?x,?y) ∧ ?r(?y,?z) ) => ?r(?x,?z) KIF : (forall (?r) (<=> (transitive_relation ?r) (forall (?x ?y ?z) (=> (and (?r ?x ?y) (?r ?y ?z)) (?r ?x ?z))) )) KIF : (defrelation transitive_relation (?r) := (forall (?x ?y ?z) (=> (and (?r ?x ?y) (?r ?y ?z)) (?r ?x ?z))) ) FL : transitive_relation (?r) := [ [^x ?r: (^y ?r: ^z)] => [^x ?r: ^z] ]; //^x, ^y et ^z are free variables, i.e., implicitely universally quantified
Répertoire d'informations [information repository] : base de données ou de connaissances.
Base de données (BD)
[database (DB)] :
collection structurellement organisée de
données.
Dans une BD, il n'existe essentiellement que trois 'types de relations' explicites :
partie(-de), type(-de), attribut(-de).
Un document structuré (e.g., un document XML) peut être
considéré comme une BD.
Inversement, une BD peut être stockée dans un document structuré.
Les types de données autorisées - et leurs inter-relations possibles -
sont souvent énumérés
dans un "schéma de BD". Ce schéma est fixe (prédéfini par le
concepteur de la BD) : l'utilisateur
de la BD ne peut alors pas ajouter dynamiquement (i.e., déclarer ou définir)
de nouveaux types
de données et ne peut pas définir de nouveaux types
de relations.
Un document XML peut être plus souple qu'une BD relationnelle: il
est aussi souple
qu'une BD orientée objet dans la représentation
de certaines hiérarchies (e.g., celles structurées par
des relations partie-de) et peut aussi ne pas avoir de schéma associé
(auquel cas il peut stocker
n'importe quoi mais aucun contrôle n'est alors
effectué).
Une BC peut stocker n'importe quel type de contenu et néanmoins permettre
de nombreux
contrôles car les relations et les objets qu'elles relient
ont des contraintes|définitions associées
exploitables pour effectuer des inférences logiques.
SGBD [DBMS] :
système de gestion de BD [DB management system].
Certains SGBDs - e.g., les NoSQL - ne semblent pas
avoir de schéma : ils ne gèrent que des tableaux
associatifs (donc plusieurs tables|objets possibles mais seulement 2 colonnes
par table :
"nom d'attribut de l'objet" - "valeur pour cet attribut").
Il est possible de dire qu'ils n'ont pas
de schéma mais, techniquement ou
virtuellement, ils ont en fait un schéma fixe très
général (chaque table doit avoir les deux colonnes mentionnées
ci-dessus) que même le
concepteur de la BD ne peut changer.
Base de connaissances (BC)
[(machine readable) knowledge base (KB)] :
collection de RCs.
L'utilisateur d'une BC peut y ajouter dynamiquement de nouveaux types d'objets
(via des
définitions ou déclarations) et les utiliser.
Une BC peut être "implémentée" via une BD avec un
schéma très général composé de 2 tables (types d'objets) :
- "concept node" (colonnes|attributs : "type", "quantifier", ...)
- "relation node" (colonnes|attributs : "type", "source/destination nodes", ...).
Le fait que les relations soient explicites et que certains types (e.g., "any", "exists",
"transitive_relation", "subtype", ...) aient un sens connu des moteurs
d'inférences permet
plus de précision et d'inférences qu'avec les
SGBDs aux schémas fixes génériques.
Si JSON-LD est employé comme schéma
générique de BD, la frontière avec une BC est fine
mais cela reste une BD car
- JSON-LD n'a pas (suffisamment) d'interprétation en logique (et ne fournit
ni opérateur logique,
ni quantificateur, ni moyen d'effectuer des définitions),
- des attributs - et non des relations (entités du 1er-ordre) - sont
utilisés.
Une BC est composée d'une ontologie et, généralement, d'une base de
faits exprimée grâce
aux termes définis dans l'ontologie.
SGBC [KBMS] : système de gestion de BC [KB management system].
Base de faits [base of facts] : ensemble de croyances.
Ontologie : ensemble de termes formels avec, associés à ceux-ci
et portant sur eux, des
définitions partielles/totales et des croyances.
Onto-terminologie : ensemble de termes formels ou informels connectés
entre eux par des
relations sémantiques ou lexicales.
Thésaurus : ensemble de termes informels liés par des relations sémantiques ou lexicales.
Exercice (avec début de solution donné et expliqué)
:
- représentez en FL-DF puis en FL les relations de sous-typage, d'exclusion
et de sous-partie
entre les termes en gras de la page précédente.
entity
/ \
(>) \(>: 'subtype'; relations may be within/beside the line;
/ \ reminder: the '()' are optional)
v v
tool--(exclusion)-->information_repository
/ \ | \
(>)/ \(>) |(>) \(>)
v v v v
DBMS--#--KBMS--[0..*]--(p)--[0..*]->KB DB<--[0..*]--(p)--[0..*]--DBMS
| /| |\___
| / | \ \________________
|(>) (p)/ (p) (p) \('p' = 'part')
| / | \ \
| [0.1]/ [1] \[0..1] \[0..1]
v v v v v
WebKB base_of_facts ontology onto-terminology thesaurus
| ↑ / \[0..*] ↑[0..1]
|(instance) \-[1]--(p)---/ \---(p)--/
v
WebKB_on_the_12/11/2010
//Notes: 1) For relations from a type or to a named instance
// the default multiplicities are [any->0..*] and [0..* <-any]
// (hence, [0..* <-any] is sometimes ommited above).
// 'any->' and '<-any' can be (and are) also ommited.
// 'most->' or '<-54%' would need to be explicitly mentionned.
// 2) Compared to the solution in FL below, the above solution in FL-DF
// does not represent some relations from the parts of 'KB' :
// - their 'subtype of' relations to 'information_repository'
// - the exclusion relations between them
entity
> excl //the next subtypes (tool and information_repository) are exclusive
{ (tool > (DBMS part: DB __[any->0..*, 0..*<-any])
(KBMS part: KB __[any->0..*, 0..*<-any],
exclusion: DBMS,
> (WebKB instance: WebKB_on_the_12/11/2010)
)
)
(information_repository
> excl //the next subtypes are exclusive
{ (KB part: base_of_facts __[any->0..1, 0..*<-any] //any KB has for
ontology __[any->1, 0..*<-any] // part only 1
onto-terminology __[any->0..1, 0..*<-any] // ontology,
thesaurus __[any->0..1, 0..*<-any],
> ontology //an ontology is a KB that has for part only 1 ontology
)
DB
base_of_facts
thesaurus
(onto-terminology part: ontology __[any->1, 0..*<-any]
thesaurus __[any->0..1, 0..*<-any]
)
}
)
};
Représentation d'une BC via une BDD; modèles de données :
class Objet : {/*...*/} ; class ObjectReference : {/*...*/}; //pointer, database id, ... class Quantifier : Object {/*...*/}; class Node : Object //concept (node) or relation (node) { RelationRefArray get_relations (/*rel. selection parameters*/); RelationRefArray set_relations (/*rel. selection parameters*/); // references to relations connected (from/)to this node, // directly or not ("directly" is a default in the parameters); //1 relation selection parameter is the relation type: subtype, // type, creator, ... (a relation "creator" is (implicitly or // not) about the node representation, not its semantic content) //A node that has a meta-statement (black/white context) // has a relation of type pm#meta-statement (note: any node // that is existentially quantified (e.g., a relation) is a // statement (and probably a sub-statement) and conversely ; // a statement is either a belief, definition or command (e.g. // a query). //A (concept) node that is a meta-statement has a relation of // type pm#first_node and/or pm#embedded_node (an n-ary relation) //1 other parameter should allow the selection of binary } // relations that are "from"/"to" this node class ConceptNode : Node //alias "concept" { //The code should not "know" that actually relations are stored // in concepts, or concepts are stored in relations, or neither. //Similarly, the code should not "know" that node quantifiers // are stored in nodes or in relations: QuantifierRef quantifier_get (/*rel. selection parameters*/); QuantifierRef quantifier_set (/*rel. selection parameters*/); //A node that is a formal/informal "term" (e.g., a word, a type, // a date, ...) has no/all quantifier(s). //A node that has a quantifier is not named (it is not a term). //A particular user is a term ; a set/class of users is not. } //A node may have for creator/believer a (set of) user(s). class RelationNode : Node //alias "relation" { //a relation has directly or indirectly related concepts NodeRefArray relatedConcepts_get (/*concept selection parameters*/); NodeRefArray relatedConcepts_set (/*concept selection parameters*/); QuantifierRefArray quantifiers_get (/*concept selection parameters*/); QuantifierRefArray quantifiers_set (/*concept selection parameters*/); //these are the quantifiers of the linked concepts; } //the existential quantifier of a relation is implicit
WWW (Web)
[World Wide Web] : (système
hypermédia sur l')ensemble des
ressources (documents ou élément de documents,
bases de données/connaissances, ...)
accessibles via internet.
À l'origine, techniquement, le Web n'est que l'implémentation d'un
système hypertexte très simple (HTTP+HTML+navigateur Web) sur
Internet
(TCP + DNS).
Web 2.0: mot "fourre-tout"
(utilisé à partir de 2001 mais enfin passé de mode) désignant
- les technologies liées à la construction de
pages Web dynamiques
(i.e., générables),
e.g., le
DOM (Document Object Model) et
Ajax (Asynchronous Javascript
and XML), et
- la participation des internautes à la construction et indexation de
documents Web via
des sites/systèmes collaboratifs tels que les wikis, les blogs, les
réseaux sociaux,
les folksonomies et les systèmes de
sciences citoyennes.
Par opposition à la partie du Web 2.0 du Web, le reste est un
"Web de documents statiques (i.e., non dynamiques)".
Web 3.0: mot "fourre-tout"
(utilisé à partir de 2009) désignant les futures applications,
combinaisons et évolutions des technologies récentes et en particulier
celles liées
- au Web Sémantique,
- à la mobilité, l'universalité et l'accessibilité:
internet des objets,
indépendance vis à vis des
supports matériels et des
systèmes d'exploitation, ...
- au graphisme vectoriel (e.g., SVG qui est en fait maintenant une ancienne
technologie) et
aux formulaires XForms.
Web sémantique
[Semantic Web] :
mot (surtout utilisé à partir de 1996, soit 4 ans après
la naissance officielle du Web) désignant
Par opposition à la partie Web sémantique du Web, le reste est un "Web peu/non compréhensible par les machines".
Règles élémentaires du
Web des données:
- identifier et relier le plus possible de choses en utilisant des
adresses URI HTTP,
- fournir à ces adresses des informations lisibles par les humains et par
les machines
(en utilisant des langages formels intuitifs ou bien en fournissant
différentes
versions écrites avec des différents langages; e.g., via le
mécanisme de
redirection HTTP code 302 et la variable User-Agent contenu dans les
entêtes des
requêtes HTTP, un serveur peut afficher une page en RDF/XML pour une
machine ou
une page HTML pour le navigateur d'une personne).
Exercice :
- reliez graphiquement ou en FL les différents types et instances de web
référés ci-dessus
via des relations 'subtype', 'instance', 'exclusion' et 'part'
Ci-dessous, une représentation/modélisation/solution possible, dans la
notation FL,
pour le graphe demandé dans l'exercice précédent.
La page suivante propose une représentation graphique des 9 premières lignes
ci-dessous.
Note : ici, "web" ou "WWW" réfère seulement à un ensemble de "descriptions"
ou de
"containeurs de descriptions" (fichiers, base de données, ...),
et non pas aussi aux techniques/applications qui exploitent cet
ensemble.
web
instance of: first_order_type, //optional (see Note 2 below)
subtype:
(static_web instance: static_WWW)
(web_2.0 //juste pour l'exemple car
instance: WWW_2.0, // introduire/représenter
exclusion: static_web // les types web_2.0, web_3.0, ...
) // semblent peu intéressants
(semantic_web
subtype: (knowledge_web instance: Knowledge_WWW)
(data_web instance: Data_WWW,
exclusion: knowledge_web),
//no exclusion with web_2.0 and web_statique since one can imagine
// an instance of semantic_web that is also static or web_2.0
instance: Semantic_WWW,
part: knowledge_web __[any->a] //"a" = "some" = "existential quantifier" = "1..*"
data_web __[any->0..*] //__[some->a] is also correct but not equivalent
),
instance: WWW_3.0 WWW_2.0_and_3.0 //not yet already declared above
(WWW
part: (WWW_2.0
part: WWW_2.0_and_3.0)
(WWW_3.0
part: WWW_2.0_and_3.0
(Semantic_WWW
part: (Data_WWW
part: Knowledge_WWW)
))
);
/* Note 1: we could assume that, by default, a category that has subtypes is
a first-order type, unless it has instance which (by the same rule)
is a type; not all languages or inference engines assume that.
Note 2: the above representation assume that, by default, all
categories (types or individuals) with different names
are different; since this is not the case for most semantic web
languages and inference engines, we could add the 3 following lines.
*/
{WWW WWW_2.0 WWW_3.0 WWW_2.0_and_3.0
Semantic_WWW Data_WWW Knowledge_WWW} _[collective_set];
{semantic_web web_2.0 web_statique} _[collective_set];
//To represent that "no instance of 'semantic_web' can share a part with an
// instance of 'static_web'", i.e., that "no semantic web has for (proper) part
// something which is a (proper) part of a static_web", here are three
// equivalent ways in FL:
semantic_web
not part: (thing part: static_web __[?x->1..*]
) __[any->1..* ?x];
semantic_web part: (thing part: a static_web) __[no->1..*];
semantic_web not part: (a thing part: a static_web);
//this is equivalent since __[any->a] is the default for "relations between
// individuals" (as opposed to "relations between types")
Représentation graphique des 9 premières lignes du code FL de la page précédente.
first_order_type | |(instance) v -----web-------------- | | |(subtype) |(subtype) v v static_web <--(exclusion)-- web_2.0 | | |(instance) |(instance) v v static_WWW WWW_2.0
Insuffisances du Web dues à son peu de
méta-données/organisation/sémantique :
- recherches sur des informations peu/in-organisées -> résultats
redondants, qui doivent
être interprétés et combinés par l'homme (seuls des
traitements lexicaux ou structurels
peuvent être appliqués), (faible) ratio
rappel/précision ou
précision/rappel
[precision/recall],
recherches sensibles au vocabulaire utilisé, ...
- faible interopérabilité et flexibilité des logiciels et des
bases de données (et des bases de connaissances si peu de relations
existent entre les éléments de ces bases pour relier ces
éléments).
Note: recherches à base de mot-clés avec des listes de
documents/paragraphes/phrases pour résultats
[document retrieval / question answering] ->
(faible) ratio rappel/précision ou précision/rappel, redondances et
inorganisation,
même si des techniques (automatiques) d'extraction de connaissances sont
appliquées (e.g., analyse terminologique/syntaxique/sémantique
du langage naturel).
Google utilise la BC Freebase
mais ne fait que de la recherche de documents :
il ne répond pas
de manière précise à des questions précises.
Pour avoir des résultats organisés [knowledge retrieval/browsing],
il faut que les auteurs des diverses informations les relient (organisent)
entre elles par des relations sémantiques.
Même dans le futur, des techniques automatiques plus avancées ne
pourront extraire ce qui n'a pas été écrit ou représenté.
En d'autres termes,
"plus un ensemble/répertoire d'informations a des relations explicites et bien définies,
plus il est compréhensible et exploitable par l'homme et la machine".
Pour faciliter les partages/recherches/comparaisons/ré-utilisations/traitements d'informations
(ce qui revient à éviter les redondances et contradictions implicites entre informations)
voici donc - par ordre croissant de priorité - ce qu'il vaut mieux utiliser :
des documents statiques informels
(pas de relation: recherches lexicales, dont collocation),
des serveurs de documents informels (wikis)
(idem + coopération minimale),
des serveurs de BDs non connectées
(schémas fixes; quelques relations prédéfinies),
des serveurs de BD formant une BD unique distribuée
(idem + coopération minimale),
des documents statiques contenant des connaissances
(relations ; pas de coopération),
des serveurs de BCs non connectés
(idem + protocoles de coopération interne),
des serveurs de BC formant une BC virtuelle
(idem + protocoles de coopération externe).
Exercice :
1. La recherche de documents va t-elle beaucoup s'améliorer dans le futur ?
Si oui, pourquoi ?
2. La recherche d'informations précises va t-elle beaucoup s'améliorer ?
Pourquoi/comment ?
Connaissance tacite :
connaissance qui n'est pas
explicite,
i.e., qui n'a pas été
décrite précisément dans un document ou un SGBC.
Certaines connaissances, comme les savoir-faire et la reconnaissance de
situations ou d'objets (visages, écriture, ...), sont difficiles à
décrire ou définir
précisément et donc à représenter.
"Gestion des connaissances" (au sens des industriels)
[knowledge management] :
ensemble des techniques permettant de collecter/extraire, analyser, organiser et partager
des informations, le plus souvent à l'intérieur d'une organisation, e.g.,
les connaissances
importantes d'un employé (carnet d'adresses, trucs/expertise, etc.)
avant qu'il ne parte à
la retraite.
Ces informations sont généralement stockées sous la forme de
documents
informels, très rarement via des représentations de
connaissances, du moins jusqu'à présent.
Un outil permettant une telle gestion est un
système de gestion de connaissances (SGC)
[knowledge management system (KMS)].
"Gestion|ingénierie des connaissances" (au sens des universitaires)
[knowledge engineering] :
ensemble des techniques permettant de collecter/extraire,
représenter, organiser et de partager des représentations de connaissances.
Un système de gestion de BC (SGBC) [KB management system (KBMS)] est un des
outils permettant une telle gestion. D'autres outils sont ceux de collection/extraction
et analyse de connaissances qui aident à créer un SGBC.
Système à base de connaissances (SBC): tout outil exploitant des RCs, e.g.,
pour
résoudre certains problèmes. Techniquement, un SGBC est aussi un SBC
mais est rarement
classé en tant que tel.
Les systèmes experts sont
des SBCs mais ne sont pas forcément
basés sur des "connaissances profondes" (représentations détaillées de
connaissances
nécessaires à un raisonnement).
Gestion de contenu
[(Enterprise) Content Management] : prendre en compte sous
forme électronique des informations qui ne sont pas structurées, comme les
documents électroniques, par opposition à celles déjà
structurées dans les SGBD.
Ceci peut être vu comme une sous-tâche
particulière de "gestion des connaissances,
au sens des industriels", et inversement.
De plus, si des métadonnées "précises"
sont utilisées pour indexer les documents,
"gestion de contenu" implique aussi des tâches d'ingénierie des connaissances".
La gestion de contenu peut donc inclure la conversion de données brutes en informations
plus structurées : [information extraction]
ou, si des connaissances sont représentées,
[knowledge extraction].
Cela peut conduire à la création d'un système d'information
(cf. page suivante).
Ne pas confondre avec le [data mining] qui
découvre des
groupes [clusters], des anomalies ou encore des règles d'associations dans des données
structurées. [Data analysis] réfère
à [data mining/visualisation/dissemination/modeling].
Le terme "contenu" a donc divers sens contradictoires.
Dans "gestion de contenu", ce
terme réfère à des données non structurées.
Dans "recherche de documents/informations par le contenu", il réfère
à la sémantique des
informations, par opposition à leur structure
ou leurs aspects lexicaux (orthographe, ...).
Dans "recherche d'images par le contenu", il réfère
- soit à la sémantique de l'image (les choses qu'elle contient et leur relations spatiales),
- soit à des
caractéristiques visuelles de l'image comme les textures, couleurs et formes.
Exercice :
- représentez graphiquement (en FL-DF) ou en FL les relations de sous-typage et d'exclusion
entre SBC, SGC, SE, SGBC et SGBD,
- représentez graphiquement et en FL les relations de sous-typage et/ou de
sous-tâche
entre "gestion de contenu",
"gestion de connaissances, au sens des industriels" (GCI) et
"gestion des connaissances, au sens des universitaires" (GCU)
(note : une relation de sous-tâche ne peut pas directement lier deux
types de tâches,
elle ne peut lier que des instances de tâches -> utilisez des multiplicités).
//solution en FL:
SGC > excl{ SGBD (SBC > SE SGBC) };
process
> (GCI //Gestion/ingénierie des Connaissances au sens des Industriels
> excl{ GCI_sur_donnees //ce que la plupart des industriels font
(GCI_sur_connaissances
> (GCU //... au sens des universitaires
subtask: GCI __[any->0..*, 0..*<-any]
)) //rare mais possible
},
subtask: gestion_de_contenu __[any->0..*, 0..*<-any]
GCU __[any->0..*, 0..*<-any]
) //e.g., pour certaines meta-data en GCI
(gestion_de_contenu
subtask: GCI __[any->0..*, 0..*<-any]
);
Note sur la résolution de problèmes :
//reminder: a problem_solving_method (PSM) is one way to do a problem_solving_task
// exanple of PSMs: problem decomposition, backward chaining, forward chaining
problem_solving_task < process,
> teaching solving_an_exercice understanding_an_information
PSM_search PSM_application, //they are subtypes and parts (-> recursive definition)
input: a problem ?pb,
parameter: (a KB ?kb part: 0..* PSM {1..* accepted_and_understood_fact ?auf} ?set_of_auf,
part: (1..* PSM_search input: ?pb ?kb,
output: (1..* PSM ?psm
parameter of: {1..* PSM_application ?psm_app
input: ?pb ?kb, parameter: ?psm,
output: (1..* accepted_and_understood_fact member of: ?set_of_auf)
} ?set_of_psm-app ) )
?psm_app ;
Système d'Information (SI)
[Information System] : ensemble organisé de
ressources permettant de collecter, stocker, classifier, traiter et diffuser de
l'information sur un environnement donné. Types principaux de ces ressources :
- base d'informations
- logiciels système/application (e.g., un SGBD, des serveurs/clients)
- matériels et réseaux
- personnel, e.g., des spécialistes I.T. (administrateur BDD, ingénieur réseaux, ...)
- procédures de saisie/traitement/stockage/communication/... de l'information.
Sous-types de haut-niveau :
- SI temps réel de conception,
supportant des opérations (transactions,
contrôle de processus, communication)
- SI d'informatique de gestion (-> production de rapports, aide à la décision, ...)
Exemples (en anglais) : data warehouse, ERP, enterprise/expert systems,
search engines, geographic/global information system, office automation.
Sous-parties de SI d'une grande entreprise :
- un PGI
(Progiciel de Gestion Intégré) qui
intègre les systèmes soutenant le fonctionnement de l'entreprise, et/ou
- des systèmes "spécifiques | sur mesure" connectés via un PGI ou pas.
L'urbanisation d'un SI est la
gestion de l'évolution de son architecture.
Le domaine/process de la
Business|organizational informatics (BI)
est similaire à
celui des SIs mais plus orienté solution et implémentation.
Progiciel :
mot-valise - car contraction de "produit" et "logiciel" -
référant à un
logiciel applicatif, libre/ propriétaire,
"prêt-à-porter", standardisé et générique, prévu pour répondre à des besoins ordinaires.
Sous-parties de SI (en général) : un PGI ou bien plusieurs progiciels
connectés via un PGI ou interfacés entre eux ainsi qu'avec des applications.
Exemples de fonctions de ce PGI ou de ces progiciels/applications :
- [CRM (Customer Relationship Management)] -> relation client
- [XRM (eXtended Relationship Management)] -> relation tiers
- [SCM (Supply Chain Management)] -> chaîne logistique (achats -> production -> vente)
- [HRM (Human Resource Management)] -> ressources humaines
- [PDM (Product Data Management)] -> données techniques (et de stockage),
e.g., pour les bureaux d'études.
Sous-parties de SI auparavant :
Progiciel de Gestion Intégré (PGI) [Enterprise Resource Planning (ERP)] : progiciel d'ERP
Le cours de Guy du Boisberranger sur les PGIs
(ce cours là est "pour culture" car ses parties "essentielles à retenir"
sont reprises dans les sous-sections de la section 1.4).
Fonctions (et donc "composantes fonctionnelles" et "processus métier" de
l'entreprise) typiquement gérées (au moins partiellement) par un PGI :
Processus "métier"
[business process] :
* "operational processes | core business processes" :
ceux créant la source de revenue principal de l'organisation, e.g.,
"purchasing",
"manufacturing",
"sales",
"advertising and
marketing"
* "supporting processes" : "accounting",
"recruitment",
"call center",
"technical support", ...
* "management processes" :
"corporate governance",
"strategic management", ...
Le cours de Guy du Boisberranger sur les processus "métier" (ce cours ci est essentiel).
Réseau sémantique de quelques processus "métier" de haut niveau
(il s'agit d'une synthèse et organisation des processus référés
dans le cours ci-dessus et
dans SAP ERP).
Périmètre intérieur (sous-parties) à un ERP :
- le "back office" : activités internes à l'entreprise
- les flux complémentaires : workflow, data-warehouse, knowledge-warehouse
- le "front office" et les flux collaboratifs :
le portail, le CRM, le Business Intelligence (BI), le Supply Chain Management (SCM)
Périmètre extérieur (extensions) à l'ERP de SAP :
la "SAP Business Suite"
(basée sur SAP ERP grâce au
moteur d'exécution
"SAP NetWeaver") :
- SAP Enterprise Resource Planning (SAP ERP)
- SAP Supplier Relationship Management (SAP SRM)
- SAP Customer Relationship Planning (SAP CRM)
- SAP Supply Chain Management (SAP SCM)
- SAP Product Lifecycle Management (SAP PLM).
SAP NetWeaver est un moyen
d'urbaniser un SI et
de gérer les
interfaces+échanges inter-applicatifs
[Enterprise Applications Integration (EAI)].
JBoss Enterprise Middleware (par RedHat)
est un autre exemple de
support d'intégration d'applications.
Tous les futurs ERPs devront avoir un mécanisme d'intégration d'applications
au moins aussi performant. Y compris sur ce point, l'utilisation de bases de
connaissances (plutôt que de BDs) sera à terme nécessaire.
Modélisation de processus "métiers"
[Business process modeling] :
représentation de processus de telle
sorte qu'ils puissent être analysés et améliorés.
Nous aborderons ceci en section 2.2 s'il nous reste du temps.
La mise en œuvre d'un ERP est longue. Elle dépend beaucoup de la
taille du projet ou de l'organisation (PME, ... multi-nationales).
Elle est typiquement de 4 à 24 mois (9 mois en moyenne) avec
- 20 à 150 intervenants parmi lesquels des "function leaders" (opérationnels
des différents métiers de l'entreprise missionnés sur le projet), et
- de 10 à 50 consultants.
Cette mise en œuvre est donc couteuse (300'000 euros minimum pour un
progiciel fiable et de qualité) même avec des logiciels libres.
Les coûts sont ceux de :
Autre problème:
- captivité vis-à-vis de l'éditeur (mais moins qu'avec des logiciels
moins standards
et moins avec l'utilisation de formats ouverts).
Statistiques de 2005 (selon "AMR Research" dans "Le Monde Informatique") :
* - 20,7 Md$ ; 3% de croissance
- SAP conserve la tête du marché ERP
(43% de parts de marché et 10,5 Md$; Croissance: 11%)
- Oracle Aplication : 19% de parts du marché
(absorption de JD EDWARDS et PEOPLE SOFT: croissance de 84%
- Sage : 6% ; 11% de croissance
- Microsoft : 4% ; 15% de croissance
- SSA Global : 3%
* Orientation renforcée PME
* Architectures orientées service (SOA)
* Les 5 premiers éditeurs représentent 72% du marché contre 59% en 1999
Principaux vendeurs par segments de marché :
- grands comptes : SAP ERP, Oracle Aplication
- grosses P.M.E. : Microsoft, Lawson, SSA Global, Geac, SAP, Oracle/PeopleSoft
- petites P.M.E. : Microsoft, Epicor, Exacta, Sage, NetSuite, SAP Business One,
Movex, Adonix, Generix
- T.P.E. : Sage, Intuit, ACCPAC, NetSuite
Outils vendus :
- SAP : SAP Business Suite, SAP All-in-One, SAP Business by Design, SAP Business One
- Oracle Applications : Oracle, JD Edwards, PeopleSoft, Siebel, Retek
- Microsoft Business Solutions
- Dynamics : Great Plains, Navision, Axapta, Soloman
- The Sage Group : Sage Software (Accpac ERP, PeachTree)
- SSA Global Technologies : BAAN
Afin d'être compétitives, les entreprises - à part les très petites -
ont désormais
besoin d'un SI/PGI pour organiser et gérer leurs processus et données.
Une part de + en + importante de leur personnel
(en particulier les informaticiens et les administratifs) est donc amené à
- comprendre rapidement les "processus métiers" de leur entreprise
(son organisation fonctionnelle) et son système d'information, et
- analyser ses résultats et proposer des évolutions pour ceux-ci.
Dans les grandes ou moyennes entreprises, le service Informatique est
de + en +
intégré au service "Système d'Information" (service Direction).
Composition des Directions Informatiques :
- département "Administration systèmes" (100% d'informaticiens)
- département "Programmation et développements" (100% d'informaticiens)
- département "Business" (30% d'informaticiens)
- département "Réseaux et clients" (100% d'informaticiens)
Leurs résultats sont utilisés par l'équipe "Maintenance" et
les équipes "Programmes/Projets".
L'utilisation d'un PGI permet une mutation managériale via
* un élargissement du champs de compétence fonctionnelle :
compréhension transversale, nouvelles possibilités
* une implication et prise de responsabilité :
chaque opérateur est concerné par le processus dans sa globalité, e.g.,
- le vendeur prend connaissance de la fiabilité du client,
- l'atelier d'assemblage connaît la date de livraison,
- le responsable d'entrepôt peut adapter la gestion de son stock.
Retourner à l'index pour cette partie.