Skip to topic | Skip to bottom
Home
TechWeb07
TechWeb07.WorkingGroupACDSr1.257 - 12 Jun 2007 - 12:13 - AlessandroCaponitopic end

Start of topic | Skip to actions
-- AlessandroCaponi - 17 Apr 2007
  • Set ALLOWTOPICVIEW =
  • Set ALLOWTOPICCHANGE =

Working Group AC-DS

Membri

Chair: AlessandroCaponi

Email: caponi@cs.unibo.it

Aggiungete a questa tabella il rappresentante del vostro gruppo.

ATTENZIONE: il working group è aperto a tutti; è comunque importante (soprattutto per voi) avere un rappresentante per gruppo che segua la questione anche non attivamente.

Gruppo Rappresentante
AAAiuto AlessandroCaponi
Deprecati MatteoMarchetti e LucaZingaretti
CaLindro SilviaRighini e/o GiorgioPremi
B4July EmmanuelAdenitire e/o DaviMatteo
ACiDi ClaudiaCarpineti
MDGR SandroMusaro o GianlucaGozzoli
LCDP FrancescaBugamelli o SimoneFrau
FGGC DomenicoGermanotta e/o LuciaChiarello
GMNP GabrieleGiuranno e/o FedericaMazzocchi
MAMADE MatteoFini e/o DanieleCarati
Oneida AndreaSpagnolo
SognoOSonDesktop TommasoVitale e/o MaurizioCasimirri
4MenOnBoat MarioPedicino e/o EmanueleTaurino
LTGB GiovanniRosignoli
MenAtWork Marcello
GWAIN PaoloValleri e/o FrancescoDraicchio
ImoScbabbari MichFabb e/o DonatoIacoviello
GAF GiulioAscani e/o AlessandroRanocchini
RastaMan BetaPi
Tajwu DiLella

Una cose che non ho mai detto, ma spero che sia chiara è che useremo la codifica UTF-8 per evitare problemi,credo che questo non sia da votare più che altro ricordatevelo!

Pagine principali delle componenti del protocollo DS

Riunione POST-Fiera

ALERT! IMPORTANTE : Viste e considerate le opinioni/incongruenze che mi sono arrivate alle orecchie propongo di riunire il WG DS per una sessione straordinaria POST-fiera. Invito un rappresentante per gruppo a partecipare, e preferei avere solo un rappresentante per gruppo "attivo", cioè partecipe al tavolo di discussione, per non creare confusione, etc. Gli altri comunque possono assistere. Ricordo che sarà solo per sistemare evidenti incongruenze o parti ambigue o ancora aggiunte per situazioni evidentemente carenti. Le proposte di aggiunte, specialmente quelle, che sembrano essere di estrema importanza per il singolo gruppo, verranno cestinate senza pietà.

Dunque come data ho pensato a Lunedì 11/6 Pomeriggio intorno alle 15 ci troveremo davanti all'Ercolani e vedremo se andare al Gazebo o in altra locazione, come ad esempio la fresca zona antistante. Per eventuali problemi dei rappresentanti dei gruppi postate qui sotto. E' ovvio come sempre che non verrà spostata per una-due persone, però possiamo cercare di venirci incontro.

Argomenti trattati

1) è stato deciso di modificare il tipo all'interno di lang (language): passa da IT_it a IT-it.

2) discussione sull'introduzione delle tabelle nella grammatica DS del testo. Tabelle aggiunte alla grammatica. Voto 7 favorevoli e 5 contrari.

3) discussione inserimento di un attributo che indichi "hasNext" per l'elenco. bocciata.

4) validazione del catalogo da aggiungere al validatore online. Namespace solito.

5) modifica del validatore online.

6) correggere parte su wildcard ambigua.

ATTENZIONE: NUOVO VALIDATORE ONLINE CON PARAMETRI AGGIORNATI QUI!

Validatore 0.9.1 UPDATED

Alla mia pagina trovate la versione funzionante del validatore, che dovrete utilizzare per validare le pagine in arrivo al DS... gli schemi non sono ancora definitivi, ma nell'esempio trovate anche una versione piuttosto aggiornata degli schemi. Non prendeteli come oro colato, in quanto alcuni sono in fase di "revisione" da parte del WG del DF, da AlessandroCaponi & co.

NOTA: per il namespace della grammatica che definiamo ci conviene tenere xmlns:ltgb=http://vitali.web.cs.unibo.it/save/TechWeb07, in modo che lo condividiamo anche con il WG del DF. Comunque domani sapro` dirvi qualcosa di piu`!

ALERT! Stiamo valutando di costruire un servizio per la validazione remota dei documenti per avere una versione per tutti evitando molti problemi! Vediamo che si può fare. Inoltre ricordate che la grammatica che sta con il validatore attuale E' VECCHIA!!!! scaricatevi la nuova dalla apposita sezione del WG

