Pouquoi ne pas "redémarrer" l'informatique comme un monde lisp en utilisant des "memory locations" administratives ?

43 views
Skip to first unread message

yves75

unread,
Jun 5, 2011, 9:45:19 AM6/5/11
to
Bonjour tout le monde,

Ce message pour présenter diverses idées ou propositions (surtout 2),
basées sur une nouvelle approche du "problème de l'identification en
informatique" (pour ses objets propres).
En introduction si intéressé le mieux est de lire :

http://iiscn.wordpress.com/about

Si je poste cela ici c'est que l'une des application principales
pourrait être un "monde lisp" qui serait basé sur des ISCNs, c'est à
dire que tous les ISCNs constituerait dés le départ des atomes ou
symboles de ce monde lisp, et en particulier (après avoir "raccroché
les espaces qui vont bien des divers organismes de normalisation),
tous les codes points UNICODE, tous les pays, langues, personnes
morales, etc ..., seraient des symboles de ce monde lisp, et les ISCNs
également utilisés en tant que "administrative memory locations", ou
numéros, dans la description des listes (sructures cons).

Très briévement décrit ici :
http://iiscn.wordpress.com/2011/05/15/tinlisp/
En fait autant principes de constitution d'une base de connaissance
que nouveau langage.

En espérant avoir le temps de mieux expliquer tout ça d'ici peu (ou
première implémentation en python).

Note : ces textes sont aussi une critique d'une certaine "niaiserie"
informatique, dans sa manie d'éviter les besoins monstrueux
d'identifications associés (et en voyant toujours dans un nouveau
modèle ou syntaxe la "solution", alors qu'il y a surtout besoin d'un
gros paquet d'épingles ou distributeur d'étiquettes partagé).

yves75

unread,
Jun 5, 2011, 9:55:53 AM6/5/11
to

Pascal J. Bourguignon

unread,
Jun 5, 2011, 10:21:03 AM6/5/11
to
yves75 <yt7...@gmail.com> writes:

> Bonjour tout le monde,
>
> Ce message pour présenter diverses idées ou propositions (surtout 2),
> basées sur une nouvelle approche du "problème de l'identification en
> informatique" (pour ses objets propres).
> En introduction si intéressé le mieux est de lire :
>
> http://iiscn.wordpress.com/about
>
> Si je poste cela ici c'est que l'une des application principales
> pourrait être un "monde lisp" qui serait basé sur des ISCNs, c'est à
> dire que tous les ISCNs constituerait dés le départ des atomes ou
> symboles de ce monde lisp, et en particulier (après avoir "raccroché
> les espaces qui vont bien des divers organismes de normalisation),
> tous les codes points UNICODE, tous les pays, langues, personnes
> morales, etc ..., seraient des symboles de ce monde lisp, et les ISCNs
> également utilisés en tant que "administrative memory locations", ou
> numéros, dans la description des listes (sructures cons).

Pour ce qui est des identificateurs universels, ASN.1 fait ça assez bien
avec ses OID:

http://www.itu.int/ITU-T/asn1/

Interner tous les identificateurs n'offre pas un clair intérêt, vu leur
grand nombre (= infini), et le fait qu'il n'y a pas un registre unique,
mais comme pour le DNS, des registres distribués. La structure de
l'arbre des OID et les correspondances entre les séquences de nombres
formant un OID et les noms alphanumériques étant données par les
diverses MIB.

Mais on pourrait envisager une reader macro qui convertirait un nom
(possiblement relatif), en OID. (Et encore une fois, l'intérêt
d'utiliser des symboles pour représenter les OIDs n'est pas évident, il
vaudrait surement mieux garder un type spécifique).


--
__Pascal Bourguignon__ http://www.informatimago.com/
A bad day in () is better than a good day in {}.

yves75

unread,
Jun 5, 2011, 12:44:45 PM6/5/11
to
On Jun 5, 4:21 pm, "Pascal J. Bourguignon" <p...@informatimago.com>
wrote:

Merci pour votre réponse, mais justement les OIDs d'ASN1, et le
RH_name_tree associé, sont une grosse bêtise (et d'ailleurs quasi pas,
ou peu utilisé dans la pratique), la raison en est que les espaces
dits "hiérarchiques" ne le sont pas la plupart du temps (quand on
utilise des mots clés), et que l'on a cru que faire des espaces
hiérarchiques de numéros reviendrait au même que faire des espaces
hiérarchiques de mots clés, mais il n'en est rien, expliqué un peu
là :
http://iiscn.wordpress.com/2011/05/15/les-espaces-dits-hierarchique-ne-le-sont-pas-la-plupart-du-temps/
De fait ça ne passe pas à l'échelle.
Et mélanger classification et nommage est toujours une mauvaise idée,
de même que mélanger partitionnement pour accéder aux objets et
nommage.

Sinon, le principe proposé permet de fait de raccrocher quasi tous les
espaces existants, et oui il s'agit bien ici de mettre "à côté", une
lettre de l'alphabet, un bouquin, un paquet de nouille (en tant
qu'identifiant produit), ou même une commande pour un paquet de
nouille. Et sans oublier que 128 bits par exemple, (taille d’une
adresse IP v6), cela représente 5 10^18 numéros par millimètre carré
de terre, ou 1 10^16 numéros par seconde et par habitant sur un
millénaire pour une population de 10 milliards.

