Formati di scambio dei dati. 24-9-2014

24 Settembre 2014

I formati per lo scambio dei dati sono semantici? Certamente: esprimono dei concetti e le relazioni tra questi concetti.

Principali formati: XML e JSON.

Significato

La semantica di un XML è data, in qualche misura, dalla posizione nell’albero sintattico  di una entità, dal nome di questa entità, dai suoi attributi, e a volte dai nodi dello stesso livello. Ovvero:

Significato di un valore si deduce da:

  1. nome entità
  2. nome attributo/i
  3. valore degli attributi/o dell’entità
  4. valore di un entità presente nell’albero sintattico allo stesso livello.

La semantica di un JSON è solitamente deducibile dal nome della proprietà dell’oggetto rappresentato, oltre che dalla posizione in cui si trova l’oggetto all’interno dell’albero sintattico. Cioè

Significato di valore si deduce da:

  1. Nome proprietà
  2. Significato dell’oggetto contenente quella proprietà

e così ricorsivamente si definisce ha il significato di un valore come la concatenazione di significati dei nodi antenati nell’albero JSON.

Struttura e validazione: lo schema

Oltre a questo ci sono, o meglio ci dovrebbero essere, delle limitazioni sui tipi che un valore può assumere e sulla struttura che l’informazione può assumere.

Questo è vero per l’XML, cioè per l’XML non solo sono stati definiti dei linguaggi grazie ai quali si può definire la struttura e i tipi di dato al quale lo stream deve aderire, ma nell’xml stesso che contiene i dati si può indicare una risorsa web dove poter prendere la definizione di queste limitazioni. Si dice che l’XML è valido se aderisce alla definizione indicata in se stesso. Sono stati definiti diversi formati per definrie la struttura e i tipi di dato ammissibili:

  1. W3C XML Schema (o XSD)
  2. RELAX NG (XML syntax)
  3. RELAX NG compact syntax
  4. XML 1.0 DTDs

Penso di averli elencati in ordine di importanza, almeno per me, l’xsd definition è quella che generalmente viene fornita quasi sempre, e c’è in giro un gran numero di validatori per riconoscere se un xml è conforme. La DTD è stata la prima formalizzazione di un data type, non molto fortunata perché utilizzava un formato a parte e non un xml valido. Appunto il vantaggio della XSD è quello di poter essere trattato dallo stesso parser xml. RELAX NG è supportato da un discreto numero di validatori, ma secondo me non ha nessun vantaggio se non quello di aver traghettato verso l’affermazione dell’XSD come standard.

Non è vero per il formato JSON dove tutto è libero, ammeno che non ci si avvalga di progetti attualmente poco considerati:

  1. http://json-schema.org/ e il progetto https://github.com/json-schema/json-schema
  2. http://www.jsonschema.net/

iniziative apparentemente scorrelate, ma fanno effettivamente riferimento ad una bozza per la standardizzazione http://tools.ietf.org/html/draft-zyp-json-schema-04 (la quarta revisione è del 31 gennaio 2013). Il documento IETF nella terza revisione portava questo titolo “A JSON Media Type for Describing the Structure and Meaning of JSON Documents“, mentre nella quarta revisione un più scarno “JSON Schema: core definitions and terminology“. Il titolo della terza revisione da peso all’aspetto semantico dello schema, cioè dice, già dal titolo, che json schema da significato al dato in formato JSON.

Validazione come type checking

D’altra parte JSON è un acronimo che sta per JavaScript Object Notation, inoltre un validatore di formato JSON è in qualche maniera un validatore di oggetto javascript, e un validatore di oggetto altro non è che uno strumento di type checking all’interno del linguaggio javascript, linguaggio molto fluido e lascamente tipizzato. Qualcosa che fa la validazione di un oggetto è tcomb:

https://github.com/gcanti/tcomb

Il vantaggio di tcomb rispetto a json schema è l’essere tipizzato in modo molto vicino alla tipizzazione Javascript, anche se questo dal punto di vista del gruppo IETF è considerato uno svantaggio, in realtà un aspetto importante è l’introduzione di enum, un concetto del tutto analogo è nel xsd per xml e permette di dare delle restrinzioni precise ai dati.