GiorgioPremi

Grammatica DataSource

Ho preferito fare una pagina a parte perchè ho preparato alcuni esempi e vorrei inserire una tabella per eventuali BUG.

* Grammatica v.0.9

WSDL

* WSDL Versione 0.9

OWL e ONTOLOGIA

OwlOntolgia

Protocollo

Per eventuali incongruenze tra descrizione e schema postate qui:

Protocollo

Riunioni (CHIUSO)

Le riunioni del gruppo estivo sono terminate. DA ora in poi solo bugfix. Domani Uscira la versione 06 del Protocollo e dovrete attenervi a quella.

ATTENZIONE: Sto preparando la versione 0.6 che conterrà le tabelle ma sparirà il DTD e ci sarà solo lo schema. Inoltre verrà la versione definitiva del WSDL e degli errori relativi.

Gli argomenti da trattare saranno : ---

Proposta Gruppo Rappresentante Commenti
So che non sarebbe il caso di tornare sulla grammatica dell'elemento scheda ad oggi, ma solo ieri mi son reso conto di qualcosa di, a mio parere, disdicevole, ovvero: le keyword (o tags, o come diamine le vogliamo chiamare) son presenti ESCLUSIVAMENTE nei PuntiDiInteresse?. Ma non trovate che un itinerario possa possedere peculiarita' non deducibili dalle sole keyword dei PdI? in esso contenuti (ed idem dicasi per una guida)? Ergo propongo di aggiungere detto elemento anche ad itinerario e a guida (se non direttamente a scheda, ora che commento dovrebbe non far piu' parte dei figli) LCDP -- SimoneFrau - 19 May 2007 Sono perfettamente daccordo. Direi di introdurlo nella grammatica e magari vedere se qualcuno è contrario alla prossima riunione Chair

Spazio proposte UPDATED

Ho deciso di aprire questo spazio per eventuali proposte di discussione da inserire nella prossima riunione che non siano queste qui sopra. In modo che ne prendano visione tutti per la prossima volta.

Proposta Gruppo Rappresentante Commenti
Discutere formato standard del campo ID di una scheda: non mi sembra se ne sia discusso, servirebbe uno standard (del tipo "nomegruppo"+"numeroscheda" o qualcosa di simile) per evitare conflitti nella gestione di schede provenienti da DS di gruppi diversi. Visto che state mettendo mano alla grammatica considerate il problema. MDGR GianlucaGozzoli Abbiamo deciso che deve essere l'application controller che gestisce questo tipo di informazioni. sarà quest'ultimo a inserire un'etichetta (decideranno i gruppi come) che farà riferimento al datasource corretto.-- AlessandroCaponi - 15 May 2007
Occorre cominciare a pensare anche ai metodi per la modifica e inserimento di schede. Ho ragionato sulla faccenda ed ho scritto un po' di appunti su PdI e su Guide ed Itinerari MenAtWork MarCro  
Scusate se ritorno sulle cose già decise: consideratela solo come un'osservazione da purista. Nella definizione dell'item di elenco abbiamo messo a livello di attributo delle informazioni che, nella scheda, hanno rango di elementi. Perchè? Se c'è una qualche logica che spinge a classificare un'informazione come attributo piuttosto che come elemento, mi aspetto che quella logica sia sempre seguita. Tutto qua. MenAtWork MarCro - 11 May 2007 Questa cosa mi ha fatto riflettere ed effettivamente hai ragione. Magari vediamo lunedì se sistemare questa cosa. più che altro il problema di gestire le informazioni una volta in un modo una volta in un altro può portare problemi
volevo sottoporre il problema di accordarci e definire concretamente (in schema) la parte query del catalogo, nella discussione sul wsdl sono sorte molte domande a proposito delle keyword e dei tags e penso che per chiarire ogni dubbio ci si potrebbe accordare in modo definitivo su come sono definite in grammatica le keyword le tags etc.. MAMADE Matteo Fini - 15 Maggio 10:27 ho parlato oggi con il chair e abbiamo deciso di togliere la parte query del catalogo perche non serve a molto, siccome sara' elenco a dirci quale' tipo di ricerca possiamo fare EmmanuelAdenitire - 16 Maggio 12:30
volevo sottoporre il problema delle keyword obbligatorie che l'elenco deve avere, penso che quelli essenziali debbono essere cordinateGPS+raggio, tipo, genere, il nome non e' obbligatorio secondo me per il fatto che se uno ha un datasource intermediario non sa come gestirlo siccome puo immettere qualsiasi tipo di nome. B4July EmmanuelAdenitire - 16 Maggio 12:30 Si penso anch'io quelle siano le fondamentali. Ho guardato come hanno fatto l'anno scorso e mi e' sembrato abbastanza semplice, hanno lasciato la parte query e per ogni keyword specificano il nome che sarebbe il parametro su cui fare la ricerca, una descrizione della keyword ed il tipo di dato gestito dalla keyword, magari ne parliamo al WG oggi pomeriggio; tanto per rendere l'idea questo e' un catalogo dell'anno scorso QUI -- MatteoFini - 17 May 2007 *è stata bocciata questa proposta alla fine perciò le key restano le stesse decise all'ultima riunione.

Un pò di materiale

  • questo documento che parla di come ottenere coordinate gps e mappe da google maps.

  • Ho traslocato il messaggio di Giorgio qui nel materiale, da ciò inizieremo il lavoro per la stesura della grammatica:Il lavoro TITANICO e` terminato... almeno per questa prima bozza! (con il lavoro che ho fatto prima della lezione di Vitali, mi fa un po' senso chiamarla bozza, ma... va be'!). Ho riscritto il DTD di Marcello (bel lavoro!) in xschema; ho aggiunto tutti i vincoli che erano scritti in linguaggio naturale (viva Martini! smile ) nelle specifiche piu` alcuni altri vincoli, come ad esempio i vincoli sulla struttura GPS. Le cose che abbiamo lasciato in sospeso (come i commenti) non li ho inseriti, perche` avrebbero solo confuso il tutto... e` meglio riscriverli ex-novo quando abbiamo le idee chiare - e spero presto. Ho riempito di miei commenti personali il file in modo che vi arrivino a voi alcuni miei dubbi che non posso comunicarvi domani a lezione, in quanto staro` facendo grafica. Bando alle ciance ecco il file xschema!!! Lo terro` li` per un po'... se qualcuno sa dirmi come faccio ad accedere ad un area pub all'interno di TWiki per aggiungere il file e` meglio. Giorgio

  • ho traslocato il DTD di Marcello pure: Mi sono messo di santa pazienza a cercare di interpretare la struttura dei dati forniti dal DS. La strategia che ho adottato è stata quella di riscrivere la DTD completa: trasformarla poi in XML Schema dovrebbe essere automatico. Ve la propongo in questo linkannotazioni

Verbale riunione del 24/05/2007

Sono state modificate alcune voci all'interno di logistica e dell'ontologia. Si rimanda alla versione finale del protocollo per le modifiche.

Abbiamo deciso di utilizzare il WSDL che come parametri ha solo tipi semplici perchè ci sembra la soluzione più ovvia visto il tempo che ci rimane.

Verbale riunione del 21/05/2007

Sono state aggiunte le tag "licenza" e "lang", per includere rispettivamente eventuali licenze su un documento importato e la lingua del documento (obbligatoria).

Abbiamo tolto alcuni elementi atomici senza senso dal "testo".

E' stato aggiunto l'attributo seeAlso alle keywords per effettuare link tra schede dello stesso DS. Nel caso vengano copiate gli ID all'interno delll'attributo perdono di valore e devono essere eliminati o sostituiti (se supportato).

E' stata rimossa la tag "genere" perchè inutile. Tipo è sufficiente per definire il genere della scheda.

E' stato diviso stazione da aeroporto all'interno dell'ontologia.

Sono stati aggiunti monumenti sotto a PdI? e Teatro.

Verbale riunione del 14/05/2007

In questa riunione dopo alcune discussioni abbiamo fissato alcuni concetti fondamentali per il completamento della grammatica.

1)Abbiamo rimosso ubicazione che era stato aggiunto la settimana scorsa. Dopo una attenta riflessione e discussione ci siamo resi conto delle difficolta nel gestire questo campo e che in questo senso ci vengono in aiuto le keywords (ora chiamate tag per distinguerle dalle keywords della query elenco). Se un utente cerca "Francia" verrà cercato all'interno delle tag relative ad una scheda.

2)come già detto è stato modificato il nome dell'elemento keywords in tags, per distinguerle dalle keywords della query nella richiesta elenco. La decisione è scaturita dalla non comprensione di molti della differenza.

3) Sono state fissate le keywords (minimali) che dovranno essere supportate da tutti i DS. Ripeto sono "minimali" per il resto potete rendere più complessa la richiesta dell'elenco indubbiamente.

  • Le keywords sono: Nome, CoordinateGPS?, Raggio, Tags, Genere, Tipo

La richiesta SOAP di esempio verrà discussa e presentata Giovedì.

4) è stato definitivamente tolto ogni riferimento ad una possibile history, visti i problemi legati al riferimento a DS esterni. Abbiamo deciso di utilizzare il campo origine come era stato fissato nella prima versione del protocollo:

  • il campo "origine" indica l'URI del documento passato come scheda da un DS intermediary.

5) E' stato deciso che l'application controller deve gestire il corretto passaggio di schede tra client e DS. Sarà L'Application controller a destinare le richieste al giusto DS (dei 4 che dovrà gestire ognuno di noi), senza avere riferimento all'interno della scheda stessa. Ci è sembrato opportuno fare questo per non dover predisporre un codice particolare che ricordasse l'apparteneza della scheda ad un determinato DS.