Pascal J. Bourguignon

unread,
Jun 5, 2011, 2:17:55 PM6/5/11
to
yves75 <yt7...@gmail.com> writes:

> Merci pour votre réponse, mais justement les OIDs d'ASN1, et le
> RH_name_tree associé, sont une grosse bêtise (et d'ailleurs quasi pas,
> ou peu utilisé dans la pratique), la raison en est que les espaces
> dits "hiérarchiques" ne le sont pas la plupart du temps (quand on
> utilise des mots clés), et que l'on a cru que faire des espaces
> hiérarchiques de numéros reviendrait au même que faire des espaces
> hiérarchiques de mots clés, mais il n'en est rien, expliqué un peu
> là :
> http://iiscn.wordpress.com/2011/05/15/les-espaces-dits-hierarchique-ne-le-sont-pas-la-plupart-du-temps/
> De fait ça ne passe pas à l'échelle.
> Et mélanger classification et nommage est toujours une mauvaise idée,
> de même que mélanger partitionnement pour accéder aux objets et
> nommage.
>
> Sinon, le principe proposé permet de fait de raccrocher quasi tous les
> espaces existants, et oui il s'agit bien ici de mettre "à côté", une
> lettre de l'alphabet, un bouquin, un paquet de nouille (en tant
> qu'identifiant produit), ou même une commande pour un paquet de
> nouille. Et sans oublier que 128 bits par exemple, (taille d’une
> adresse IP v6), cela représente 5 10^18 numéros par millimètre carré
> de terre, ou 1 10^16 numéros par seconde et par habitant sur un
> millénaire pour une population de 10 milliards.


Le problème, c'est que lorsqu'on veut un système de nomage universel, en
pratique on est réduit à une structure administrative hierarchique. Il
ne s'agit pas de classification, mais de délégation d'authorité de
nomage.


D'ailleurs, cette hierarchie adminstrative se constitue naturellement,
que l'on ait une approche descendente ou ascendente:

En ascendant, on peut recenser les codes existants dans les divers
domaines, et les préfixer d'une étiquette de domaine et d'autorité (qui
à standardisé cette codification) pour faire un arbre réutilisant
l'existant. Voir par exemple, les IBAN.

Ou on peut avoir une aproche descendente, où on normalise la hierarchie
administrative, en déléguant le raccrochage des codifications par les
autorités concernée (OID ASN.1 ou URI).

Tu semble être orienté sur l'approche ascendante, mais une fois l'arbre
initial créé, le rattachement des autorités de codification (nécessaire
pour déléguer la création des nouveaux codes, ou le rattachement sans
collision des codes préexistant qui n'ont forcément pas tous été
recensés initialement), se ramène à un fonctionnement similarire à
l'approche descendante.


(Quand à l'aspect numerique des OID, c'est seulement une simplification
et un codage, pour le traitement et la transmission des OID,
conceptuellement on pourrait tout aussi bien travailler avec des chemins
d'identificateurs).

yves75

unread,
Jun 5, 2011, 3:03:52 PM6/5/11
to
On Jun 5, 8:17 pm, "Pascal J. Bourguignon" <p...@informatimago.com>
wrote:

> Le problème, c'est que lorsqu'on veut un système de nomage universel, en


> pratique on est réduit à une structure administrative hierarchique.  Il
> ne s'agit pas de classification, mais de délégation d'authorité de
> nomage.

Certes, mais justement, les espaces d'identifiants qui marchent ont en
fait très peu de segments, cas des IBAN, des ISBN ou des codes barres
EAN13 (aujourd'hui fuisionnés d'ailleurs), est de beaucoup d'autres.
L'idée est bien de dire qu'il faut un aspects hiérarchique, mais
uniquement du aux besoins de distribution (délégation de la
distributions d'identifiants), et la différence est que le principe
n'implique ni un nombre de segments fixe, ni une taille de segements
fixes (cas de la majorité de ces identifiants aujourdhui). Et que 5 ou
segments maximum ça suffit largement.
>

>
> Tu semble être orienté sur l'approche ascendante, mais une fois l'arbre
> initial créé, le rattachement des autorités de codification (nécessaire
> pour déléguer la création des nouveaux codes, ou le rattachement sans
> collision des codes préexistant qui n'ont forcément pas tous été
> recensés initialement), se ramène à un fonctionnement similarire à
> l'approche descendante.

Oui en quelque sorte.


>
> (Quand à l'aspect numerique des OID, c'est seulement une simplification
> et un codage,  pour le traitement et la transmission des OID,
> conceptuellement on pourrait tout aussi bien travailler avec des chemins
> d'identificateurs).

Non pas vraiment, les OIDs étaient vus comme "une hierarchie à nombre
de niveaux indéterminés, avec le préfixe 1 pour l'ISO, le 2 pour le
CCITT (ou quelque chose comme ça), un préfixe commun, et surtout des
principes d'utilisation compris comme : "créer de nombreux niveaux
n'est pas grave", alors que c'est exactement l'inverse, le moins de
niveaux possible, mieux ça "marche", ce qui n'empêche pas bien sur
d'identifier après un ensemble de choses par un autre ISCN (un peu
comme si vous acheter le coffret des trois premiers tomes de Knuth, ou
des Bescherelle, ces coffrets ont un ISBN à côté des ISBN des bouquins
qu'ils contiennent) : les OIDs sont morts du fait du mélange permanent
entre classification et nommage, et de la perception que ces
hiérarchies "passent à l'échelle"

Paul Gaborit

unread,
Jun 5, 2011, 6:05:06 PM6/5/11
to

À (at) Sun, 05 Jun 2011 20:17:55 +0200,
"Pascal J. Bourguignon" <p...@informatimago.com> écrivait (wrote):

>
> Le problème, c'est que lorsqu'on veut un système de nomage universel, en
> pratique on est réduit à une structure administrative hierarchique. Il
> ne s'agit pas de classification, mais de délégation d'authorité de
> nomage.
>

Les URI (URN, URL...) forment un bon exemple de système de nommage
mondialement utilisé et il est effectivement hiérarchique.

--
Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>

yves75

unread,
Jun 5, 2011, 6:44:50 PM6/5/11
to

>
> Les URI (URN, URL...) forment un bon exemple de système de nommage
> mondialement utilisé et il est effectivement hiérarchique.
>
> --
> Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>

Pas vraiment, déjà on peut définir une syntaxe pour ses URN ou URL tel
que /images amène au "directory" des images dans tout directory par
exemple, faisant que le symbole "images" a en fait une valeur unique
ou "sens", en dehors d'un directory particulier (un peu comme les
conventions qui se mettent en place dans les distributions de codes
sous unix avec /lib , /doc ou fichier README par exemple), d'autre
part les URLs aujourd'hui deviennent des vrais morceaux de codes, qui
par contre "rebouclent" souvent sur des espaces d'identifiants uniques
plus "serrés" et plats, comme par exemple les IDs des videos youtube
(là ou dailymotion est encore resté sur une transformation plus ou
moins claire du titre il me semble), ce qui permet dans les forums ou
blogs de ne mettre que [youtube]abv&fghj[/youtube] pour afficher une
video ("abv&fghj" chaîne prise au hasard dans ce cas), ou encore voir
les URL google groups par exemple

Paul Gaborit

unread,
Jun 5, 2011, 7:57:03 PM6/5/11
to

À (at) Sun, 5 Jun 2011 15:44:50 -0700 (PDT),
yves75 <yt7...@gmail.com> écrivait (wrote):

>>
>> Les URI (URN, URL...) forment un bon exemple de système de nommage
>> mondialement utilisé et il est effectivement hiérarchique.
>>

> Pas vraiment, déjà on peut définir une syntaxe pour ses URN ou URL tel
> que /images amène au "directory" des images dans tout directory par
> exemple, faisant que le symbole "images" a en fait une valeur unique
> ou "sens", en dehors d'un directory particulier (un peu comme les
> conventions qui se mettent en place dans les distributions de codes
> sous unix avec /lib , /doc ou fichier README par exemple), d'autre
> part les URLs aujourd'hui deviennent des vrais morceaux de codes, qui
> par contre "rebouclent" souvent sur des espaces d'identifiants uniques
> plus "serrés" et plats, comme par exemple les IDs des videos youtube
> (là ou dailymotion est encore resté sur une transformation plus ou
> moins claire du titre il me semble), ce qui permet dans les forums ou
> blogs de ne mettre que [youtube]abv&fghj[/youtube] pour afficher une
> video ("abv&fghj" chaîne prise au hasard dans ce cas), ou encore voir
> les URL google groups par exemple

Certes... mais où est le problème ? Dans tous les systèmes
d'indirection, il existe des indirections qui désignent la même
chose.
Les URI reste bien un système de nommage distribué mondial (même s'il n'est
pas encore universel...).

yves75

unread,
Jun 6, 2011, 1:57:20 AM6/6/11
to
On Jun 6, 1:57 am, Paul Gaborit <Paul.Gabo...@invalid.invalid> wrote:
> (at) Sun, 5 Jun 2011 15:44:50 -0700 (PDT),
> yves75 <yt75...@gmail.com> crivait (wrote):
>
>
>
>
>
>
>
>
>
>
>
> >> Les URI (URN, URL...) forment un bon exemple de syst me de nommage
> >> mondialement utilis et il est effectivement hi rarchique.
>
> > Pas vraiment, d j on peut d finir une syntaxe pour ses URN ou URL tel
> > que /images am ne au "directory" des images dans tout directory par

> > exemple, faisant que le symbole "images" a en fait une valeur unique
> > ou "sens", en dehors d'un directory particulier (un peu comme les
> > conventions qui se mettent en place dans les distributions de codes
> > sous unix avec /lib , /doc ou fichier README par exemple), d'autre
> > part les URLs aujourd'hui deviennent des vrais morceaux de codes, qui
> > par contre "rebouclent" souvent sur des espaces d'identifiants uniques
> > plus "serr s" et plats, comme par exemple les IDs des videos youtube
> > (l ou dailymotion est encore rest sur une transformation plus ou

> > moins claire du titre il me semble), ce qui permet dans les forums ou
> > blogs de ne mettre que [youtube]abv&fghj[/youtube] pour afficher une
> > video ("abv&fghj" cha ne prise au hasard dans ce cas), ou encore voir

> > les URL google groups par exemple
>
> Certes... mais o est le probl me ? Dans tous les syst mes
> d'indirection, il existe des indirections qui d signent la m me
> chose.
> Les URI reste bien un syst me de nommage distribu mondial (m me s'il n'est

> pas encore universel...).
>
> --
> Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>

Le problème ? C'est que d'une part la complexité des systèmes actuels
vient sans doute autant de ce manque plus que de la complexité
intrinsèque de la chose à écrire, et de très loin.
Et que d'autre part les refrains du genre : il faut utiliser ceci ou
cela (Corba, XML, les Web Services, etc), pour que tout marche bien,
deviennent vraiment un tantinet fatiguant.
Il n'est pas rare aujourd'hui de se retrouver dans des situations
équivalentes à un ensemble de bibliothèques (ou librairies) qui
utiliseraient chacune leur propres systèmes d'identifiants, mais que
l'on dise que ce qu'il faut c'est normaliser les notices des livres en
XML pour que cela marche, alors que plusieurs formats de notices si
même espace d'identifiants, pas bien grave, un seul format mais pas
d'identifiants commun : rien ne marche. Il y a une sorte de
fascination pour le "modèle" à trouver, en mettant systématiquement la
problématique de l'identification des instances des objets du modèle
en second plan.
Quant à "Dans tous les syst mes d'indirection, il existe des
indirections qui d signent la m mechose. ',
avoir plusieurs s-expression qui s'évaluent au même symbole/atome,
n'est pas pareil qu'avoir une multitiudes de s-expression désignant la
même chose.
Voir aussi par exemple la "géguerre" entre le système "DOI" et le fait
de considérer les DOIs comme des URIs ou pas (avait un lien là dessus
ne le retrouve plus)
Ce qui ne veut pas dire que les ISCNs ne pourrait pas être écrit comme
des URIs (encore moins qu'ils devraient remplacer les URLs), pas
vraiment la question, il s'agirait là de les utiliser aussi, de
manière beaucoup plus "native".

Paul Gaborit

unread,
Jun 6, 2011, 3:03:08 AM6/6/11
to

À (at) Sun, 5 Jun 2011 22:57:20 -0700 (PDT),
yves75 <yt7...@gmail.com> écrivait (wrote):

> Quant à "Dans tous les syst mes d'indirection, il existe des


> indirections qui d signent la m mechose. ',
> avoir plusieurs s-expression qui s'évaluent au même symbole/atome,
> n'est pas pareil qu'avoir une multitiudes de s-expression désignant la
> même chose.

J'ai l'impression que vous n'avez pas tout à fait compris ma
remarque. Ne confondez-vous pas la carte et le territoire, le nom et
l'objet, etc. La plupart des URI ne sont pas des URN.

> Voir aussi par exemple la "géguerre" entre le système "DOI" et le fait
> de considérer les DOIs comme des URIs ou pas (avait un lien là dessus
> ne le retrouve plus)

(C'est marrant : j'ai été confronté à cette question il y a peu via
l'utilisation de biblatex.)

Et alors ? De toutes manières, il me semble que l'universalité et
surtout l'unicité d'un système aménèrait plus de problème qu'il n'en
résoudrait au final.

> Ce qui ne veut pas dire que les ISCNs ne pourrait pas être écrit comme
> des URIs (encore moins qu'ils devraient remplacer les URLs), pas
> vraiment la question, il s'agirait là de les utiliser aussi, de
> manière beaucoup plus "native".

Je n'arrive toujours pas à comprendre vos remarques concernant l'aspect
hiérarchique. J'ai lu
<http://iiscn.wordpress.com/2011/05/15/les-espaces-dits-hierarchique-ne-le-sont-pas-la-plupart-du-temps/>
et je ne vois pas ce qui vous amène à dire que les URI (ou même les
chemins sous Unix) ne sont pas vraiment hiérarchiques. Quelles
restrictions imposeriez-vous pour les rendre « hiérarchiques » ?

yves75

unread,
Jun 6, 2011, 3:38:06 AM6/6/11
to

> J'ai l'impression que vous n'avez pas tout à fait compris ma
> remarque. Ne confondez-vous pas la carte et le territoire, le nom et
> l'objet, etc. La plupart des URI ne sont pas des URN.
>
Il se trouve que justement, dans beaucoup de cas en informatique, la
carte et le territoire c'est la même chose, surtout d'un point de vu
purement informatique, et les atomes lisp en sont un bon exemple.


>
> Et alors ? De toutes manières, il me semble que l'universalité et
> surtout l'unicité d'un système aménèrait plus de problème qu'il n'en
> résoudrait au final.

Je ne pense pas non, aucune bibliothèque ne fonctionnerait aujourd'hui
sans ISBN, et aucun supermarché ne fonctionnerait sans code barre GS1,
vrai aussi dans de nombreux autres domaines ou industries (où
n'importe quelle modèle de vis à droit à son identifiant, --à côté--
de celui de tous les moteurs ou autres pièces où elle peut être
utilisée), ou encore la mise à plat UNICODE, il y a plus là une espèce
de version paroxystique du "cordonnier toujours le plus mal chaussé",
d'une certaine manière.


>
> > Ce qui ne veut pas dire que les ISCNs ne pourrait pas être écrit comme
> > des URIs (encore moins qu'ils devraient remplacer les URLs), pas
> > vraiment la question, il s'agirait là de les utiliser aussi, de
> > manière beaucoup plus "native".
>
> Je n'arrive toujours pas à comprendre vos remarques concernant l'aspect
> hiérarchique. J'ai lu

> <http://iiscn.wordpress.com/2011/05/15/les-espaces-dits-hierarchique-n...>


> et je ne vois pas ce qui vous amène à dire que les URI (ou même les
> chemins sous Unix) ne sont pas vraiment hiérarchiques. Quelles
> restrictions imposeriez-vous pour les rendre « hiérarchiques » ?

On peut les voir comme hiérarchiques, leur utilisation ne l'est
souvent pas, ce sont --souvent-- plus des s-expression sur un
environnement de symboles à plat :
/mysoft/lib/doc correspond en fait à (doc (lib (mysoft)) : la
documentation de la partie librairie de la publication mysoft
Raison pour laquelle le RH-name-tree et les OIDs du modèle OSI
n'avaient aucune chance de fonctionner (si on met des numéros c'est
pour aplatir et pouvoir changer les mots clés, comme les inodes à plat
d'un système de fichiers permettent de changer les noms des fichiers.
Et je ne veux imposer aucune restriction, ces espaces hiérarchiques de
mots clés permettent justement à des syntaxes ou conventions de
s'établir sans avoir à les "visser" à priori.
Le principe serait plutôt : quand on a besoin ou que l'on veut
utiliser des identifiants du genre numéros, on peut utiliser des
ISCNs, c'est tout. Et d'autre part possibilité de batir une base de
connaissance basée sur tous les espaces de codes de ce genre existant
déjà.
Ou encore cesser de voir le "salut" dans la syntaxe.

Paul Gaborit

unread,
Jun 6, 2011, 4:31:36 AM6/6/11
to

À (at) Mon, 6 Jun 2011 00:38:06 -0700 (PDT),
yves75 <yt7...@gmail.com> écrivait (wrote):

>> J'ai l'impression que vous n'avez pas tout à fait compris ma


>> remarque. Ne confondez-vous pas la carte et le territoire, le nom et
>> l'objet, etc. La plupart des URI ne sont pas des URN.
>>
> Il se trouve que justement, dans beaucoup de cas en informatique, la
> carte et le territoire c'est la même chose, surtout d'un point de vu
> purement informatique, et les atomes lisp en sont un bon exemple.

C'est donc là que nous sommes en désaccord profond et c'est ce qui
explique tout le reste de nos incompréhensions. Et les atomes Lisp ne
sont pas, pour moi, un bon exemple de ce mélange entre identifiant et
objet que vous avancez. Même dans un système informatique, il n'existe
pas d'identifiant unique...

> Je ne pense pas non, aucune bibliothèque ne fonctionnerait aujourd'hui

> sans ISBN[...],

... qui ne garantissent l'unicité qu'en apparence (il y a déjà des bugs
connus).

> et aucun supermarché ne fonctionnerait sans code barre GS1, vrai aussi
> dans de nombreux autres domaines ou industries (où n'importe quelle
> modèle de vis à droit à son identifiant, --à côté-- de celui de tous
> les moteurs ou autres pièces où elle peut être utilisée), ou encore la
> mise à plat UNICODE, il y a plus là une espèce de version paroxystique
> du "cordonnier toujours le plus mal chaussé", d'une certaine manière.

Mais tous ces systèmes (mis à part peut-être Unicode) ne sont en rien
universels. Et même Unicode propose plusieurs noms pour un même
caractère.

[...]


> Le principe serait plutôt : quand on a besoin ou que l'on veut
> utiliser des identifiants du genre numéros, on peut utiliser des
> ISCNs, c'est tout. Et d'autre part possibilité de batir une base de
> connaissance basée sur tous les espaces de codes de ce genre existant
> déjà.
> Ou encore cesser de voir le "salut" dans la syntaxe.

D'accord avec vous sur cette toute dernière remarque.

Je crois que votre louable tentative de création d'ISCN est
malheureusement vouée à l'échec (comme toutes les autres tentatives
précédentes même limitées à un domain particulier).

yves75

unread,
Jun 6, 2011, 5:35:06 AM6/6/11
to

>
> Je crois que votre louable tentative de création d'ISCN est
> malheureusement vouée à l'échec (comme toutes les autres tentatives
> précédentes même limitées à un domain particulier).

Merci pour votre franchise, mais les autres tentatives sont très loin
d'être des échecs, UNICODE par exemple n'en est pas un, loin de là, et
qu’appelez vous un 'bug dans les ISBNs" ?
L'informatique croit toujours "modéliser" le monde, il n'en est rien,
elle en écrit une partie (toujours morte) comme la technique en
général d'ailleurs, et je reste persuadé que le fait de refuser de
considérer ce besoin de "carburant idéogrammatique jetable" comme tout
autre domaine technique (ou d'artefacts), et la raison principale de
la sur-complexité des systèmes actuels (et de l'extrême difficulté à
les faire évoluer).
L'informatique est restée dans une mentalité pré moderne (au sens
Rimbaldien ou Malarméen), d'une certaine manière.

Paul Gaborit

unread,
Jun 6, 2011, 5:50:19 AM6/6/11
to

À (at) Mon, 6 Jun 2011 02:35:06 -0700 (PDT),
yves75 <yt7...@gmail.com> écrivait (wrote):

>>


>> Je crois que votre louable tentative de création d'ISCN est
>> malheureusement vouée à l'échec (comme toutes les autres tentatives
>> précédentes même limitées à un domain particulier).
>
> Merci pour votre franchise, mais les autres tentatives sont très loin
> d'être des échecs, UNICODE par exemple n'en est pas un, loin de là, et
> qu’appelez vous un 'bug dans les ISBNs" ?

À mon sens, Unicode ne réussit (ou ne réussira car il reste encore un
peu de chemin tout de même) que parce que son périmètre est très limité,
parce qu'il touche un domaine où le besoin d'uniformisation est bien
compris de la communauté mondiale mais aussi parce que les moyens
technologiques modernes le permettent.

Les bugs ISBN ? Tout simplement les doublons (oui, il existe des
ouvrages différents qui ont le même ISBN) et son manque d'universalité
(des nombreux documents ne sont pas référencés) dans son domaine
pourtant limité.

> L'informatique croit toujours "modéliser" le monde, il n'en est rien,

L'informatique ne modélise rien. C'est l'homme qui donne du sens aux tas
de bits que manipulent nos outils informatiques. ;-)

> elle en écrit une partie (toujours morte) comme la technique en
> général d'ailleurs, et je reste persuadé que le fait de refuser de
> considérer ce besoin de "carburant idéogrammatique jetable" comme tout
> autre domaine technique (ou d'artefacts), et la raison principale de
> la sur-complexité des systèmes actuels (et de l'extrême difficulté à
> les faire évoluer).
> L'informatique est restée dans une mentalité pré moderne (au sens
> Rimbaldien ou Malarméen), d'une certaine manière.

J'avoue franchement ne pas comprendre votre discours. Il doit me manquer
les références nécessaires.

yves75

unread,
Jun 6, 2011, 7:55:34 AM6/6/11
to

>
> À mon sens, Unicode ne réussit (ou ne réussira car il reste encore un
> peu de chemin tout de même) que parce que son périmètre est très limité,
> parce qu'il touche un domaine où le besoin d'uniformisation est bien
> compris de la communauté mondiale mais aussi parce que les moyens
> technologiques modernes le permettent.

UNICODE est un exemple de numérotation de "choses" préexistantes,
signes, lettres idéogrammes, ponctuations, conventions informatiques
(line feed, eof, etc), "choses" qui restent par ailleurs assez
mystérieuses, Rimbaud écrit dans une de ses lettres "Des faibles se
mettraient à -penser- sur la première lettre de l'alphabet, qui
pourraient vite ruer dans la folie !" il faut donc faire attention ..
(et à ce sujet les circonvolutions dans le standard unicode sont assez
intéressantes)

Mais dans de nombreux autres domaines, la problématique est plus
"allocation d'un numéro à la création ou publication" : publication
d'une video sur youtube par exemple, ou création d'un fichier et
allocation d'inode.


>
> Les bugs ISBN ? Tout simplement les doublons (oui, il existe des
> ouvrages différents qui ont le même ISBN) et son manque d'universalité
> (des nombreux documents ne sont pas référencés) dans son domaine
> pourtant limité.

Il est vrai que des livres "différents" peuvent avoir le même ISBN.
Dans la collection "l'imaginaire" chez Gallimard par exemple, l'image
de couverture peut varier pour une même édition d'une certaine œuvre,
ceci en gardant le même ISBN, par contre un doublon serait plus pour
moi dans ce cas une même édition ayant des ISBNs différents suivant
les exemplaires, et pour cela je ne vois pas d'exemple (peut-être le
cas pour des livres anciens auquel on affecte des ISBNs), quant au
fait que l'on utilise pas les ISBNs pour tous les documents, c'est
vrai, et d'ailleurs cela reflète un vrai problème, voir par exemple :
http://bibnum.bnf.fr/identifiants/identifiants-200605.pdf

