1) Nodi di un documento XML

Un documento XML un albero costituito da:

- text nodes: nodi foglia, contengono l'informazione reale
- element nodes: raggruppamento logico di informazione (definiti come <element-
name>...</element-name>)
- attribute nodes: associati ad un elemento, costituiti dalla coppia name=value
- comment nodes: meta-informazione ignoarata dal parser (<!-- commento -->)
- processing instructions: istruzioni di elaborazione (<?target istruzione ?>)
- root nodes: l'elemento che racchiude il documento

2) Caratteristiche di XML
- case-sensitive
- ammette caratteri Unicode + whitespace
- le sezioni CDATA contengono testo che non viene processato
- permette riferimenti alle entit (es. &amp; -> &)

3) La dischiarazione XML
Definisce versione, encoding e standalone (se il documento ha significato in s o
parte di un altro documento).
Non obbligatoria: se omessa, il default <?XML version=1.0 ?>

4) Namespace XML
Per differenziare eventuali elementi con definizioni diverse ma nomi uguali
(provenienti da autori diversi)
si usa un nome qualificato, composto cio da ns:nome-elemento. I namespace del
documento si definiscono
tramite l'attributo ** xmlns:nome-ns="URI-ns" **.
N.B: i namespace hanno valore informativo, non dichiarativo (cio possono contenere
URI inesistenti)

5) Verifica e convalida
La verifica assicura che il documento sia ben formato, privo cio di errori sintattici.
Viene effettuata dal parser.
Le regole sono:
- tag di apertura e chiusura corrispondenti e ben annidati
- presenza di un elemento root
- tag vuoti chiusi con <nome-elemento ... />
- attributi racchiusi tra virgolette
La convalida, in presenza di uno schema, assicura che il documento rispetti la
struttura imposta dallo schema. Viene effettuata dallo schema processor.
Un parser che effettua anche la convalida si chiama parser validante.

6) Costrutti del DTD (Document Type Definition)

- <!ELEMENT element-name content-model>, dove content-model uno tra:
* EMPTY: l'elemento non pu avere contenuto
* ANY: nessuna restrizione
* Mixed content: (content1|content2|...)
* Element content: nomi di elementi figli ammessi, separati da virgola
- <!ATTLIST element-name attribute-name attribute-type attribute-value>, dove
attribute-type uno tra:
* CDATA: caratteri qualsiasi
* (v1|v2|...): enumerazione dei possibili valori
* ID: id univoco
* IDREF: riferimento ad un id
* ENTITY: entit
e attribute-value uno tra:
* "value": attributo opzionale con valore di default
* #REQUIRED: attributo obbligatorio
* #IMPLIED: attributo opzionale
* #FIXED "value": attributo obbligatorio con valore

7) Costrutti XSD (XML Schema Definition)

Si compone di 4 tipi di costrutti:
- definizione di tipi semplici: una specializzazione del tipo CDATA
- definizione di tipi complessi: vincoli su attributi, elementi e CDATA
- dichiarazione di elementi: associa un tipo complesso ad un elemento
- dichiarazione di attributi: associa un tipo semplice ad un attributo
La definizione di un tipo semplice avviene per restrizione o estensione di un tipo
semplice predefinito
attraverso l'uso dei facets (vincoli), per esempio length, max/minLength,
min/maxInclusive/Exclusive, pattern...
I tipi complessi si definiscono includendo nell'elemento <sequence> gli elementi figli
ammessi +
eventualmente la loro cardinalit e altri vincoli

---------------

1) XPath
XPath un linguaggio di traversing di un documento XML basato sui "percorsi di
posizione (location path)",
ordinati secondo la gerarchia del documento. Un location step consiste di:
- asse
- test
- predicati
La valutazione di un'espressione XPath parte da un contesto, composto da:
- nodo di contesto
- posizione e dimensione
- insieme di operatori
- funzioni di libreria
- dichiarazione di namespace

2) Gli assi di XPath

Un asse definisce quali nodi includere nella ricerca. E' caratterizzato dalla direzione:
- diretta (child, descendant...)
- inversa (parent, ancestor...)
- attributo
- namespace

3) I test di XPath
Un test definisce se includere un tipo di nodo nel risultato della ricerca:
- text()
- comment()
- processing-instruction()
- node()
- *: tutti i nodi, indipendentemente dal tipo
- element-name: i nodi del tipo specificato
- *:localname: i nodi con nome qualificato
- ns:*: tutti i nodi del namespace indicato

