Bonjour,
 
Ci-dessous VendrEDI n° 76 à imprimer pour un meilleur confort de lecture. Comme d'habitude, me signaler par retour de courrier des adresses de nouveaux lecteurs ou votre souhait de ne plus recevoir VendrEDI.
 
A l’occasion de la 5ème édition de son congrès annuel  "Net 2004 : Compétitivité et lnnovation", l’AFNeT mobilise pour faire gagner l’entreprise France et organise deux journées pour la compétitivité et l'innovation des PME, des grands industriels et des territoires. Ces journées du 6 et 7 avril  doivent permettre d’accompagner la transformation des entreprises et des administrations provoquée par l’Internet et  le développement des supply  chains industrielles.
 
AFNeT  : 6 et 7 avril 2004
Ministère à la Recherche et aux Nouvelles Technologies
1,rue Descartes – Paris 75005
(Entrée libre sur
inscription
en ligne)  

Pour découvrir l’agenda détaillé du Congrès "Net 2004" : http://www.afnet.fr/net200x/net2004/
Pour découvrir le Programme ePME : http://e-pme.afnet.fr/documents/plak_pme.pdf
 
Cordialement
 
Claude Chiaramonti
 
 


 
 
   VendrEDI   lettre de Claude Chiaramonti
 sur les données de
l'échange électronique
           Numéro 76      2 avril 2004
    Choreography :
 
 Les instances EDI
      en place pour le quadrille ?
    à refonder 20 ans après 
Le W3C vient d'annoncer la sortie d'une version de travail d'un Web Services Choreography Model Overview et d'un 2ème draft des Requirements. On trouve dans ce dernier deux exemples simples, l'un basé sur le rôle d'un travel agent, l'autre sur un quote request.  Très bien ! Mais le W3C peut-il prétendre jouer le rôle de chef d'orchestre ? Il faut se rappeller (cf VendrEDI n° 62) que Microsoft n'a fait qu'une apparition au bal du W3C et reste à celui d'Oasis, au groupe WS-BPEL pour la définition d'un Business Process Execution Language. Certes, l'un des tous premiers critical success factors mentionnés par le W3C est d'éviter tout double emploi avec d'autres standards, mentionnant le WS-BPEL comme exemple. Mais les Requirements du W3C ne le citent que comme informative refe-rence, de même que les WS* de Microsoft, IBM et BEA, ou la spécification BPSS d'ebXML, qui sont en développement à Oasis. Cette référence formelle sera-t-elle suffisante pour éviter que les utilisateurs soient obligés de pratiquer une choreography avec plusieurs chefs d'orchestre à la fois ? En principe, le W3C prétend assurer une cohérence entre les standards qu'il recommande. De son coté, Oasis est une instance ouverte qui laisse ses membres lancer les travaux qui leurs conviennent sans trop pouvoir imposer de cohérence. Mais Microsoft et ses alliés ont, eux, ce souci de cohérence et de modularité entre leurs dernières propositions de standards de la série des WS* d'une part,  et d'autre part leur participation à Oasis ou, au W3C, à la maintenance des standards de base des Services Web. A noter, de ce point de vue, que deux nou-velles versions de travail des parties 1 (Core) et 2 ( Message Exchange Patterns) de la version WSDL 2_0 viennent d'être publiées par le W3C, avec Microsoft et Sun comme éditeurs communs ! Autre nouvelle d'un chef d'orchestre potentiel,  l'adoption par l'ISO TC154 de quatre parties techniques d'ebXML comme TS, spécifications techniques qui resteront maintenues par Oasis. Quid, alors, de la syntaxe Edifact du Cefact, toujours norme officielle du TC 154 ?
Au total, une partition qui peut devenir commune au quadrille des chefs d'orchestre W3C, Oasis, Cefact et ISO. Mais sous la houlette de Microsoft and co ?
 
Si , son  Délégué Général, reste impliqué dans la standardisation, en France et dans les instances internationales de l'EDI, l'excel-lente association Editransport (cf VendrEDI n° 70), a néanmoins été mise en liquidation judiciaire. Et pourtant, dans le transport comme ailleurs, en Europe et encore plus aux USA, l'EDI traditionnel continue de se développer. Rançon "injuste" de ce succès, les utilisateurs n'ont plus besoin des instances de standardisation où ils ont mis au point les messages dont ils avaient besoin ! Sauf peut-être pour les secteurs ou cette standardisation de l'EDI est mariée avec des fonctions complémen-taires d'aide au business, comme dans la banque, la distribution ou l'automobile. Pour les instances EDI n'englobant pas d'autres fonctions, le "tout-ebXML" n'a rien arrangé ! Présenter aux PME une usine à gaz révolutionnaire comme le moyen de les faire entrer facilement dans l'e-business a laissé sceptiques des utilisateurs qui, heureux de leur Edifact, voulaient seulement tâter l'eau XML ! A l'eBES comme au Cefact, on ne s'est guère préoccupé de faire tâter l'eau XML grâce à l'EDI sur Internet (AS1 et AS2), ou à la traduction des messages Edifact en XML (sauf, notamment, Dominique Vankemmel). De même,  le position-nement de l'EDI comme forme automatisée des Services Web ne fait qu'un peu s'esquisser avec le BCF du Cefact.
Les instances de standardisation Edifact doivent donc être refondées en partant des préoccupations concrètes des utilisateurs, et non à partir de révo-lutions méthodologiques. De ce point de vue, il est heureux de voir que la prochaine "plénière" du Cefact devrait enfin conférer plus de pouvoirs aux utilisateurs du Forum.
Du coup, l'instance qui chapeautait le Forum, le CSG (Cefact Steering Group) devrait sans doute être dissoute. Et le Président du CSG, Ray Walker, leader incontesté d'Edifact depuis près de 20 ans, a annoncé qu'il prendra du recul. Mais auparavant, Ray a eu l'audace de conduire une démarche très iconoclaste : ouvrir les discussions sur le BC F avec Microsoft au bénéfice des 95% d'utilisa-teurs qui, cela plaise ou non, sont les clients de Microsoft ! Salut Ray !
  Pour que "le message passe" il faut être d'accord sur le sens des données   Petit Glossaire du B2Bfr

   RDF ou Topic Maps 
Des UIDs aux URIs :
    pour le mapping sémantique ? 
 
de la library aux namespaces
Il faut disposer d'un outil de mapping entre les sémantiques de systèmes hétérogènes, surtout s'il s'agit d'automatiser les échanges. Les numéros 5658 67, 72, 73 et 74 de VendrEDI ont insisté sur RDF et OWL, tandis que les numéros 57 et 65 présentaient Topic Maps. Voir le Primer pour RDF et une introduction TAO pour Topic Maps. Le doublon est réel : d'un côté RDF du W3C, et de l'autre les Topic Maps de l'ISO, sont bien deux séries d'outils sémantiques. Il n'est pas inutile de les comparer, de vérifier leur interopérabilité, et de déterminer celui de ces outils paraissant le mieux adapté à la sémantique de l'e-business.
Dans un article très pédagogique de la société norvégienne Ontopia, les mérites respectifs des deux outils sont présentés et on peut effectivement vérifier que RDF et Topic Maps ne sont pas incompatibles. Ils peuvent même s'enrichir mutuel-lement. Tous deux parlent de "choses" identifiées avec des URIs, des resources dans RDF, des subjects dans Topic Maps. Mais les resources  ne sont pas limités aux pages Web, ni les subjects au KM (knowledge management) ; RDF comme Topic Maps peuvent tous deux très bien assurer le mapping des concepts de l'e-business et de ses données codées ou non. La question est alors : quel est l'outil le mieux adapté à ce mapping ? Les assertions simples RDF avec sujet, attribut et objet  ou, dans Topic Maps, nom, occurrence et des associations pouvant être multiples ? 
Le critère de choix pourrait être l'adaptation à une utilisation automatisée, mais relativement simple permettant de prévoir et de traiter des correspon-dances univoques. Sans prétendre épuiser le sujet, il semble que Topic Maps, prévu pour le traitement des connaissances, soit mieux adapté à des utilisa-tions humaines complexes. Au contraire, RDF et ses assertions simples, conçues pour un traitement machine dans le cadre d'un Semantic Web automa-tisé, parait mieux adapté pour organiser une interopérabilité sémantique entre applications qui puisse justement être automatisée. D'autant qu'au niveau des ontologies, OWL (Web Ontology Lan-guage) permet d'élargir la mise en oeuvre de RDF, par exemple pour traiter la complexité du rapprochement entre domaines entiers.
Comme la compatibilité entre RDF et Topic Maps garantit qu'il n'y aura pas de guerre de religion entre W3C et ISO, il serait dommage que la standardisation de l'e-business ne se joigne pas à un mouvement pouvant réellement devenir universel. 
 
Pour que "le message passe", il ne suffit pas de définir chaque donnée, encore faut-il identifier ces définitions et publier le chemin d'accès à ces défini-tions identifiées, pour que chacun puisse s'y référer sans ambiguïté. Avant XML et le Web, la solution était la library, du type répertoire centralisé TDID Edifact. La library  est encore prévue par ebXML où la CCTS spécifie que les Core Components (CC) doivent être identifiés par des UIDs (Unique IDentifiers). C'est toujours un mécanisme très top down : même si les propositions viennent des sec-teurs, c'est l'administration centralisée de la library qui décidera d'inclure un nouveau concept et de lui attribuer un nouvel UID.
A l'inverse, l'eXtensibilité de XML comporte un mécanisme non centralisé : pour éviter l'ambiguïté de deux balises portant le même nom tout en se référant à des concepts différents, il est prévu que l'on mentionne dans chaque balise un namespace. C'est un URI (Uniform Resource Identifier), le plus souvent un URL, qui donne l'adresse sur le Web de la resource où trouver la définition utilisée dans la balise XML.   Ce mécanisme des URIs de namespaces pour des balises XML à différencier ne suppose pas d'administrateur centralisé, et laisse chaque secteur ou communauté d'échanges en charge de définir ses URIs. C'est donc un méca-nisme bottom up utilisant pleinement les possibilités de la "toile". Mais comment relier alors des domaines voisins si tout le monde fait ce qu'il veut ? Trois conditions pour une réponse satisfaisante à cette question : 1/ que les URIs soient stables et gérés par des organismes reconnus, Swift pour les données bancaires etc. 2/ que les URIs ne soient pas vides mais contiennent bien les définitions des balises 3/ que, si besoin, ces définitions soient reliées par RDF pour expliciter l'équivalence, l'inclusion, la différence de contexte etc. entre deux définitions voisines. Un tel travail avec RDF n'étant à faire qu'en bilatéral entre deux secteurs voulant auto-matiser leurs relations. Ce serait, de toute façon, encore plus nécessaire dans la library ebXML pour décliner les CC suivant des BIE tenant compte des contextes. Encore une fois, la différence entre une library centralisée et  des réseaux d'URIs et de namespaces étant  que deux secteurs ayant à com-muniquer peuvent définir cette articulation de leurs namespaces sans la  permission de quiconque. La culture de la "toile" devrait donc faire passer de la library des "anciens" de l'EDI à des réseaux "modernes" d'URIs. 
Ce numéro 76 de VendrEDI a été adressé à 1209 abonnés      Pour écrire    
Tous les numéros de VendrEDI peuvent être téléchargés à  http://www.actimum.com/acvendredi.htm