A ce sujet, remarquons aussi qu'une numérotation peut vouloir
identifier une "oeuvre" plus qu'une édition particulière, le cas pour
les ISANs par exemple :
http://www.isan.org/portal/page?_pageid=168,1&_dad=portal&_schema=PORTAL

"The ISAN identifies works, not publications or broadcasts. The ISAN
remains the same for an audiovisual work regardless of the various
formats in which the work is distributed (e.g. DVD, video recording)
or the uses to which it is put."
Le cas aussi d'ailleurs pour les IDs alloués par IMDB il me semble (ou
IDs différents à la fois pour les oeuvres et éditions)

>
> > L'informatique croit toujours "modéliser" le monde, il n'en est rien,
>
> L'informatique ne modélise rien. C'est l'homme qui donne du sens aux tas
> de bits que manipulent nos outils informatiques. ;-)

Quand je dis "l'informatique" je fais référence aux personnes qui la
pratiquent, en écrivant des programmes, articles de recherche, livres
d'explications, white papers, power point ou rapports de consultants,
blogs ou autres


>
> J'avoue franchement ne pas comprendre votre discours. Il doit me manquer
> les références nécessaires.
>
> --

En fait il s'agirait surtout d'améliorer la dynamique, la
"thermodynamique"(si une telle chose existait dans ce cas), du gros
bouquin de la technique pour son écriture et fonctionnement. Fournir
le carburant nécessaire (qui pour une fois ne coûte rien ou pas grand
chose), et permettre aussi l'écriture de systèmes cohérents non
nécessairement monopolistiques (car à l'intérieur d'un monopole, on ne
se gêne pas pour définir les espaces d'identifiants nécessaires).

Je travaille actuellement dans les telecoms (enfin plus informatique
des telecoms, BSS, OSS) et actuellement dans ce domaine la manie
"recherche du salut par la syntaxe ou modèles", et ceci en laissant de
façon quasi systématique la problématique des identifiants de côté est
vraiment impressionnante (quand les identifiants eux "traversent"
toute syntaxe ou modèle).
Mais bon, de meilleurs explications restent certainement
nécessaires ...

Merci beaucoup pour cet échange en tout cas !


Paul Gaborit

unread,
Jun 6, 2011, 9:09:37 AM6/6/11
to

À (at) Mon, 6 Jun 2011 04:55:34 -0700 (PDT),
yves75 <yt7...@gmail.com> écrivait (wrote):

> Il est vrai que des livres "différents" peuvent avoir le même ISBN.


> Dans la collection "l'imaginaire" chez Gallimard par exemple, l'image
> de couverture peut varier pour une même édition d'une certaine œuvre,
> ceci en gardant le même ISBN, par contre un doublon serait plus pour
> moi dans ce cas une même édition ayant des ISBNs différents suivant
> les exemplaires, et pour cela je ne vois pas d'exemple (peut-être le
> cas pour des livres anciens auquel on affecte des ISBNs), quant au
> fait que l'on utilise pas les ISBNs pour tous les documents, c'est
> vrai, et d'ailleurs cela reflète un vrai problème, voir par exemple :
> http://bibnum.bnf.fr/identifiants/identifiants-200605.pdf

