AkaSigPrenez une once de peer-to-peer, trois coudées de web sémantique, deux livres de bureautique et un denier de réseau sociaux, malaxez avec énergie et vous obtenez… le “Networked Semantic Desktop”. Ca c’est de la convergence où je ne m’y connais pas… Projet de recherche, circulez, il n’y a rien à télécharger ! Vu également ici.
IBM a récemment acquis SRD, éditeur d’un logiciel qui met en correspondance :
Bref, un logiciel tout à fait adéquat pour qui veut se constituer la parfaite panoplie du petit big brother.
Cette technologie semble un peu similaire aux méta-annuaires qui se sont spécialisés dans la jointure simple d’identités électroniques. Mais elle semble trouver ses principales applications dans le domaine du data mining pour le marketing et la CRM, dans l’analyse du risque crédit et dans le renseignement d’Etat et la sécurité privée. Elle me fait penser à Semagix qui, tout en ciblant des champs d’application similaires (CRM, détection d’opérations financières frauduleuses et déconstruction de réseaux sociaux mafieux), mise sur une approche “web sémantique”.
Il serait sans doute intéressant de savoir sur quelle approche technologique s’appuie SRD et si cette techno est suffisamment robuste, fiable et automatisée pour apporter des éléments de solution dans des problématiques très opérationnelles de gestion des identités électroniques.
The Central Authentication Service (aka CAS) is an open source lightweight framework that provides Web Single Sign On to big organizations (universities, agencies, corporations). It seems to be wildly used and seen as as much mature and reliable as the struts framework.
An existing server can benefit CAS WebSSO features if its technology is supported by a CAS client. So, please welcome Zope’s CAS User Folder, that SSOizes Zope within complex SSO infrastructures.
Le Gartner Group reconnait dans les wikis, les blogs, les logiciels de réseautage social et RSS un fort potentiel pour l’entreprise. L’attention portée par le cabinet d’analyse au mouvement de la gestion des connaissances “grass-roots” contribuer à apporter à celui-ci la légitimité (la consécration ?) qui lui permettront de prendre pied dans le secteur privé.
Depuis quelques mois, je sentais le vent venir : mon chef me parle de plus en plus souvent blogs et RSS (”c’est quoi ?”, “à quoi ça sert ?”, “comment je pourrais essayer ?”). Au début, c’était peut-être un peu pour me faire plaisir ? Mais, non, il a même souhaité que je lui installe un agrégateur RSS sur son poste de travail. Ah ! Du concret ! Ajouté à cela tout le buzzwording du Gartner et autres MetaGroup sur le sujet (”blogs et wiki sont les outils de collaboration de troisième génération”), on peut dire que, ça y est, les grandes entreprises portent l’attention de leur informatique sur ce sujet (il était temps). Maintenant, il faudra encore attendre un peu avant de voir des usages prendre racines à l’échelle de l’entreprise entière. En attendant, carnettons et agrégeons tous en coeur !
Zemantic is an RDF module for Zope (read its announcement). From what I read (not tested by me yet), it implements services similar to zope catalogs and enables universal management of references (such as the Archetypes reference engine but in a more sustainable way). It is based on RDFLib, similarly to ROPE.
I feel enthusiastic about this product since it sounds to me like a good future-proof solution for the management of metadata, references and structured data within content management systems and portals. Plus Zemantic would sit well in my vision of Plone as a semantic aggregator.
Example One : I am looking for my next job. So I subscribe to many job sites in order to receive notifications by email of new job ads (example = Monster…). But I’d rather check these in my RSS aggregator instead of my mailbox. Or in some sort of aggregating Web platform. Thus, I would be able to do many filtering/sorting/ranking/comparison operations in order to navigate through these numerous job ads.
Example Two : I want to buy a digital camcorder. So I want to compare the available models. Such a comparison implies that I rank the most common models according to their characteristics. Unfortunately, the many sites providing reviews or comparisons of camcorders are not often comprehensive and they don’t offer me the capability of comparing them with respect to my way of ranking and weighting the camcorder features (example = dvspot). So I would prefer pumping all the technical stuff from these sites and manipulate this data locally on my computer. Unfortunately, this data is merged within HTML. And it may be complex to extract it automatically from all the presentation code.
These are common situations : interesting data spread all over the web and merged in HTML presentation code. How to consolidate this data so that you can analyze and process it with your own tools ? In some near future, I expect this data will be published so that it is directly processable by computers (this is what the Semantic Web is intending to do). For now, I was used to do it with Excel (importing Web data, then cleaning it and the like) and I must admit that Excel is fairly good at it. But I’d like some more automation for this process. I’d like some more scripting for this operation so that I don’t end with inventing complex Excel macros or formulas just to automate Web site crawling, HTML extraction and data cleaning. With such an itch to scratch, I tried to address this problem with python.
This series of messages introduces my current hacks that automate web sites crawling and data extraction from HTML pages. The current output of these scripts is a bunch of CSV files that can be further processed … in Excel. I wish I would output RDF instead of CSV. So there remains much room for further improvement (see RDF Web Scraper for a similar but approach). Anyway… Here is part One : how to crawl complex web sites with Python ?. The next part will deal with data extraction from the retrieved web pages, involving much HTML cleansing and parsing.
My crawlers are fully based on the John L. Lee’s mechanize framework for python. There are other tools available in Python. And several other approaches are available when you want to deal with automating the crawling of web sites. Note that you can also try to scrape the screens of legacy terminal-based applications with the help of python (this is called “screen scraping”). Some approaches of web crawling automation rely on recording the behaviour of a user equipped with a web browser and then reproduce this same behaviour in an automated session. That is an attractive and futuristic approach. But this implies that you find a way to guess what the intended automatic crawling behaviour will be from a simple example. In other words, with this approach, you have either to ask the user to click on every web link (all the job postings…) and this gives no value to the automation of the task. Or your system “guesses” what automatic behaviour is expected just by recording a sample of what a human agent would do. Too complex… So I preferred a more down-to-earth solution implying that you write simple crawling scripts “by hand”. (You may still be interested in automatically record user sessions in order to be more productive when producing your crawling scripts.) As a summary : my approach is fully based on mechanize so you may consider the following code as example of uses of mechanize in “real-world” situations.
For purpose of clarity, let’s first focus on the code part that is specific to your crawling session (to the site you want to crawl) . Let’s take the example of the dvspot.com site which you may try to crawl in order to download detailed description of camcorders :
# Go to home page
#
b.open("http://www.dvspot.com/reviews/cameraList.php?listall=1&start=0")
#
# Navigate through the paginated list of cameras
#
next_page = 0
while next_page == 0:
#
# Display and save details of every listed item
#
url = b.response.url
next_element = 0
while next_element >= 0:
try:
b.follow_link(url_regex=re.compile(r"cameraDetail"), nr=next_element)
next_element = next_element + 1
print save_response(b,"dvspot_camera_"+str(next_element))
# go back to home page
b.open(url)
# if you crawled too many items, stop crawling
if next_element*next_page > MAX_NR_OF_ITEMS_PER_SESSION:
next_element = -1
next_page = -1
except LinkNotFoundError:
# You certainly reached the last item in this page
next_element = -1
#
try:
b.open(url)
b.follow_link(text_regex=re.compile(r"Next Page"), nr=0)
print "processing Next Page"
except LinkNotFoundError:
# You reached the last page of the listing of items
next_page = -1
You noticed that the structure of this code (conditional loops) depends on the organization of the site you are crawling (paginated results, …). You also have to specify the rule that will trigger “clicks” from your crawler. In the above example, your script first follows every link containing “cameraDetail” in its URL (url_regex). Then it follows every link containing “Next Page” in the hyperlink text (text_regex).
This kind of script is usually easy to design and write but it can become complex when the web site is improperly designed. There are two sources of difficulties. The first one is bad HTML. Bad HTML may crash the mechanize framework. This is the reason why you often have to pre-process the HTML either with the help of a HTML tidying library or with simple but string substitutions when your tidy library breaks the HTML too much (this may be the case when the web designer improperly decided to used nested HTML forms). Designing the proper HTML pre-processor for the Web site you want to crawl can be tricky since you may have to dive into the faulty HTML and the mechanize error tracebacks in order to identify the HTML mistakes and workaround them. I hope that future versions of mechanize would implement more robust HTML parsing capabilities. The ideal solution would be to integrate the Mozilla HTML parsing component but I guess this will be some hard work to do. Let’s cross our fingers.
Here are useful examples of pre-processors (as introduced by some other mechanize users and developpers) :
class TidyProcessor(BaseProcessor):
def http_response(self, request, response):
options = dict(output_xhtml=1,
add_xml_decl=1,
indent=1,
output_encoding='utf8',
input_encoding='latin1',
force_output=1
)
r = tidy.parseString(response.read(), **options)
return FakeResponse(response, str(r))
https_response = http_response
#
class MyProcessor(BaseProcessor):
def http_response(self, request, response):
r = response.read()
r = r.replace('"image""','"image"')
r = r.replace('"','"')
return FakeResponse(response, r)
https_response = http_response
#
# Open a browser and optionally choose a customized HTML pre-processor
b = Browser()
b.add_handler(MyProcessor())
The second source of difficulties comes from non-RESTful sites. As an example the APEC site (a French Monster-like job site) is based on a proprietary web framework that implies that you cannot rely on links URLs to automate your browsing session. It took me some time to understand that, once loggin in, every time you click on a link, you are presented with a new frameset referring to the URLs that contain the interesting data you are looking for. And these URLs seem to be dependent on your session. No permalink, if you prefer. This makes the crawling process even more tricky. In order to deal with this source of difficulty when you write your crawling script, you have to open both your favorite text editor (to write the script) and your favorite web browser (Firefox of course !). One key knowledge is to know mechanize “find_link” capabilities. These capabilities are documented in _mechanize.py source code, in the find_link method doc strings. They are the arguments you will provide to b.follow_link in order to automate your crawler “clicks”. For more convenience, let me reproduce them here :
Links include anchors (a), image maps (area), and frames (frame,iframe).
Enough with explanations. Now comes the full code in order to automatically download camcorders descriptions from dvspot.com. I distribute this code here under the GPL (legally speaking, I don’t own the copyleft of this entire code since it is based on several snippets I gathered from the web and wwwsearch mailing list). Anyway, please copy-paste-taste !
from mechanize import Browser,LinkNotFoundError
from ClientCookie import BaseProcessor
from StringIO import StringIO
# import tidy
#
import sys
import re
from time import gmtime, strftime
#
# The following two line is specific to the site you want to crawl
# it provides some capabilities to your crawler for it to be able
# to understand the meaning of the data it is crawling ;
# as an example for knowing the age of the crawled resource
#
from datetime import date
# from my_parser import parsed_resource
#
"""
Let's declare some customized pre-processors.
These are useful when the HTML you are crawling through is not clean enough for mechanize.
When you crawl through bad HTML, mechanize often raises errors.
So either you tidy it with a strict tidy module (see TidyProcessor)
or you tidy some errors you identified "by hand" (see MyProcessor).
Note that because the tidy module is quite strict on HTML, it may change the whole
structure of the page you are dealing with. As an example, in bad HTML, you may encounter
nested forms or forms nested in tables or tables nested in forms. Tidying them may produce
unintended results such as closing the form too early or making it empty. This is the reason
you may have to use MyProcessor instead of TidyProcessor.
"""
#
class FakeResponse:
def __init__(self, resp, nudata):
self._resp = resp
self._sio = StringIO(nudata)
#
def __getattr__(self, name):
try:
return getattr(self._sio, name)
except AttributeError:
return getattr(self._resp, name)
#
class TidyProcessor(BaseProcessor):
def http_response(self, request, response):
options = dict(output_xhtml=1,
add_xml_decl=1,
indent=1,
output_encoding='utf8',
input_encoding='latin1',
force_output=1
)
r = tidy.parseString(response.read(), **options)
return FakeResponse(response, str(r))
https_response = http_response
#
class MyProcessor(BaseProcessor):
def http_response(self, request, response):
r = response.read()
r = r.replace('"image""','"image"')
r = r.replace('"','"')
return FakeResponse(response, r)
https_response = http_response
#
# Open a browser and optionally choose a customized HTML pre-processor
b = Browser()
b.add_handler(MyProcessor())
#
""""
Let's declare some utility methods that will enhance mechanize browsing capabilities
"""
#
def find(b,searchst):
b.response.seek(0)
lr = b.response.read()
return re.search(searchst, lr, re.I)
#
def save_response(b,kw='file'):
"""Saves last response to timestamped file"""
name = strftime("%Y%m%d%H%M%S_",gmtime())
name = name + kw + '.html'
f = open('./'+name,'w')
b.response.seek(0)
f.write(b.response.read())
f.close
return "Response saved as %s" % name
#
"""
Hereafter is the only (and somewhat big) script that is specific to the site you want to crawl.
"""
#
def dvspot_crawl():
"""
Here starts the browsing session.
For every move, I could have put as a comment an equivalent PBP command line.
PBP is a nice scripting layer on top of mechanize.
But it does not allow looping or conditional browsing.
So I preferred scripting directly with mechanize instead of using PBP
and then adding an additional layer of scripting on top of it.
"""
#
MAX_NR_OF_ITEMS_PER_SESSION = 500
#
# Go to home page
#
b.open("http://www.dvspot.com/reviews/cameraList.php?listall=1&start=0")
#
# Navigate through the paginated list of cameras
#
next_page = 0
while next_page == 0:
#
# Display and save details of every listed item
#
url = b.response.url
next_element = 0
while next_element >= 0:
try:
b.follow_link(url_regex=re.compile(r"cameraDetail"), nr=next_element)
next_element = next_element + 1
print save_response(b,"dvspot_camera_"+str(next_element))
b.open(url)
# if you crawled too many items, stop crawling
if next_element*next_page > MAX_NR_OF_ITEMS_PER_SESSION:
next_element = -1
next_page = -1
except LinkNotFoundError:
# You reached the last item in this page
next_element = -1
#
try:
b.open(url)
b.follow_link(text_regex=re.compile(r"Next Page"), nr=0)
print "processing Next Page"
except LinkNotFoundError:
# You reached the last page of the listing of items
next_page = -1
#
return
#
#
#
if __name__ == '__main__':
#
""" Note that you may need to specify your proxy first.
On windows, you do :
set HTTP_PROXY=http://proxyname.bigcorp.com:8080
"""
#
dvspot_crawl()
In order to run this code, you will have to install mechanize 0.0.8a, pullparser 0.0.5b, clientcookie 0.4.19, clientform 0.0.16 and utidylib. I used Python 2.3.3. Latest clientcookie’s version was to be integrated into Python 2.4 I think. In order to install mechanize, pullparser, clientcookie and clientform, you just have to do the usual way :
python setup.py build python setup.py install python setup.py test
Last but not least : you should be aware that you may be breaking some terms of service from the website you are trying to crawl. Thanks to dvspot for providing such valuable camcorders data to us !
Next part will deal with processing the downloaded HTML pages and extract useful data from them.
La technologie RDF est la brique de base du web sémantique. Dans une grange, un poète vous rappelle qu’à l’école maternelle, vous saviez déjà faire du RDF avec des ours funambules.
Pour faire suite à mes deux derniers messages sur les carnets web en entreprise, ne pas louper la lecture des articles connexes de Padawan et de Loic Le Meur. Au passage, bonjour à Gilles (celui qui est en vrac et en ligne) qui s’intéresse québecquoisement aux mêmes sujets ! :)
Pour créer un portail d’entreprise en J2EE, il y a le choix entre acheter un coûteux portail propriétaire (IBM ou BEA pour ne citer que les leaders des serveurs d’application J2EE) ou recourir à un portail J2EE open source. Mais autant l’offre open source en matière de serveurs d’application J2EE (JBoss, Jonas) atteint une certaine maturité qui la rend crédible pour des projets de grande envergure, autant l’offre open source en matière de portails J2EE semble largement immature. Ceci semble fermer à l’open source le marché des portails et de la gestion de contenu des grandes entreprises pour encore de nombreuses années.
Aux yeux de la communauté J2EE, des cabinets de conseil du secteur et des gros éditeurs, le meilleur produit du marché sera nécessairement celui qui supportera au moins les deux standards du moment : JSR 168 pour garantir la portabilité des portlets d’un produit à l’autre, et WSRP pour garantir l’interopérabilité des portlets distantes entre leur serveur d’application et le portail qui les agrège et les publie. Il y a donc dans cette gamme de produit une course à celui qui sera le plus dans la mode de la “SOA” (Service-Oriented Architecture). Comme portails J2EE open source, on cite fréquemment Liferay et Exo. Cette offre open source n’est pas étrangère à la fanfaronnade SOA (il faut bien marketer les produits, eh oui…). Du coup, l’effort de développement des portails J2EE open source semble davantage porter sur l’escalade de la pile SOA que sur l’implémentation de fonctionnalités utiles. C’est sûrement ce qui amène la communauté J2EE à constater que les portails J2EE open source manquent encore beaucoup de maturité et de richesse fonctionnelle surtout lorsqu’on les compare à Plone, leader du portail / CMS open source. En effet, Plone s’appuie sur un serveur d’application Python (Zope) et non Java (a fortiori non J2EE) ; il se situe donc hors de la course à JSR168 et semble royalement ignorer le bluff WSRP.
Nombreuses sont les entreprises qui s’évertuent à faire de J2EE une doctrine interne en matière d’architecture applicative. Confrontées au choix d’un portail, elles éliminent donc rapidement l’offre open source J2EE (pas assez mûre). Et, plutôt que de choisir un portail non J2EE reconnu comme plus mûr, plus riches en fonctionnalités et moins coûteux, elles préfèrent se cantonner à leur idéologie J2EE sous prétexte qu’il n’y a point de salut hors J2EE/.Net. Pas assez buzzword compliant, mon fils… Pfff, ne suivez pas mon regard… :-(
On les appelle couramment des weblogs, ou blogs pour faire plus court, ou carnets web pour faire plus francophone. Certains carnets web s’étant spécialisés, on a poussé les néologismes : klogs désigne les carnets web dédiés au partage de connaissance (knowledgelogs) ; plogs désigne les carnets de bord d’équipes projets (project logs) ; moblogs désigne les carnets web dont la mise à jour s’effectue depuis un PDA ou un téléphone portable (mobile logs). Sans compter les photologs et autres vlogs (video logs). Et puisque les carnets Web font leur entrée dans le monde de l’entreprise, on en revient à dire que blog = business-log.
Un journaliste du magazine CIO (dédié aux directeurs informatiques) confirme que parmi les plus grosses entreprises au monde (Fortune 500), un nombre significatif utilisent des blogs au sein de leurs départements informatiques notamment en tant que project logs pour coordonner et commenter l’avancement de projets informatiques.
Il cite dans son article les motivations de ces entreprises, et ses lecteurs en ajoutent quelques unes :
[leur] mélange de commentaires critiques est vu davantage comme constructif que l’inverse
si j’étais un gestionnaire des ventes d’un géant pharmaceutique, j’apprécierais de pouvoir de temps en temps parcourir le carnet de mon interlocteur informatique qui installe un système d’automatisation des forces de vente
[on peut] difficilement imaginer un meilleur moyen d’ancrer les nouveaux membres d’un service informatique dans un même contexte
un plog donne l’occasion à un leader d’observer dans son ensemble le “storyboard continu” [de son projet] pour évaluer si les actions ou les réflexions en cours vont permette de produire les livrables attendus pour le projet
Il peut ainsi réagir comme le ferait un réalisateur ou un metteur en scène
les plogs et leurs cousins permettent au savoir de rester proche du créateur de ce savoir
Les carnets web sont des outils individuels et qui valorisent la contribution de l’individu plutôt que de le noyer dans la masse
L’auteur de cet article, et ceux qui l’ont commenté, citent également divers risques qu’il s’agit de gérer intelligemment dans l’adoption des carnets web en entreprise :
la ligne entre la libre expression et l’auto-indulgence est effroyablement fine
et les carnetiers peuvent avoir tendance à verser dans l’auto-promotion ou le noyage de leurs lecteurs potentiels dans une prose égocentrique qui n’intéresse qu’eux-mêmes
Dave Pollard avait quant à lui, sur son carnet Web, réuni un certain nombre de (bons) conseils pour mettre en oeuvre un politique de carnettage dans une entreprise :
Le journaliste de CIO.com estime que
les organisations IT qui utilisent efficacement les blogs comme outils de management (ou comme ressources pour la communication) sont probablement des environnements de développement [humain] qui prennent au sérieux les personnes et les idées.
Il estime enfin que
lorsqu’un développeur ou un manager ou un chargé de support clientèle réussit à produire un plog qui suscite l’attention, qui sensibilise et qui suscite le changement, alors c’est une compétence qui mérite reconnaissance et récompense.
J’ai été très impressionné par la qualité de la vision du directeur scientifique de chez Mc Donald Bradley au sujet du web sémantique. Il présente non seulement de très justes illustrations de la vision de Tim Berner’s Lee mais il la remet également de manière très pertinente dans le contexte général de l’évolution de l’informatique sur les dernières décennies, à travers notamment la perspective d’applications concrètes pour l’entreprise. Sa déclaration d’indépendance des données laisse présager un avenir excellent pour la nouvelle discipline informatique qu’est l’architecture de l’information. McDonald Bradley est une entreprise que je trouve d’autant plus intéressante qu’elle se positionne sur des marchés verticaux clairement délimités, au sein du secteur public (et donc précurseurs en matière d’open source) : les services de renseignement, la défense, la sécurité, les finances publiques et les collectivités locales. A rapprocher des interrogations de Kendall Grant Clark au sujet de l’appropriation du web sémantique par les communautés du libre ? Malheureusement, je crains qu’il n’existe pas d’entreprise équivalente en France…
On me reproche parfois d’être un peu trop théorique. Alors, concernant le style architectural REST, voici quelques bonnes pratiques et guide de conduite pour construire des services Web conformes au style REST.
Here is an output of my imagination (no code, sorry, just a speech) : what if a CMS such as Plone could be turned into a universal content aggregator. It would become able to retrieve any properly packaged content/data from the Web and import it so that it can be reused, enhanced, and processed with the help of Plone content management features. As a universal content aggregator, it would be able to “import” (or “aggregate”) any content whatever its structure and semantic may be. Buzzwords ahead : Plone would be a schema-agnostic aggregator. It would be a semantic-enabled aggretor
Example : On site A, beer-lovers gather. Site A’s webmaster has setup a specific data schema for the description of beers, beer flabours, beer makers, beer drinkers, and so on. Since site A is rich in terms of content and its community of users is enthusiastic, plenty of beers have been described there. Then site B, powered by a semantic aggregator (and CMS), is interested in any data regarding beverages and beverages impact on human’s health. So site B retrieves beer data from site A. In fact it retrieves both the description of beer1, beer2, beerdrinker1, … and the description of what a beer is, how data is structured when it describes a beer, what the relationship is between a beer and a beer drinker. So site B now knows many things about beer in general (data structure = schema) and many beers specifically (beers data). All this beer data on site B is presented and handled as specific content types. Site B’s users are now able to handle beer descriptions as content items, to process them through workflows, to rate them, to blog on them, and so on. And finallly to republish site B’s own output in such a way it can be aggregated again from other sites. That would be the definitive birth of the semantic web !
There are many news aggregators (RSSBandit, …) that know how to retrieve news items from remote sites. But they are only able to aggregate news data. They only know one possible schema for retrievable data : the structure of a news item (a title + a link + a description + a date + …). This schema is specified in the (many) RSS standard(s).
But now that CMS such as Plone are equipped with schema management engines (called “Archetypes” for Plone), they are able to learn new data schema specified in XML files. Currently, Plone’s archetypes is able to import any schema specified in the form of an XMI file output by any UML modelizing editor.
But XMI files are not that common on the Web. And the W3C published some information showing that any UML schema (class diagram I mean) is the equivalent of an RDF-S schema. And there even is a testbed converter from RDF-S to XMI. And there even are web directories inventoring existing RDF schemas as RDF-S files. Plus RSS 1.0 is based on RDF. Plus Atom designers designed it in such a way it is easily converted to RDF.
So here is my easy speech (no code) : let’s build an RDF aggregator product from Plone. This product would retrieve any RDF file from any web site. (It would store it in the Plone’s triplestore called ROPE for instance). It would then retrieve the associated RDF-S file (and store it in the same triplestore). It would convert it to an XMI file and import it as an Archetypes content type with the help of the ArchGenXML feature. Then it would import the RDF data as AT items conforming to the newly created AT content type. Here is a diagram summarizing this : 
By the way, Gillou (from Ingeniweb) did not wait for my imagination output to propose a similar project. He called it ATXChange. The only differences I see between his proposal and what is said above are, first, that Gillou might not be aware about RDF and RDF-S capabilities (so he might end with a Archetypes-specific aggregator inputting and outputting content to and from Plone sites only) and that Gillou must be able to provide code sooner or later whereas I may not be !
Last but not least : wordpress is somewhat going in the same direction. The semweb community is manifesting some interest in WP structured blogging features. And some plugins are appearing that try to incorporate more RDF features in WP (see also seeAlso).
Did you think the Semantic Web is a stratospheric concept for people smoking too many HTTP connections ? If so, don’t even try to understand what Pierre Levy is intending to do. He and the associatied network of people say they are preparing the next step after the Semantic Web. Well… In fact, I even heard Pierre Levy saying he is preparing the next step in the evolution of mankind, so this is not such a surprise. The worst point in this story is that his ambitious work may be extremely relevant and insightful for all of us, mortals. :)
Voici un papier blanc (si, si…) au sujet de RSS (à nouveau via l’excellent Outils Froids). Enfin un document qui présente l’écosystème RSS en des termes marketing compréhensible par une D.S.I. de grande entreprise… enfin j’espère. Je testerai ce document sur mes collègues et supérieurs à mon retour de congés.
Voici une explication illustrée des usages de ces outils qu’on appelle les blogs ou carnets Web (via Outils Froids du Web). En dehors du fond très juste de ces illustrations, je trouve que leur forme permet de manière élégante d’appréhender des usages technologiques. L’outil, c’est bien. Mais ce sont les usages que chacun batît autour qui en font une technologie.
(Oh ! ben tiens, j’ai réussi à publier un message sur mon carnet entre deux biberons ! auto-félicitation !) :)
01 Informatique a publié un état de l’art très synthétique au sujet des technologies XML. Chaque technologie présentée est qualifiée selon son degré de maturité. Et les seules technologies XML à avoir atteint le degré de maturité maximal sont les suivantes :
Autrement dit, si vous envisagez d’appuyer une architecture informatique sur une technologie XML qui n’est pas dans cette liste, sachez que vous faites un choix technologique risqué car non éprouvé ! A vos risques et périls…
Clever Age a publié dans sa newsletter une excellente et didactique synthèse sur l’interopérabilité J2EE, .NET et PHP. J’en retiens les leçons suivantes :
J’ajouterais que les services Web de style REST offrent un couplage non seulement encore plus lâche (modularité du S.I.) mais également encore plus tardif : inutile, au moment de la conception de vos services Web, de faire des hypothèses sur l’usage qui en sera fait dans le futur, le style REST vous garantit leur intégrabilité future.
La différence essentielle entre le style REST et le style RPC (XML-RPC ou pile SOAP), c’est que le style REST permet l’intégration spontanée (non planifiée centralement) de services alors que la pile SOAP suppose une planification plus centralisée des projets d’intégrations de services à travers la négociation et la spécification de contrats entre fournisseurs et consommateurs de services (et qui dit contrat dit “une certe forme de codification” et donc une certaine perte de flexibilité pour le futur).
Ma conclusion : l’approche REST est plus adaptée aux organisations qui sont elles-mêmes faiblement couplées. Autrement dit : pour faire du SOA sur SOAP, il faut réunir toutes les parties prenantes et établir des contrats de services spécifiques et peu évolutifs ; conséquence : faites du SOAP dans une organisation non centralisée et vous vous retrouverez dans une situation similaire à celle dont se lamentait Reinout Van Rees, une situation qui conduit à l’échec ou au moins au gaspillage d’efforts. Posez-vous plutôt la question :
Au bout d’un moment, j’ai l’impression de me répéter à force de ressasser les mêmes choses sur REST. Mais j’espère que d’un billet à l’autre, mes idées sur le sujet gagnent en clarté (au moins dans ma tête). Et les vôtres ?
Good news ahead : Reinout van Rees has recentrly restarted struggling with his ROPE project. I had just been thinking about the current status of this project this weekend. I hope there will soon be some nice RDF support within Zope. And ROPE is made for this since ROPE = Rdflib + zOPE.
Voici une esquisse de plan de présentation des technologies du Web Sémantique pour un public (francophone) d’informaticiens de grandes entreprises :