Un discorso importante che è venuto fuori è che un intermediary è solo ed esclusivamente quello: ogni scheda che vorrà essere salvata dovrà essere gestita con un opportuno altro DS.

6) E' stata tolta l'operazione "modifica" ed i relativi metodi dal WSDL perchè non ritenuti necessari per il corretto funzionamento del nostro sistema. Ovviamente ora ogni operazione di inserimento dovrà avvenire con "inserisci scheda".

Verbale riunione del 17/05/2007

Le discussioni fondamentali sono state 2:

1)La prima che riguarda le scelte sulle richieste SOAP:

  • aggiungeremo i tipi alle richieste. Sto lavorando su una versione + o - definitiva da portare per lunedì.

  • aggiunti i metodi che richiedono e aggiungono direttamente i commenti, perchè portati fuori da scheda. I commenti verranno inseriti con un metodo che spedisce i commenti + l'id della scheda (pdi o iti o guida). I commenti verrano richiesti con un "id" più un offset dei commenti richiesti(per ora credo che sia "il numero di commenti richiesti", però sto pensando di strutturarlo diversamente).

  • come dicevo ad alcuni "catalogo" sarà solo un xml da richiedere direttamente tramite URI per ricevere i meta-dati del DS e l'URI del WSDL del SOAP corrispondente a quel DS di un determinato gruppo (che giro di parole).

  • aggiungeremo gli errori, i "fault" all'interno del WSDL, se riscontrerò eventuali problemi ne discuteremo lunedì.

2)La seconda riguarda l'ontologia:

  • abbiamo chiarito i meccanismi per cui utilizzeremo l'ontologia. Sarà necessaria per eventuali ricerche ad ampio spettro, mi spiego: se io cercò "località" l'Application Logic può fornire ricerche su tutti i figli all'interno dell'albero(comuni, provincie, regioni, etc...). Un altro punto importante è, ""cosa mi aspetto di trovare nella logistica?"". Anche a questo risponderà una interrogazione dell'ontologia.

  • abbiamo discusso sul come e perchè debba essere aggiunta o tolta una nuova voce all'interno della tassonomia della nostra ontologia(cioè togliere una classe dall'albero). Se è necessario specializzare e aggiungere una nuova voce ci deve essere un motivo bene preciso.
    • Nel caso di aggiunte deve essere una necessità oggettiva rispetto agli argomenti di un gruppo che non trova aderenza tra le informazioni che ha e l'albero.
    • Nel caso di specializzazione (negozio->salumeria) deve esserci la necessità di aggiungere una caratteristica che non farebbe parte di quella più generica, ma solo di quella specializzata (ad esempio se io voglio aggiungere "tipoDiProsciutto" a salumeria deveo aggiungere quest'ultima, perchè negozio generico non può contenere "tipoDiProsciutto", solo pochi negozi hanno necessità di una caratteristica del genere.

  • Abbiamo discusso l'aggiunta di nuove voci all'interno della logistica (per questo vedete la nuova versione del protocollo), le riassumo brevemente:
    • ubicazione (per descrivere l'indirizzo, la città, la via in maniera "libera".
    • nomeLocalità (per descrivere il nome di una città , stato, provincia...etc..
    • abbiamo aggiunto "teatro" come classe e di conseguenza è stato aggiunto "!calendarioSpettacoli", verrà descritto più specificatamente nella grammatica.
    • abbiamo aggiunto "monumento" come classe, che avrà nella logistica elementi già definiti come "orario", "biglietto", etc..
    • abbiamo discusso sull'aggiunta di agriturismo, aggiungeremo agriturismo come figlio sia di locale che di ristorante ereditando le caratteristiche di entrambi Eventuali aggiunte sulla logistica dovranno essere presentate dal gruppo interessato.

3) Il terzo argomento ha riguardato alcune modifiche e chiarimenti su alcuni vocaboli utilizzati all'interno della nostra grammatica. Una decisione presa è stata quella di far tornare keywords al posto di tag all'interno della scheda, e far diventare parametriDiRicerca, le key della query.

Verbale riunione del 11/05/2007

1)La prima discussione è stata sul WSDL del protocollo SOAP relativo al DS. Abbiamo eliminato tutti quei parametri che abbiamo alla fine di una discussione considerato non necessari e difficili da gestire. Abbiamo anche discusso sul fatto di inserire tipi complessi invece di stringa come parametro, chiuderemo questo discorso lunedì. Metterò la nuova versione (la terza) su sabato.

2)Abbiamo deciso di eliminare l'elemento %altro, ormai inutilizzato, e abbiamo spostato le liste nell'elemento blocchi. Mi sono accorto che comunque non è il caso di mettere questa roba allo stesso livello di descrizione quando dovrebbe andare all'interno perciò dovremmo rivedere anche questo.