Avec l'ISBN, il existe de vrais bugs : deux livres complètement
différents (auteurs et contenus différents) avec le même ISBN. L'exemple
qu'on m'avait cité (je ne suis pas sûr de le retrouver) concernait un
même éditeur (un bug dans leur logiciel d'attribution des numéros
ISBN ?). Mais il paraît qu'il y a même des exemples entre éditeurs
différents !

Pascal J. Bourguignon

unread,
Jun 6, 2011, 9:13:15 AM6/6/11
to
yves75 <yt7...@gmail.com> writes:

> Mais dans de nombreux autres domaines, la problématique est plus
> "allocation d'un numéro à la création ou publication" : publication
> d'une video sur youtube par exemple, ou création d'un fichier et
> allocation d'inode.

Dans youtube et de nombreux numéros utilisés dans les URI, un critère de
conception est de faire en sorte que le numéro ne soit pas devinable.


> Je travaille actuellement dans les telecoms (enfin plus informatique
> des telecoms, BSS, OSS) et actuellement dans ce domaine la manie
> "recherche du salut par la syntaxe ou modèles", et ceci en laissant de
> façon quasi systématique la problématique des identifiants de côté est
> vraiment impressionnante (quand les identifiants eux "traversent"
> toute syntaxe ou modèle).