4) I predicati XPath
Un predicato un espressione booleana che viene verificata sugli elementi risultanti
dopo la parte di test.
Pu anche contenere un'ulteriore espressione XPath, che viene valutata senza
spostarsi nell'albero.

Es.
* //recipe[//ingredient/@name="sugar] seleziona le ricette con discendenti ingredienti
con figli con attributo name="sugar"
* //recipe[//ingredient@name="sugar"] seleziona le ricette con discendenti con
attributo name="sugar"
* //recipe/ingredient@name="sugar" seleziona gli ingredienti con attributo
name="sugar"

------
1) XQuery
E' un linguaggio pensato per trasformare e generare documenti XML e segue il
paradignma FLOWR:
- For: iterazione su ogni elemento di una selezione XPath
- Let: assegna un risultato XPath ad una variabile
- Where
- Order by
- Return: costruisce il risultato (si possono usare direttamente costrutti XML)
Le espressioni XQuery sono racchiuse tra {}

------

1) WebService
Un servizio una procedura/metodo/oggetto con un'interfaccia pubblica e stabile
invocabile da un client.
L'interfaccia composta da protocollo + formato + comportamento. Il suo ciclo di vita
articolato in:
- Creation: il servizio reso disponibile e pubblicato (tramite registrazione ad un
directory service
o disseminazione di messaggi di advertisement)
- Procurement: fornitore e client si accordano in base a discovery (ricerca del servizio
pi adatto) e
negotiation (termini di fornitura - SLA - e Quality Of Service)
- Enactment: fruitura del servizio
Un WebService realizza un servizio sul WEB, tramite HTTP + XML + SOAP. Esso offre:
- interoperabilit
- modularit
- riuso
- affidabilit
- sicurezza

------
1) SOAP
Protocollo per realizzare SOA sul Web. Specifica:
- formato dei messaggi, in XML
- binding su HTTP e SMTP
- regole di elaborazione dei messaggi
- convenzioni per le RPC (Remote Procedure Call)
I messaggi SOAP sono racchiusi in Envelope, costituite da:
- header: opzionale, con istruzioni per il middleware (di gestione)
- body: obbligatorio, con istruzioni per le applicazioni
SOAP un protocollo molto semplice e interoperabile, ma piuttosto inefficiente e
troppo generico

2) L'Header SOAP
Contiene informazioni di coordinamento, identificazione, sicurezza...
Non ha una struttura obbligatoria, ma esistono campi predefiniti:
- role: URI del tipo di nodo che pu elaborare il blocco. Invece di un URI, si pu usare
uno tra:
* none: propagare senza elaborare
* next: tutti possono elaborare
* ultimateReceiver (default): il blocco per il destinatario finale
- mustUnderstand: true/false se obbligatorio elaborare il messaggio (un nodo che
non completa l'elaborazione
deve generare un fault)
- relay: indica se inoltrare una eventuale parte del messaggio non elaborata

3) Il Body SOAP
Contiene i dati per il destinatario. Pu contenere i blocchi:
- Fault: composto da un codice (Code) obbligatorio tra Sender, Receiver,
MustUnderstand, VersionMismatch e DataEncodingUnknown
e Reason (per gli umani, non elaborata) + eventualmente Detail, Node, Role
- RPC: Document-style o RPC-style, contiene i metodi + i parametri delle chiamate a
procedure remote
4) UDDI (Universal Description, Discovery and Integration)
Permette il binding dinamico di WebService in modo automatico.
Classifica le informazioni secondo le modalit:
- pagine bianche: secondo le organizzazioni, con i loro dati e i servizi che espongono
- pagine gialle: secondo la tassonomia dei servizi
- pagine verdi: secondo i dettagli tecnici dei servizi (modalit di utilizzo e parametri di
QoS)

------

1) Il Semantic Web
Lo scopo del semantic web di rendere il web da machine-representable a machine-
understandable tramite l'uso
di un framework per la definizione della conoscenza, un linguaggio ontologico ed
efficiente con semantica condivisa,
un'infrastruttura a "indirizzamento" univoco nel web.

2) RDF (Resource Description Framework)

