Bonjour,
 
Ci-dessous VendrEDI n° 73 à 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.
 
Cordialement
 
Claude Chiaramonti
 
 


 
 
   VendrEDI   lettre de Claude Chiaramonti
 sur les données de
l'échange électronique
           Numéro 73      13 février 2004
    UBL et CC ebXML :
 
e-Business Registry
      réconciliation à l'ISO ? 
liant UDDI et ebXML Registry ?
Le portail Danois pour les achats publics (étendus au privé), fait partie d'un projet XML national super-visé par un comité pour la standardisation des schémas XML et des "information objects". Ce Danish XML Committee vient d'annoncer pour l'e-commerce, et donc le portail, l'adoption d' UBL (Universal Business Language) mis au point par un TC d'Oasis (avec la participation de France Télécoms) qui est présidé par Jon Bosak (Sun), le vice-président étant Mark Crawford (LMI, agence de management du gouvernement US) qui est en même temps editor du groupe chargé des Core Components (CC) au Cefact.
Le vocabulaire d'UBL respecte d'ailleurs les spécifi-cations de ces Core Components ebXML, mais peut être utilisé indépendamment du framework ebXML, lequel, avec ses CC, peut aussi ignorer UBL. D'ailleurs, si un projet de Hong-Kong associe UBL et les CC ebXML, le projet européen IDA, Interchange of Data between Administrations (dont le volet eProcurement mentionne le portail danois) fait souvent référence à ebXML comme aux Services Web sans mentionner spécialement UBL. En effet, UBL s'est développé à Oasis car le Cefact s'est surtout attaché à la définition des Core Components ebXML plutôt qu'à leur rassem-blement. D'où le "je t'ebXML moi non plus" entre Oasis et le Cefact ! D'où un développement para-llèle dont le côté désordre vient d'être signalé à la tutelle ONU du Cefact par le Chef de la Délé-gation Française, Jean-Pierre Henninot (Ministère de l'Industrie). UBL a ainsi accueilli les ajouts souhaités par le portail danois. Et la question : "Où développer les Core Components, dans les groupes d'UBL, ou dans ceux du Cefact ? " a été posée aux Communautés EDI par l'association crEDIble.
En fait, la réconciliation dans un seul registre sémantique viendra peut-être de l'ISO : d'une part, UBL, une fois adopté comme recommandation Oasis, devrait être présenté à l'ISO TC 154 pour être normalisé, d'autre part, l'ISO a entamé la mise à jour de sa norme TDED datant de 1993 (données du trade) en y incluant notamment le TDID (données Edifact mises à jour deux fois par an) et la définition des Core Components. L'ISO TC 154 pourrait ainsi aboutir à un EDI+UBL+CCebXML.
 
La partie e-business registry est le maillon faible commun aux Services Web et à ebXML : aussi bien UDDI qu'ebXML Registry sont en retard par rap-port à SOAP et à ebXML messaging (ebMS). Cette difficulté de démarrage est habituelle, de tels répertoires n'ayant d'intérêt que si suffisamment d'entreprises s'y sont inscrites, mais les entreprises ne s'y inscrivant que s'ils présentent déjà de l'in-térêt ! D'où la nécessité, au moins d'éviter toute concurrence inutile entre eux en précisant bien leurs domaines respectifs de prédilection, voire l'avantage de pouvoir s'épauler l'un l'autre en leur assurant une interopérabilité opérationnelle.
UDDI, déjà souvent utilisé en interne, est centré sur la fonction discovery consistant à enregistrer, d'une part, les types de Services Web pouvant être offerts, et d'autre part, l'indication par les entreprises de ceux de ces services qu'elles offrent. C'est la fonction "annuaire" d'un e-business registry.
La spécification ebXML Registry (en fait composée de deux spécifications, ebXML Registry Information Model (ebRIM) et ebXML Registry Services (ebRS) va plus loin que cette simple fonction d'annuaire : d'une certaine manière, on peut dire que si ebXML Registry conduit au CPA (Collaboration Partnership Agreement), UDDI s'en tient à un CPP (Collaboration Partnership Profile). Dès 2001, l'articulation des annuaires a été étudiée dans le sens inclure dans UDDI des références à des composants ebXML, CPP, Business Process Schemas Specifications etc. Des étapes supplémentaires pourraient être de mentionner dans UDDI la référence à un ebXML Registry dans son ensemble, de pouvoir transférer de l'information d'un type de registry à l'autre et d'avoir un mécanisme de query permettant d'inter-roger les deux types de registries à la fois.
En attendant, l'interopérabilité entre UDDI et ebXML Registry s'améliorera sans doute, mais sans qu'une fusion soit pour autant souhaitable. Leurs forces respectives sont en effet complémentaires : d'une part annuaires internes de services s'étendant prudemment à l'extérieur pour UDDI, d'autre part collaborative commerce interactif pour ebXML Registry pouvant apparaître dans certains secteurs ou Communautés.
 
  Pour que "le message passe" il faut être d'accord sur le sens des données   Petit Glossaire du B2Bfr

  XRI et XDI (Dataweb)
 Le sens commun :
       pour le partage de données 
 
 des taxinomies à l'ontologie 
Avant l'interopérabilité sémantique des contenus, il y a la nécessaire interconnectivité entre les conte-nants. Oasis propose pour cela, d'une part Exten-sible Resource Identifiers (XRIs), d'autre part XRI Data Interchange (XDI). Outils de cross-domain security and privacy management, XRI et XDI peuvent servir à l'enregistrement sur des sites Web, à relier des carnets d'adresses et des agendas, à  des recherches croisées  sur de multiples sites Internet, à la synchronisation d'outils, au remplissage de  formulaires et à des transactions d'e-commerce. De manière générale, XDI permet de sécuriser le partage et l'échange automatisés de données à partir de XDI Links reliant les documents et les resources à travers leurs identités XRI. Le but de XDI est d'identifier, décrire, relier et synchroniser toute donnée en tant que machine-readable "dataweb", de même que tout contenu peut être relié dans le human-readable Web d'aujourd'hui. De plus, les XDI links permettront de contrôler "contractuellement" authority, security, privacy et rights of shared data. Le Livre Blanc pour la 1ère réunion du Comité XDI d'Oasis (télé-conférence le 20 février 2004) précise en quoi les XDI links sont donc plus que des simples pointages d'une resource vers une autre, mais des tuyaux à double sens entre ces resources. De plus, les XDI pipes seront permanents, même si un XRI a changé, et surtout permettront un contrôle fin des données passant dans le tuyau à partir d'optionnels contracts relatifs à chaque XDI link. Ces contrats, eux-mêmes des documents XDI, pourront être mis à jour et pourront traiter de l'authentification, des autorisations, contrôles d'accès, d'utilisation, de redistribution et de synchronisation des données. A noter que XDI intéresse déjà le Trusted Computing Group incluant Microsoft, IBM ou Sun, mais sans que cela vaille encore engagement de l'utiliser.
XDI accueillera les XRI synonyms, par exemple pour le même XRI, human e-names différents suivant le langage et machine e-numbers différents suivant les applications, ce qui faciliterait le map-ping entre applications : "map once, link every-where" ! L'idée, avec un XDI Meta-Schema, est de retrouver la simplicité du Web actuel en dépassant la multiplicité des schémas XML, en transportant les descriptions WSDL de Services Web ou les triples RDF du Semantic Web.
Au total, le XRI/XDI Dataweb  entend donc relier les meilleurs aspects du Web actuel, des Services Web en cours et du futur Semantic Web.
 
Il est de bon ton de vouloir encadrer l'eXtensibilité de XML pour éviter autant que possible une inutile prolifération de langages-métiers et de balises différentes se référant  en fait au même concept sous-jacent. Pour cela, il convient de pouvoir inde-xer ses données sur des catalogues d'informations pouvant être des nomenclatures organisées, aussi appelées taxinomies (les anglo-américains utilisent taxonomies qui est déconseillé en français). Mais encore faut-il d'abord établir une liste sans omission ni répétition. Et comme c'est assez lourd, autant se référer à ce qui a pu être déjà rassemblé dans un taxonomy warehouse. Ensuite, le mécanisme des URI pointant à partir des balises des données vers ces taxonomies permet de bien savoir de quoi on parle dans un domaine. Ordonner ce "sens commun" est tout  particulièrement important pour les données administratives autour desquelles de nombreuses applications privées s'organisent. Les agences US ont ainsi été invitées par l'E-Government Act à établir leur taxonomy.
Un problème naît lorsque des échanges électro-niques de données doivent être organisés entre domaines ou secteurs différents. Deux solutions :
1/ Rapprocher les taxinomies, ce qui peut obliger à une redéfinition complète, les taxinomies n'ayant pas forcément été construites avec des partitions bien compatibles. Et simplement les réunir dans une liste de codes "fourre-tout" ne régle rien pour un traitement automatisé. En effet, si la comparaison des libellés peut suffire au spécialiste pour identifier le concept sous-jacent, il faudra aller plus loin pour un EDI "ouvert" ou un Service Web sans aucune intervention humaine.
2/ Passer à l'ontologie pour relier des taxinomies différentes pouvant avoir des zones de recou-vrement sémantique. Après l'indexation des données vers la taxinomie, on passe ainsi à la modélisation entre taxinomies. Là, les outils existent : RDF  et XSLT permettent d'exécuter (cf VendrEDI n° 71) les transformations identifiées.
Mais c'est la sémantique et la syntaxe d'OWL (Web Ontology Language), avec ses trois versions Lite, DL et Full, qui valorisent complétement RDF et sa capacité à fournir un "sens commun" qui soit "machine processable". Et de même qu'il faut apprendre RDF  (cf VendrEDI n° 72), il faut apprendre OWL, par exemple à partir du  Guide OWL du W3C, assez convivial pour un francophone, puisqu'il est basé sur un exemple d'ontologie oenologique !
Ce numéro 73 de VendrEDI a été adressé à 1132 abonnés      Pour écrire    
Tous les numéros de VendrEDI peuvent être téléchargés à  http://www.actimum.com/acvendredi.htm