Oui, mais ça s'explique.


Comme tu l'as remarqué, les OID de ASN.1 ne sont pas "pratiques" parce
qu'ils ont dans une application donnée tous un préfixe imposant et
identique.

Choisir des préfixes plus courts ne changera pas le problème: par
relativisme des systèmes de nommage et accrétion, on finira toujours par
ajouter des codes préfixes.

Mais le point important c'est que les identifiants sont toujours
relatifs. Même si tu conçois un système qui identifie tous les atomes
de la Terre et tous les concepts inventés (même en incluants les futurs
concepts), tu n'auras jamais qu'un code local, qui foirera complètement
quand on commencera à commercer avec des civilisations extra-terrestres.
Même si tu conçois un système qui fonctionne pour l'univers entier:

1- comment fais tu hors de l'horizon?

2- comment impose tu ton système à l'intérieur de l'horizon? Même un
système universel et absolu et relatif à son utilisateur. Si on
autre utilisateur veut utiliser un autre système, ton système devient
relatif, et nécessite un préfixe chez cet autre, et tu devras
utiliser le système de l'autre en le rattachant au tien avec un
préfixe.

Tu te plains que les OID sont trop lourds. Déjà les gens se plaignent
que unicode avec 21 bits ou 32 bits c'est trop lourd. Et tu voudrais
ajouter un préfixe à chaque caractère? Pourquoi faire?

Il est bien plus raisonnable de savoir que dans un domaine donné, les
identifiants sont relatifs à un catalogue donné, quite à faire des
tables de correspondances si on doit convertir les codes de caractères
ou les codes de livres ou de n'importe quel autre produit. Amazone n'a
pas tant de difficulté à le faire.


La seule chose, c'est bien sur d'éviter de s'amener avec la figure
enfarinée et de limiter les codes à ce qu'on connait: tôt où tard on
devra traiter avec des codes étendus. (Un numéro de téléphone ce n'est
pas 10 chiffres, ISDN défini les numéros de téléphone sur 27
caractères. Une adresse postale ce n'est pas 4 lignes, La Poste les
défini sur 7 lignes de 32 caractères, etc).


(Et de toutes façons les préfixes communs sont compressés les doigts
dans le nez lors des transmissions, alors ils ne posent pas de problème
réel non plus).

yves75

unread,
Jun 6, 2011, 10:14:07 AM6/6/11
to