3)Abbiamo aggiunto l'elemento ubicazione a scheda. La discussione è nata dal momento he abbiamo dovuto gestire la "località" nell'ontologia. Il discorso alla fine è stato il seguente: l'utente inserirà comunque la locazione dall quale estrarremo le coordinate (o comunque si possono inserire a mano) ma la locazione rende meglio l'idea se si tratta di un quartiere, città, etc...Ci è sembrato opportuno inserirlo per evitare ragionamenti troppo complessi e astrusi da parte dell'Appication Logic.

4)Abbiamo aggiunto l'elemento "Rifcommenti" in "info" come riferimento ai commenti, di tipo ID. Ci sembrava logico per trovare i commenti. La possibilità di fare una richiesta di commenti+ scheda, implicava il fatto di utilizzare uno switch di qualche tipo sul/i parametro/i di ritorno.

5)Abbiamo discusso della logistica e dell'ontologia. Sono nate alcune voci che metterò nella prossima versione del protocollo e delle quali discuteremo lunedì se ci sono problemi/ulteriori proposte. Renderò disponibile al più presto anche queste nuove modifiche.

Verbale riunione del 09/05/2007

1)Oggi abbiamo dato una soluzione al problema della gestione degli "item", cioè di quegli elementi che compongono sia l'elenco sia le seqPdI e le seqIti. Sono state presentate varie proposte di differenziazione, alla fine si è scelto di adottare una soluzione molto semplice, ma efficace:

    <!ENTITY item (descrizioneBreve)> 
      <!ATTLIST item
        genere CDATA #REQUIRED
        tipo CDATA #REQUIRED
        RichiediCon ID #REQUIRED
        nome CDATA #REQUIRED
        modificatoIl CDATA #REQUIRED >

L'item contiene dunque la descrizione breve e ha come attributi:

  • il genere, che indica la tipologia di scheda (PdI?, Itinerario o Guida)
  • il tipo secondo la classificazione proposta nell'ontologia
  • RichiediCon? che è l'ID utile per recuperare la scheda completa
  • nome, cioè il titolo della scheda
  • modificatoIl contiene la data di modifica (nel nostro caso fondamentalmente di creazione)

2) Siamo ritornati sulla questione "copia si, copia no" trovando nuovamente un accordo per cercare di semlificare le cose ed evitare situazioni comunque da controllare con ulteriore carico di lavoro. Abbiamo deciso di tornare al vecchio sistema in cui ogni modifica sulla scheda è una copia, qualsiasi essa sia. Ogni interazione in input perciò può essere solo o una nuova scheda o una copia dell'originale. Vorrei migliorare lo schema qui sotto (Prima non mi ero veramente reso conto di quanto fosse fatto male!) per rendere chiara questa faccenda.

Comunque ricordo che nessuno vi impedisce di poter ammettere una sovrascrittura nel vostro DS, per non generare copie a vostro rischio e pericolo!

Come ho detto oggi metterò a disposizione a breve un WSDL completo, credo domani (giovedì 10), sul quale discutere su eventuali proposte/problemi.

Abbiamo dato anche un senso all'elemento logistica contenuto nei PdI?. Questo significa che ora logistica sarà descritto più o meno in questo modo:

 <!ELEMENT logistica (orarioChiusura?,orarioApertura?,chiusuraSett?,camere?,numeroTel?,...)> 

ATTENZIONE: questa non è definitiva, anzi è solo un esempio.Eventuali proposte vanno fatte nell'apposito spazio (magari creando una nuova pagina se si tratta di proposte molto lunghe).

Abbiamo discusso un pò la logistica per poi spostare la discussione alla prossima riunione quando molti avranno delle proposte da avanzare.

Verbale riunione del 07/05/2007

Oggi abbiamo chiuso (almeno per ora) alcune importanti questioni che riguardano la gestione dei dati all'interno del DataSource.

La prima decisione che è stata presa è utilizzare Xml-Schema (più eventualmente Schematron) per ciò che riguarda la validazione dei dati. Ci sono stati due pareri contrari ma abbiamo deciso a maggioranza dopo una breve discussione.

Il secondo problema da risolvere è quello che riguardava l'history. Abbiamo deciso di dedicare un pò di tempo alla presentazione di una leggera modifica rispetto alla versione precedente della gestione delle schede in base alla copia o alla modifica. Ci siamo soffermati un pò di tempo a cercare di capire e rivedere tutti i meccanismi del DS. Il disegno qui sotto illustra (più o meno) la nuova situazione: [manca qualcosa ma più che altro è un reminder]

imgDs.JPG

Per ora l'history verrà gestita solamente con un parametro che indica il "padre" della scheda. Un history dinamica si è rivelata impossibile a causa del solito problema delle referenze.Questo parametro "origine" è un parametro atomico che indica la risorsa da cui è stata copiata la scheda.

Un altro importante problema risolto, è la gestione dei commenti: i commenti saranno gestiti come scheda e punteranno alla scheda a cui fanno riferimento, mentre in quest'ultima ci sarà un riferimento ai commenti nel campo "commenti". I commenti saranno una "lista" di "commento", elementi atomici di tipo stringa.

ALERT! entro stasera vorrei rendere disponibile la nuova versione del protocollo, la 0.4. Se ci sono problemi, mancano cose, servono aggiustamenti poi ne discuteremo un attimo mercoledì, comunque sarà il documento che sto preparando che farà testo nella prossima discussione.

Verbale riunione del 03/05/2007

Quest'oggi dopo la discussione con il professore riguarda alle problematiche pendenti scaturite dalle discussioni, abbiamo ottenuto un bel pò di informazioni su come procedere nel nostro lavoro.

Prima di tutto abbiamo discusso, appunto, delle novità riguardanti l'editing. Ora le schede sono tutte modificabili, ma la modifica significa creazione di una nuova copia. Quindi è stato pensato di definire un modo per avere una "history" che gestisca le versioni delle copie, per avere la possibilità di visualizzare le copie in base a richieste o necessità. Questo discorso è ancora aperto speriamo di chiudere questo discorso durante la prossima riunione.

Un altro importante argomento di discussione di oggi è stato la gestione dei commenti. Si è pensato di gestire i commenti esternamente rispetto alle singole schede. Il commento dovrebbe diventare o una scheda o addirittura più esterno.

Il problema principale che è nato riguarda la gestione dei commenti come "lista di" oppure ogni commento come singola risorsa. La prima ipotesi compatta la gestione, ma la seconda permette di non duplicare i commenti ad ogni copia.

E' stato definitivamente tolto l'elemento pagina dalla scheda. La gestione sarà fatta esternamente. Ogni gruppo gestirà le pagine come meglio crede. (potrà anche tenerle nel datasource e gestirle con una apposita richiesta privata).

Per ora sono stati definiti i contenuti di descrizione estesa e descrizione breve, rispettivamente come %CMblocco; e %CMatomico;

Verbale riunione del 30/04/2007

Gli argomenti trattati sono stati molti sono scaturite molte problematiche delle quali dovremo parlare e comunque delle quali dovrò parlare con il prof.

  • All'inizio abbiamo subito deciso con un voto unanime di utilizzare la modalità modulare di utilizzo del SOAP. Dovremo nelle prossime riunioni definire le possibili richieste per poi implementarle.

  • Abbiamo rinviato la decisione su XML-Schema/RelaxNG sul validatore per informarci ulteriormente su alcune problematiche relative a XML-SChema/schematron.

  • Abbiamo affrontato per un bel pò l'argomento "editing" scoprendo problemi ulteriori rispetto a quelli che già erano scaturiti da discussioni esterne al working group, abbiamo ragionato soprattutto considerando due problemi fondamentali:

    • se la guida è strutturata a puntatori, potremmo avere il problema di dover arrivare a DS che non fanno parte di quelli che abbiamo acquistato.
    • se la guida è "monoblocco" cioè si porta dietro i PDI e gli itinerari duplicati, abbiamo problemi di "versioning" dei dati relativi ad orari e informazioni che riguardano tutto ciò che è locale pubblico. Un esempio può essere il ristorante che cambia locazione, orario o chiude.

A tal proposito, come ho già detto alla riunione, vorrei discuterne con il prof di queste ipotesi e problematiche, per farmi per lo meno indirizzare.

  • è stato affrontato il tema di come trattare le pagine funzionali. Per ora questa discussione è stata rimandata alla prossima riunione.

  • sono state apportate diverse modifiche a "commenti" :
    • è stato aggiunto il contenitore "commenti" (si è deciso per ora di gestirlo esternamente rispetto alle schede, anche se la discussione sul come è ancora aperta)
    • a "commento" contenuto in "commenti" è stato aggiunto l'attributo "data", per poter datare i commenti rispetto alle modifiche del documento soprattutto.

  • è stato deciso di strutturare descrizione in maniera diversa con una votazione (decisa da una larga maggioranza) : una descrizione breve e una descrizione estesa. Questa idea è nata dalla possibilità di poter spedire in un primo momento la guida (o il PdI? o l'Itinerario) in versione breve per poi estenderla a seconda delle necessità/richieste.

  • è stato scelto a maggioranza di lasciare gli elementi con i nomi attuali senza tradurli tutti in una sola lingua (inglese o italiano).

  • è stato modificato "coordinateGPS" ed è stato diviso in due voci latitudine e longitudine. Si sfrutta sempre il meccanismo DD cioè Gradi Decimali.

  • è stata fatta una lunga chiaccherata per definire meglio il concetto di "keywords". Il meccanismo è lo stesso a livello di data source, solo si pensava di dare la possbilità di definire keywords e tag (youtube style).

ALERT! Non credo sia necessario tirare fuori un altra versione del protocollo, attedenrei la riunione di giovedì visto che abbiamo fatto 2 modifiche effettive, il resto è ancora in discussione

Verbale riunione del 26/04/2007

1) Innanzitutto nella prima ora è stato presentato il problema del protocollo SOAP. Il Chair del working group del Data Formatter è venuto a presentare il problema proponendo due possibili soluzioni per ciò che riguarda la struttura del protocollo.

Abbiamo deciso di rinviare la decisione alla prossima settimana, chi è interessato a partecipare alla discussione dovrebbe dare un'occhiata al materiale fornito nella pagina del working group DF o cercare del materiale per conto proprio, comunque si dovrebbe informare sull'utilizzo dei web service SOAP.

2)Nella seconda ora sono state formulate ipotesi di comportamento per ciò che riguarda alcuni aspetti generali sui quali ci dovremo informare meglio anche discutendone con il prof. Per citarne alcuni, abbiamo parlato di come gestire gli utenti, soprattutto per ciò che riguarda i permessi, la gestione della struttura delle pagine (non il layout o la skin), un accenno ad alcuni meccanismi del protocollo. Per ciò che riguarda i permessi abbiamo ipotizzato di gestirli in maniera banale (tutto/niente), cioè le uniche due opzioni possibili sono:

  • o sempre modificabile da tutti
  • o mai da nessuno, nemmeno da chi l’ha creato, una determinata scheda.

Di questo ne discuteremo sicuramente più avanti.

3)Si è pensato (ancora da discutere) come gestire le schede funzionali delle pagine del sito, si è pensato di far gestire la cosa ai gruppi, ma non è stata presa una decisione definitiva in merito.

4)Nell’ultima parte della riunione è stato fatto un grosso lavoro di ristrutturazione di alcune componenti degli elementi costitutivi le schede del nostro DS.

  • Abbiamo modificato alcuni elementi atomici, abbiamo lasciato aperte alcune discussioni, tra cui la definizione delle coordinate GPS e l’unità di misura del raggio.
  • Inoltre abbiamo trovato difficoltà, per cui chiederò delucidazioni, nel capire se fosse necessario memorizzare in qualche modo, un riferimento alla skin e al layout della guida impostati dall'utente che l'ha prodotta. I problemi fondamentali sono 2:
    • un utente che vuole vendere una guida ha sicuramente deciso un layout per la sua guida, ma come fare a tenerlo se poi possono cambiare i formatter?
    • il layout deve essere legato alla guida perciò deve essere contenuto nel DS per forza.

Ora senza alcun dubbio presenterò il problema al professore per capire se ciò sia effettivamente necessario, cioè se dobbiamo obbligatoriamente gestire un layout e una skin di default per la guida.

  • Sono stati corretti vari errori, alcuni dovuti ad incomprensione del testo.
  • È stato aggiunto l’elemento keywords tra i contenitori come lista di tutte le keyword associate ad un Punto di Interesse

5)Sono anche state fatte alcune considerazioni su Elenco e Catalogo, sulle quali vedremo di tornare solo nel momento in cui avremo più chiaro il protocollo.

IDEA! Per ciò che riguarda tutte le modifiche in particolare si rimanda al protocollo 0.9.03.

Verbale riunione del 23/04/2007

Nella prima parte di questa Riunione abbiamo discusso su alcune problematiche lasciate aperte nell'ultima riunione.

Soprattutto ci siamo soffermati sul fatto della necessità di aggiungere un campo raggio all'interno di Punto di Interesse, ed alla fine di una votazione è stato aggiunto con un solo voto contrario. L'altro problema a cui è stata trovato subito soluzione tramite voto con un solo contrario è stata la possibilità di cambiare il campo "nome" all'interno di guida con "titolo"; è stato deciso di lasciare come è ora con il campo nome.

In seguito sono sorti altri problemi relativi ad altri elementi appartenenti agli elementi contenitore e ad alcuni elementi di tipo blocco e inline. Abbiamo deciso con il voto di modificare il Content Model di seqPdI e seqItinerari per renderli sintatticamente più corretti. Dopo una lunga discussione dovuta al fatto che si potesse risolvere attuando tecniche che non permettessero il verificarsi di errori, è stato deciso alla fine di modificare i CM differenziandoli. Inserito il campo Id all'interno degli elementi Punto di Interesse, Itinerario, Guida.

Negli elementi blocco abbiamo modificato "para" in "p". Abbiamo notevolmente modificato l'entità "inline" togliendo tutte quelle voci che rappresentavano esplicitamente caratteristiche che riguardassero la "skin" della pagina (quindi i testi colorati e abbiamo sostituito testo corsivo e grassetto con strong e emph per il momento)

IDEA! ricordo che le modifiche ad alcuni elementi "altro", "blocco" e "inline" potranno essere modificate in un secondo momento per le esigenze dei gruppi.

Verbale riunione del 19/04/2007

ALERT! IMPORTANTE PER TUTTI : Ho parlato con il prof. sul fatto dei contenuti del DS. Sta a noi decidere la tipologia e l'organizzazione dei contenuti gruppo per gruppo, anche per renderli più appetibili al momento della fiera. Non dobbiamo organizzarci in maniera statica dunque.

Neanche oggi abbiamo finito di visionare l'intero materiale, ma dalle discussioni sono scaturite un bel pò di argomenti e di modifiche. Perciò in questo caso farò l'update della versione 0.9.01 del protocollo LTGB-DS. Tutte le modifiche verranno mostrate all'interno del nuovo documento, porto comunque a conoscenza di tutti gli argomenti chiave della discussione odierna:

  • Il Working Group ha deciso di utilizzare Xml-schema per la esprimere la sintassi del vocabolario del progetto. Attendiamo la risposta da parte dell'altro Working Group per confermare questa decisione.

NEW Intanto comunque ho deciso di postare il link al sito html.it della sezione che parla di xml-schema e la recommendation del W3C(ci servirà comunque per l'esame) Xml Schema su html.it Xml schema parte 1 Xml schema parte 2

per ciò che riguarda !RelaxNG vi fornisco un link *RelaxNG Tutorial Ufficiale

N.B. Le recommendation per la versione 1.1 sono previste per Ottobre 2007 se non sbaglio. Per ora prendiamo la 1.0.

  • Per ora abbiamo deciso che il catalogo va richiesto solamente una volta per sessione. Il catalogo inoltre deve essere statico.
  • è stato deciso per alcune voci e lasciato in sospeso altre che riguardano gli elementi costitutivi di Punto di Interesse e Guida.
  • Abbiamo corretto alcuni errori sintattici e semantici all'interno del documento

Le modifiche e le discussioni in sospeso saranno mostrate nel nuovo documento del protocollo. Il documento spero di metterlo su domani (20/04/2007) in mattinata. UPDATED è stato inserito il nuovo protocollo con le modifiche apportate.

Verbale riunione del 17/04/2007

Visto che non è stata completata la comprensione e la correzione del protocollo credo che non sia il caso di mettere su una nuova versione del protocollo

  • Innanzitutto abbiamo osservato la necessità di vedere alcuni argomenti, come i Web Service, e i sistemi per la gestione semantica dei contenuti.
  • Abbiamo evidenziato le caratteristiche generali (molto generali) della Query al DataSource soffermandoci su alcune problematiche che sono state incontrate da una prima lettura delle specifiche. si è discussa la possibilità di inserire ulteriori campi oltre all'ID per richiedere elementi di tipo scheda. Abbiamo visto che gli elementi di tipo scheda ottenuti come elenco possono essere gestiti con il solo ID.
  • Sono state evidenziate delle problematiche relative alle informazioni necessarie per identificare una guida od un itinerario; è stato riscontrato un errore su una delle caratteristiche dell' itinerario usando alternativamente NOME o TITOLO. Abbiamo deciso di utilizzare titolo in maniera univoca.
  • Sono stati riscontrati errori di battitura che verranno corretti nella prossima versione del protocollo.
  • è stato proposto di inserire la data di pubblicazione della guida, ma risulta già inserita nelle specifiche degli elementi contenitore (paragrafo 4.3.1 della specifica 0.9).
  • è stato richiesto di informarsi sul come si devono dividere i contenuti tra i gruppi, cioè se i contenuti vanno divisi tra i gruppi per categoria ontologica oppure per locazione geografica o se in realtà non c'è questa necessità.

to top

You are here: TechWeb07 > WorkingGroupACDS

to top

Copyright? © Fabio Vitali + TechWeb students 2006