Modello per descrivere relazioni (propriet) tra entit (risorse) tramite asserzioni.
Un'asserzione lega un Soggetto (risorsa) ad un Oggetto (risorsa o literal) tramite un
Predicato (risorsa).
Esistono diversi tipi di serializzazione:
- RDF/XML
- N-Triple: nel formato <soggetto> <predicato> <oggetto>
- Turtle: come N-Triple, ma con namespace e sintassi breve:
* <soggetto> <predicato> <oggetto>, <oggetto>, ...
* <soggetto> <predicato> <oggetto>; <predicato> <oggetto>; ...
- N3: introduce regole, implicazioni logiche, ...
3) Risorse anonime
Servono a strutturare informazioni di tipo literal eterogenee, senza URI, con visibilit
locale
es. <soggetto> <contact:office> +39-080-5963515 Via Orabona, 4 Bari Italy
diventa:
<soggetto> <contact:office> _:off .
_:off <contact:phone> <tel:+39-080-5963641> .
_:off <contact:address> _:add .
_:add <contact:city> Bari .
_:add <contact:country> Italy .
_:add <contact:street> Via Orabona, 4 .

4) Reificazione
Riduzione ad oggetto di una asserzione tramite le proprit rdf:type=Statement,
rdf:subject, rdf:predicate, rdf:object.
Permette di specificare ulteriori metadati (autore, timestamp...)

5) I literal
Un literal una stringa a cui pu essere aggiunta informazione:
- sulla lingua, via @lang-code
- sul tipo, via ^^datatype (sono disponibili i datatype di XSD)

6) RDFS (RDF Schema)

Per assicurare la correttezza semantica di un documento RDF serve un vocabolario
condiviso che stabilisca
delle regole di associazione. RDFS mette a disposizione le classi:
- rdfs:Class
- rdfs:Resource
- rdfs:Literal
- rdfs:Datatype
- rdfs:Property
- rdfs:subClassOf
- rdfs:subPropertyOf
- rdfs:domain: definisce il dominio di una asserzione (insieme dei valori accettabili per
il soggetto dell'asserzione)
- rdfs:range: definisce il codominio di una asserzione (insieme dei valori accettabili
per l'oggetto dell'asserzione)
Tramite domain e range possibile "obbligare" la correttezza semantica di una
asserzione.

------

1) SPARQL (Sparql Protocol And RDF Query Language)

Linguaggio di interrogazione per dataset RDF con sintassi Turtle.
Permette di ritornare i risultati in XML, JSON, RDF, HTML.
es.
SELECT ?film ?attore ?country
FROM <http://dbpedia.org>
WHERE {
?film dbpedia-owl:starring ?attore.
?film dbpprop:budget ?budget.
OPTIONAL { ?film dbpprop:country ?country }
FILTER (?budget > 1.0E8)
}

------

1) Linked Open Data Star Rating

- licenza open, in qualsiasi formato
- in formato elaborabile
- in formato elaborabile non proprietario
- in formato standard del W3C (es. RDF)
- " + collegamento ad altri dataset liberi

2) Licenze IODL
Riferite agli Italian Open Data (del progetto Open Government Directive sulla
divulgazione dei dati e-government), prevedono:
- IODL 1.0: i lavori derivati devono mantenere la stessa licenza
- IODL 2.0: bisogna citare la fonte dei dati

3) Licenze Creative Commons

- Attribution: indicare chi l'autore originario dell'opera
- Non Commercial: lavori derivati solo per scopi non commerciali
- No Derivative Works: distribuire solo copie identiche dell'opera
- Share Alike: lavori derivati con licenza compatibile
- No Rights Reserved: lavori derivati senza vincoli di licenza

------

1) NoSQL (Not Only SQL)

Vantaggi:
- gli elementi sono "self-contained" (no JOIN)
- semplice e scalabile
- mappatura diretta alle Object Classes
Svantaggi:
- integrit non "obbligata" dal DBMS
- mancanza di uno standard
- API proprie
- migrazione non immediata
Tecniche di organizzazione dei dati:
- Column Store (Google BigTable): dati immagazzinati per colonna, non per riga
- Key-Value Store (Amazon DynamoDB): dati immagazzinati come un dizionario
secondo la chiave
- DocumentStore (MongoDB): dati immagazzinati come documenti (JSON o XML),
eventualmente annidati; schema-free
- Graph Store (neo4j): dati immagazzinati come nodi di un grafo collegati da rami
(usando un modello Key-Value); estremamente prestanti per dati gerarchici