Lo svantaggio è che la definizione di un tipo di dato non è essa stessa un JSON, ma a questo credo si possa ovviare con qualche adattamento.

Scambio dati o “advanced programming interface”

Internet e servizi, servizi ed interfacce tramite i quali usufruirne. https://www.mashape.com/ è un servizio dove poter registrare la propria API e monetizzare il servizio offerto. Tipicamente il formato col quale ci si intefaccia ad un servizio sta diventando via via sempre più JSON+OAuth e sempre meno XML/SOAP. Il formato è sicuramente più semplice e leggibile, inoltre è facilmente interpretabile, ma lo svantaggio è non avere una definizione di schema altrettanto espressiva quanto lo è XSD. La documentazione viene fornita in formati non fortemente strutturati, mentre xsd permette di generare la documentazione all’interno della definizione stessa dello schema utilizzando elementi opportuni che non fanno parte della definizione (annotazioni), generando quindi un ipertesto che documenta la definizione di schema stessa.

È possible fare la stessa cosa col JSON? http://jsonapi.org/ questo fa qualcosa a riguardo, sembra.

Ma come convertire da XML a JSON?

usando questi 7 pattern: http://www.xml.com/pub/a/2006/05/31/converting-between-xml-and-json.html ?

Come convertire da JSON a XML

Ci sono diversi approcci

JSON e RDF

è possibile esprimere relazioni tra dati in formato json: http://en.wikipedia.org/wiki/JSON-LD

Ma è possibile fare le query usando SPARQL su un db di JSON-LD, sembra http://lists.w3.org/Archives/Public/public-linked-json/2012Jul/0043.html che sia stato almeno discusso

Cosa è SPARQL

PREFIX foaf: <http://xmlns.com/foaf/0.1/>
    SELECT *
    WHERE {
        ?x foaf:name "Gregg Kellogg";
             foaf:knows ?y .
       ?y foaf:name ?n .
    }

Un linguaggio per fare deduzioni a partire da una base di conoscenza espressa con un linguaggio semantico (un linguaggio formale che esprime la conoscenza). Quella sopra ad esempio restituisce tutte le conoscenze (knows) di Gregg Kellogg.

E sarebbe figo avere la stessa cosa senza scrivere in XML ma in JSON. Sì sarebbe figo.

RDF e RDFa

RDF è definito in XML, mentre RDFa utilizza i namespaces per integrare informazioni semantiche all’interno dell’albero XML (che può essere xhtml, appunto una pagina web)

JSON-LD

JSON Linked Data è un formato per la rappresentazione di triple basato su JSON invece che RDF o RDFa. Esenoio di integrazione in una pagina web:

Embedding JSON-LD in HTML
<script type="application/ld+json">
{
  "@context": "http://json-ld.org/contexts/person.jsonld",
  "@id": "http://dbpedia.org/resource/John_Lennon",
  "name": "John Lennon",
  "born": "1940-10-09",
  "spouse": "http://dbpedia.org/resource/Cynthia_Lennon"
}
</script>

questo per esprimere il corrispondente microdata (rif. http://www.w3.org/TR/json-ld/ sez. 6.20)

API per gestire le conoscenze

Per OWL c’è https://github.com/owlcs/owlapi per un programmatore è utilissima questa presentazione: http://owlapi.sourceforge.net/owled2011_tutorial.pdf

Mentre è possibile fare delle query con SPARQL tramite Hydra http://www.hydra-cg.com/ . Ed Hydra funziona sia con rdf sia con JSON-LD

Come pubblicare una propria API

Come rendere pubblica una API JSON? usando uno standard http://apisjson.org/

Tools JSON

la risorsa definitiva: http://jsonauts.github.io/

Per il front-end, interessante i template http://www.jsonml.org/

Per fine http://www.programmableweb.com/ ha un blog molto aggiornato sul semantic web e costruzione di API


Posted

in

,

by

Tags: