Working Draft 0.5 (Telefonia)

Transcript

1 Working Draft 0.5 (Telefonia) Abstract Lo scopo del progetto è lo sviluppo di un SCP (Semantic Collaborative Portal), cioè un sistema di visualizzazione di una banca dati documentaria di grandi dimensioni ( documenti) ed omogenea riguardante la Telefonia. Il progetto si articola in quattro fasi: 1. Identificazione di un campione di documenti (in qualsiasi formato), conversione in modo automatico o semi-automatico in XML secondo le regole strutturali previste dal Working Group e realizzazione di una banca dati documentaria che permetta l accesso a questi documenti. 2. Definizione di un ontologia comune, utile per la navigazione e la ricerca in RDF, creazione di un formato dati per la syndacation RSS, conversione dei dati dei documenti in meta-informazioni secondo lo schema così creato. 3. Realizzazione di un sistema che permetta di importare le descrizioni, i titoli e i documenti dagli altri sistemi dello stesso argomento e dello stesso periodo. 4. Realizzazione di un meccanismo che per ogni documento della banca dati ne organizzi il contenuto, realizzazione di un sistema di visualizzazione specializzato per almeno due tipi di browser. Cambiamenti dal WD 0.1 In questa versione sono stati modifiche radicalmente tutti gli elementi di base, inoltre sono stati aggiunti gli elementi generici. dal WD 0.2 In questa versione sono stati modificicati molti Content-Model. Inoltre è stata cambiata la struttura del documento come mostra meglio l indice. 1

2 dal WD 0.3 Aggiunta la definizione delle relazioni RDF e modificati alcuni errori riscontrati all interno della definizione degli elementi, in particolare sono stati specificati alcuni elementi come espandibili e corretti errori di battitura. dal WD 0.4 Aggiornato l orribile stato del tesauro. dal WD La parte sul tesauro e stata cambiata completamente. 2

3 Indice 1 Regole Generali 4 2 Elementi Generici Nome Valore Descrizione Elementi Base Telefono Tariffa Accessorio Pagina Tesauro 9 5 RSS Criteri di accesso Versione di RSS Estensioni al vocabolario RSS Come esprimere il tesauro in RSS Come specificare il match tra le metainformazioni di un documento e i summary in RSS dei vari canali Accesso al source dei documenti XML

