Skip to topic | Skip to bottom
Home

TechWeb11
Create personal sidebar
TechWeb11.SpamProtocol091r1.5 - 06 Jun 2011 - 21:10 - GiacomoBergamitopic end
Start of topic | Skip to actions

SPAM Protocol

Specifiche di protocollo

Versione 0.9.1 , Maggio 2011

Questa versione: SpamProtocol091

Ultima versione: SpamProtocol11

Versione Precedente: SpamProtocol09

Autori: FabioVitali, AngeloDiIorio, SilvioPeroni, GioeleBarabucci

Note di Versione: Questa versione è stabile ma non completa. La versione completa e ultimata sarà rilasciata più avanti dai Working Group come versione 1.0.

Abstract

Questo protocollo nasce all’interno del progetto SPAM del corso di Tecnologie Web 2011. L'obiettivo del progetto è la realizzazione di un sistema federato di microblog, noto appunto con il nome di SPAM("Social Production of Audiovisual Microblogs").

Il protocollo si compone in realtà di due protocolli diversi: PAM ("Protocol for Audiovisual Microblog") e UPIM ("Unified Protocol for Interoperable Microblogs").

L’architettura SPAM prevede infatti due componenti principali: client (per la creazione di post, visualizzazione, ricerca, etc.) e server (per il salvataggio dei documenti, propagazione dell'informazione, etc.). Ogni client comunica con il proprio server di riferimento tramite il protocollo PAM, mentre i server comunicano tra loro usando il protocollo UPIM.

Stato del documento

Questo documento è stato redatto da FabioVitali, AngeloDiIorio, SilvioPeroni e GioeleBarabucci. Deve essere utilizzato come materiale di riferimento per il progetto SPAM per garantire l’interoperabilità fra i gruppi. Questo documento è la versione 0.9.1 del protocollo ed è soggetto a modifiche da parte dei working group organizzati secondo le regole del W3C (http://www.w3.org/Consortium/Process/). I WG potranno emettere i documenti di riferimento aggiornati, numerati e versionati, che verranno usati per le specifiche di interoperabilità.

Introduzione

SPAM è un sistema federato di microblog. E' fondamentale quindi riconoscere in modo univoco le risorse indirizzabili nel sistema: utenti, server e post. Ad ogni server infatti sono associati più utenti, ognuno dei quali può scrivere più post.

In questo documento per evitare ambiguità si applicano le seguenti regole:

  • Ogni server è identificato da un identificatore univoco, chiamato "serverID" in questo documento.
  • Ogni utente è identificato da una coppia univoca "serverID/userID".
  • Ogni post è identificato da una tripla univoca "serverID/userID/postID".

I gruppi possono decidere anche una sintassi differente, purché sia garantita univocità all'interno della federazione.

Questo documento descrive le specifiche di entrambi i protocolli PAM e UPIM.

1. Meccanismi di autenticazione

Tutte le operazioni descritte in questo documento prevedono autenticazione.

Per autenticarsi basta l'invio dell'username dal client al server, senza la necessità di alcuna password.

L'utente che ha eseguito la richiesta non deve essere mai specificato nell'URL della richiesta ma usando i meccanismi appositi di HTTP.

2. Protocollo PAM

PAM è un protocollo HTTP che regola la comunicazione tra client e server. Di seguito sono descritte tutte le possibili richieste previste. Le richieste sono progettate secondo l'architettura REST.

Per ogni richiesta è indicato:

  • il metodo HTTP
  • la struttura dell'URL, i parametri ed eventualmente gli esempi
  • il body della richiesta
  • l'header (e i codici HTTP) e il body della risposta.

Note generali:

  • Per poter eseguire azioni di modifica o inserimento di una risorsa sul server (e.g. punto 2.1, 2.2, 2.3) è necessario essere autenticati (vedasi paragrafo 1.)
  • Per inserire una risorsa (video/audio/immagine) è necessario utilizzare il seguente tag così formattato: 
        <span resource="audio" src="link_audio" /> : per risorse audio
        <span resource="video" src="link_video" /> : per risorse video
        <span resource="image" src="link_immagine" /> : per risorse immagine
  • I termini del tesauro sono unici.

2.1 Invio nuovo post

L'invio di un nuovo post genera, sul server che riceve questa richiesta, un nuovo post il cui contenuto è passato nel corpo della richiesta.

Metodo: PUT

URL: http://ltwxxxx.web.cs.unibo.it/post

Header: 

Content-Type: text/html; charset=UTF-8

Body: 

<article 
   xmlns:sioc="http://rdfs.org/sioc/ns#" 
   xmlns:ctag="http://commontag.org/ns#" 
   xmlns:skos="http://www.w3.org/2004/02/skos/core#" 
   typeof="sioc:Post">
   Testo di un post contenente 
   <span rel="sioc:topic">#<span typeof="ctag:Tag" property="ctag:label">hashtag</span></span>,
   altri hashtag che si riferiscono a concetti del tesauro condiviso (ad esempio 
   <span rel="sioc:topic">#<span typeof="skos:Concept" about="/sport/calcio/portiere" 
   rel="skos:inScheme" resource="http://vitali.web.cs.unibo.it/TechWeb11/thesaurus">portiere</span> </span>)
   o del tesauro esteso (ad esempio 
   <span rel="sioc:topic">#<span typeof="skos:Concept" about="/sport/calcio/portiere/roma" 
   rel="skos:inScheme" resource="http://ltw11.web.cs.unibo.it/thesaurus">roma</span></span>)

   o link sparsi (ad esempio, http://www.example.com),
   e perché no un po' di audio (ad esempio, 
   <span resource="audio" src="http://www.example.com/song.mp3" />),
   o un po' di video (ad esempio, 
   <span resource="video" src="http://www.example.com/video.ogv" />),
   e immagini (ad esempio, 
   <span resource="image" src="http://www.example.com/pic.png" />).

</article>

Risposta

In caso di successo

Header: 

HTTP/1.1 201 Created

Body: 

vuoto

2.2 Retweet post

Il retweet di un nuovo post genera, sul server che riceve questa richiesta, un nuovo post il cui contenuto è dato dal post che si sta retwittando.

Metodo: PUT

URL: 

http://ltwxxxx.web.cs.unibo.it/retweet/<serverID>/<userID>/<postID>

Header: 

Content-Type: text/html; charset=UTF-8

Body: 

<article 
   xmlns:sioc="http://rdfs.org/sioc/ns#" 
   xmlns:ctag="http://commontag.org/ns#" 
   xmlns:skos="http://www.w3.org/2004/02/skos/core#" 
   typeof="sioc:Post">
   Testo di un post contenente 
   <span rel="sioc:topic">#<span typeof="ctag:Tag" property="ctag:label">hashtag</span></span>,
   altri hashtag che si riferiscono a concetti del tesauro condiviso (ad esempio 
   <span rel="sioc:topic">#<span typeof="skos:Concept" about="/sport/calcio/portiere" 
   rel="skos:inScheme" resource="http://vitali.web.cs.unibo.it/TechWeb11/thesaurus">portiere</span> </span>)
   o del tesauro esteso (ad esempio 
   <span rel="sioc:topic">#<span typeof="skos:Concept" about="/sport/calcio/portiere/roma" 
   rel="skos:inScheme" resource="http://ltw11.web.cs.unibo.it/thesaurus">roma</span></span>)

   o link sparsi (ad esempio, http://www.example.com),
   e perché no un po' di audio (ad esempio, 
   <span resource="audio" src="http://www.example.com/song.mp3" />),
   o un po' di video (ad esempio, 
   <span resource="video" src="http://www.example.com/video.ogv" />),
   e immagini (ad esempio, 
   <span resource="image" src="http://www.example.com/pic.png" />).

</article>

Risposta

In caso di successo

Header: 

HTTP/1.1 201 Created

Body: 

vuoto

2.3 Rispondi al post

Rispondendo ad un post si genera, sul server che riceve questa richiesta, un nuovo post collegato a quello originale.

Metodo: PUT

URL: 

http://ltwxxxx.web.cs.unibo.it/replyto/<serverID>/<userID>/<postID>

Header: 

Content-Type: text/html; charset=UTF-8

Body: 

<article 
   xmlns:sioc="http://rdfs.org/sioc/ns#" 
   xmlns:ctag="http://commontag.org/ns#" 
   xmlns:skos="http://www.w3.org/2004/02/skos/core#" 
   typeof="sioc:Post">
   Testo di un post contenente 
   <span rel="sioc:topic">#<span typeof="ctag:Tag" property="ctag:label">hashtag</span></span>,
   altri hashtag che si riferiscono a concetti del tesauro condiviso (ad esempio 
   <span rel="sioc:topic">#<span typeof="skos:Concept" about="/sport/calcio/portiere" 
   rel="skos:inScheme" resource="http://vitali.web.cs.unibo.it/TechWeb11/thesaurus">portiere</span> </span>)
   o del tesauro esteso (ad esempio 
   <span rel="sioc:topic">#<span typeof="skos:Concept" about="/sport/calcio/portiere/roma" 
   rel="skos:inScheme" resource="http://ltw11.web.cs.unibo.it/thesaurus">roma</span></span>)

   o link sparsi (ad esempio, http://www.example.com),
   e perché no un po' di audio (ad esempio, 
   <span resource="audio" src="http://www.example.com/song.mp3" />),
   o un po' di video (ad esempio, 
   <span resource="video" src="http://www.example.com/video.ogv" />),
   e immagini (ad esempio, 
   <span resource="image" src="http://www.example.com/pic.png" />).

</article>

Risposta

In caso di successo

Header: 

HTTP/1.1 201 Created

Body: 

vuoto

2.4 Ricerca post

È possibile effettuare delle ricerche sui post presenti all'interno della federazione. Queste ricerche possono essere di vario tipo:

  • i post di un autore
  • i post degli autore che si seguono
  • i post più recenti
  • i post che hanno a che fare con il post attualmente visualizzato
  • i post che hanno a che contengono una data stringa
  • i post i cui argomenti sono simili ad un dato argomento

Metodo: GET

URL: 

http://ltwxxxx.web.cs.unibo.it/search/<limit>/<type>/[<param>/]*

dove: 

   * <limit>: all | 1 | 2 | ...
   * <type>: author | following | recent | related | fulltext | affinity

Esistono infatti sei chiavi di ricerca. I parametri variano a seconda della chiave usata, secondo il seguente schema:

author 

http://ltwxxxx.web.cs.unibo.it/search/<limit>/author/<serverID>/<userID>

http://ltwxxxx.web.cs.unibo.it/search/10/author/tw18/pippo: restituiscimi i dieci più recenti post dell'utente "tw18/pippo".

following 

http://ltwxxxx.web.cs.unibo.it/search/<limit>/following

http://ltwxxxx.web.cs.unibo.it/search/10/following : restituiscimi i dieci più recenti post degli utenti seguiti dall'utente che fa la richiesta (HTTP basic).

recent 

http://ltwxxxx.web.cs.unibo.it/search/<limit>/recent/<term>

http://ltwxxxx.web.cs.unibo.it/search/10/recent/fc_roma: restituiscimi i dieci più recenti post che abbiano come argomento "fc_roma".

related 

http://ltwxxxx.web.cs.unibo.it/search/<limit>/related/<term>

http://ltwxxxx.web.cs.unibo.it/search/10/related/fc_roma: restituiscimi i dieci post più correlati all'argomento "fc_roma" (ottenuti navigando e cercando nel tesauro).

fulltext 

http://ltwxxxx.web.cs.unibo.it/search/<limit>/fulltext/<string>

http://ltwxxxx.web.cs.unibo.it/search/10/fulltext/ha%20fatto%20er%20cucchiaio: restituiscimi i dieci che contengono la stringa "ha fatto er cucchiaio" o parti di essa. Ogni server implementare politiche diverse, più o meno sofisticate, di ricerca full-text.

affinity 

http://ltwxxxx.web.cs.unibo.it/search/<limit>/affinity/<serverID>/<userID>/<postID>

http://ltwxxxx.web.cs.unibo.it/search/10/affinity/tw18/pippo/12: restituiscimi i dieci post più affini al post "tw18/pippo/12".

Header/Body: vuoto.

Risposta

La risposta DEVE essere inviata attraverso il meccanismo multipart/form-data (RFC 2388). Ogni risposta deve quindi contenere un header HTTP Content-Type: multipart/form-data, adattato volta per volta con i parametri necessari ('HTTP/1.1 200 OK' se l'operazione è avvenuta con successo)..

Ogni parte deve contenere un elemento ARTICLE (da HTML 5). Inoltre DEVE includere contenuto RDFa per identificare il post e le informazioni collegate. Vedi sezione [XXX.RDFa]* 


Content-Type: multipart/form-data; boundary="aXFFS"

--aXFFS

Content-Type: text/html; charset=UTF-8

<article
   xmlns:sioc="http://rdfs.org/sioc/ns#"
   xmlns:ctag="http://commontag.org/ns#"
   xmlns:skos="http://www.w3.org/2004/02/skos/core#"
   xmlns:dcterms="http://purl.org/dc/terms/"
   xmlns:tweb="http://vitali.web.cs.unibo.it/vocabulary/"
   about="/tw12/pippo/11" typeof="sioc:Post" rel="sioc:has_creator" resource="/tw12/pippo"
   property="dcterms:created" content="2006-09-07T09:33:30Z">
   <div about="/tw12/pippo/11">
      Testo di un post contenente 
   <span rel="sioc:topic">#<span typeof="ctag:Tag" property="ctag:label">hashtag</span></span>,
   altri hashtag che si riferiscono a concetti del tesauro condiviso (ad esempio 
   <span rel="sioc:topic">#<span typeof="skos:Concept" about="/sport/calcio/portiere" 
   rel="skos:inScheme" resource="http://vitali.web.cs.unibo.it/TechWeb11/thesaurus">portiere</span> </span>)
   o del tesauro esteso (ad esempio 
   <span rel="sioc:topic">#<span typeof="skos:Concept" about="/sport/calcio/portiere/roma" 
   rel="skos:inScheme" resource="http://ltw11.web.cs.unibo.it/thesaurus">roma</span></span>)

   o link sparsi (ad esempio, http://www.example.com),
   e perché no un po' di audio (ad esempio, 
   <span resource="audio" src="http://www.example.com/song.mp3" />),
   o un po' di video (ad esempio, 
   <span resource="video" src="http://www.example.com/video.ogv" />),
   e immagini (ad esempio, 
   <span resource="image" src="http://www.example.com/pic.png" />).

      <span rev="tweb:like" resource="/tw14/pluto" />
      <span property="tweb:countLike" content="1" />
      <span property="tweb:countDislike" content="5" />
   </div>
</article>

--aXFFS

Content-Type: text/html; charset=UTF-8

<article>
   ...
</article>

--aXFFS

2.5 Richiesta post

È possibile recuperare il contenuto di un post a partire dal suo ID.

Metodo: GET

URL: 

http://ltwxxxx.web.cs.unibo.it/post/<serverID>/<userID>/<postID>

Header/Body: Body vuoto.

Risposta

In caso di successo

Header: 

HTTP/1.1 200 OK

Body: 

<article
   xmlns:sioc="http://rdfs.org/sioc/ns#"
   xmlns:ctag="http://commontag.org/ns#"
   xmlns:skos="http://www.w3.org/2004/02/skos/core#"
   xmlns:dcterms="http://purl.org/dc/terms/"
   xmlns:tweb="http://vitali.web.cs.unibo.it/vocabulary/"
   about="/tw12/pippo/11" typeof="sioc:Post" rel="sioc:has_creator" resource="/tw12/pippo"
   property="dcterms:created" content="2006-09-07T09:33:30Z">
   <div about="/tw12/pippo/11">
      Testo di un post contenente 
   <span rel="sioc:topic">#<span typeof="ctag:Tag" property="ctag:label">hashtag</span></span>,
   altri hashtag che si riferiscono a concetti del tesauro condiviso (ad esempio 
   <span rel="sioc:topic">#<span typeof="skos:Concept" about="/sport/calcio/portiere" 
   rel="skos:inScheme" resource="http://vitali.web.cs.unibo.it/TechWeb11/thesaurus">portiere</span> </span>)
   o del tesauro esteso (ad esempio 
   <span rel="sioc:topic">#<span typeof="skos:Concept" about="/sport/calcio/portiere/roma" 
   rel="skos:inScheme" resource="http://ltw11.web.cs.unibo.it/thesaurus">roma</span></span>)

   o link sparsi (ad esempio, http://www.example.com),
   e perché no un po' di audio (ad esempio, 
   <span resource="audio" src="http://www.example.com/song.mp3" />),
   o un po' di video (ad esempio, 
   <span resource="video" src="http://www.example.com/video.ogv" />),
   e immagini (ad esempio, 
   <span resource="image" src="http://www.example.com/pic.png" />).

      <span rev="tweb:like" resource="/tw14/pluto" />
      <span property="tweb:countLike" content="1" />
      <span property="tweb:countDislike" content="5" />
   </div>
</article>

Importante: obbligatorio specificare tramite RDFa le sequenti informazioni:

  • il valore di "like/dislike" dell'utente che ha fatto la richiesta.
  • il numero di "like" totali sul post
  • il numero di "dislike" totali sul post

2.6 Set "I like"

Tramite la richiesta setlike si imposta il grado di interesse dell'utente per un dato post.

