Come accennavo, ho avuto diversi problemi di performance (molti in realtà causati da default strani di yacy).
Ho quindi preferito proteggere il cluster dietro password, per eliminare la variabile query esterne.
Inoltre, non capendo ancora bene come si fa un cluster privato secondo yacy, al momento ho semplicemente 5 istanze isolate tra le quali sono suddivisi gli host casualmente, man mano che si liberano slot di crawling (crawl.py). Per avere un risultato completo dovresti quindi ripetere la query sui 5 nodi, come fa solr.py (cosa che accadrebbe automaticamente se costituissero un vero cluster yacy).
Non è molto utilizabile, quindi per ora rimane chiuso al pubblico.
I risultati sui formati file invece sono nel notebook citato prima e nella cartella output come json.
Ho studiato un po’ la diatriba sui formati ooxml. Da quel che ho capito, Microsoft è riuscita a sfruttare la standardizzazione per coprire la propria arretratezza, creando confusione col nome “office open”, proponendo uno standard iso e poi implementandolo solo in parte ed anni dopo.
Ooxml può infatti significare 3 cose diverse:
uno “standard” fasullo non pienamente specificato e ratificato dalla ECMA
uno meno fasullo concesso dalla ISOZ per permettere la transizione, ISO Transitional,
Il vero standard ISO Strict, implemtato solo con grave ritardo e tutt’ora non predefinito
Dunque, occorre classificare gli ooxml anche a seconda che siano ISO Strict, che sarebbe veramente open, oppure gli altri 2, che non possono consentire una vera interoperabilità. Non dovrebbe essere troppo difficile.
Ho capito bene, @italovignoli? ISO Strict è al pari di ODF o ci sono discriminanti? ( a parte le 6500 pagine contro 800…)
Purtroppo il tema non è se sia uno standard elegante, ma solo se sia formalmente aperto. In tal caso, non si può dire nulla ad una amministrazione che decida di adottarlo: rispetta la legge.
Quindi occorre dimostrarlo classificando questi ooxml, altrimenti ci si sentirà rispondere: “ma ooxml è standard aperto quanto odf, che volete ancora?”.
È questo che sto cercando di capire.
Anche una iniziativa di sensibilizzazione di questo tipo avesse successo, il risultato sarà un generico impegno a formare gli operatori a cliccare sul bottone giusto in modo da salvare lo strict, e magari comprare l’ultima licenza di office se quello che hanno è troppo vecchio per lo strict.
Di certo non adotteranno odf in quanto standard aperto, se lo (può essere) anche ooxml… o mi sfugge qualcosa?
Nella mia esperienza ooxml è uno standard come gli odf, il problema è che a livello tecnico è un macello.
Cioè cambia ogni due per tre e anche in base alla versione di office, quindi riuscire a catalogare le varie versioni usate nei comuni/ecc potrebbe essere un altro modo per dimostrare quanto di standard abbia solo la copertina. Il che comporta altri processi per assicurarsi che sia un formato che segue la legge rispetto agli odf che non hanno tutte queste complicazioni.
Siamo al 15% dei domini, scelti casualmente, e ci sono solo 50 documenti ooxml strict! (marcati come ooxml, mentre quelli fake sono msofficexml).
Nel json ho salvato anche le versioni di office utilizzate per salvare questi file: intendevo utilizzarle per dimostrare come, pur avendo a disposizione la possibilità di salvare strict sin dal 2010 direi, non viene mai utilizzata perché volontariamente “nascosta”. Essendo i numeri così bassi, non sarà necessario…
Nota ulteriore: LibreOffice a quanto pare non supporta il salvataggio in OOXML strict. A questo punto è utile classificare l’app che ha prodotto il documento, per capire quanti ooxml sono, paradossalmente, prodotti proprio da libreoffice.
Update: dopo un percorso travagliatissimo, siamo a 833k documenti, ma il succo non cambia: la promessa dello standard OOXML Strict ha annientato sia lo standard OASIS, che sé stesso.
Update: ho iniziato a buttare giù roba a caso per un potenziale articolo/documentazione.
Non sono per nulla competente circa la parte legale, quindi chiederei un aiuto alla community (in particolare @italovignoli) per chiarire alcuni passaggi del processo di standardizzazione e di quello normativo italiano.
Per ciascuna di queste domande servirebbe un riferimento diretto ad una legge (anno, legge, link)
Quando iniziano le raccomandazioni ufficiali circa l’uso di standard aperti nella PA?
Quando diventa obbligatorio?
Qual’è e a quando risale la legge che impone di valutare sempre alternative opensource quando si adotta un software?
Finora ho trovato solo questo inserto in gazzetta ufficiale, del 2014:
L’anomalia che sto cercando di spiegare è il picco di ODF tra il 2012 ed il 2014, pari o addirittura superiore a quello di OOXML (seppur non-strict).
Nel 2015 ODF inizia a decrescere fortemente.
Perché?
La prima versione del Codice di Amministrazione Digitale risale al 2005, quando AgID si chiamava ancora CNIPA, e già includeva la parte relativa all’utilizzo di formati aperti (il professor Meo lo cita spesso tra i suoi aneddoti) anche se da nessuna parte veniva definito “formato aperto”. Credo che il documento che hai linkato sia stata la prima versione di tale definizione ufficiale e formale.
Anche le valutazioni comparative sono state previste fin dall’inizio, ma nella norma facevano riferimento a delle linee guida che sono state per la prima volta stabilite e pubblicate nel 2013 (salvo essere aggiornate nel 2019, cfr. Gazzetta Ufficiale 119 del 23 maggio 2019).
Il glossario, che è parte integrante dell’ultima versione delle Linee
Guida, definisce il concetto di standard aperto, che mette fuori legge -
perché rispettano solo uno dei parametri - i formati Microsoft Office.
Dopo il FOSDEM, che è durante questo weekend, riesco anche a contribuire
alla discussione con qualche elemento specifico in più.
Se qualcuno vuole partecipare alla stesura, vi condivido il link in scrittura.
NOTA: Ho disabilitato quel link in quanto poi non potrebbe essere pubblicato su rivista per problemi di copyright (anche se naturalmente sarebbe poi openaccess…). Per chi è interessato a vederlo, posso mandare un link in dm.
Che spettacolo, il mio dubbio è che è in inglese e lo farei anche in italiano ma si può tradurre una volta finito.
Meglio sentire @italovignoli sul tema e il contenuto visto che lui ci è abituato a parlare con questa gente.
Grazie @italovignoli, tieni conto che è una super bozza e nei commenti latex sono indicati diversi punti ancora da scrivere completamente. L’aspetto legislativo per me purtroppo è del tutto ignoto: ho provato a ricostruire ma credo ci vorrebbe un paragrafetto con un sunto del CAD e delle linee guida AdID riguardo i formati.
Ho provato ad ipotizzare che la dinamica dipenda esclusivamente dalle release di office, con la promessa di OOXML nel 2007, realizzatasi solo nel 2010, e con la release di Office 2007, avente una interfaccia talmente diversa da rendere appetibile LibreOffice.
Ipotesi in libertà, avendo solo questi dati come base.
@mte90 l’obiettivo è tentare una pubblicazione peer-reviewed qui:
Dopodiché una traduzione è d’obbligo, rivolgendoci all’Italia.
La situazione lato OOXML è molto più complessa, e quando dico molto vuol dire almeno cinque ordini di grandezza (ma forse anche dieci). Dentro al problema ci sono: lo standard OOXML accettato in versione transitional, che non è mai passato a strict; l’evoluzione non documentata dello standard OOXML, che è stato modificato una trentina di volte senza che la documentazione delle modifiche venisse pubblicata e trasmessa a ISO; l’invenzione di uno schema XML per OOXML che va contro il buon senso, le regole di base del linguaggio XML, e il rispetto della sintassi XML; la presenza di formati proprietari e non documentati anche all’interno di OOXML strict; l’implementazione di OOXML strict in Excel, che corregge il bug togliendo un giorno dal contaggio, per cui le date precedenti al 28 febbraio 1900 vengono spostate di un giorno indietro, e se queste vengono corrette le date successive al 1 marzo 1900 vengono spostate un giorno in avanti, alla faccia della precisione. Più altre piacevolezze sparse a destra e a sinistra, come la reinvenzione dei codici colore e quella dei codici linguistici.
Italo, direi che tutte queste considerazioni passano in secondo piano, nel momento in cui si constata che l’adozione di OOXML-Strict nelle PA, pur con tutte le sue limitazioni, è di 139 parti per milione.
Ha totalmente fallito, e ancor più clamorosamente in confronto all’OpenDocument, che mantiene un 15%.
Questo è il punto centrale che voglio dimostrare nell’articolo, portando al contempo un paio di ipotesi sul perché sia andata così.
Il quadro normativo è fondamentale in quanto stiamo parlando di PA, ma deve essere accennato in forma molto riassuntiva (max 1 pagina direi), per chiarire quale possa essere stata l’influenza normativa sulle scelte tecnologiche (a mio parere, nulla).
Allo stesso modo, la differenza tra i vari OOXML è solo di contorno: l’importante è come questa confusione sia stata abilmente sfruttata da Microsoft per affossare il loro stesso OOXML-Strict, ritardandone la pubblicazione nel 2010 e poi rendendone difficile (per l’utente medio) la selezione. Se OOXML-Strict fosse stato un successo, Microsoft Office avrebbe perso gran parte del suo potenziale di lock-in e di network effect.
Il fatto che OOXML-strict abbia una documentazione folle e non sia comunque un vero standard, può essere sommariamente accennato, magari citando altri articoli come quello già individuato in questo thread.