3FN Killer
Nicolas Thouvenin
des commits sans rapport avec Pxxo et ses widgets.
En fait, le svn Pxxo héberge (pour le moment) le projet AIT. Ce mini
projet vise à créer une API permettant le stockage et la recherche de
méta données.
Ce projet bien que parfaitement opérationnel n'est pas encore trop
documenté, cependant si cette problématique vous intéresse vous pouvez
consulter ces quelques pages http://ait.touv.fr
--
Nicolas
François Parmentier
http://code.google.com/apis/protocolbuffers/docs/overview.html
Mais ça me fait surtout penser à RDF (qui n'a pas de notion de
hiérarchie, contrairement à Protocol Buffers).
RDF stocke toutes ses informations (métadonnées, comme pour
DublinCore) dans des triplets (triples en anglais).
Objet -> relation -> valeur
Genre:
"a1902425" -> Titre -> "Heroes"
"a1902425" -> Artiste -> "Antonio Vivaldi"
"a1902425" -> Artiste -> "Philippe Jaroussky"
Bon. La syntaxe de mon exemple n'a rien de standard, mais RDF a une
syntaxe XML (parmi d'autres).
Je pense que AIT pourrait faire des import/export en RDF assez
facilement, du coup (même si on risque de perdre le typage au sens
informatique).
Les gens du web sémantique (qui préfèrent maintenant dire web des
données) aiment appliquer aux données en RDF des requêtes en SPARQL.
Du coup, on obtient quasiment une base de données distribuée sur le
web (mais je m'égare).
http://en.wikipedia.org/wiki/Resource_Description_Framework
Nicolas Thouvenin
<francois....@gmail.com> a écrit :
>
> Ça me fait penser à Protocol Buffers, que Google vient de sortir...
> http://code.google.com/apis/protocolbuffers/docs/overview.html
Sauf que Protocol Buffers est un format principalement utilisé pour
des transactions RPC, AIT non
Protocol Buffers dispose d'APIs pour analyser le format et le
manipuler mais (pas encore) pour le stocker ni pour faire des
recherches.
>
> Mais ça me fait surtout penser à RDF (qui n'a pas de notion de
> hiérarchie, contrairement à Protocol Buffers).
> RDF stocke toutes ses informations (métadonnées, comme pour
> DublinCore) dans des triplets (triples en anglais).
> Objet -> relation -> valeur
Pourquoi pas ...
mais d'une part RDF est un format (AIT non) d'autre part ce format ne
sait rien représenter d'autre que des relations (le fameux triples)
Si on veut formaliser de l'information en RDF et utiliser (soyons fou
;-)) une base de données XML il faudra forcement y associer une autre
grammaire xml et jouer avec des espace de noms, bref en théorie RDF
c'est puisant en pratique ça l'est beaucoup moins ...
>
> Genre:
>
> "a1902425" -> Titre -> "Heroes"
> "a1902425" -> Artiste -> "Antonio Vivaldi"
> "a1902425" -> Artiste -> "Philippe Jaroussky"
>
> Bon. La syntaxe de mon exemple n'a rien de standard, mais RDF a une
> syntaxe XML (parmi d'autres).
Pour avoir déjà pratiquer RDF, je crois me souvenir que la
représentation en XML de tes 3 lignes n'est pas si simple...
Si tu maitrises le RDF je suis preneur de la traduction
> Je pense que AIT pourrait faire des import/export en RDF assez
> facilement, du coup (même si on risque de perdre le typage au sens
> informatique).
Je prévois plutôt à l'avenir des import/export en ATOM (bcp plus
pratique et plus utile que le RDF)
mais si tu veux te lancer, AIT repose sur un système de plugin
donc tu peux facilement créer une extension pour traiter du RDF et
implémenter un requêteur SPARQL ;-)
>
> Les gens du web sémantique (qui préfèrent maintenant dire web des
> données) aiment appliquer aux données en RDF des requêtes en SPARQL.
> Du coup, on obtient quasiment une base de données distribuée sur le
> web (mais je m'égare).
>
>
> http://en.wikipedia.org/wiki/Resource_Description_Framework
c'est gens du web ont de bonne idée en théorie mais leur approche
n'est pas très pragmatique contrairement aux gens de chez google ;-)
AIT est loin de tout cela...
le but est de stocker rapidement de l'info sans connaitre à l'avance
leur nombre ni leurs caractéristiques et de disposer d'un moyen simple
pour les retrouver...
tout cela en écrivant un minimum de ligne de code PHP et de code SQL
François Parmentier
On 10 juil, 15:38, "Nicolas Thouvenin" <nthouve...@gmail.com> wrote:
> Le 10 juillet 2008 14:19, François Parmentier
> des transactions RPC, AIT non
> Protocol Buffers dispose d'APIs pour analyser le format et le
> manipuler mais (pas encore) pour le stocker ni pour faire des
> recherches.
> Pourquoi pas ...
> mais d'une part RDF est un format (AIT non) d'autre part ce format ne
> sait rien représenter d'autre que des relations (le fameux triples)
> Si on veut formaliser de l'information en RDF et utiliser (soyons fou
> ;-)) une base de données XML il faudra forcement y associer une autre
> grammaire xml et jouer avec des espace de noms, bref en théorie RDF
> c'est puisant en pratique ça l'est beaucoup moins ...
> > Genre:
>
> > "a1902425" -> Titre -> "Heroes"
> > "a1902425" -> Artiste -> "Antonio Vivaldi"
> > "a1902425" -> Artiste -> "Philippe Jaroussky"
>
> > Bon. La syntaxe de mon exemple n'a rien de standard, mais RDF a une
> > syntaxe XML (parmi d'autres).
>
> Pour avoir déjà pratiquer RDF, je crois me souvenir que la
> représentation en XML de tes 3 lignes n'est pas si simple...
> Si tu maitrises le RDF je suis preneur de la traduction
(ce serait mieux avec un URL qui identifierait la ressource, plutôt
que simplement l'identifiant, je pense):
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:dc="http://purl.org/dc/elements/1.1/">
<rdf:Description rdf:about="a1902425">
<dc:title>Heroes</dc:title>
<dc:creator>Antonio Vivaldi</dc:creator>
<dc:creator>Philippe Jaroussky</dc:creator>
</rdf:Description>
</rdf:RDF>
> > Je pense que AIT pourrait faire des import/export en RDF assez
> > facilement, du coup (même si on risque de perdre le typage au sens
> > informatique).
>
> Je prévois plutôt à l'avenir des import/export en ATOM (bcp plus
> pratique et plus utile que le RDF)
> mais si tu veux te lancer, AIT repose sur un système de plugin
> donc tu peux facilement créer une extension pour traiter du RDF et
> implémenter un requêteur SPARQL ;-)
> c'est gens du web ont de bonne idée en théorie mais leur approche
> n'est pas très pragmatique contrairement aux gens de chez google ;-)
>
> AIT est loin de tout cela...
> le but est de stocker rapidement de l'info sans connaitre à l'avance
> leur nombre ni leurs caractéristiques et de disposer d'un moyen simple
> pour les retrouver...
> tout cela en écrivant un minimum de ligne de code PHP et de code SQL
Extrait de http://framework.zend.com/manual/en/zend.search.lucene.html
:
----8<----
it stores its index on the filesystem and does not require a database
server, it can add search capabilities to almost any PHP-driven
website. Zend_Search_Lucene supports the following features:
* Ranked searching - best results returned first
* Many powerful query types: phrase queries, wildcard queries,
proximity queries, range queries and more [6]
* Search by specific field (e.g., title, author, contents)
----8<----
On part d'un document (qui peut juste être un identifiant), on lui
ajoute des champs (auteur, titre, genre, ...) avec leurs valeurs, et
on peut chercher là-dedans avec une syntaxe proche de celle de Google,
de manière assez puissante (http://framework.zend.com/manual/en/
zend.search.lucene.query-language.html).
Bon, Lucene optimise les recherches, pas la volumétrie, mais ça peut
correspondre aussi (et ça m'évite d'écrire un parseur SPARQL ;) )
Nicolas Thouvenin
>Au fait, tu as déjà jeté un œil à Zend_Search_Lucene?
> AIT est loin de tout cela...
> le but est de stocker rapidement de l'info sans connaitre à l'avance
> leur nombre ni leurs caractéristiques et de disposer d'un moyen simple
> pour les retrouver...
> tout cela en écrivant un minimum de ligne de code PHP et de code SQL
Extrait de http://framework.zend.com/manual/en/zend.search.lucene.html
:
----8<----
it stores its index on the filesystem and does not require a database
server, it can add search capabilities to almost any PHP-driven
website. Zend_Search_Lucene supports the following features:
* Ranked searching - best results returned first
* Many powerful query types: phrase queries, wildcard queries,
proximity queries, range queries and more [6]
* Search by specific field (e.g., title, author, contents)
----8<----
On part d'un document (qui peut juste être un identifiant), on lui
ajoute des champs (auteur, titre, genre, ...) avec leurs valeurs, et
on peut chercher là-dedans avec une syntaxe proche de celle de Google,
de manière assez puissante (http://framework.zend.com/manual/en/
zend.search.lucene.query-language.html).
Bon, Lucene optimise les recherches, pas la volumétrie, mais ça peut
correspondre aussi (et ça m'évite d'écrire un parseur SPARQL ;) )
pour l'utiliser de la même manière que j'ai écrit un plugin pour exploiter le moteur de recherche fourni par MySQL. Les seuls traitements que j'ai ajouté au moteur MySQL concerne le traitement des chaines de caractères : stopwords (fr,en), steaming (fr, en), appauvrissement des accents. D'ailleurs ces algos seraient facilement intégrable dans Zend_Lucene, http://framework.zend.com/manual/en/zend.search.lucene.extending.html et en plus le code est isolé dans un package PEAR secret ;-) http://sourcesup.cru.fr/cgi/viewvc.cgi/trunk/misc/Text/?root=pxxo