Metodo: POST

URL: 

http://ltwxxxx.web.cs.unibo.it/setlike/<value>/<serverID>/<userID>/<postID>

dove: 

<value> : +1 (like)  |  0 (neutral)  |  -1 (dislike)

Header/Body: Body vuoto.

Risposta

Header: 

HTTP/1.1 200 OK

Body: 

vuoto

2.7 Richiesta lista server federati

Il client può richiedere al proprio server la lista dei server che si considerano all'interno della federazione.

Metodo: GET

URL: 

http://ltwxxxx.web.cs.unibo.it/servers

Header/Body: vuoto

Risposta

In caso di successo

Header: 

HTTP/1.1 200 OK

Body: 

Content-type: application/xml

<servers>

   <server serverID="tw2" />
   <server serverID="tw3" />
   <server serverID="tw4" />
   <server serverID="tw11" />

</servers>

2.8 Sovrascrittura lista server federati

Il client può fornire al proprio server la nuova lista dei server che si considerano all'interno della federazione.

Metodo: POST

URL: 

http://ltwxxxx.web.cs.unibo.it/servers

Header: 

Content-type: application/xml

Body: 


<servers>

   <server serverID="tw2" />
   <server serverID="tw3" />
   <server serverID="tw4" />
   <server serverID="tw11" />

</servers>

Risposta

In caso di successo

Header: 

HTTP/1.1 200 OK

Body: 

vuoto

2.9 Seguire (follow) un utente

Il client può richiedere al server di considerare un certo utente come "seguito".

Metodo: POST

URL: 

http://ltwxxxx.web.cs.unibo.it/follow/<serverID>/<userID>

Header/Body: Body vuoto.

Risposta

In caso di successo

Header: 

HTTP/1.1 200 OK

Body: 

vuoto

2.10 Smettere di seguire (unfollow) un utente

Il client può richiedere al server di non considerare più un certo utente come "seguito".

Metodo: POST

URL: 

http://ltwxxxx.web.cs.unibo.it/unfollow/<serverID>/<userID>

Header/Body: Body vuoto.

Risposta

In caso di successo

Header: 

HTTP/1.1 200 OK

Body: 

vuoto

2.11 Aggiungi termine al tesauro esteso

È possibile aggiungere termini al tesauro condiviso, arrivando così al tesauro esteso. Per estendere il tesauro, il client fornisce al server il termine da usare come genitore e il nuovo termine foglia.

Metodo: PUT

URL: 

http://ltwxxxx.web.cs.unibo.it/addterm/<parentterm>/<newterm>


http://ltwxxxx.web.cs.unibo.it/term/fc_roma/totti

http://ltwxxxx.web.cs.unibo.it/term/totti/cucchiaio

Header/Body: Body vuoto.

Risposta

In caso di successo

Header: 

HTTP/1.1 201 Created

Body: 

vuoto

2.12 Rimuovi termine dal tesauro esteso

Il client può chiedere la rimozione dal tesauro esteso di un dato termine. Non è possibile rimuovere un termine dal tesauro condiviso. Metodo: DELETE

URL: 

http://ltwxxxx.web.cs.unibo.it/term/<term>

Se il tesauro include, ad esempio, il termine "sport/calcio/roma/totti/cucchiaio" è lecito cancellare "cucchiaio" ma non si può eliminare "totti" (a meno di cancellare il termine "cucchiaio"). L'applicazione Ajax può rendere le cancellazioni multiple trasparenti all'utente, ma il protocollo ne supporta una alla volta.

http://ltwxxxx.web.cs.unibo.it/term/cucchiaio OK

http://ltwxxxx.web.cs.unibo.it/term/totti ERRORE

Header/Body: Body vuoto.

Risposta

In caso di successo

Header: 

HTTP/1.1 200 OK

Body: 

vuoto

2.13 Restituisci il tesauro esteso

La risorsa thesaurus contiene il tesauro (sia condiviso che esteso) in formato SKOS, come descritto in sez. [XXX].

Metodo: GET

URL: 

http://ltwxxxx.web.cs.unibo.it/thesaurus

Header/Body: Body vuoto.

Risposta

In caso di successo

Header: 

HTTP/1.1 200 OK

Body: 

L'intero tesauro, nel formato SKOS descritto in sez. [XXX].

3. Protocollo UPIM - ANCORA DA SISTEMARE E AGGIORNARE (UNSTABLE)

UPIM è un protocollo HTTP che regola la comunicazione tra server e server. Di seguito sono descritte tutte le possibili richieste UPIM. Alcune di tra queste richieste pono sovrapposte con il protocollo PAM, poichè si occupano di propagare richieste dell'utente ai server che memorizzano altri post. Le richieste sono progettate secondo l'architettura REST.

Per ogni richiesta è indicato:

  • il metodo HTTP
  • la struttura dell'URL, i parametri ed eventualmente gli esempi
  • il body della richiesta
  • l'header (e i codici HTTP) e il body della risposta.

3.1 Ricerca post

La richiesta è esattamente uguale alla corrispondere richiesta in PAM (sez. 2.4).

3.2 Richiesta di un post

La richiesta è esattamente uguale alla corrispondere richiesta in PAM (sez. 2.5).

3.3 Set "I Like"

Variazione del "Set Like". Necessario, infatti, aggiungere lo dell'utente che ha settato la preferenza. Ogni server può comunque scegliere le proprie policy di gestione delle preferenze (caching, limiti, etc.).

Metodo: POST

URL: 

http://ltwxxxx.web.cs.unibo.it/propagatelike/<fulluserID>/<value>/<fullpostID>

che, tenendo conto dei meccanismi di identificazione di server, utenti e post, si espande in: 

http://ltwxxxx.web.cs.unibo.it/propagatelike/<serverID>/<userID>/<value>/<serverID>/<userID>/<postID>

Un esempio è mostrato in seguito:

http://ltwxxxx.web.cs.unibo.it/propagatelike/tw18/pippo/+1/tw2/pluto/4

Header/Body: Body vuoto.

Risposta

:

Body vuoto e codici HTTP appropriati.

4. Gestione degli errori

Nel caso in cui una richiesta generi un errore, il server DEVE rispondere utilizzando gli appropriati codici HTTP 4xx e 5xx. I client DEVONO gestire ogni codice d'errore in maniera appropriata.

Client e server DEVONO gestire almeno questi errori (con relativi codici HTTP):

$ 403 Forbidden

404 Not available
risorsa non disponibile
405 Method not allowed
il servizio è stato chiamato con un metodo HTTP non previsto (ad esempio GET piuttosto che POST).
406 Not acceptable
non è possibile erogare il servizio perché i vincoli della richiesta non sono soddisfacibili.
500 Internal server error
c'è stato un problema interno al servizio durante l'elaborazione dalla richiesta.
501 Not implemented
il servizio richiesto non è fornito.

In aggiunta ai codici d'errore HTTP, il contenuto fornito dal server deve fornire più indicazioni possibili sull'errore generato e fornire suggerimenti su come risolverlo. I servizi sono liberi di usare qualsiasi tipo di dato per il contenuto restituito, tenendo comunque in considerazione la richiesta originaria del client (fornite nell'header Accept o in altro modo).

5. Tesauro

La tassonomia condivisa da usare è descritta dalla seguente lista annidata, dove gli annidamenti definiscono relazioni via via sempre più circoscritte e precise:

  • sport
    • calcio
      • portiere
      • difensore
      • centrocampista
      • attaccante
    • pallavolo
      • schiacciatore
      • palleggiatore
      • allenatore
      • arbitro
    • nuoto
      • stile_libero
      • farfalla
      • delfino
      • dorso
    • tennis
      • racchetta
      • pallina
      • terra_battuta
      • cemento
      • erba
      • sintetico
  • musica
    • genere
      • rock
      • jazz
      • classica
      • pop
    • strumenti
      • chitarra
      • tastiera
      • piano
      • batteria
      • sassofono
      • tromba
      • sintetizzatore
    • media
      • cd
      • mp3
      • vinile
      • wav
      • streaming
  • letteratura
    • genere
      • fantascienza
      • fantasy
      • storia
      • epistolare
      • filosofia
    • ruolo
      • autore
      • editore
      • lettore
      • distributore
    • tipologia
      • romanzo
      • racconto
      • poesia
      • collana

La tassonomia condivisa, così come le estese, deve essere implementata in SKOS in uno qualsiasi dei formati di linearizzazione per RDF, ovvero RDF/XML e Turtle. Di seguito un esempio di implementazione in Turtle: 

# Tesauro
<http://vitali.web.cs.unibo.it/TechWeb11/thesaurus> a skos:ConceptScheme
    ; skos:prefLabel "Tesauro per il progetto di Tecnologie Web 2011" .

</sport>
   ; skos:topConceptOf <http://vitali.web.cs.unibo.it/TechWeb11/thesaurus>
   ; skos:prefLabel "Sport"
   ; skos:narrower
        </sport/calcio>
      , </sport/pallavolo>
      , </sport/nuoto>
      , </sport/tennis> .

</sport/calcio>
   ; skos:prefLabel "Calcio"
   ; skos:broader </sport>
   ; skos:narrower
        </sport/portiere>
      , </sport/difensore>
      ...

6. RDFa

Ogni post creato, anche a seguito di una risposta ad un altro post o a un retweet, deve arrivare al server opportunamente arricchito, sia di costrutti HTML sia di definizioni semantiche, espresse via RDFa. Ad esempio, si consideri il seguente post (come viene scritto da un utente utilizzando il client): 

Testo di un post contenente #hashtag, altri hashtag che si riferiscono a
concetti del tesauro condiviso (ad esempio #portiere) o del tesauro esteso (ad
esempio #roma) e altro html sparso (ad esempio, http://www.example.com)

Questo testo viene (automaticamente o semi-automaticamente) arricchito con opportuni elementi HTML: 

<article>
   Testo di un post contenente #hashtag, altri hashtag che si riferiscono a
   concetti del tesauro condiviso (ad esempio #portiere) o del tesauro esteso
   (ad esempio #roma) e altro html sparso (ad esempio, 
   <a href="http://www.example.com">http://www.example.com</a>)
</article>

Oltre a ciò, è necessario indicare, in qualche modo, le altre informazioni relative al post, ad esempio che i tag liberi ("hashtag" nell'esempio) e i termini del tesauro usati ("/sport/calcio/portiere" dal tesauro controllato e "/sport/calcio/portiere/roma" dal tesauro esteso) siano resi esplicitamente argomenti di questo post. Questo deve essere fatto usando RDFa: 

<article
   xmlns:sioc="http://rdfs.org/sioc/ns#"
   xmlns:ctag="http://commontag.org/ns#"
   xmlns:skos="http://www.w3.org/2004/02/skos/core#"
   typeof="sioc:Post">
   Testo di un post contenente
   <span rel="sioc:topic">#<span typeof="ctag:Tag" property="ctag:label">hashtag</span></span>,
   altri hashtag che si riferiscono a concetti del tesauro condiviso (ad esempio 
   <span rel="sioc:topic">#
      <span typeof="skos:Concept" 
         about="/sport/calcio/portiere" 
         rel="skos:inScheme"
         resource="http://vitali.web.cs.unibo.it/TechWeb11/thesaurus">
         portiere</span>
   </span>)
   o del tesauro esteso (ad esempio
   <span rel="sioc:topic">#
   <span typeof="skos:Concept" 
      about="/sport/calcio/portiere/roma" 
      rel="skos:inScheme"
      resource="http://ltw11.web.cs.unibo.it/thesaurus">roma</span></span>)
   e altro html sparso (ad esempio, <a href="http://www.example.com">http://www.example.com</a>)
</article>

Inoltre, una volta arrivato al server, vengono aggiunte ulteriori asserzioni RDFa (riguardanti l'autore, l'uri della risorsa che identifica il post, ecc.) in modo da meglio descrivere il post stesso, es: 

<article
   xmlns:sioc="http://rdfs.org/sioc/ns#"
   xmlns:ctag="http://commontag.org/ns#"
   xmlns:skos="http://www.w3.org/2004/02/skos/core#"
   xmlns:dcterms="http://purl.org/dc/terms/"
   about="/tw12/pippo/11" typeof="sioc:Post" rel="sioc:has_creator" resource="/tw12/pippo"
   property="dcterms:created" content="2006-09-07T09:33:30Z">
   <div about="/tw12/pippo/11">
      Testo di un post contenente
      <span rel="sioc:topic">#<span typeof="ctag:Tag" property="ctag:label">hashtag</span></span>,
      altri hashtag che si riferiscono a concetti del tesauro condiviso (ad esempio 
      <span rel="sioc:topic">#
      <span typeof="skos:Concept" 
         about="/sport/calcio/portiere" 
         rel="skos:inScheme"
         resource="http://vitali.web.cs.unibo.it/TechWeb11/thesaurus">portiere</span></span>)
      o del tesauro esteso (ad esempio
      <span rel="sioc:topic">#
      <span typeof="skos:Concept" 
         about="/sport/calcio/portiere/roma" 
         rel="skos:inScheme"
         resource="http://ltwxxxx.web.cs.unibo.it/thesaurus">roma</span></span>)
      e altro html sparso (ad esempio, <a href="http://www.example.com">link</a>)
   </div>
</article>

Gli oggetti e le relazioni, minimi ed obbligatori, da usare per le varie descrizioni di un post sono i seguenti:

  • sioc:Post – identifica un post pubblicato da un certo utente
  • dcterms:created – descrive la data di creazione di un post
  • sioc:has_creator – collega un post al suo autore
  • sioc:topic – collega un post con gli argomenti (tag o termini del tesauro) a cui fa riferimento
  • sioc:reply_of – identifica un post come risposta di un altro post
  • tweb:retweetOf – identifica un post come retweet di un altro post
  • tweb:countLike – descrive a quanti utenti è piaciuto un post
  • tweb:countDislike – descrive a quanti utenti non è piaciuto un post
  • skos:Concept – identifica un termine del tesauro
  • skos:inScheme – collega un termine con il tesauro che lo definisce
  • ctag:Tag – identifica un termine libero non legato al tesauro
  • ctag:label – descrive l'etichetta di un tag
  • tweb:like – collega un utente ad un post che gli è piaciuto
  • tweb:dislike – collega un utente ad un post che non gli è piaciuto

Fare riferimento ai vocabolari SIOC, Common Tag e SKOS per maggiori dettagli. Il prefisso tweb si riferisce a http://vitali.web.cs.unibo.it/vocabulary/.

7. Registrazione dei server SPAM

Ogni server deve registrarsi alla federazione SPAM, per potere rendere disponibili i propri contenuti e servizi.

La registrazione non avviene in maniera automatica ma modificando manualmente un file XML condiviso da tutti i gruppi. E' compito del working group decidere l'URL del registro SPAM.

Alla fine di ogni fiera, i gruppi sono tenuti a redarre il file XML condiviso. I gruppi dovranno inoltre consegnare una copia del file al docente o pubblicarlo sul wiki. Questa versione NON DEVE essere ulteriormente modificata.

Ogni server dovrà richiedere questo file (tramite un GET HTTP) e usarlo per riconoscere i file della federazione.

Il registro XML deve avere la seguente struttura XML: 

<servers>
   <server serverID="tw2" serverURL="http://tw2.web.cs.unibo.it/">
   <server serverID="tw3" serverURL="http://pippo.web.cs.unibo.it/">
   <server serverID="tw4" serverURL="http://pluto.web.cs.unibo.it/">
</servers>

8. TRAM: Testing Reliability of Audiovisual Microblogs

TRAM è la test suite di SPAM. Il suo scopo è accertarsi che le implementazioni di SPAM siano conformi alle richieste del protocollo.

<test-suite>

La test suite è composta da una serie di test.

<!ELEMENT test-suite (test)*>

<test>

Ognuno di questi test ha:

  • un nome che identifica cosa si sta testando;
  • una o più azioni da compiere per valutare il test;
  • una descrizione di cosa ci si aspetta.

<!ELEMENT test (name, action+, expect)>

<name>

Nome di che cosa si sta testando. 

<!ELEMENT name (#PCDATA)>

<action>

L'azione da compiere e` descritta da:

  • il metodo da usare;
  • un frammento URI da usare per comporre l'URI verso quale fare la richiesta di test;
  • una serie di coppie chiave-valore da usare come header della richiesta di test;
  • una serie di byte da usare come corpo della richiesta di test;


<!ELEMENT action (method, uri, headers, body?)>


<!ELEMENT method (#PCDATA)>
<!ELEMENT uri (#PCDATA)>
<!ELEMENT headers (header)>
<!ELEMENT header EMPTY>
<!ATTLIST header
   name CDATA #REQUIRED
   value CDATA #REQUIRED
>
<!ELEMENT body (#PCDATA)>

<expect>

La descrizione di ciò che ci si aspetta in risposta è composta da:

  • un codice HTTP;
  • una serie di byte che dovrebbero essere restituiti come corpo della richiesta fatta.

<!ELEMENT expect (status, body?)>

<!ELEMENT status (#PCDATA)>
<!ELEMENT body (#PCDATA)>

Variabili

All'interno di ogni test posso comparire variabili che, al momento del lancio dei test, saranno sostituite con valori appropriati.

Le variabili possibili sono:

  • ${serverID-ok}
    • identificativo di un server che si sa esistente e funzionante;
  • ${userID-ok}
    • identificativo di un utente che si sa esistente su ${serverID-ok};
  • ${postID-ok}
    • identificativo di un post che si sa esistente su ${serverID-ok} e generato da ${userID-ok};

  • ${serverID-err}
    • identificativo di un server che si sa NON esistente o NON funzionante;
  • ${userID-err}
    • identificativo di un utente che si sa NON esistente su ${serverID-ok};
  • ${postID-err}
    • identificativo di un post che si sa NON esistente su ${serverID-ok} o NON generato da ${userID-ok};

    Si e' deciso al fine di semplificare il processo di testing di usare un valore di default riconosciuto come errato, e che quindi non potrà mai essere considerato come cme userID, postID o come serverID valido.

    • ${serverID-err}: ltw0000

    • ${userID-err}: user0

    • ${postID-err}: 0000

    Esempi di test

    Retweet di un post non esistente ad un server esistente deve restituire un errore.

    <test>
   <name>Retweet di un post non esistente ad un server esistente deve restituire un errore</name>
   <action>
      <method>put</method>
      <uri>/retweet/lw18/admin/${postID-err}</uri>
      <headers/>
   </action>
   <expect>
      <status>404</status>
   </expect>
</test>

    Rimuovere un termine appena creato non crea problemi

    <test>
   <name>Rimuovere un termine appena creato non crea problemi</name>
   <action>
      <method>put</method>
      <uri>/term/venezia/san_marco</uri>
      <headers/>
   </action>
   <action>
      <method>delete</method>
      <uri>/term/venezia/san_marco</uri>
      <headers/>
   </action>
   <expect>
      <status>200</status>
   </expect>
   </test>

    8.1 TRAM-PAM

    TRAM-PAM testa il protocollo client/server PAM.

    <testsuite name="TRAM-PAM">
   <test>
      <name>Un nuovo post</name>
      <action>
         <method>put</method>
         <uri>/post</uri>
         <headers>
            <header name="Content-Type" value="text/html"/>
         </headers>
         <body>
            &lt;article>Un nuovo post&lt;/article>
         </body>
      </action>
      <expect>
         <status>200</status>
      </expect>
   </test>
   
   <test>

      <name>Un nuovo post con caratteri non ASCII</name>

      <action>
         <method>put</method>
         <uri>/post</uri>
         <headers>
            <header name="Content-Type" value="text/html"/>
         </headers>
         <body>
            &lt;article>Un nuovo post con &#224;ccenti&lt;/article>
         </body>
      </action>
      <expect>
         <status>200</status>
      </expect>
   </test>
   
   <test>
      <name>I post devono essere XHTML ben formato</name>
      <action>
         <method>put</method>
         <uri>/post</uri>
         <headers>
            <header name="Content-Type" value="text/html"/>
         </headers>
         <body>
            &lt;article>Un nuovo post &lt;non ben formato &lt;/article>
         </body>
      </action>
      <expect>
         <status>200</status>
      </expect>
   </test>
   
   <test>

      <name>I post non si possono cancellare</name>

      <action>
         <method>delete</method>
         <uri>/post/${serverID-ok}/${userID-ok}/${postID-ok}</uri>
         <headers/>
      </action>
      <expect>
         <status>405</status>
      </expect>
   </test>
   
   <test>
      <name>Rimuovere un termine appena creato non crea problemi</name>
      <action>
         <method>put</method>
         <uri>/term/venezia/san_marco</uri>
         <headers/>
      </action>
      <action>
         <method>delete</method>
         <uri>/term/venezia/san_marco</uri>
         <headers/>
      </action>
      <expect>
         <status>200</status>
      </expect>
   </test>
   
   <test>

      <name>Non è possibile rimuovere un termine dal tesauro condiviso.</name>

      <action>
         <method>delete</method>
         <uri>/term/sport</uri>
         <headers/>
      </action>
      <expect>
         <status>405</status>
      </expect>
   </test>
   
   <test>

      <name>Non esiste il tipo di ricerca "since-date"</name>

      <action>
         <method>get</method>
         <uri>/search/all/since-date/2011-02-11</uri>
         <headers/>
      </action>
      <expect>
         <status>501</status>
      </expect>
   </test>
</testsuite>

    8.2 TRAM-UPIM

    TRAM-UPIM testa il protocollo server/server UPIM. Include tutti i test di TRAM-PAM piu` altri specifici del protocollo UPIM.

    <testsuite name="TRAM-UPIM"> 
     <test>
     <name>Non si puo` propagare un "dislike" di un post che non esiste</name>
      <action>
         <method>POST</method>
         <uri>/propagatelike/${userID-ok}/-1/${postID-err}</uri>
         <headers/>
      </action>
      <expect>
         <status>404</status>
      </expect>
   </test> 
   <test>
   <name>Si puo` propagare un "like" di un post che esiste</name>
    <action>
         <method>POST</method>
         <uri>/propagatelike/${userID-ok}/+1/${postID-ok}</uri>
         <headers/>
      </action>
      <expect>
         <status>200</status>
      </expect>
   </test> 

      
        <test>
      <name>non si puo'richiedere un post che non esiste</name>
      <action>
         <method>get</method>
         <uri>/post/${serverID-ok}/${userID-ok}/${postID-err}</uri>
         <headers/>
      </action>
      <expect>
         <status>404</status>
      </expect>
   </test>

    <test>
      <name>La richiesta di un post che esiste deve andare a buon fine</name>
      <action>
         <method>get</method>
         <uri>/post/${serverID-ok}/${userID-ok}/${postID-ok}</uri>
         <headers/>
      </action>   
      <expect>
         <status>200</status>
      </expect>
   </test>

</testsuite>

    9. Esempio di percorso di un post

    9.1 Articolo iniziale

    Testo semplice inserito dall'utente. 

    Testo di un post contenente #hashtag, altri hashtag che si riferiscono a concetti del tesauro condiviso (ad esempio
#portiere) o del tesauro esteso (ad esempio #roma) o link sparsi (ad esempio, http://www.example.com),
e perché no un po' di audio (ad esempio, http://www.example.com/song.mp3),
o un po' di video (ad esempio, http://www.example.com/video.ogv),
e immagini (ad esempio, http://www.example.com/pic.png).

    9.2 Articolo arricchito lato client

    Il testo semplice sopra inserito viene letto e arricchito di nuovi tag HTML e XML: il risultato verrà poi inviato al server. 

    <article 
   xmlns:sioc="http://rdfs.org/sioc/ns#" 
   xmlns:ctag="http://commontag.org/ns#" 
   xmlns:skos="http://www.w3.org/2004/02/skos/core#" 
   typeof="sioc:Post">
   Testo di un post contenente 
   <span rel="sioc:topic">#<span typeof="ctag:Tag" property="ctag:label">hashtag</span></span>,
   altri hashtag che si riferiscono a concetti del tesauro condiviso (ad esempio 
   <span rel="sioc:topic">#<span typeof="skos:Concept" about="/sport/calcio/portiere" 
   rel="skos:inScheme" resource="http://vitali.web.cs.unibo.it/TechWeb11/thesaurus">portiere</span> </span>)
   o del tesauro esteso (ad esempio 
   <span rel="sioc:topic">#<span typeof="skos:Concept" about="/sport/calcio/portiere/roma" 
   rel="skos:inScheme" resource="http://ltw11.web.cs.unibo.it/thesaurus">roma</span></span>)
   o link sparsi (ad esempio, http://www.example.com),
   e perché no un po' di audio (ad esempio, 
   <span resource="audio" src="http://www.example.com/song.mp3" />),
   o un po' di video (ad esempio, 
   <span resource="video" src="http://www.example.com/video.ogv" />),
   e immagini (ad esempio, 
   <span resource="image" src="http://www.example.com/pic.png" />).
</article>

    9.3 Articolo finito

    L'articolo soprastante arriva al server e questo lo arricchisce di ulteriori informazioni. Ora l'articolo è pronto per essere salvato. 

    <article 
   xmlns:sioc="http://rdfs.org/sioc/ns#" 
   xmlns:ctag="http://commontag.org/ns#" 
   xmlns:skos="http://www.w3.org/2004/02/skos/core#" 
   mlns:dcterms="http://purl.org/dc/terms/"
   about="/tw12/pippo/11" typeof="sioc:Post" rel="sioc:has_creator" resource="/tw12/pippo"
   property="dcterms:created" content="2006-09-07T09:33:30Z">
   <div about="/tw12/pippo/11">
      Testo di un post contenente 
      <span rel="sioc:topic">#<span typeof="ctag:Tag" property="ctag:label">hashtag</span></span>,
      altri hashtag che si riferiscono a concetti del tesauro condiviso (ad esempio 
      <span rel="sioc:topic">#<span typeof="skos:Concept" about="/sport/calcio/portiere" 
      rel="skos:inScheme" resource="http://vitali.web.cs.unibo.it/TechWeb11/thesaurus">portiere</span> </span>)
      o del tesauro esteso (ad esempio 
      <span rel="sioc:topic">#<span typeof="skos:Concept" about="/sport/calcio/portiere/roma" 
      rel="skos:inScheme" resource="http://ltw11.web.cs.unibo.it/thesaurus">roma</span></span>)
      o link sparsi (ad esempio, http://www.example.com),
      e perché no un po' di audio (ad esempio, 
      <span resource="audio" src="http://www.example.com/song.mp3" />),
      o un po' di video (ad esempio, 
      <span resource="video" src="http://www.example.com/video.ogv" />),
      e immagini (ad esempio, 
      <span resource="image" src="http://www.example.com/pic.png" />).
   </div>
</article>

    10. Modifiche rispetto alle versioni precedenti

    Tutte le modifiche da SPAM 0.9 a SPAM 0.9.1 sono evidenziate in grassetto.

    10.1 PAM

    10.1.1 Modifiche Generiche

    • Inseriti i codici HTTP nei vari header di risposta
    • Aggiunto il 'charset' nel content-type di ogni richiesta/risposta
    • Aggiunta la regola di login per qualsiasi azione che modifichi risorse sul server
    • Inserito il codice che gestisce le risorse audio/video/immagini
    • Rimossa la seguente stringa dai rely e retweet, siccome il server può identificare l'utente dalla connessione in atto: 
             <span rel="tweb:retweet_of" resource="/tw34/pluto/76" />
    • Aggiunta la regola dell'unicità dei termini del tesauro
    • Aggiunto il paragrafo 9

    10.1.2 Modifiche Specifiche

    • 2.1: modificato l'URL dell'invio del post.
    • 2.7/2.8: aggiustato l'XML della lista dei server
    • 2.12: sostituito il metodo CANCEL col metodo DELETE
    • 4: modificato l'errore da 408 a 406
    • 5: rimossi dal tesauro i termini doppi
    • 8.1: modificato/inserito regole nella Test Suite TRAM-PAM
    • 8.1: aggiustato l'XML della Test Suite

    10.2 UPIM

    • 8.2: aggiunti valori errati di default
    • 8.2: aggiunte le Test suite per UPIM

    -- VincenzoFerrari - 18 May 2011

    • Set ALLOWTOPICVIEW =
    • Set ALLOWTOPICCHANGE =

    to top
End of topic
Skip to action links | Back to top

Edit | Attach image or document | Printable version | Raw text | More topic actions
Revisions: | r1.5 | > | r1.4 | > | r1.3 | Total page history | Backlinks
You are here: TechWeb11 > SpamProtocol091

to top

Copyright © Fabio Vitali 2017 Last update of SpamProtocol091 on 06 Jun 2011 - 21:10 by GiacomoBergami