> Il est bien plus raisonnable de savoir que dans un domaine donné, les
> identifiants sont relatifs à un catalogue donné, ---quite à faire des
> tables de correspondances--- si on doit convertir les codes de caractères

> ou les codes de livres ou de n'importe quel autre produit.  Amazone n'a
> pas tant de difficulté à le faire.

Justement non, et c'est là la maladie de l'informatique, de croire que
les identifiants sont liés à des systèmes, ou que "faire des
tables de correspondances" ne coute rien, alors que justement ça
coute en fait "les yeux de la tête" et cela croit extrêmement vite.

Quant à Amazon, justement, l'ASIN ne s'amuse absolument pas à
renuméroter tous les produits déjà numéroté par GS1 !! (ce qui intègre
déjà les ISBN), mais ajoute un préfix pour les produits de
particuliers ou plus artisanaux, ou un autre "gimmick", je ne sais
plus exactement comment ça marche, mais les EAN13 sont intégrés dans
les ASINs et bien évidemment pas renumérotés.

Quant aux extraterrestres, la terre et son gros bouquin suffit à la
peine...

Mais bon, je ne compte pas forcément vous convaincre, le fait est que
la maladie informatique est bien là cependant (et même pour l'écriture
des programmes eux-mêmes), vous verrez ..

yves75

unread,
Jun 6, 2011, 10:31:18 AM6/6/11
to

> Mais tous ces systèmes (mis à part peut-être Unicode) ne sont en rien
> universels. Et même Unicode propose plusieurs noms pour un même
> caractère.
>

Juste un point : si ces systèmes sont universels, qu'il s'agissent des
ISBNs ou des codes barres GS1 (résultat de la fusion du système
Européen et Américain), et par exemple une app iphone/android comme
http://redlaser.com/ marche sur les codes barres des supermarchés du
monde entier.

Paul Gaborit

unread,
Jun 6, 2011, 11:32:53 AM6/6/11
to

À (at) Mon, 6 Jun 2011 07:31:18 -0700 (PDT),
yves75 <yt7...@gmail.com> écrivait (wrote):

>> Mais tous ces systèmes (mis à part peut-être Unicode) ne sont en rien

Mais tous les produits vendus ne comportent pas obligatoirement de code
barre... même dans un supermarché. Et si cela marchait si bien, on ne
verrait pas si souvent la caissière taper elle-même l'intitulé du
produit pour en retrouver le prix exact (je ne parle des codes barre
illisibles mais bien des mauvaises correspondances dans les bases de
données). La lecture des codes barre marche partout pareil.
L'interprétation de la valeur lue est bien moins fiable...

yves75

unread,
Jun 6, 2011, 11:54:20 AM6/6/11
to
> Et si cela marchait si bien, on ne
> verrait pas si souvent la caissière taper elle-même l'intitulé du
> produit pour en retrouver le prix exact (je ne parle des codes barre
> illisibles mais bien des mauvaises correspondances dans les bases de
> données).

Bof, d'une part cela n'arrive pas temps que ça, et d'autre part quand
cela arrive c'est bien dans la très grande majorité des cas que la
lecture du code barre ne passe pas.
De plus, rien n'empêche de définir un code barre (numéro GS1) associé
à un produit défini comme "un kilo de pommes locales", ou plage de
numéros à signification locale (d'ailleurs déjà le cas très
probablement).

yves tremolet

unread,
Jul 8, 2011, 12:52:54 AM7/8/11
to
On 6 juin, 17:32, Paul Gaborit <Paul.Gabo...@invalid.invalid> wrote:
> À (at) Mon, 6 Jun 2011 07:31:18 -0700 (PDT),
> yves75 <yt75...@gmail.com> écrivait (wrote):

>
> >> Mais tous ces systèmes (mis à part peut-être Unicode) ne sont en rien
> >> universels. Et même Unicode propose plusieurs noms pour un même
> >> caractère.
>
> > Juste un point : si ces systèmes sont universels, qu'il s'agissent des
> > ISBNs ou des codes barres GS1 (résultat de la fusion du système
> > Européen et Américain), et par exemple une app iphone/android comme
> >http://redlaser.com/marche sur les codes barres des supermarchés du

> > monde entier.
>
> Mais tous les produits vendus ne comportent pas obligatoirement de code
>je ne parle des codes barre
> illisibles mais bien des mauvaises correspondances dans les bases de
> données). La lecture des codes barre marche partout pareil.
> L'interprétation de la valeur lue est bien moins fiable...
>
> --

D'autre part je ne sais pas ce que vous appelez "mauvaises


correspondances dans les bases de

données" ou "interprétation de la valeur lue est bien moins fiable",
il n'y a pas de correspondance ou interprétation d'un code barre dans
le système d'un super marché !
Le code barre (numéro GS1) est utilisé en tant que "clé primaire" dans
ces systèmes, un point un trait (version ivoirienne de point barre).
Ne feriez vous pas là "l'erreur classique" consistant à croire qu'il
faut des "identifiants internes ou "système"" pour ces choses ?
Erreur qui il est vrai, arrive à se transformer en des renumérotations
absolument pas nécessaire dans ces systèmes, mais heureusement pas
toujours ! (et certainement pas pour les supermarchés)

Reply all
Reply to author
Forward
0 new messages