Come specificato in sezione 2, l’applicazione può inoltrare tre tipi di richieste al Data Source:
L'architettura di Poliwiki tipicamente prevede due tipi diversi di documenti:
Tuttavia i documenti speciali sono di proprietà e cura dell'applicazione Poliwiki e quindi non sono né gestiti dai Data Source, né altrimenti di interesse per il protocollo AC-DS.
Nelle sottosezioni successive sono riportate le specifiche dettagliate e complete per l’inoltro delle query verso il DS.
Tale richiesta è realizzata con una GET HTTP di un documento con URL stabilito e reso pubblico da ogni DS al momento della registrazione (nella sezione 7 sono riportate le regole per la registrazione dei data-source e dei formatter). Si assuma ad esempio che nel wiki sia registrato il seguente DS:
| NOME | CATALOGO XML | CATALOGO HTML |
|---|---|---|
| TWDataSource | http://tw.web.cs.unibo.it/TWds.xml | http://tw.web.cs.unibo.it/TWds.html |
L’URL da utilizzare per la richiesta è appunto:
http://tw.web.cs.unibo.it/TWds.xml
Il DS risponde con una auto-descrizione espressa in sintassi XML secondo le specifiche riportate nella sezione 4.2. Si noti che il catalogo può essere un documento statico o dinamico e che è necessario fornire anche una versione human-readable (HTML) dello stesso.
Il ruolo del catalogo di un DS è fondamentale: per ogni richiesta l'AC deve consultare il catalogo del DS e recuperare l'URL completo per eseguire una richiesta o un salvataggio. Sebbene sia possibile implementare meccanismi di caching, è obbligatorio recuperare dinamicamente l'indirizzo dello script del DS dal catalogo. La modifica degli URL relativi ad un DS, quindi (tranne l'URL del catalogo) deve essere atomicamente gestita dall'AC, senza nessuna modifica manuale al codice dell'applicazione.
Il contenuto dell’elenco è appunto parametrizzato: i parametri di costruzione dell’elenco vengono specificati al momento della richiesta da parte del AC attraverso una query string e devono supportate il modello di metadati descritto in questo documento, e basato su Dublin Core e FRBR. Il DS deve supportare la ricerca per ogni elemento Dublin Core definito nel paragrafo 4.1.
L’applicazione potrebbe richiedere, ad esempio, la risorsa:
http://tw.web.cs.unibo.it/get.php?ecreator[0]=vitali&edate=2000
a cui il DS risponderà con l’elenco dei documenti (espressioni di un work) scritti dall'autore 'vitali' nell'anno 2000.
In modo simile la richiesta:
http://tw.web.cs.unibo.it/get.php?ecreator[0]=vitali&ecoverage=2008
restituirà l'elenco dei documenti (espressioni di un work) scritti dall'autore 'vitali' a proposito di eventi avvenuti nel '2008'
L'elenco di tutte le versioni di uno stesso documento il cui URI di work é norma122 può essere richiesto con:
http://tw.web.cs.unibo.it/get.php?widentifier=norma122
La ricerca invece per tag, cioe` gli elementi che sono taggati come folksonomia si dovra` effettuare cosi:
http://tw.web.cs.unibo.it/get.php?folksonomia[0]=Politica&folksonomia[1]=senato
La richiesta di una specifica versione (expression) di un documento è realizzata con una GET HTTP
all'URI univoco della expression richiesta contenuto nel campo eidentifier. Ad esempio la richiesta potrebbe essere:
http://tw.web.cs.unibo.it/pathdeidati/expressionTalDeiTali
Tale richiesta permette di creare un nuovo documento (expression e work correlato) o di salvare una nuova versione (expression) di un documento esistente. In fase di salvataggio, l'AC deve spedire al server (che è sempre lo stesso server su cui la precedente versione era memorizzata o il proprio DS se l'expression e` nuova) sia il contenuto del documento sia il set di metadati per classificare la versione.
Tale richiesta è realizzata con una POST HTTP all’URL specificato nel catalogo dall’elemento salvaURI. Il corpo della richiesta contiene una variabile di nome scheda che contiene l'XML edlla scheda vera e propria, così come descritto nella sezione 4.1. Il set di metadati deve essere completato da processi server-side in base alle informazioni di salvataggio. I metadati che il server deve completare sono eIdentifier,wDate,eDate,ePublisher, per la loro definizione si legga il paragrafo 4.2.1. L'application controller dovrà fornire valori validi al validatore XML conscio che il DS sovrascriverà qesti ultimi. In caso di creazione di work nuovo l'application controller deve fornire il valore di default "0" per widentifier e in tal caso il DS dovra` fornire un identificativo univoco a quello e inizializzare esource. La scheda che si vuole salvare deve essere contenuta nella variabile scheda, il DS dovrà rispondere con un documento xml che confermerà l'avvenuto salvataggio. Ecco il dtd dell'elemento:
<!ELEMENT risposta (%URI)>
dove %URI è l'url della risorsa appena creata e pronta per essere visualizzata. In caso di errore deve essere tornato un errore come descritto nel paragrafo 4.4. A questa pagina trovate il file schema corrispondente.
Il data source (o DS) è un modulo indipendente (cioè scollegato da qualunque altra applicazione) e passivo (cioè non ha comportamenti proattivi, ma risponde soltanto ad esplicita richiesta) che fornisce contenuti in formato XML
Ogni data source deve obbligatoriamente fornire 3 servizi: il catalogo, la query e il salvataggio.
Di seguito si definisce l'oggetto scheda, per poi andare a specificare le operazioni fattibili su di essa una volta appresane la natura.
La scheda contiene sia i metadati sia il contenuto vero e proprio di un documento. Queste informazioni sono organizzate in sezioni che raggruppano informazioni tra loro omogenee per uso. Importante notare che tutte le pagine prodotte dall'AC devono essere codificate come schede e formattate dal DF.
Ogni pagina prodotta dall'AC, inclusi il catalogo e gli elenchi, è un documento che deve essere formattato dal DF.
Questo vincolo impone che sia la home-page sia ogni eventuale altra pagina statica o dinamica, help, ringraziamenti, siano sempre gestite attraverso il DF.
Sia i documenti memorizzati nei DS che i documenti speciali devono essere formattati dal DF e condividono la stessa struttura interna
Ogni scheda ha un elemento radice scheda che contiene due elementi figlio meta e body (entrambi obbligatori) per esprimere i metadati ad esso associati ed il contenuto vero e proprio.
I content-model degli elementi meta e body seguono rispettivamente il modello di FRBR/DublinCore(con alcune modifiche) e XHTML1.1
Di seguito è riportato il dtd completo per questo elemento per una migliore comprensione della struttura. Per la validazione e` fornito anche lo schema dello stesso, successivamente le sottosezioni meta e body spiegheranno le relative parti in dettaglio.
<!ELEMENT scheda (metadati, body)>
<!ELEMENT metadati (work, expression)>
<!ELEMENT work (widentifier, wcreator+, wcoverage?, wtitle, wdate)>
<!ELEMENT expression (eidentifier, ecreator+, econtributor*, edate, edescription, elanguage, erelation,
esource, epublisher, esubject, etitle, etype)>
<!ELEMENT widentifier %URI>
<!ELEMENT eidentifier %URI>
<!ELEMENT econtributor (#PCDATA)>
<!ELEMENT wcreator (#PCDATA)>
<!ELEMENT ecreator (#PCDATA)>
<!ELEMENT wcoverage (#PCDATA)>
<!ELEMENT wdate (#PCDATA)>
<!ELEMENT edate (#PCDATA)>
<!ELEMENT edescription (#PCDATA)>
<!ELEMENT elanguage (#PCDATA)>
<!ELEMENT erelation ( %URI )>
<!ELEMENT esource ( %URI )>
<!ELEMENT epublisher (#PCDATA)>
<!ELEMENT esubject (folksonomia)+>
<!ELEMENT folksonomia (#PCDATA)>
<!ELEMENT wtitle (#PCDATA)>
<!ELEMENT etitle (#PCDATA)>
<!ELEMENT etype EMPTY>
<!ATTLIST etype
tipo (originale | dibattito | risposta | riassuto | sintesi | revisione | altro) "altro">
<!ELEMENT body (heading | block | list | image)*>
<!ELEMENT heading (h1 | h2 | h3 | h4 | h5 | h6)>
<!ELEMENT block (address | blockquote | div | p | pre)>
<!ELEMENT list (dl | dt | dd | ol | ul | li)>
<!ELEMENT flow (heading | block | inline)>
<!ELEMENT inline (abbr | acronym | br | cite | code | dfn | em | kbd | q | samp | span | strong | var | image | presentation| a)>
<!ELEMENT presentation (b | big | hr | i | small | sub | sup | tt)>
<!-- elementi di heading, block e inline -->
<!ELEMENT div (#PCDATA | flow)*>
<!ELEMENT blockquote (heading | block | list)*>
<!ELEMENT br EMPTY>
<!ELEMENT abbr (#PCDATA | inline)*>
<!ELEMENT acronym (#PCDATA | inline)*>
<!ELEMENT address (#PCDATA | inline)*>
<!ELEMENT cite (#PCDATA | inline)*>
<!ELEMENT code (#PCDATA | inline)*>
<!ELEMENT dfn (#PCDATA | inline)*>
<!ELEMENT em (#PCDATA | inline)*>
<!ELEMENT h1 (#PCDATA | inline)*>
<!ELEMENT h2 (#PCDATA | inline)*>
<!ELEMENT h3 (#PCDATA | inline)*>
<!ELEMENT h4 (#PCDATA | inline)*>
<!ELEMENT h5 (#PCDATA | inline)*>
<!ELEMENT h6 (#PCDATA | inline)*>
<!ELEMENT image EMPTY>
<!ATTLIST image (o img)
src %URI; #REQUIRED
alt %URI; #REQUIRED>
<!ELEMENT kbd (#PCDATA | inline)*>
<!ELEMENT p (#PCDATA | inline)*>
<!ELEMENT pre (#PCDATA | inline)*>
<!ELEMENT q (#PCDATA | inline)*>
<!ELEMENT samp (#PCDATA | inline)*>
<!ELEMENT span (#PCDATA | inline)*>
<!ELEMENT strong (#PCDATA | inline)*>
<!ELEMENT var (#PCDATA | inline)*>
<!-- elementi di presentation -->
<!ELEMENT b (#PCDATA | inline)*>
<!ELEMENT big (#PCDATA | inline)*>
<!ELEMENT hr (#PCDATA | inline)*>
<!ELEMENT i (#PCDATA | inline)*>
<!ELEMENT small (#PCDATA | inline)*>
<!ELEMENT sub (#PCDATA | inline)*>
<!ELEMENT sup (#PCDATA | inline)*>
<!ELEMENT tt (#PCDATA | inline)*>
<!-- elementi di list -->
<!ELEMENT dl (dt | dd)+>
<!ELEMENT dt (#PCDATA | inline)*>
<!ELEMENT dd (#PCDATA | flow)*>
<!ELEMENT ol (li)+>
<!ELEMENT ul (li)+>
<!ELEMENT li (#PCDATA | flow)*>
<!-- Modulo Hypertext -->
<!ELEMENT a (#PCDATA) >
<!ATTLIST a href CDATA #REQUIRED >
Qui si trova il file schema con cui validare i documenti contenenti schede.Attenzione Per quanto a livello di DTD etype sia vuoto e contenga le differenziazioni a livello di attributi, negli Schema si e` spostata la differenziazione a livello di elemento per semplificare le interazioni con la query. Sempre negli schema sono specificati i valori di default per le date,per il widentifier e per esource, cose che non si evincono dal DTD che, ripetiamo, serve solo per la comprensione strutturale.
meta Il modello di metadati di PoliWiki si ispira a FRBR. Tuttavia siccome gli elementi manifestation e item sono forniti dal Data Formatter, non sono riportati tra i figli di meta Non sarebbe possibile riempire i campi manifestation di una scheda a priori in quanto il data source può non sapere che data formatter è in uso, è altrettanto difficile definire la locazione fisica di un oggetto che potrebbe essere semplicemente il risultato di uno script server-side che restituisce la scheda a partire dalle varie expression della stessa organizzando il tutto in un file xml corretto.Sono state rimosse le voci dc:Format e dc:Rights , la prima per il sopracitato motivo, la seconda perche tutti i documenti del PoliWiki sono rilasciati secondo la licenza Gnu FDL.La prima lettera di ogni elemento indica l'apparteneza del medesimo a Work oppure Expression, pertanto non si adotta il namespace dc.
Di seguito sono riportati esempi dell'intero modello FRBR, si ricorda che in questo protocollo si utilizzano solo i primi due termini.
Ogni scheda è quindi descritta specificando i metadati relativi ad ognuno di questi due concetti. Questo vuol dire che il content-model dell'elemento meta è una sequenza di due elementi (obbligatori): work, expression.
Ognuno di questi elementi può contenere una sequenza di elementi metadatali, secondo lo schema Dublin Core. Lo schema Dublin Core prevede che alcune proprietà abbiano come valore una stringa (Data Properties) altri un riferimento ad un’istanza di una qualche classe (Object Property). Alcune stringhe sono limitate ad una serie di valori predefinite. Altre sono libere. Altre ancora sono stringhe multiple separate da spazi o altri separatori.
Inoltre, alcune delle proprietà Dublin Core sono significative per alcune categorie FRBR, ma non hanno senso in altri casi. Ad esempio, si può parlare dell'editor (dc:publisher) di una manifestation ma non di un work. Allo stesso modo, ha senso parlare del periodo a cui un documento si riferisce (dc:coverage) per un work, ma non per una manifestation (perché in realtà si riferiscono allo stesso periodo). Altre proprietà Dublin Core hanno senso per tutte le dimensioni FRBR, come dc:identifierche infatti è stato suddiviso in eidentifier per rappresentare l'identificativo dell'expression e widentifier per identificare quello del Work.
La seguente tabella riporta l'elenco delle proprietà il cui supporto è richiesto e garantito dal protocollo, il tipo di ogni proprietà, una breve descrizione del suo uso in PoliWiki, l'ambito FRBR a cui si applica e il nome PoliWiki.
| Elemento Dublin Core | DataProperty/ ObjectProperty |
Tipo | Descrizione | Ambito FRBR | Nome Poliwiki |
|---|---|---|---|---|---|
dc:contributor |
OP | agente (organizzazione o persona) | Entità che ha contribuito alla stesura dell'expression | E | econtributor |
dc:creator |
OP | agente (organizzazione o persona) | Entità che hanno creato l'opera. | W,E | wcreator ecreator |
dc:coverage |
OP | Year | Collocazione temporale dell'argomento del documento | W | wcoverage |
dc:date |
DP | Date | Data associata ad un evento del ciclo di vita della risorsa. | W, E | wdate edate |
dc:description |
DP | Stringa | Spiegazione del contenuto della risorsa. | E | edescription |
dc:identifier |
OP | URI | Identificativo univo della risorsa all'interno del sistema. Usato per fare retrieve della risorsa, selezionarla da un elenco, etc. In caso di creazione di un nuovo work deve essere settato a "0" per permettere al DS di istanziarlo correttamente. | W, E | widentifier eidentifier |
dc:language |
DP | Lista Valori | Indica il linguaggio, o anche più linguaggi, in cui un documento è scritto. L'elenco di valori usabili e` "it" ed "en". | E | elanguage |
dc:relation |
OP | URI | Punta ad un URI. Indica l'expression di cui è una nuova versione. Importante nel sistema PoliWiki per permettere un corretto versionamento e retrieval dei documenti, in una expression non dipendente da nessun altra deve venir lasciato vuoto. | E | erelation |
dc:source |
OP | URI | Punta ad un URI. Indica il work di cui è un expression. Importante nel sistema PoliWiki per permettere un corretto versionamento e retrieval dei documenti. | E | esource |
dc:publisher |
OP | URI | L'entità responsabile di rendere la risorsa accessibile.Questo campo deve contenere l'URI del catalogo da cui la risorsa e` stata richiesta. | E | epublisher |
dc:subject |
DP | Lista Valori | Indica gli argomenti trattati in un documento. Particolarmente utile in PoliWiki per costruire folksonomie relative ai documenti e classificare le varie risorse. Tale classificazione sarà poi usata per generare elenchi, meccanismi di navigazione avanzati, selezione ragionata dei data, etc. | E | esubject |
dc:title |
DP | Stringa | Indica il titolo di una risorsa. Il titolo non si riferisce ad una manifestation, ma all'expression e all'intero work da cui derivano. Tutte le varianti dello stesso documento, dunque, condividono lo stesso titolo a livello di work, e possono averne uno diverso a livello di expression. | W, E | wtitle etitle |
dc:type |
DP | Lista Valori | Il tipo di un documento. Esistono alcuni tipi predefiniti, il cui elenco va eventualmente esteso in successive versioni del protocollo PoliWiki: 'originale','dibattito','risposta','riassunto','sintesi','revisione','altro'. | E | etitle |
Legenda:
| OP | Object Property |
|---|---|
| DP | Data Property |
| W | Work |
| M | Manifestation |
| E | Expression |
Il seguente frammento riporta un esempio di scheda validabile e i suoi metadati:
<ds:scheda
xmlns:ds="http://ltw.web.cs.unibo.it/esempio"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://ltw.web.cs.unibo.it/esempio http://vitali.web.cs.unibo.it/twiki/pub/TechWeb08/PagSchemaDS/schedaSchema.xsd"
>
<metadati>
<work>
<widentifier>http://www.datasourcedelcittadino.it/elettorale2008</widentifier>
<wcreator>Onorevole Rossi</wcreator>
<wcoverage>2008</wcoverage>
<wtitle>Legge Elettorale 2008</wtitle>
<wdate>2001-01-01T01:01:01</wdate>
</work>
<expression>
<eidentifier>http://www.datasourcedelcittadino.it/elettorale2008/v02</eidentifier>
<ecreator>Onorevole Rossi</ecreator>
<edate>2001-01-01T01:01:01</edate>
<edescription>Questa documento parla della legge elettorale valida nelle elezioni 2008,
e si focalizza sullo sbarramento al Senato.</edescription>
<elanguage>it</elanguage>
<erelation>http://www.datasourcedelcittadino.it/elettorale2008/v01</erelation>
<esource>http://www.datasorcedelcittadino.it/elettorale2008/v01</esource>
<epublisher>Data Source del Cittadino</epublisher>
<esubject>
<folksonomia>Politica</folksonomia>
<folksonomia>Senato</folksonomia>
<folksonomia>Elezioni</folksonomia>
</esubject>
<etitle>Legge Elettorale 2008</etitle>
<etype>risposta</etype>
</expression>
</metadati>
<body>
...
</body>
</ds:scheda>
body L'elemento body contiene il contenuto vero e proprio di un documento. Tale contenuto deve essere validato dallo schema che si trova qui. In particolare, dalla versione XHTML1.1. Tale versione permette di selezionare/deselezionare moduli del DTD ed includere/escludere alcuni elementi. La seguente tabella riporta l'elenco dei moduli di XHTML 1.1 che devono essere supportati in PoliWiki
| Modulo | Supporto PoliWiki | Elementi |
|---|---|---|
| Structure Module | NO | - sostituiti dagli elementi PoliWiki - |
| Text Module | SI | abbr, acronym, address, blockquote, br, cite, code, dfn, div, em, h1, h2, h3, h4, h5, h6, kbd, p, pre, q, samp, span, strong, var |
| Hypertext Module | SI | a |
| List Module | SI | dl, dt, dd, ol, ul, li |
| Object Module | NO | - |
| Presentation Module | SI | b, big, hr, i, small, sub, sup, tt |
| Edit Module | NO | - |
| Bidirectional Text Module | NO | - |
| Forms Module | NO | - |
| Table Module | Opzionale | caption, col, colgroup, table, tbody, td, tfoot, th, thead, tr |
| Image Module | SI | img |
| Client-side Image Map Module | NO | - |
| Server-side Image Map Module | NO | - |
| Intrinsic Events Module | NO | - |
| Metainformation Module | NO | - sostituiti dagli elementi PoliWiki - |
| Scripting Module | NO | - |
| Stylesheet Module | NO | - gestiti dal DF - |
| Style Attribute Module | NO | - gestiti dal DF - |
| Link Module | NO | - gestiti dal DF - |
| Base Module | NO | - |
All'interno del contenuto sono quindi ammessi elementi come div, span, b, ul (tutti gli elementi dei moduli attivati), mentre non sono ammessi gli elementi per form, mappe, oggetti, etc. Le versioni successive del protocollo PoliWiki potranno obbligare l'uso di moduli al momento opzionali (es. tabelle) o richiedere il supporto per ulteriori moduli.
Il catalogo è un documento statico o dinamico in cui vengono elencate le funzionalità fornite dal modulo. Attraverso il catalogo un’applicazione o un utente a valle può decidere cosa utilizzare del modulo e come. Il catalogo è sempre accessibile via un URI fisso obbligatoriamente registrato (vedi cap. 7).
Il catalogo ha l’elemento catalogo come radice, ed è diviso in
due parti: globale e accesso . Nella parte globale
si forniscono informazioni sul modulo. Nella parte accesso si forniscono gli URI dei servizi richiedibili al catalogo.
<!ELEMENT catalogo (globale, accesso) > <!ELEMENT globale (nome, descrizione) > <!ELEMENT nome (#PCDATA)> <!ELEMENT descrizione %inline; > <!ELEMENT accesso (queryURI,salvaURI) > <!ELEMENT queryURI %URI > <!ELEMENT salvaURI %URI; > <!ENTITY % URI (CDATA)>Qui si trova il file schema a cui riferirsi per la validazione.
L’elemento globale riporta il nome del DS e una descrizione leggibile del tipo di contenuti ad esso relativi. L'elemento accesso specifica gli URI dei meccanismi di accesso da utilizzare per accedere ai vari tipi di documento e richiedere i vari servizi al DS.
Ogni URI è assoluto, le regole per formare le query seguono lo schema http cioè in caso di query si specificano i parametri con un elenco di attributo=valore divisi da & preceduti da ?. In caso di assenza di coppie attributo=valore dopo il ? la query e` da ritenersi errata e quindi va generato un errore come descritto al paragrafo 4.4.
L'elemento salvaURI specifica l'URL da usare per il POST di salvataggio di un nuovo documento o versione. E' possibile ma non strettamente necessario aggiungere parametri di salvataggio, oltre ai metadati contenuti all'interno del documento che si sta salvando.
Il response è un documento fornito come risposta ad una query. La query è sempre
una espressione della forma campo1=val1&campo2=val2… in cui
campo1 e campo2 sono campi Dublin Core ammessi alla query, e
val1 e val2 sono valori compatibili con i tipi dei
campi 1 e 2. Inoltre le query hanno una componente che permette di identificare una risorsa all'interno del modello FRBR. La sezione 4.1 descrive il modello di metadati adottato da PoliWiki. Per i valori di wcreator,ecreator,econtributor e folksonomia si utilizzano degli array per ricercare in tutti i tag, pertanto una ricerca su piu creatori di un work avra` la forma http://queryURI?wcreator[0]=autor&wcreator[1]=altroAutor ecc ecc. Per la ricerca di folksonomie non si deve creare una query con valore associato a esource in quanto i DS sono teuti a supportare la specifica pergli elementi folksonomia.
Tutte le ricerche devono supportare la wildcard *, mentre di nessun'altra è richiesta l'implementazione. Qualora si scelga di implementare anche altre wildcard bisogna offrire il supporto per il -, ovvero la ricerca con omissione di parole. Il simbolo di * indica una qualunque sequenza (anche vuota) di caratteri, secondo la sintassi delle espressioni regolari. Quindi l'elenco corrispondente alla richiesta
http://www.sito.com/techweb_ds.php?etitle=p*
conterrà informazioni su tutte e sole le schede-contenuto il cui titolo inizia per 'p'. Ci sarà quindi un item relativo a "Partito Democratico" o uno per "Popolo della Libertà"., ma non ci sarà un item relativo a "Sinistra Arcobaleno"
L'elemento response è definito come una sequenza di 0 o piu sezioni di metadati. Contando l'interazione con piu DS contemporaneamente infatti, bisogna collezionare tutti i set di metadati che hanno corrisposto alla nostra richiesta pertanto ogni DS è obbligato a rispondere solo quelli se ne ha. L’elemento response riporta nell’attributo query la query che è stata effettuata per generare l’elenco stesso.
<!ELEMENT response (meta)*> <!ATTLIST response query CDATA #REQUIRED>Qui trovate il file schema da utilizzare per validare.
Ad esempio, il seguente è un elenco di commenti relativi ad uno stesso work intitolato "Legge Elettorale 2008":
<response query="etype=risposta&wTitle=Legge%20Elettorale%202008">
<metadati>
<work>
<widentifier>http://www.datasourcedelcittadino.it/elettorale2008/comm01</widentifier>
<wcreator>Onorevole Rossi</wcreator>
<wcoverage>2008</wcoverage>
<wtitle>Legge Elettorale 2008</wtitle>
<wdate>2001-01-01T01:01:01</wdate>
</work>
<expression>
<eidentifier>http://www.datasourcedelcittadino.it/elettorale2008/comm01V01</eidentifier>
<ecreator>Onorevole Rossi</ecreator>
<edate>2001-01-01T01:01:01</edate>
<edescription>Questa documento parla della legge elettorale valida nelle elezioni
2008 e ne evidenzia gli aspetti positivi.</edescription>
<elanguage>it</elanguage>
<esource>http://www.datasorcedelcittadino.it/elettorale2008/comm01</esource>
<erelation></erelation>
<epublisher>Data Source del Cittadino</epublisher>
<esubject>
<folksonomia>Politica</folksonomia>
<folksonomia>Senato</folksonomia>
</esubject>
<etitle>Legge Elettorale 2008, la buona notizia</etitle>
<etype>risposta</etype>
</expression>
</metadati>
<metadati>
<work>
<widentifier>http://www.datasourcedelcittadino.it/elettorale2008/comm01</widentifier>
<wcreator>Onorevole Rossi</wcreator>
<wcoverage>2008</wcoverage>
<wtitle>Legge Elettorale 2008</wtitle>
<wdate>2001-01-01T01:01:01</wdate>
</work>
<expression>
<eidentifier>http://www.datasourcedelcittadino.it/elettorale2008/comm01V02</eidentifier>
<ecreator>Onorevole Verdi</ecreator>
<edate>2001-01-02T01:01:01</edate>
<edescription>Questa documento parla della legge elettorale valida nelle elezioni 2008,
e si focalizza sullo sbarramento al Senato.</edescription>
<elanguage>it</elanguage>
<esource>http://www.datasorcedelcittadino.it/elettorale2008/comm01</esource>
<erelation>http://www.datasorcedelcittadino.it/elettorale2008/comm01V01</erelation>
<epublisher>Data Source del Cittadino</epublisher>
<esubject>
<folksonomia>Politica</folksonomia>
<folksonomia>Senato</folksonomia>
<folksonomia>Elezioni</folksonomia>
</esubject>
<etitle>Legge Elettorale 2008, al senato</etitle>
<etype>risposta</etype>
</expression>
</metadati>
<metadati>
<work>
<widentifier>http://www.datasourcedelcittadino.it/elettorale2008/comm01</widentifier>
<wcreator>Onorevole Rossi</wcreator>
<wcoverage>2008</wcoverage>
<wtitle>Legge Elettorale 2008</wtitle>
<wdate>2001-01-01T01:01:01</wdate>
</work>
<expression>
<eidentifier>http://www.datasourcedelcittadino.it/elettorale2008/comm01V03</eidentifier>
<ecreator>Onorevole Pigna</ecreator>
<edate>2001-01-03T01:01:01</edate>
<edescription>Questa documento parla della legge elettorale valida nelle elezioni 2008 e
discute tutti gli aspetti negativi in dettaglio.</edescription>
<elanguage>it</elanguage>
<esource>http://www.datasorcedelcittadino.it/elettorale2008/comm01</esource>
<erelation>http://www.datasorcedelcittadino.it/elettorale2008/comm01V02</erelation>
<epublisher>Data Source del Cittadino</epublisher>
<esubject>
<folksonomia>Politica</folksonomia>
<folksonomia>Senato</folksonomia>
<folksonomia>Male</folksonomia>
</esubject>
<etitle>Legge Elettorale 2008, la cattiva notizia</etitle>
<etype>risposta</etype>
</expression>
</metadati>
</response>
Il modello di metadati adottato nel sistema PoliWiki è quello esposto nella prima sezione dedicata alla scheda.
Le richieste inoltrate al DS possono generare diversi errori. Per gestirli il protocollo ACDS prevede una risposta HTTP appropriata con status code corretto e un body contenente un messaggio di errore che riporta un codice ed una descrizione human-readable per l’errore. Il messaggio deve essere validato dal seguente DTD:
<!ELEMENT errore (codice, descrizione)> <!ELEMENT codice (#PCDATA)> <!ELEMENT descrizione %inline;>Qui trovate il file schema da utilizzare per validare.
Il seguente frammento XML riporta un esempio di messaggio di errore:
<errore> <codice>503</codice> <descrizione>DS non disponibile.</descrizione> </errore>
Viene riportata di seguito una tabella con gli errori e le relative descrizioni:
| Codice errore | Descrizione Errore |
|---|---|
| 503 | DS non disponibile |
| 400 | Parametri query errati o errore nel salvataggio della scheda |
| 404 | Scheda inesistente (id non valido) |
IMPORTANTE: il codice di errore deve essere contenuto obbligatoriamente anche all'interno della risposta HTTP. In particolare, ogni errore dovrà essere associato al corrispondente codice HTTP ed essere ritornato dal DS. Il contenuto dell'elemento errore è quindi duplicato e non strettamente richiesto.