Skip to topic | Skip to bottom
Home

TechWeb08
TechWeb08.ProtocolloDSFreez2r1.7 - 29 May 2008 - 18:40 - MarcoPatrignanitopic end

Start of topic | Skip to actions
-- MarcoPatrignani - 21 May 2008
  • Set ALLOWTOPICVIEW =
  • Set ALLOWTOPICCHANGE = MarcoPatrignani?

3. Query al Data Source

Come specificato in sezione 2, l’applicazione può inoltrare tre tipi di richieste al Data Source:

  • catalogo ossia le metainformazioni relative al DS
  • query ovvero la richiesta di un sottoinsieme ragionato dei dati presenti nel DS, costruito in base ai parametri della richiesta ricevuta. Questa richiesta ottiene come risposta l'elenco dei metadati dei documenti che hanno soddisfatto i parametri di ricerca.
  • salvataggio di un documento (expression), ossia un documento completo dei metadati ad esso associati.

L'architettura di Poliwiki tipicamente prevede due tipi diversi di documenti:

  • documenti contenuto (versioni/varianti (expression) di documenti (work) editati dagli autori di PoliWiki)
  • documenti speciali (home-page, indici, pagine intermedie di navigazione) che forniscono servizi agli utenti di Poliwiki.
  • 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.

    3.1 Il catalogo

    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.

    3.2 Query di uno o più documenti

    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

    3.3 Salvataggio di una scheda-contenuto

    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.

    4. Output del Data Source

    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.

    4.1 La scheda

    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.

    L'elemento 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.

    • Work: il concetto diacronico di documento: tutto quello che accomuna ogni copia di un libro, ogni versione di un documento di Word, ogni formato di dati in cui un documento viene convertito. “I Promessi Sposi di Alessandro Manzoni”
    • Expression: il concetto sincronico di documento: quello che caratterizza un documento in una specifico momento nel tempo, incluso il contenuto. Una specifica versione di un documento. “I Promessi Sposi di Alessandro Manzoni nell’edizione del 1827”
    • Manifestation: una materializzazione di un documento in uno specifico formato dati. Un modello che accomuna tutti gli oggetti fisici che lo rappresentano. Un flusso di byte che contiene e descrive una expression. Una specifica resa grafica di un documento. “I Promessi Sposi di Alessandro Manzoni nell’edizione del 1827 in formato PDF generato dal PDF creator versione 1.3”
    • Item: una specifica istanza di un documento in una specifica locazione su uno specifico computer. Una copia di un libro. Un file in una directory. Una risorsa associata ad un URL (Locator, non Identifier). “Il file “promsposi.pdf” nella directory “esempio” del mio computer, che contiene i Promessi Sposi di A.M nell’edizione del 1827…”

    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>
    

    L'elemento 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.

    4.2 Il catalogo

    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.

    4.2.1 La parte globale e accesso

    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.

    4.3 La query

    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&agrave 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.

    4.4 Gestione Errori

    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.


    to top

You are here: TechWeb08 > ReleasesProtocollo > ProtocolloDSFreez2

to top

Copyright © Fabio Vitali 2022 Last update of ProtocolloDSFreez2 on 29 May 2008 - 18:40 by MarcoPatrignani