4 1 Regole Generali Tutti i documenti appartenenti alla categoria Telefonia devono avere come nodo radice l elemento telefonia. Di seguito vengono presentati gli elementi che possono discendere dall elemento telefonia ogni elemento può essere obbligatorio o facoltativo. Un elemento obbligatorio è un elemento la cui presenza deve essere garantita nei documenti, la cui implementazione deve essere garantita da parte di ogni team; un elemento facoltativo invece è un elemento la cui implementazione non è obbligatoria, ma se effettuata deve seguire le regole previste da questo documento. Tutti gli elementi possono essere espansi nel numero degli attributi, mentre per quel che riguarda il content-model, questi possono essere espansi solo dove è esplicitamente dichiarato. Nota: Tutti i nomi dei tag anche se nelle sezioni se ne parla in maiuscolo sono in minuscolo, (ex. Telefono è telefono). 2 Elementi Generici Sono definiti alcuni elementi generici che verranno utilizzati all interno di altri elementi definiti nel documento o dai vari team laddove lo ritengano necessario. Per prima cosa si riprendono da html i seguenti elementi b; i; u; p; img, ma col nome di immagine; a, ma col nome di link; Elementi definiti dal working group che non hanno un equivalente in HTML. 2.1 Nome Costituisce un nome; è richiesto che sia visualizzato in maniera rilevante tenendo conto anche degli elemento presentazionali che lo compongono. <!ELEMENT nome (#PCDATA b i u)*> 4

5 2.2 Valore Costituisce il valore di una caratteristica del modello. <!ELEMENT valore 1 (#PCDATA b i u immagini link )*> 2.3 Descrizione Costituisce la descrizione del modello, con tutte le informazioni considerate rilevanti o le curiosità. <!ELEMENT descrizione (ANY)> 3 Elementi Base Tre sono gli elementi di base (facoltativi) dell elemento telefonia: Telefono, Tariffa, Accessorio e Pagina. 3.1 Telefono Al suo interno è richiesta la presenza dei seguenti elementi obbligatori: Nome, Produttore e richiesta inoltre la presenza di almeno un elemento Caratteristiche. Al suo interno possono anche essere presenti gli elemento facoltativi immagine e descrizione. Ogni Telefono possiede anche un attributo tipo obbligatorio che deve essere uguale a Mobile, Fisso o Cordless. Segue una breve descrizione degli elemento presentati. <!ELEMENT telefono (nome, produttore, immagine?, caratteristiche+, descrizione?)> Produttore Costituisce il nome del produttore del modello. <!ELEMENT produttore (#PCDATA b i u immagine link)*> 1 Questo elemento è espandibile anche per il content model 5

6 Caratteristiche Costituisce un elemento di raggruppamento delle caratteristiche del cellulare. <!ELEMENT caratteristiche (nome?, caratteristica+)> Caratteristica Costituisce una caratteristica del modello. 3.2 Tariffa <!ELEMENT caratteristica (nome, valore)> Al suo interno è richiesta la presenza dei seguenti elementi obbligatori: Nome e Gestore, è richiesta inoltre la presenza di almeno un elemento Costi; può essere presente l elemento facoltativo Descrizione. Ogni Telefono possiede anche un attributo tipo obbligatorio che deve essere uguale a Mobile, Fisso, Mista. Segue una breve descrizione degli elemento presentati. <!ELEMENT tariffa (nome, gestore, costi, descrizione?)*> Gestore Costituisce il nome del fornitore del servizio. <!ELEMENT gestore (#PCDATA b i u link immagine)*> Costi Costituisce un elemento di raggruppamento dei costi delle singole opzioni che compongono una tariffa. <!ELEMENT costi (costo+)> 6

7 Costo Costituisce la descrizione di una delle opzioni che compongono una tariffa. Deve contenere l elemento obbligatorio Valore e può contenere gli elementi facoltativi Destinario, Fascia Oraria e Descrizione. Ogni Costo possiede anche un attributo tipo obbligatorio che deve essere uguale a Secondi, Scatti, Flat, Scatto Riposta. <!ELEMENT costo (valore, destinatario?, fascia oraria?, descrizione?)> Destinatario Costituisce l insieme dei numeri verso cui vale questa particolare opzione. <!ELEMENT destinatario (#PCDATA b i u)*> Fascia Oraria Costituisce la fascia oraria in cui vale quella particolare opzione. <!ELEMENT fascia oraria (#PCDATA b i u)*> 3.3 Accessorio Al suo interno è richiesta la presenza dei seguenti elementi obbligatori: Nome Produttore e Compatibilita, può contenere l elemento facoltativo Descrizione. Ogni Telefono possiede anche un attributo tipo obbligatorio. Segue una breve descrizione degli elemento presentati. <!ELEMENT accessorio (nome, produttore, compatibilita, descrizione?)> Compatibilita Costituisce l insieme dei modelli su cui funziona l accessorio. <!ELEMENT compatibilita 2 (#PCDATA b i u link)*> 2 Questo elemento è espandibile anche per il content model 7

8 3.4 Pagina Al suo interno è richiesta la presenza dei seguenti elementi obbligatori: Titolo e Corpo, può contenere l elemento facoltativo Abstract. Ogni Pagina possiede anche un attributo tipo obbligatorio che deve essere uguale a Telefono, Tariffa o Accessorio. Segue una breve descrizione degli elemento presentati. <!ELEMENT pagina (titolo, abstract?, corpo)> Titolo Costituisce il nome della pagina; è richiesto che sia visualizzato in maniera rilevante tenendo conto anche degli elemento presentazionali che lo compongono. <!ELEMENT titolo (#PCDATA b i u)*> Abstract Costituisce un testo che specifica in breve di cosa parla di documento. <!ELEMENT abstract 3 (#PCDATA b i u p)*> Corpo Costituisce il corpo della pagina, con tutte le informazioni considerate rilevanti o le curiosità.. <!ELEMENT corpo (ANY)> 3 Questo elemento è espandibile anche per il content model 8

9 4 Tesauro Il tesauro sarà contenuto all interno di più file.rdf che rappresenteranno ciascuno un nodo dell albero di navigazione. La scelta dei termini da utilizzare per la descrizione del tesauro è lasciata alle implementazioni dei singole team. I file.rdf devono però sottostare ad alcune regole sintattiche in modo da permettere l interoperabilità fra i team. Le regole sono le: I file del tesauro devono risultare sintatticamente corretti per un parser rdf. Ogni tag (sia di rdf che di xml) dovrà avere l indicazione del namespace corretto associata a un prefisso. La descrizione del singolo file deve essere contenuta all interno di un unico tag description. Le proprietà delle varie risorse devono essere tag definiti dal recommendation per xml che non presentino alcun attributo (limitazione della sintassi di RDF) a parte alcune eccezioni definite di seguito. Esse possono essere nidificate in quel caso dovranno contenere solo altre proprietà e portare l attributo rdf:parsetype= Resource Lo stesso tag xml del recommendation può essere ripetuto più volte I collegamenti tra i vari file che compongono il tesauro e tra documenti e tesauro sono fatti esclusivamente con i tag figlio, sinonimo e correlato con la sintassi definita di seguito: <s:collegamento s:nome="stringa cliccabile" s:href="url di destinazione"/> <s:figlio s:nome="stringa cliccabile" s:href="url di destinazione"/> <s:sinonimo s:nome="stringa cliccabile" s:href="url di destinazione"/> <s:correlato s:nome="stringa cliccabile" s:href="url di destinazione"/> Le url di destinazione come definito dal raf sui tag xml devono essere relative. 9

10 Un esempio di file del thesaurus può essere il seguente. <rdf:rdf xmlns:rdf=" xmlns:s=" <rdf:description> <s:titolo>telefoni</s:titolo> <s:telefono>nokia 3310</s:telefono> <s:figlio s:nome="sito 1" s:href=\emph{url1}/> <s:figlio s:nome="sito 2" s:href=\emph{url2}/> <s:correlato s:nome="sito 3" s:href=\emph{url3}/> <s:telefono>nokia 3330</s:telefono> <s:figlio s:nome="sito 3" s:href=\emph{url1}/> </rdf:description> </rdf:rdf> 5 RSS 5.1 Criteri di accesso 5.2 Versione di RSS É stato scelto di utilizzare la versione di RSS Estensioni al vocabolario RSS Come esprimere il tesauro in RSS Come specificare il match tra le metainformazioni di un documento e i summary in RSS dei vari canali 5.4 Accesso al source dei documenti XML 10