Progetto:Qualità/Semantizzazione

Da oggi 10.10.10 (bella data!), i contenuti dei parametri dei template Autore e i contenuti dei parametri del template Intestazione (per le opere con testo a fronte) sono "semantizzati", ossia sono richiamabili in qualsiasi spazio di it.source.

Briciole approssimative di teoria

Normalmente, wiki non consente di definire "variabili" (ossia oggetti dotati di un nome e di un contenuto, quest'ultimo richiamabile per nome), con l'unica eccezione della pagina (infatti, il contenuto di una pagina può essere "richiamato per nome": è la transclusione).

Ma tutte le source hanno installata l'estensione #lst, che consente di definire, all'interno di una pagina, un numero indeterminato di "variabili" (le sezioni) dotate di "nome" e di "contenuto", e fornisce uno strumento per richiamarne il contenuto attraverso il nome (nome della pagina+nome della sezione).

Esistono, in wiki, delle speciali "variabili", i parametri dei template; ma la loro esistenza è limitata al template; NON possono essere richiamate dall'esterno dello specifico template.

Due strade per la semantizzazione (novembre 2011)

Vi sono due strade possibili per trasformare dati in variabili:

1. la trasclusione, che permette di utilizzare i dati in qualsiasi pagina, tranne che nella stessa pagina che li contiene;
2. la inclusione di codice html, che permette di utilizzare i dati nella sola pagina che li contiene via javascript (senza ricorrere a chiamate AJAX).

Meccanismo della semantizzazione via transclusione

Si tratta semplicemente di un'applicazione del normale meccanismo di transclusione via section (transclusione selettiva). Se il dato (un frammento di testo qualsiasi) viene racchiuso fra tag section, il nome della section funziona da nome di variabile e il contenuto della section diventa il valore della variabile. Per richiamare la variabile, occorre però conoscere il nome della pagina che la contiene; in pratica, il "nome della variabile" è costituito dal nome della pagina che contiene la variabile + nome della section.

Occorre tener conto che la lettura di una di queste variabili implica, lato server, la lettura di una pagina diversa da quella visualizzata ed è quindi "costosa" in termini di impegno del server. Se una pagina richiama molte variabili di questo tipo, la risposta può diventare molto lenta e il carico del server notevole; occorre moderazione. Da evitare se il numero di variabili utilizzate oltrepassa le 10-20.

Meccanismo della semantizzazione via inclusione di codice html

Se viene scritto, nella pagina, un codice html tipo:

• <span class="SAL">215,1,Alex_brollo</span>

allora questo codice sarà transcluso tal quale sia nella pagina dove il testo è contenuto che in eventuali pagine che transcludono la pagina originale. All'apertura della pagina, uno script js può trovare il codice ed interpretarlo, eseguendo ogni tipo di elaborazione immaginabile.

E' teoricamente possibile assegnare un nome a questi "contenitori span", utilizzando un attributo del tag span, ad es. l'attributo title:

• <span class="SAL" title="test">Contenuto della variabile test</span>

E' quindi teoricamente possibile disporre di variabili, come nel caso della transclusione, dotate di un nome e di un contenuto.

La class SAL ha la caratteristica di avere uno stile display:hidden (vedi MediaWiki:Common.css), e quindi nulla viene visualizzato nella pagina; il dato è disponibile e utilizzabile solo a un opportuno script js.

Questo metodo di semantizzazione è totalmente trasparente per il server (tutta l'elaborazione si svolge nel browser locale) e quindi non vi sono preoccupazioni di sovraccarico del server. Le routine js necessarie a reperire e elaborare le informazioni sono molto semplici, e quindi non vi è apprezzabile ritardo nella visualizzazione della pagina in caricamento.

Il metodo di semantizzazione

La "semantizzazione" dei dati contenuti nei parametri di un template può però avvenire creando, per ogni parametro del template, una sezione esterna al template (le sezioni definite all'interno di un template non funzionano!), con lo stesso nome del parametro, contenente il valore del parametro. Il procedimento sarebbe estremamente tedioso e esporrebbe a molti errori e dimenticanze, se fatto a mano da un utente; è stato quindi preparato uno specifico script python che, ad ogni modifica di una pagina Autore o di una pagina principale Ns0:

1. legge la pagina e estrae i template Autore o Intestazione;
2. ottiene l'elenco dei parametri e dei loro valori;
3. crea il codice delle sezioni e le accoda in un testo unico;
4. aggiunge in testa e in coda codici tali da impedire la visualizzazione delle sezioni, ma di consentirne la transclusione, e aggiunge un messaggio per invitare l'utente che modifica la pagina a non modificare questa "zona dati";
5. aggiunge la "zona dati" alla pagina, previa eliminazione dell'eventuale zona dati preesistente.

La "zona dati" di Rime (Vittorelli) per esempio ha questo aspetto:

<!-- Area dati: non modificare da qui: --><onlyinclude><div style="display:none">
<section begin="Nome e cognome dell'autore" />Iacopo Vittorelli<section end="Nome e cognome dell'autore" />
.......
<section begin="nome template" />Intestazione<section end="nome template" />
</div></onlynclude><!-- a qui -->

Questo codice rende disponibile il contenuto della pagina Rime (Vittorelli)|section="Nome e cognome dell'autore" che è ilnome dell'autore, esattamente come inserito nel template. La stessa cosa per tutti gli altri parametri. Nel caso di parametri vuoti, non viene scritta alcuna section; questo sfrutta una delle proprietà delle section, che restituiscono "un bel nulla" (una stringa vuota) sia che esistano e contengano una stringa vuota, sia che non esistano affatto.

Usare il tutto: il {{Dato}}

Il template {{Dato}}, come dice il nome, restituisce un dato. ;-)

Restituisce cioè il nome di una "variabile", ossia del contenuto di una section in una pagina (qualsiasi section di qualsiasi pagina, ma suggerisco di usarlo solo per i "dati semantici").

Esempio: gli autori hanno un campo Anno di nascita; per recuperare l'anno di nascita di Giacomo Leopardi, scriviamo:

* {{Dato|Autore:Giacomo Leopardi|Anno di nascita}}

e otteniamo:

Oppure, per ottenere un dato di un'opera, scriviamo ad esempio:

* {{Dato|Georgiche|URL della versione cartacea a fronte}}

e otteniamo

• Indice:Georgiche.djvu

Ma possiamo anche annidare le variabili: ad esempio, possiamo chiedere nome, professione e nazionalità dell'autore di Georgiche usando solo Georgiche come dato di partenza (passando il risultato di un template a un secondo template) e "linkeggiare"

* [[Georgiche]] è stato scritto da [[Autore:{{Dato|Georgiche|Nome e cognome dell'autore}}|{{Dato|Georgiche|Nome e cognome dell'autore}}]], {{Dato|Autore:{{Dato|Georgiche|Nome e cognome dell'autore}}|Professione e nazionalità}}.

• Georgiche è stato scritto da Publio Virgilio Marone, .

Sviluppi futuri

Niente, ma niente, impedisce di "fondere" della sezione dati i contenuti di diversi template, anche contenuti in diverse pagine. Lo sviluppo più ovvio è quello di incorporare nella sezione dati delle opere anche i dati contenuti nel template Qualità (contenuto nella stessa pagina) e nel template Infotesto dell'opera (contenuto nella pagina di discussione).

I dati elementari possono essere "montati" in template derivati, che li inseriscono in frasi a schema fisso, oppure generano righe di tabelle standard (anche "sortable").

Update

Esiste già una versione "pre-alfa" dello script che raccoglie dentro l'area dati sia i parametri di qualità, che di infotesto, ma c'è un piccolo bug da risolvere. Bug a parte, la cosa non solo è fattibile, ma è dimostrato che funziona.

Un test

Il codice:

* {{testo/Sandbox|Georgiche}}

produce:

•     Georgiche  , Publio Virgilio Marone, traduzione di Clemente Bondi, Venezia, Adolfo Cesare, 1801

Ma se invece viene posto un una pagina o sottopagina qualsiasi di Georgiche, si comporta in maniera differente per dimostrare che non è un template stupido. :-)

Limiti

Creando tabelle occorre considerare il limite di template ammessi in una pagina; è facile lasciarsi prendere dall'entusiasmo e superare il limite ammesso (qualche centinaio).

Tutto chiaro? :)

Non ho questa presunzione.... commenti, critiche, vaffi in Discussioni progetto:Qualità/Semantizzazione o nella pagina di discussione del primo contributore. Test: dove più vi piace: la cosa dovrebbe funzionare ovunque.

Update: area dati contenente variabili da template multipli e pagine multiple

In Georgiche è caricata la prima "area dati" che contiene una collezione di tuti i dati provenienti da:

1. template Intestazione, della stessa pagina;
2. template Qualità, della stessa pagina;
3. template Infotesto, della pagina di discussione.

Trick 1

Esiste un facile metodo per puntare più "nomi di variabile" (=più nomi di section) sullo stesso contenuto. Per farlo basta annidare le section sinonime una dentro l'altra. Il trucco è applicato per far puntare allo stesso dato, il dato logico "autore", due diversi nomi di parametro: "Nome e cognome dell'autore" (la maggioranza dei progetti) e "Organismo emittente" (il progetto Diritto). Il codice che viene usato per estrarre il dato impostando indifferentemente l'uno o l'altro sininimo è:

<section begin="Organismo emittente" /><section begin="Nome e cognome dell'autore" />Regno di Sardegna<section end="Nome e cognome dell'autore" /><section end="Organismo emittente" />

Il numero di section annidate non pare avere limiti. Il sistema funziona perchè, durante la lettura per la transclusione, il sistema legge tutto quello che c'è fra le section begin e end chiamate per nome, e poi rimuove tutti i tag section dal testo estratto.

Una prima implementazione pratica

Allo scopo di rendere immediatamente utile la procedura, e di dimostrare la sua versatilità, è stata implementata una variante sperimentale del template Testo.

La sintassi del template è rimasta immodificata.

L'output del template però si è arricchito, e ha anche comportamenti implicitamente "condizionali".

Le regole di comportamento del template sono:

1. se l'opera è proofread, viene generata una piccola icona-link alla corrispondente pagina Indice;
2. se il template viene apposto in una pagina diversa dalla pagina dell'autore dell'opera, o in una sottopagina dell'opera, viene visualizzato solo il link + icona SAL;
3. se il template viene apposto in una pagina diversa dalle precedenti, viene visualizzato anche il nome dell'autore, come link, e la data di pubblicazione fra parentesi.

Esempio con Georgiche:    Georgiche   di Publio Virgilio Marone (I secolo a.C.), traduzione dal latino di Clemente Bondi (1801)

Tabelle

I dati si prestano molto bene alla rappresentazione tabellare.

Titolo	Autore	Anno di pubblicazione	Progetto	Argomento	URL della versione cartacea a fronte
I promessi sposi	[[Autore:]]				[[]]
Rime nuove	Autore:Giosuè Carducci	1906	letteratura	Raccolte di poesie	Indice:Poesie_(Carducci).djvu
Tigre reale	Autore:Giovanni Verga	1875	letteratura	Romanzi	Indice:Tigre_Reale.djvu
Il giaurro	Autore:George Gordon Byron	1813	Letteratura	Poemi	Indice:Poemi (Byron).djvu

Il codice delle righe può essere incorporato in un template;il tempate Riga dati, con parametro tipoRiga=1, fornisce una riga completa della tabella di esempio precedente (la terza e quarta riga della tabella sono richiamate in questo modo). Il template si basa su uno switch, per cui può "montare" diversi set di dati, ognuno con una particolare formattazione, richiamabili singolarmente con tipoRiga=2, tipoRiga=3... fino a esaurimento del numero di alternative ammesse per la funzione #switch.

Le tabelle derivate possono anche essere sortable:

Titolo	Autore	Anno di pubblicazione	Progetto	Argomento	URL della versione cartacea a fronte
I promessi sposi	[[Autore:]]				[[]]
Rime nuove	Autore:Giosuè Carducci	1906	letteratura	Raccolte di poesie	Indice:Poesie_(Carducci).djvu
Tigre reale	Autore:Giovanni Verga	1875	letteratura	Romanzi	Indice:Tigre_Reale.djvu
Il giaurro	Autore:George Gordon Byron	1813	Letteratura	Poemi	Indice:Poemi (Byron).djvu

Obiettivi (in ordine di priorità)

1. Sistemare il template Testo e farlo diventare lo standard Fatto, no? --Aubrey McFato 10:11, 18 ott 2010 (CEST)
2. Sistemare la sezione Ultimi Arrivi, se possibile, con dati semantici (ci manca ancora la DPL, intanto iniziamo)
3. Riprodurre la tabella autori con i dati semantici
4. Riprodurre le liste di testi e autori ora gestiti da Bimbot con i dati semantici (Indici e Liste)

A latere, data la "semantizzazione", sarebbe utile definire nuovamente i template utilizzando Dubln Core e magari riuscendo a costruire dei form per l'inserimento dei Dati. Si potrebbe iniziare dalla pagina autore, prendendo spunto dal namespace Creator di Commons. (Menzione di Creator + Dublin Core=Aubrey sloggato) :-)

Limiti

Va sottolineato che il sistema non può produrre liste, ma solo recuperare un set di informazioni collegate all'opera, o all'autore, con una relazione 1:1 (anche concatenate fra di loro: opera->autore->dato autore).

Test dimostrano che purtroppo il sistema viene facilmente "stressato" ed è molto facile raggiungere il numero massimo di template inclusi ammessi (500); va quindi riservato a elenchi limitati. Tuttavia, dovrebbe semplificare (in quanto "standardizza" e mette in luce alcuni errori formali nei template) anche il lavoro di un eventuale bot nel parsing e estrazione dei dati.

Le liste potrebbero essere prodotte con la DPL? Si potrebbero creare categorie ad hoc (magari nascoste)? --Aubrey McFato 10:09, 18 ott 2010 (CEST)

DPL produce solo liste di link, che però sono presenti nel solo html della pagina e non nel codice. In teoria possono essere lette da Alebot se Alebot carica l'html e non il codice; dopodichè dei link Alebot potrebbe fare qualcosa.... ma senza toccare il codice DPL, altrimenti... ;-)

Comunque, accertato che edit multipli di pagine lista non sono poi così mal visti dal "grandi capi", purchè riflettano vere modifiche dei dati, sì: si può pensare che DPL generi le liste e che Alebot le legga sull'html e con quella lista costruisca un'altra pagina utilizzando (ma non via template Dato: direttamente) i dati semantizzati. --Alex brollo (disc.) 10:16, 18 ott 2010 (CEST)

Update 17.10.10

Girano, sui miei js personali (Utente:Alex brollo/ocr_var.js) alcune funzioni in fase di test che:

1. in fase di caricamento pagina eliminano l'area dati dal testo caricato, e memorizzano l'area dati in una variabile globale areaDati, se:
   1. la pagina è Ns0 o Autore e
   2. la modalità è modifica pagina
2. in fase di upload, ricaricano nel testo l'area dati immodificata in testa alla pagina.

Al momento, Alebot carica l'area dati in una zona diversa della pagina (sotto Intestazione o Autore) e i prossimi passi sono:

1. caricare gli script in Common.js;
2. modificare gli script di Alebot in modo che carichi l'area dati in testa alla pagina

Il passo successivo, più impegnativo, è quello di aggiornare l'area dati via js, in base all'edit dell'utente, prima del caricamento. Fatto questo i dati "semantizzati" saranno immediatamente aggiornati all'atto dell'edit (al momento, invece, sono aggiornati nel momento in cui ci passa sopra Alebot, esattamente come oggi avviene per gli script di BimBot).

Update 19.10.10

1. Il sistema è implementato su Commons.js (routine in fondo alla pagina) e sono stati adeguati gli script di Alebot per la verifica dei dati ad ogni edit intercettato.
2. E' stato testata positivamente la possibilità di estendere il sistema alle pagine Pagina e nulla impedisce di estenderlo alle pagine Indice.

WIP: qualità delle pagine Pagina

Sono in un dilemma. Da un lato mi piacerebbe inserire un'area dati delle pagine Pagina:, sempre "a scomparsa", dall'altro mi pare più giusto inserire l'area, invece, nella pagina Discussioni pagina:, dove creerebbero disturbo minimo (nessuno ci entra mai...)

Opto per la seconda soluzione ma provvisoriamente: inserire il dato nella Pagina consentirebbe a Candalua di scrivere poche righe di js per aggiurnare il SAL semantizzato al volo.... bè, casomai rifaremo tutto daccapo.

Già adesso, vedete che le iconcine link alla pagina, in Ns0, hanno spesso il simbolo SAL (grigino).In dettaglio, le regole sono:

1. se non esiste la pagina di discussione della pagina, il simbolo manca;
2. se la pagina è SAL 00% oppure se non c'è ancora un'Area dati, il simbolino è grigino;
3. se l'area dati c'è, e il SAL è 25% o superiore, il simbolo SAL rappresenta il vero SAL pagina, al momento dell'ultima passata di Alebot (che core almeno una volta al giorno).

Attivata procedura per la semantizzazione del pagequality level

La procedura di semantizzazione del pagequality level delle pagine è attivata lato Alebot.

Ad ogni edit nel nsPagina, Alebot legge il level nel tag pagequality e lo registra in un'area dati della pagina di discussione della pagina (al momento nascosta in visualizzazione ma non in edit). Si rende quindi disponibile la "variabile" pagequality, richiamabile dovunque con la sintassi {{#section:Discussioni nome pagina|pagequality}}, che contiene i valori SAL 00%, 25%... 100%. La chiamata della variabile è stata montata nel template di sistema MediaWiki:Proofreadpage pagenum template ‎, che genera il link alla pagina nel ns0, e a cui adesso viene aggiunta l'icona SAL quale risulta dall'aggiornamento della variabile. Siccome l'aggiornamento è fatto via bot, può esserci un certo ritardo nell'aggiornamento.

Al momento vengono aggiornate solo le pagine effettivamente editate.

Le opere "completamente allineate sono, al momento, Storia di una capinera e, sperimentalmente, Le poesie di Catullo.