Skip to topic | Skip to bottom
Home

TechWeb11
TechWeb11.SpamProtocol09r1.56 - 06 Jun 2011 - 21:10 - GiacomoBergamitopic end

Start of topic | Skip to actions

SPAM Protocol

Specifiche di protocollo

Versione 0.9 Aprile 2011

Questa versione: SpamProtocol09

Ultima versione: SpamProtocol11

Versione Precedente: Non ci sono versioni precedenti

Autori: FabioVitali, AngeloDiIorio, SilvioPeroni, GioeleBarabucci

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 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. I meccanismi di autenticazione devono supportare "basic access authentication" di HTTP:

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.

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/Body:

Content-Type: text/html

<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>

Risposta

Body HTTP vuoto e codici appropriati.

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/Body:

Content-Type: text/html

<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>)
   <span rel="tweb:retweet_of" resource="/tw34/pluto/76" />
</article>

Risposta

Body HTTP vuoto e codici appropriati.

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/Body:

Content-Type: text/html

<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>)
   <span rel="sioc:reply_of" resource="/tw34/pluto/76" />
</article>

Risposta

Body HTTP vuoto e codici appropriati.

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.

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

<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://ltwxxxx.web.cs.unibo.it/thesaurus">roma</span></span>)
      e altro html sparso (ad esempio, <a href="http://www.example.com">link</a>)
      <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

<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

Codici HTTP appropriati appropriati. Il body, se non ci sono errori, è:

<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://ltwxxxx.web.cs.unibo.it/thesaurus">roma</span></span>)
      e altro html sparso (ad esempio, <a href="http://www.example.com">link</a>)
      <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

Body vuoto e codici HTTP appropriati appropriati.

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

Codici HTTP appropriati appropriati. Il body, se non ci sono errori, è:

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/Body:

Content-type: application/xml

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

Risposta

Body vuoto e codici HTTP appropriati appropriati.

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

Body vuoto e codici HTTP appropriati.

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

Body vuoto e codici HTTP appropriati.

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

Body vuoto e codici HTTP appropriati.

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: CANCEL

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

Body vuoto e codici HTTP appropriati.

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

Il body della risposta contiene l'intero tesauro, nel formato SKOS descritto in sez. [XXX].

3. Protocollo UPIM

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).
408 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
      • allenatore
      • arbitro
    • 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)>

<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};

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</anem>
      <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</anem>
      <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.</anem>
      <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"</anem>
      <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</anem>
      <action>
         <method>get</method>
         <uri>/propagatelike/tw2/admin/+1/tw18/admin/questopostnonesiste</uri>
         <headers/>
      </action>
      <expect>
         <status>404</status>
      </expect>
   </test>
</testsuite>
      

9. Modifiche rispetto alle versioni precedenti

Non esistono versioni precedenti. Non si hanno dunque modifiche.

  • Set ALLOWTOPICVIEW =
  • Set ALLOWTOPICCHANGE =

to top

You are here: TechWeb11 > SpamProtocol09

to top

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