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 :
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).
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é).
> 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 :
> 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).
> 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 <yt75...@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 :
> 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:
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).
> yves75 <yt75...@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 :
> > 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:
> 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).
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-n... 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 dune 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.
yves75 <yt75...@gmail.com> writes: > On Jun 5, 4:21 pm, "Pascal J. Bourguignon" <p...@informatimago.com> > wrote: >> yves75 <yt75...@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 :
>> > 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:
>> 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).
> 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-n... > 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 dune > 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).
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"
À (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.
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
>> 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...).
> >> 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...).
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".
À (at) Sun, 5 Jun 2011 22:57:20 -0700 (PDT), yves75 <yt75...@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-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 » ?
> 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.
À (at) Mon, 6 Jun 2011 00:38:06 -0700 (PDT), yves75 <yt75...@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).
> 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 quappelez 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.
À (at) Mon, 6 Jun 2011 02:35:06 -0700 (PDT), yves75 <yt75...@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 > quappelez 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.
> À 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
"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 ...
À (at) Mon, 6 Jun 2011 04:55:34 -0700 (PDT), yves75 <yt75...@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 !
yves75 <yt75...@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).
> 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 ..
> 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.
À (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 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...
> 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).
> À (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)
