Vysoká škola ekonomická v Praze. Strukturovaná data na webu: Srovnání Linked Data a webových API

Transkript

1 Vysoká škola ekonomická v Praze Fakulta informatiky a statistiky Katedra informačního a znalostního inženýrství Strukturovaná data na webu: Srovnání Linked Data a webových API Bakalářská práce Student: Jan Zemánek Vedoucí práce: doc. Ing. Vojtěch Svátek, Dr. Praha 2011

2 Abstrakt česky Účelem této práce je nejdříve teoreticky popsat dvě v současnosti populární metody pro zpřístupňování strukturovaných dat na webu webová API a Linked Data a následně provést teoretické srovnání obou technik. Přínosem práce je tabulka srovnání a podrobné zpracování jednotlivých položek, přes které bylo srovnání webových API a Linked Dat provedeno. V závěru práce je vynesen verdikt, která z obou technik umožňuje z technologického hlediska lepší znovupoužití dat, jež jsou jejím prostřednictvím na webu vystavena.

3 Abstract in English The aim of this work is, firstly, to describe the two popular ways of making structured data accessible on the Web, namely Web APIs and Linked Data; secondly, it is to conduct a theoretical survey of features of each of these two techniques. The contribution of this work lays in a table comparing Web APIs and Linked Data and a detailed description of each of the items in the table. In conclusion, this work gives a verdict on which one of these two techniques leads from a technological point of view to more reusable data on the Web.

4 Prohlášení Prohlašuji, že jsem bakalářskou práci na téma [Strukturovaná data na Webu: Webová API a Linked Data] vypracoval samostatně. Použitou literaturu a další podkladové materiály uvádím v přiloženém seznamu literatury. V Praze dne... června Podpis studenta

5 Poděkování Rád bych zde tímto poděkoval vedoucímu mé bakalářské práce doc. Ing. Vojtěchu Svátkovi, Dr. a rodičům za jejich podporu a trpělivost.

6 Obsah 1 Úvod Linked Data Úvod Linked Data principy Identifikujte zdroje pomocí URI Používejte HTTP URI, aby se zdroje daly vyhledat na webu Při HTTP požadavku na danou URI poskytněte RDF reprezentaci zdroje Reprezentace by měla obsahovat odkazy na související zdroje Technologie RDF RDF serializace N-Triples serializace: Turtle serializace Grafový datový model RDF RDF je tzv. samopopisné Spojování RDF grafů SPARQL Porovnávání grafů Ukázkový SPARQL dotaz SPARQL endpoint Ontologie Ontologické jazyky RDFS Třídy a vlastnosti Definiční obory a obory hodnot vlastností Subsumpce tříd a vlastností OWL Předpoklad neunikátních jmen Předpoklad otevřeného světa Příklady ontologií DBpedia Webová API Terminologie Definice webových služeb a API

7 7.2.1 Webová služba Webové API Vývoj webových API XML Webové Služby Webová API Technologie URI HTTP XML JSON Dělení webových API Richardsonův model dospělosti webových API RPC API Hybridní RPC-REST API Pragmatická REST API Plnohodnotná REST API Srovnání Datový model Rozhraní Globálně unikátní identifikátory Dereferencovatelné identifikátory Rozlišení zdroje a jeho reprezentace Odkazy Ekvivalentnost zdrojů Objevitelnost dat Znovupoužívání schémat (ontologií) Odvozování Generické procházení Indexovatelná data Distribuované dotazování Dotazování dat Integrace dat z různých zdrojů (mashupy) Identifikace aplikace Dump

8 11.18 Programovací knihovny Seznámenost programátorů s technologií Licencování dat Závěr Literatura

9 1 Úvod Nejlepší způsob využití vašich dat vymyslí někdo jiný. 1 - Rufus Pollock, ředitel Open Knowledge Foundation Přibližně od roku 2005 můžeme na webu pozorovat rostoucí ochotu provozovatelů webových aplikací a jiných vlastníků strukturovaných dat sdílet tyto data s ostatními. Do velké míry je tento fenomén spjat s tzv. Webem 2.0, tj. vlnou webových aplikací, které umožňují uživatelům vytvářet vlastní obsah na webu, např. Wikipedia 2, Flickr 3, Delicious 4, atd. a v poslední době se sociálními sítěmi jako je Facebook 5 a Twitter 6. Uživatelé, kteří přispívají daty do těchto aplikací přirozeně očekávají, že jim daná aplikace poskytne k těmto datům přístup. Webové aplikace poskytují přístup k těmto datům vesměs prostřednictvím webových API. Webová API nejsou nová technologie, nýbrž nový přístup k využívají již existujících technologií webu URI, HTTP, XML a v poslední době stále častěji JSON. Dá se říci, že webová API jsou zdola nahoru řešením problému zpřístupňování strukturovaných dat na webu. Webová API ale nejsou jediným způsobem zpřístupňování strukturovaných dat na webu. Přibližně ve stejné době, kdy se začala rozšiřovat webová API, v roce 2006, se objevila tzv. Linked Data. Linked Data je metoda pro zveřejňování strukturovaných dat na webu pomocí standardu RDF a ontologií. Linked Data narozdíl od webových API představují shora dolů řešení problému sdílení strukturovaných dat. Linked Data totiž využívají technologií, které byly navrženy speciálně pro tento účel. Linked Data se v současné době také prosazují především v komunitě, která funguje shora dolů a to ve veřejné správě, kde se Linked Data využívají pro zpřístupňování tzv. otevřených vládních dat. Popularita klíčových slov REST API a Linked Data ve vyhledávání na Google (Zdroj: Google Insight 7 ) Cílem této práce je prostřednictvím srování obou technik zjistit, jaké jsou výhody a nevýhody každé z nich a pokusit se odpoveďet na otázku jaký přístsup vede ke znovupoužitelnějším datům. Práce se dělí na tři části, první část o Linked Data a druhou o webových API, které se pokoušejí popsat obě techniky zpřístupňování strukturovaných dat na webu. Třetí část se zabývá srovnáním obou přístupů. Stěžejní je v tomto ohledu tabulka srovnávající webová API a

10 Linked Data přes 20 položek. Tabulka je v další části podrobně vysvětlena pro každou položku zvlášť. Ze srovnání jsou ovozeny odpovívající závěry. 5

11 2 Linked Data Představuji si, že jednou bude na webu všechno propojeno se vším. - Tim Berners-Lee, autor World Wide Webu [2] 2.1 Úvod World Wide Web zásadním způsobem proměnil, jak sdílíme a získáváme informace. Web vytváří globální informační prostor, který abstrahuje od sítí a počítačů, které zpřístupňují webové stránky. Hypertextové odkazy nám umožňují procházet webem ze stránky na stránku a webovým vyhledávačům tzv. crawlovat, indexovat a počítat relevantnost webových stránek. Ćím více odkazů na stránku směřuje, tím spíše se k ní "proklikáme" a tím vyšší relevantnost má ve výsledcích vyhledávání ve vyhledávačích. Za to, že můžeme webem plynule procházet a stroje jej mohou snadno crawlovat a indexovat, vděčíme architekturě webu. Navzdory úspěchu World Wide Webu, jsme donedávna neaplikovali stejnou architekturu také na strukturovaná data. Linked Data jsou o využití webové architektury pro vystavování a propojování strukturovaných dat z heterogenních datových zdrojů (relačních databází, CSV, Excel, XML souborů, webových API, atd.). Data vystavená na webu jako Linked Data jsou strojově zpracovatelná, mají formálně definovaný význam a jsou propojená sémantickými odkazy. Linked Data vytváří globální informační prostor, tzv. web dat. Přesněji: Graf věcí z reálného světa popsaný daty na webu. [5] Web dat (Linked Open Data Cloud) tak jak vypadal v roce 2009 (Zdroj: Richard Cyganiak a Anja Jentzsch 1 ) 1 6

12 Za Linked Data stojí předpoklad, že čím více jsou data propojena s jinými daty, tím jsou užitečnější. Tim Berners-Lee tvrdí, že hodnota dat je do velké míry funkcí toho, na jaká data odkazují. [3] Linked Data mění, jak objevujeme, přistupujeme k, integrujeme a používáme data. Linked Data jsou o sdílení a znovupoužívání dat v globálním měřítku. Linked Data standardizují datový model (RDF), systém identifikátorů (HTTP URI), vyhledávací mechanismus (dereferencovatelná HTTP URI) a integrační mechanismus (spojování RDF grafů). Linked Data jsou souhrn doporučení (tzv. Linked Data principy) pro zveřejňování strukturovaných dat na webu. Linked Data definoval Tim Berners-Lee v roce 2006 v poznámce Linked Data. [3] 2.2 Linked Data principy Linked Data principy jsou čtyři jednoduchá pravidla, kterými by se Linked Data měla řídit: [16] 1. Identifikujte zdroje pomocí URI. 2. Používejte HTTP URI, aby se zdroje daly vyhledat na webu. 3. Při HTTP požadavku na danou URI poskytněte RDF reprezentaci zdroje. 4. Reprezentace by měla obsahovat odkazy na související zdroje Identifikujte zdroje pomocí URI. URI (angl. Uniform Resource Identifier) jsou globálně unikátní identifikátory, které umožňují jednoznačně identifikovat jakýkoli zdroj. Na jednoznačně identifikované zdroje lze snadno odkazovat. Identifikátory URI by měly být perzistentní. Tzn. měly by mít v každém okamžiku stejný tvar a být trvale dostupné. Přestože URI identifikuje právě jeden zdroj, tentýž zdroj může být identifikován několika různými URI. Linked Data jsou totiž založena na tzv. předpokladu neunikátních jmen (angl. nonunique name assumption), který připouští existenci více URI pro jeden zdroj Používejte HTTP URI, aby se zdroje daly vyhledat na webu. S URI se pojí tzv. dereferencování. Dereferencování je proces získání reprezentace zdroje pomocí jeho URI. V procesu dereferencování dochází k přechodu z URI zdroje, na URL reprezentace zdroje. URI mohou být dereferencována např. prostřednictvím HTTP protokolu. HTTP URI jsou na rozdíl od jiných typů identifikátorů jednoduše dereferencovatelná, protože v roli překladače je zavedený systém doménových jmen (DNS). Díky tomu jsou URI univerzálně přístupná Při HTTP požadavku na danou URI poskytněte RDF reprezentaci zdroje. Při zaslání HTTP požadavku na URI identifikátor zdroje by měl server vrátit RDF reprezentaci daného zdroje. S tím, že je možné pomocí tzv. vyjednávání o obsahu (angl. content negotiation) si vyjednat preferovanou serializaci RDF. Reprezentace zdroje by měla obsahovat data o zdroji samotném, ale ideálně také metadata o reprezentaci. Součásí takových metadat může být licence dat, autor dat nebo datum vzniku dat, odkaz na SPARQL endpoint a nebo na RDF soubor, který popisuje celý dataset, jehož je daný zdroj součástí. 7

13 2.2.4 Reprezentace by měla obsahovat odkazy na související zdroje. Reprezentace zdroje by měla obsahovat odkazy na URI logicky souvisejících zdrojů z externích datasetů. To umožní klientům plynule procházet mezi zdroji a napříč datasety. 3 Technologie Linked Data layer cake (Adaptováno z: W3C 1 ) Linked Data layer cake je vyobrazení technologií, které využívají Linked Data. Začneme-li odspodu těmito technologiemi jsou URI/IRI identifikátory (pozn. IRI je URI kódované v Unicode 2 ). XML, protože RDF/XML, jediná standardizovaná serializace RDF, je založena na XML. Dále je to samotný datový model RDF a ostatní jeho serializace (jako např. Turtle, N3, N-Triples, atd.). Nad RDF je RDFS a OWL. RDFS je jazyk pro vytváření jednoduchých RDF schémat, umožňuje definovat třídy a vlastnosti zdrojů a jejich hierarchie. OWL je expresivnější alternativa k RDFS, je založen na deskripční logice a dovoluje vytvářet komplexnější doménové modely. Vedle ontologických jazyků RDFS a OWL je SPARQL, dotazovací jazyk pro RDF. SPARQL vyhodnocuje dotazy nad RDF na principu tzv. porovnávání grafů (angl. graph pattern matching). Úplně nahoře je uživatelské rozhraní a aplikace, které s Linked Daty provádí něco užitečného. 4 RDF Datový model RDF reprezentuje informace jako orientovaný graf s pojmenovanými hranami. RDF je speciálně navrženo pro výměnu dat s bohatou sémantickou strukturou a integraci dat z různých zdrojů, rozdílných datových modelů a schémat. RDF aspiruje na to stát se linguou francou pro sdílení různorodých dat na webu. RDF (Resource Description Framework) je datový model pro popis distribuovaných zdrojů na webu. Základní jednotkou RDF je tzv. tvrzení (angl. statement), neboli trojice (angl. triple). Tvrzení vyjadřuje nějaký fakt o zdroji. Zdrojem (angl. resource) může být věc z reálného světa RFC 3987: International Resource Identifiers (IRIs) 8

14 (např. člověk, místo, atd.), abstraktní koncept (např. událost), nebo webová stránka, atd. Tvrzení se skládá ze tří částí, které dohromady tvoří jednoduchou větu: subjekt predikát objekt 1. <Hobit> <má rok vydání> <Hobit> <má autora> <J. R. R. Tolkien> Subjekt je zdroj (např. <Hobit>), o kterém něco tvrdíme, predikát specifikuje, co tvrdíme (např. <má rok vydání> nebo <má autora>) a objekt je buď (1) hodnota (tzv. literál), kterou predikát přiřazuje subjektu (např ), nebo (2) odkaz na jiný zdroj (např. <J. R. R. Tolkien>). RDF trojice (Zdroj: DevX.com 1 ) Zdroje jsou v RDF identifikovány pomocí URI. Hobit a J. R. R. Tolkien jsou např. identifikováni následujícími HTTP URI: < a < Predikáty, kterými popisujeme zdroje, pochází z tzv. schémat (jinak také slovníků, nebo ontologií). Vlastnosti (predikáty) jsou stejně jako zdroje identifikovány pomocí URI. Vlastnost <má autora> se nachází např. ve schématu Dublin Core (DC) a je identifikována následujícím HTTP URI: < Výše uvedený příklad (2) můžeme v tzv. Turtle syntaxi vyjádřit např. takto: dbpedia:the_hobbit dc:creator dbpedia:j._r._r._tolkien Podíváme-li se na definici vlastnosti dc:creator do dokumentace k DC schématu, dozvíme se, že: Creator (tvůrce) je entita primárně zodpovědná za vznik zdroje, např. člověk, organizace nebo služba. Takže jsme tuto vlastnost použili správně. 4.1 RDF serializace RDF můžeme zapsat pomocí několika různých syntaxí (serializací). Standardizovanou syntaxí pro RDF je XML v tzv. RDF/XML. RDF/XML syntaxe je poměrně něpřehledná a proto ne příliš vhodná ke čtení nebo ručnímu zápisu RDF dat. Pro tyto účely vznikla zjednodušená syntaxe 1 9

15 Turtle, která využívá jmenné prostory s prefixy. Dalšími syntaxemi jsou N3 (N3 je nadmnožinou Turtle a RDF samotného, umožňuje totiž vyjadřovat navíc pravidla, atd.), minimalistická N- Triples, která je naopak podmnožinou Turtle (neumožňuje zkrácený zápis prostřednictvím prefixů) a RDF data serializuje jako celé trojice. RDF lze také vložit do HTML pomocí RDFa (RDFin-attributes) a zapsat v JSON (JavaScript Object Notation) pomocí JSON-LD 1 (JSON for Linked Data). Následující dva příklady ilustrují zápis RDF v syntaxi N-Triples, na níž je dobře vidět struktura RDF (RDF trojice), a v kompaktní lidsky čitelné syntaxi Turtle. Data v obou příkladech popisují knížku Hobit od J. R. R. Tolkiena. Trojice byly vybrány z RDF reprezentace Hobita v DBpedii (o DBpedii více dále). Data nejdříve říkají, že zdroj < který identifikuje Hobita, patří ke třídě < tedy že se jedná o knihu. Kniha má jmenovku The Hobbit, která je v angličtině a celý název The Hobbit, or There and Back Again, který je opět v angličtině. Autorem knihy je zdroj < který reprezentuje J. R. R. Tolkiena. Další trojice tvrdí, že Hobit vyšel poprvé v roce 1937, a že 1937 je číslo (< Kniha má 310 stránek a 310 je opět číslo. Hobit patří k žánru dětská literatura (< Zdroj < je totožný se zdrojem z Freebase (o Freebase více dále) s HTTP URI < to identifikuje Hobita ve Freebase databázi N-Triples serializace: < < < < < "The Hobbit"@en. < < "The Hobbit, or There and Back Again"@en. < < < < < "1937"^^< < < "310"^^< < < < < < < Turtle rdf: xsd: rdfs: owl: dc: foaf: dbpedia: dbpprop: dbpedia-owl: < dbpedia:the_hobbit rdf:type dbpedia-owl:book;

16 rdfs:label "The foaf:name "The Hobbit, or There and Back dc:creator dbpedia:j._r._r._tolkien; dbpprop:releasedate "1937"^^xsd:int; dbpedia-owl:pages "310"^^xsd:int; dbpedia-owl:genre dbpedia:children%27s_literature; owl:sameas < 4.2 Grafový datový model RDF Graf je dostatečně obecná datová struktura, tak že dokáže vyjádřit všechny ostatní datové struktury, jako např. relační model, CSV, Excel-ovské tabulky, XML, UML, atd. Graf je také velmi flexibilní datová struktura, grafová data mohou být snadno rozšířena o další data v jiném schématu (narozdíl od např. relačního modelu, který vyžaduje změnu databázového schématu). Grafový datový model je z tohoto důvodu vhodný pro data, která se často mění. Jinou vlastností grafového datového modelu je, že graf je pro člověka přirozená struktura. Člověk přemýšlí v konceptech a jejich asociacích a ne např. v normalizovaných relačních tabulkách. 4.3 RDF je tzv. samopopisné Samopopisnost RDF souvisí s tím, že v RDF datovém modelu je predikát tzv. občanem první kategorie. Tzn. že predikát je součástí RDF dat. Narozdíl např. od relačního modelu, kde relační schéma a relační data existují odděleně. Díky této vlastnosti se RDF data někdy označují jako tzv. sémantická data. RDF trojice obsahuje subjekt, predikát a objekt. Predikát je stejně jako subjekt a objekt identifikován pomocí URI, v případě Linked Data tzv. dereferencovatelným HTTP URI. Tj. URI, které lze vyhledat na webu a které nás dovede ke schématu a definici dané vlastnosti (predikátu) v tomto schématu. Např. pokud provedeme HTTP GET požadavek na HTTP URI < vlastnosti <má autora> z DC schématu, dostaneme v HTTP odpovědi definici tohoto schématu, která obsahuje definici vlastnosti dc:creator: < rdf:type rdf:property; rdfs:label "Creator"@en-US; rdfs:comment "An entity primarily responsible for making the resource."@en-us; dcterms:description "Examples of a Creator include a person, an organization, or a service."@en-us; dcterms:issued " "; dcterms:modified " "; dcterms:hasversion < rdfs:isdefinedby < Druhým aspektem samopopisnosti RDF je fakt, že schémata se vyjadřují také v RDF. Lze s nimi tudíž pracovat stejně jako s obyčejnými RDF daty. Díky tomu se lze např. dotazovat zároveň dat a jejich schémat(u). 4.4 Spojování RDF grafů Největší předností RDF je přímočará integrace RDF dat z více zdrojů, tzv. spojování RDF grafů. To je možné díky tomu, že RDF pro identifikaci zdrojů využívá URI, která jsou globálně unikátní. 11

17 RDF grafy se spojují napříč shodnými URI. Dva zdroje se shodným URI ve dvou různých grafech identifikují tentýž zdroj. Máme-li např. dva grafy a oba obsahují zdroj dbpedia:berlin, můžeme je přes tento zdroj propojit. Spojením dvou dikrétních grafů vzniká jeden větší kompaktní graf. Dva různé RDF grafy (černý a červený) obsahující shodný zdroj dbpedia:berlin: RDF graf vzniklý spojením předchozích dvou grafů přes zdroj dbpedia:berlin: [4] Dohromady nám URI jako globálně unikátní identifikátory a RDF datový model umožňují integrovat data z různých zdrojů na webu. 5 SPARQL SPARQL (SPARQL Protocol and RDF Query Language) je deklarativní dotazovací jazyk pro RDF. SPARQL je navržen tak, aby se podobal dotazovacímu jazyku SQL (podobnost měla usnadnit přechod ke SPARQLu). Kromě toho je to však také protokol pro komunikaci mezi klientem a tzv. SPARQL endpointem (o SPARQL endpointech více dále) a XML formát pro serializaci výsledků dotazů. SPARQL pracuje na principu tzv. porovnávání grafů (angl. graph pattern matching). 5.1 Porovnávání grafů 12

18 Porovnávání grafů je nejlépe vysvětlit na porovnávání obyčejných trojic. Mějme následující RDF data (trojice), které tvrdí, že Frodo Baggins (hlavní postava Tolkienova Pána prstenů) zná (foaf:knows) Bilbo Bagginse, Gandalfa, Sama (dbpedia:samwise_gamgee), Merryho (dbpedia:meriadoc_brandybuck) a Pippina (dbpedia:peregrin_took): dbpedia:frodo_baggins foaf:knows dbpedia:bilbo_baggins. dbpedia:frodo_baggins foaf:knows dbpedia:gandalf. dbpedia:frodo_baggins foaf:knows dbpedia:samwise_gamgee. dbpedia:frodo_baggins foaf:knows dbpedia:meriadoc_brandybuck. dbpedia:frodo_baggins foaf:knows dbpedia:peregrin_took. Chceme-li seznam všech přátel Frodo Bagginse, stačí, když z výše uvedených dat vybereme všechny trojice, které mají Frodo Bagginse (dbpedia:frodo_baggins) na pozici subjektu a vlastnost zná (foaf:knows) jako predikát. Objekt je v tomto případě proměnná. Do proměnné bude přiřazena hodnota, která vyhovuje tzv. vzoru trojice (angl. triple pattern). Vzor trojice by v našem případě vypadal: dbpedia:frodo_baggins foaf:knows?friend Ve SPARQLu jsou proměnné uvozeny otazníkem (?friend). Vyhodnotíme-li dotaz nad našimi RDF daty, proměnné?friend bude přiřazeno pět zdrojů. Všech pět zdrojů vyhovuje vzoru trojice a konstituuje tak řešení dotazu (s). s = ((?friend dbpedia:bilbo_baggins), (?friend dbpedia:gandalf), (?friend dbpedia:samwise_gamgee), (?friend dbpedia:meriadoc_brandybuck), (?friend dbpedia:peregrin_took)) Nejobecnější (nejméně restriktivní) vzor trojice je?subject?predicate?object Tento vzor vybere v jakýchkoli RDF datech všechny trojice. 5.2 Ukázkový SPARQL dotaz Dotaz, který najde všechny postavy, které se objevily v Hobitovi a zároveň v Pánovi prstenů. PREFIX rdf: < PREFIX yago: < SELECT?character WHERE {?character rdf:type yago:charactersinthehobbit.?character rdf:type yago:charactersinthelordoftherings. } řešení s = ((?character dbpedia:bilbo_baggins), (?character dbpedia:gandalf), (?character dbpedia:gollum), (?character dbpedia:elrond)) 13

19 5.3 SPARQL endpoint SPARQL endpoint je v podstatě vstupní bod do (RDF) databáze, má přiřazenu URL a lze na něj přistupovat z webu. Na endpoint se SPARQL dotazy posílají prostřednictvím HTTP metody GET, nebo POST. Přesný způsob komunikace se SPARQL endpointem je popsán ve SPARQL protokolu 1, který zároveň specifikuje, v jaké podobě endpoint vrací výsledky vyhodnocení dotazu nad databází. SPARQL endpointy jsou zvláště vhodné pro velké datasety, kde stahovat RDF dump do lokální databáze by bylo časově náročné. Na webu dnes existuje asi 180 funkčních SPARQL endpointů. 2 Např. DBpedia SPARQL endpoint dostupný na adrese 6 Ontologie Ontologie je původně pojem z filozofie, kde označuje tzv. nauku o bytí (resp. jsoucnu), o světě tak jak objektivně je. Ontologie ve filozofickém pojetí zkoumá otázky klasifikační povahy, tj. jaké třídy jsoucen existují a jaké jsou mezi nimy vztahy. [12] V informatickém pojetí je ontologie informační artefakt, který modeluje zájmovou (problémovou) doménu. Ontologie definuje koncepty a vztahy, které v modelované doméně existují. Ontologie se skládají ze čtyř základních prvků: tříd, vlastností, relací a individuí (angl. individuals). Existuje několik pokusů o definici pojmu ontologie. Uveďme si dvě nejznámnější. První je od Toma Grubra, jednoho z duchovních otců ontologií, z roku 1993: Ontologie je explicitní specifikace konceptualizace. Druhá je rozšířením Grubrovi definice a pochází od Willema Borsta, ten v roce 1997 ontologii definoval jako: formální specifikaci sdílené konceptualizace. Gruber požaduje pouze, aby konceptualizace (systém konceptů definujících určitou doménu) byla specifikována explicitně, tj. nikoliv jen skryta v hlavě svého autora. Borst přídává požadavek, aby ontologie byla vyjádřena pomocí formálního jazyka (tj. jazyka s přesně definovanou syntaxí, případně i sémantikou). Dále by podle Borsta měla být ontologie sdílená. Ontologie by neměla být individuální záležitostí, ale výsledkem konsenzu zájmové skupiny lidí. Účelem ontologií je definovat sdílený a znovupoužitelný model zájmové domény, který usnadní porozumění mezi lidmi (např. odborníky, programátory, atd.) a podpoří interoperabilitu mezi různými systémy. [11] 6.1 Ontologické jazyky Schémata (ontologie), která se používají na webu dat, jsou definována jedním ze dvou ontologických jazyků RDFS a nebo v menší míře OWL. 6.2 RDFS RDFS, neboli RDF Schema (RDF Vocabulary Description Language), je nejjednodušší ontologický jazyk založený na RDF. RDFS umožňuje definovat třídy a vlastnosti, vztahy podřazenosti mezi třídami a vlastnostmi (taxonimie tříd a vlastností) a definiční obor a obor hodnot vlastností. Obsahuje předdefinované koncepty:

20 rdfs:class definuje třídu rdfs:property definuje vlastnost rdfs:subclassof definuje subsumpci mezi třídami rdfs:subpropertyof definuje subsumpci mezi vlastnostmi rdfs:domain definuje doménu vlastnosti rdfs:range definuje obor hodnot vlastnosti a několik dalších Třídy a vlastnosti V RDF může každý zdroj příslušet k nějaké třídě a nebo mít přiřazenu nějakou vlastnost. Že zdroj přísluší k nějaké třídě se vyjádří pomocí predikátu rdf:type. dbpedia:j._r._r._tolkien rdf:type foaf:person dbpedia:the_hobit dc:creator dbpedia:j._r._r._tolkien Sémantika třídy foaf:person a vlastnosti dc:creator je definována v ontologiích FOAF (Friend of a Friend) 1 a Dublin Core (DC). Definice třídy v RDFS je jednoduchá, stačí zdroj přiřadit ke zdroji rdfs:class. foaf:person rdf:type rdfs:class Definice třídy foaf:person v ontologii FOAF: foaf:person rdf:type rdfs:class; rdf:type owl:class; rdfs:comment "A person."; rdfs:isdefinedby foaf:; rdfs:label "Person"; rdfs:subclassof foaf:agent; owl:disjointwith foaf:document, foaf:organization, foaf:project. Výše uvedený úsek ontologie FOAF říká, že zdroj foaf:person je třídou v RDFS, a také třídou v OWL (o OWL více dále). Že foaf:person je podtřídou třídy foaf:agent, atd. Platí tedy např., že každý zdroj, který přísluší ke třídě foaf:person, patří také ke třídě foaf:agent Definiční obory a obory hodnot vlastností Pro specifikaci definičního oboru a oboru hodnot vlastností poskytuje RDFS vlastnosti rdfs:domain a rdfs:range. Ukažme si použití rdfs:domain a rdfs:range např. na definici vlastnosti rdf:type: rdf:type rdf:type rdfs:property; rdfs:label "type"; rdfs:comment "The subject is an instance of a class"; rdfs:domain rdfs:resource; rdfs:range rdfs:class; rdfs:isdefinedby < -ns#>;

21 Z uvedeného příkladu je vidět, že RDF a RDFS jsou definovány reflexivně. RDF je definováno v termínech RDFS a naopak. Vlastnost rdf:type je definována s využitím sebe samé (rdf:type rdfs:property;). Definičním oborem vlastnosti rdf:type je jakýkoli zdroj (rdfs:domain rdfs:resource;) a oborem hodnot je množina všech tříd (rdfs:range rdfs:class;). Definice na první pohled vypadá v pořádku, typ individua je totiž vždy třída (rdfs:class). Tj. zdroj, který se objevuje na pozici objektu v trojici, kde predikátem je rdf:type, je třída Subsumpce tříd a vlastností RDFS umožňuje definovat hierarchii tříd a vlastností. Třídy mohou být definovány jako podtřídy jiných tříd. K definici subsumpce tříd slouží vlastnost rdfs:subclassof. Např. foaf:person rdfs:subclassof foaf:agent Z výše uvedeného příkladu v RDFS vyplývá, že individuum, které přísluší ke třídě osoba (foaf:person), přísluší také ke třídě agent (foaf:agent). Podobně lze definovat podvlastnosti s využitím vlastnosti rdfs:subpropertyof. Můžeme např. definovat specializovanou vlastnost ex:bookauthor, která je podvlastností vlastnosti z Dublin Core schématu dc:creator. ex:bookauthor rdf:type rdfs:property; rdfs:subpropertyof dc:creator. Jestliže řekneme, že J. R. R. Tolkien je ex:bookauthor Hobita, z definice ex:bookauthor pak vyplývá, že J. R. R. Tolkien je také dc:creator Hobita. 6.3 OWL OWL (Web Ontology Language) je další ontologický jazyk založený na RDF. OWL je expresivnější alternativou k RDFS. Navíc k RDFS nabízí možnost definovat např. tzv. lokální omezení (existenční, univerzální a kardinalitní) nad vlastnostmi vztaženými ke specifické třídě, ekvivalentnost a disjunktnost tříd, nutné a postačující podmínky příslušnosti ke třídě, atd. [12] OWL se podle míry expresivnosti dělí na tři podjazyky (angl. sublanguages) OWL Lite, OWL DL a OWL Full. OWL Lite je nejjednodušší verze jazyka OWL, obsahuje jen základní konstrukce a je výpočetně nejméně náročný OWL DL (deskripční logika) představuje kompromis mezi expresivitou a výpočetní složitostí, je rozhodnutelný (tj. je zaručeno, že odvozovací nástroj provede všechna logická odvození v konečném čase) OWL Full je úplná verze jazyka OWL, neklade žádná omezení na to, jaké konstrukce mohou být použity (např. třídy mohou příslušet k jiným třídám). Nabízí maximální expresivitu, ale negarantuje rozhodnotelnost. OWL je založen na dvou poněkud neintuitivních předpokladech: (1) předpokladu neunikátních jmen (angl. non-unique name assumption) a (2) předpokladu otevřeného světa (angl. open world assumption). 16

22 Předpoklad neunikátních jmen a otevřeného světa jsou základní principy webu dat. Na webu dat předpokládáme, že lokální informace je neúplná. Někde na webu může totiž vždy existovat doplňující informace Předpoklad neunikátních jmen Předpoklad unikátních jmen je koncept z ontologických jazyků (např. Frames) a deskripční logiky. V logikách, kde platí předpoklad unikátních jmen, různá jména vždy označují různé zdroje. Ontologický jazyk OWL nepředpokládá unikátní jména. Nemůžeme tedy říci, že dva zdroje jsou různé jen proto, že mají různá jména (identifikátory). Máme-li dva zdroje např. zdroj identifikovaný HTTP URI a zdroj s HTTP URI nemůžeme jen na základě toho, že mají různá jména (identifikátory) usoudit, že jde o různé zdroje. Ve skutečnosti oba zdroje označují stejnou věc J. R. R. Tolkiena. První URI je identifikátor Tolkiena ve Freebase a druhá URI je Tolkienův identifikátor v DBpedii. OWL umožňuje explicitně říci, že dva zdroje jsou stejné, nebo různé. Že jsou zdroje stejné lze vyjádřit pomocí vlastnosti owl:sameas. Že jsou zdroje různé můžeme vyjádřit pomocí vlastnosti owl:differentfrom. V DBpedii existuje RDF trojice, která říká, že a označují stejnou věc: dbpedia:j._r._r._tolkien owl:sameas freebase:j_r_r_tolkien Předpoklad otevřeného světa Předpoklad otevřeného světa je koncept z formální logiky. Podle něj jsou naše znalosti neúplné a jakékoli tvrzení je potenciálně pravdivé. Tvrzení je nepravdivé jen pokud máme explicitní informaci o tom, že je nepravdivé. Víme-li např. že dbpedia:j._r._r._tolkien rdf:type dbpedia-owl:writer nemůžeme předpokládat, že Tolkien nebyl také básník (např. ex:poet). (Tolkien byl také básník.) Z neznalosti informace nemůžeme usuzovat na její nepravdivost (na tomto principu funguje např. SQL). Pokud nemáme explicitní informaci o tom, že Tolkien byl básník (nebo že jím nebyl), tak jednoduše nevíme, zda byl nebo nebyl také básník. 6.4 Příklady ontologií Příklady několika nejpoužívanějších ontologií na webu dat: [8] Dublin Core (DC) 1 definuje obecné metadatové vlastnosti jako titulek (dc:title), autor (dc:creator), datum (dc:date), předmět (dc:subject), atd. Firend of a Friend (FOAF) 2 definuje koncepty pro popis osob, jejich aktivit a jejich vztahů k jiným osobám a objektům GoodRelations 3 definuje koncepty pro popis produktů, služeb a dalších věcí relevantních pro e-komerci

23 Semantically Interlinked Online Communities (SIOC) 1 je navržen pro popis uživatelů a jejich příspěvků na weblozích, diskuzních fórech, atd. Basic Geo (WGS84) 2 definuje vlastnosti pro zeměpisnou šířku a délku pro popis geografické polohy věcí Music Ontology 3 definuje koncepty pro popis věcí souvisejících s hudbou jako umělci, alba, písně, atd. 6.5 DBpedia DBpedia 4 je nejdůležitější RDF dataset (zdroj dat) na webu. DBpedii tvoří strukturovaná data vyextrahovaná z tzv. infoboxů a kategorií z Wikipedie. Na DBpedii můžeme najít informace o tři a půl milionu věcí. Z těch je necelých osob, téměř půl milionu míst, sto tisíc hudebních alb, šedesát tisíc filmů, organizací, atd. DBpedia dále obsahuje přibližně šest a půl milinou odkazů do jiných datasetů. Dohromady DBpedii tvoří 672 milionu RDF trojic. Následující obrázek znázorňuje DBpedii a externí datasety, do kterých DBpedia odkazuje. Odkazy z DBpedie do externích datasetů (Zdroj: DBpedie 5 ) Na následující stránce je pro ilustraci uveden infobox z článku o J. R. R. Tolkienovi na Wikipedii ( a strukturovaná data, která z něj byla vyextrahována, převedena do RDF a vystavena jako součást DBpedie ( Data jsou zapsána v Turtle syntaxi

24 @prefix rdf: xsd: rdfs: owl: dc: foaf: dbpedia: dbpprop: dbpedia-owl: yago: < dbpedia:j._r._r._tolkien rdf:type owl:thing, foaf:person, dbpedia-owl:artist, dbpedia-owl:writer, yago:englishfantasywriters, yago:englishphilologists, yago:mythopoeicwriters, yago:translatorsfromoldenglish. owl:sameas < < rdfs:label "J. R. R. foaf:name "J. R. R. foaf:givenname "J. R. foaf:surname dc:description "British philologist and dbpedia-owl:birthdate " "^^xsd:date; dbpedia-owl:birthplace dbpedia:bloemfontein, dbpedia:orange_free_state; dbpedia-owl:deathplace dbpedia:bournemouth; dbpedia-owl:deathdate " "^^xsd:date; dbpedia-owl:occupation dbpedia:philology, dbpedia:academia; dbpedia-owl:genre dbpedia:fantasy, dbpedia:high_fantasy; dbpedia-owl:notablework dbpedia:the_hobbit, dbpedia:the_lord_of_the_rings, dbpedia:the_adventures_of_tom_bombadil, dbpedia:the_silmarillion, dbpedia:the_children_of_h%c3%barin; dbpedia-owl:spouse dbpedia:edith_bratt; dbpprop:caption "Tolkien, foaf:depiction < olkien_1916.jpg>. foaf:page < 19

25 7 Webová API [Webová] aplikace bez API je jako dům bez dveří. - Josh Walker, analytik Forrester Research Webová API 1 (v angličtině Web API) jsou druhem webových služeb. Webová API jsou založena na základních webových technologiích URI, HTTP a XML (případně jiných textových formátech JSON, YAML a dalších). Webová API se vymezují vůči Webovým Službám (angl. Web Services) vystavěným nad protokolem SOAP a vzdálenému volání procedur XML-RPC. Webová API zprostředkovávají vzdálený přístup k datům (např. Freebase API 2 ), funkcionalitě (např. Amazon S3 3 ) nebo vizualizaci (např. Google Maps API 4 ). Webová API jsou vhodná ke zpřístupňování strukturovaných dat, která se často mění a kde objem přenášených dat je omezený. API totiž poskytují data na požádání, a proto mohou poskytovat aktuální data (narozdíl od dumpů dat ke stažení). Webová API se často nesprávně označují jako tzv. RESTová API. RESTová API jsou však pouze speciálním (a poměrně přesně definovaným) případem webových API. Webové služby využívají řadu různých protokolů SOAP, XML-RPC, HTTP + textový formát (webová API), atd. Webová API využívají HTTP protokol, řadu různých textových formátů (XML, JSON, YAML, atd.) a schémat (Atom, RSS, atd., nebo proprietální schémata). 7.1 Terminologie Na úvod je potřeba si ujasnit termonologii, protože klíčové pojmy, které se vztahují k webovým API, jsou používány nekonzistentně a někdy vyloženě špatně. Klíčovými pojmy jsou: webová API, webové služby, Webové Služby (pozor na dvojitou kapitalizaci) a RESTová API. Webová API. Pojem webová API se používá ve dvou významech: 1. Webová API jako synonymum pro webové služby (např. katalog webových API ProgrammableWeb.com používá výraz webová API v tomto smyslu). 2. Webová API jako speciální kategorie webových služeb. A to taková, že webová API = webové služby - (Webové Služby + XML-RPC). 1API (Application Programming Interface), v češtině aplikační programové rozhraní

26 Dělení webových služeb (Zdroj: Autor) Webová API jsou takové webové služby, které nejsou implementovány ani jako Webové Služby (SOAP) ani pomocí protokolu pro volání vzdálených procedur XML-RPC. Webové služby. Webové služby (bez kapitalizace; angl. web services) jsou obecný termín. Označují typ softwarových komponent, k nimž lze přistupovat vzdáleně prostřednictvím World Wide Webu. Webové služby jsou implementovány buď jako webová API, nebo jako Webové Služby, a nebo pomocí protokolu XML-RPC. Webové Služby (SOAP). Pojem Webové Služby (s dvojitou kapitalizací; angl. Web Services) se používá podobně jako výraz webová API ve dvou významech: 1. Webové Služby jako rodina technologií SOAP, WSDL, atd. 1, které se využívají pro implementaci webových služeb (především v podnikovém prostředí). 2. Webové Služby jako webové služby implementované pomocí těchto technologií. RESTová API. (Alternativně RESTové webové služby) Tento pojem se často a nesprávně používá ve významu webových API. Např. katalog API ProgrammableWeb.com nesprávně používá RESTová API ve významu webových API. RESTová API jsou přesně definovanou kategorií webových API. API lze považovat za RESTové API v případě, že je navrženo v souladu s tzv. REST principy. 7.2 Definice webových služeb a API Webová služba Webová služba je softwarová komponenta, která umožňuje vzdálený přístup k nějaké funcionalitě nebo datům. Webové služby umožňují komunikaci mezi heterogenními systémy (operačními systémy a programovacími prostředími), napříč národními a organizačními hranicemi. Neomezená komunikace mezi systémy je možná díky překládání a přenášení dat v textových formátech dříve téměř výhradně v XML, dnes stále častěji v JSON

27 Webové služby jsou založeny na architektuře klient/server, kde klientem je webová nebo jiná aplikace. Klient pošle požadavek serveru (webové službě), ten jej zpracuje a zpět klientovi zašle odpověd s výsledkem. Aby mohla komunikace klient-služba proběhnout, musí klient vědět, jak službu zavolat a jak interpretovat její odpovědi. Jak se službou komunikovat je popsáno v dokumentaci a formálně-strojově vyjádřeno v popisu rozhraní služby, například ve WSDL (v případě SOAP) Webové API Webové API (aplikační programové rozhraní) je definováno množinou HTTP požadavků a formátů odpovědí, nejčastěji serializovaných v XML nebo JSON. 1 8 Vývoj webových API S vývojem webových služeb a API je nerozlučně spjata technologie XML. 8.1 XML XML (Extensible Markup Language) je značkovací meta-jazyk pro zápis značkovacích jazyků. XML je zjednodušená forma standardu pro zápis značkovacích jazyků z poloviny 80. let minulého století SGML (Standard Generalized Markup Language). Tim Berners-Lee se při tvorbě hypertextového značkovacího jazyka pro World Wide Web (HTML) v roce 1990 inspiroval právě SGML (do té míry, že HTML je aplikací SGML). HTML je omezený jazyk, jehož účelem je strukturovat hypertextové dokumenty (webové stránky). Na World Wide Webu však od začátku existovala potřeba sdílet dokumenty (data) s jinou než jen HTML sémantikou. Na Evropské konferenci o hypertextových technologiích v roce 1994 se poprvé diskutovala možnost adopce, respektive adaptace SGML pro web. V roce 1995 se SGML dostalo na seznam aktivit W3C a o rok později začal vývoj zjednodušené formy SGML speciálně pro web XML. W3C přijalo XML jako standard (doporučení) na začátku roku Webové Služby Webové Služby se poprvé objevují v roce Důvodem je fakt, že na začátku roku 1998 skončil vývoj a standardizace XML 1.0. Webové Služby využívají pro přenos zpráv právě XML. Webové Služby jsou založeny na stejné filozofii jako dřívější technologie pro vzdálené volání funkcí RPC, Corba nebo RMI (Remote Method Invocation). Stejně jako ony se webové služby snaží před programátorem skrýt, že volá metody napříč sítí (internetem). Nejdříve v roce 1998 vznikají XML-RPC a WDDX (Web Distributed Data Exchange). XML-RPC a WDDX se staly inspirací pro protokol SOAP (Simple Object Access Protocol). SOAP vytvořil v druhé polovině roku 1998 autor XML-RPC Dave Winer z Microsoftu. SOAP je jednoduchý, platformově nezávislý protokol pro posílání zpráv (angl. messaging protocol). Winer si pro návrh SOAP vypůjčil strukturu zpráv (obálka/hlavička/tělo) a nezávislost na transportní vrstvě (HTTP, SMTP, FTP, atd.) z WDDX a HTTP, jako hlavní transportní mechanismus a způsob zápisu volání metod, proměnných a jejich hodnot z XML-RPC. Microsoft kvůli vnitřním sporům zveřejnil SOAP až v roce SOAP si jako platformově nezávislé řešení pro integraci distribuovaných systémů získal přízeň IBM. IBM se na začátku roku 2000 připojilo k Microsoftu a obě společnosti začaly dohromady vyvíjet SOAP 1.1. Na podzim 2000 vznikla první specifikace WSDL. WSDL je na XML založený jazyk pro formalizovaný strojově-čitelný popis rozhraní webových služeb. Do konce roku 2000 oznámilo pět největších softwarových společností (Oracle, HP, Sun, IBM a Microsoft) podporu pro webové

28 služby založené na SOAP a WSDL. Webové služby (nyní již synonymum pro SOAP a WSDL) se staly de facto průmyslovým standardem. Vývoj a standardizaci webových služeb proto v roce 2000 převzalo W3C. Zatím poslední verze SOAP 1.2 pochází z roku Pod hlavičkou W3C vznikla řada dalších standardů pro webové služby (WS-*), které přidávají například autentizaci, zabezpečení a transakce. 8.3 Webová API Od roku 1993 je možné prostřednictvím CGI (Common Gateway Interface) předávat HTTP požadavky zaslané na server programu (skriptu), který běží na tomto serveru. Skripty umožňují dynamicky generovat webové stránky a jsou základem webových aplikací. Webové aplikace začínají na webu dominovat od poloviny 90. let, například vyhledávač AltaVista nebo jakýkoli CMS systém (systém pro správu obsahu). Webové aplikace jsou typicky vystavěny nad databází, ze které generují webové stránky stavy aplikace. Rozmach webových aplikací od roku 1995 byl umožňen standardizací URL na konci roku 1994 a HTML 2.0 (první standardizovaná verze HTML) o rok později. HTML 2.0 oproti předchozím verzím HTML přidalo značky pro formuláře. Standard URL definoval způsob ( dotazovací řetězec, angl. query string), jakým předávat v URL adrese parametry, které řídí běh skriptu na straně serveru. Formuláře a předávání parametrů v URL umožnily webovým aplikacím získávat data (vstupy) od uživatelů. Weboví programátoři od začátku zneužívali webové aplikace jako zdroj strukturovaných dat a funkcionality. Data a výsledky běhu skriptů však museli nejdříve získat z webových stránek takzvaným screen-scrapováním. Webový vizionář Jon Udell jako první popsal, jak používat webové aplikace (AltaVista a Yahoo!) jako on-line komponenty (webová API) ve svém článku On-Line Componentware v roce Udell v tomto článku načrtnul vizi, podle které webové stránky můžeme považovat za znovupoužitelné softwarové komponenty. V roce 1997 přednesl Andrew Schulman na Perl konferenci přednášku s názvem The Web is the API 1. Udell poprvé použil termín web API v článku Exploring XML-RPC 2 v roce Průkopníkem používání webových služeb se stal v roce 2001 ebay.com. Následovaný o rok později Amazonem. Rozmach Webových Služeb a webových API nastal ale zejména po roce S tím, že webová API postupně vystačila Webové Služby. Webová API jsou totiž daleko jednodušší než těžkopádné Webové Služby a na webu obvykle vítězí jednoduchost. Převahu API nad službami lze dokumentovat pomocí trendu vyhledávání API a služeb např. na Googlu: Web sites that support CGI-based services implicitly define what I call Web APIs. 23

29 Popularita klíčových slov REST API a SOAP web services ve vyhledávání na Google (Zdroj: Google Insight 1 ) Z grafu je dobře vidět, že Webové Služby (SOAP web services ) postupně ztrácí na popularitě, zatímco webová API (REST API) naopak získávají. Webová API předstihla v popularitě Webové Služby na začátku roku Další zajímavý graf pochází z katalogu webových API ProgrammableWeb.com 2. Graf znázorňuje kumulovaný počet API, která jsou na ProgrammableWeb.com registrována. V době psaní této práce jich bylo Z vývoje křivky můžeme usuzovat, že počet API roste exponenciálně. Celkový počet webových API v katalogu ProgrammableWeb.com (Zdroj: ProgrammableWeb.com) 9 Technologie Webová API staví na dobře známých technologiích webu URI (URL), HTTP, XML a novějším JSON a případně dalších formátech jako např. YAML URI

30 URI (Uniform Resource Identifier) je obecné schéma pro identifikaci zdrojů. Konkrétní instancí URI je textový řetězec, který pojmenovává, resp. identifikuje nějaký zdroj na internetu. URI je obecnější koncept, který zahrnuje známější URL (Uniform Resource Locator) a URN (Uniform Resource Name). Pokud mluvíme o (HTTP) URI, přemýšlíme o daném řetězci jako o identifikátoru, pokud hovoříme o URL, zdůrazňujeme, že daný řetězec je adresa fyzického umístění zdroje na intertnetu. URN jsou pak schémata pro identifikaci zdrojů, které ale zároveň neumožňují získat reprezentaci zdroje na internetu (např. ISBN URN). Příkladem HTTP URI je identifikátor J. R. R. Tolkiena v DBpedii: Příkladem URL je adresa HTML reprezentace J. R. R. Tolkiena v DBpedii: HTTP HTTP (Hypertext Transfer Protocol) je internetový protokol původně určený pro přenos hypertextových dokumentů (HTML stránek) mezi klientem a serverem, později rozšířen o možnost přenášet jakékoli soubory. HTTP je jeden z nejpoužívanějších internetových protokolů. HTTP používá URL pro směrování požadavků klienta na server. Ukázka jednoduchého HTTP GET požadavku do DBpedie: GET /resource/j._r._r._tolkien HTTP/1.1 Host: dbpedia.org Accept: text/turtle, application/rdf+xml V našem příkladu se pokoušíme pomocí HTTP metody GET získat reprezentaci zdroje J. R. R. Tolkien v DBpedii v RDF serializaci Turtle. Používáme přitom HTTP protokol ve verzi 1.1. HTTP hlavička Accept specifikuje jaký formát (tzv. MIME typ) reprezentace preferujeme, v našem případě Turtle (text/turtle), případně, pokud server nenabízí reperezentaci zdroje v Turtle, se spokojíme s RDF/XML (application/rdf+xml). Tomuto se říká tzv. vyjednávání o obsahu (angl. content negotiation). V HTTP odpovědi serveru dostaneme v hlavičce informace o úspěšném odbavení dotazu a v těle odpovědi pak RDF data v požadované serializaci. Uveďme si pro stručnost jenom hlavičku odpovědi: HTTP/ OK Date: Sun, 26 Jun :20:25 GMT Server: Apache/ (Unix) PHP/4.3.8 Content-Type: text/turtle; charset=utf-8 HTTP definuje několik metod pro manipulaci se zdroji na webu. Zde si uvedeme jen čtyři z nich: GET Požadavek na zaslání obsahu na dané URL. GET lze použít i pro zaslání uživateli zadaných dat na server, data se serializují do URL. Nejpoužívanější HTTP metoda. POST Požadavek odesílá uživateli zadaná data serveru ke zpracování. Používá se ve spojení s HTML formuláři. PUT Požadavek vytvoří na serveru na daném URL nový zdroj. 25

31 DELETE Požadavek odstraní ze serveru zdroj na daném URL. 9.3 XML XML (Extensible Markup Language) je značkovací meta-jazyk pro zápis značkovacích jazyků. XML umožnuje definovat vlastní tagy, tj. značky s vlastní sémantikou. Vlastní značky umožňují lépe vystihnout význam zapisovaných dat. XML s sebou přineslo na web neutralitu textového formátu. Textový formát je zpracovatelný nezávisle na prostředí, na kterém byl vytvořen (operačním systému nebo programovacím prostředí). XML definuje jednoduchou datovou strukturu strom, ta je snadno manipulovatelná pomocí tzv. parseru. Parser je speciální program, který umožňuje programatický přístup k datům v XML dokumentech. Dále je možné pomocí zvláštních jazyků (DTD, XML schéma a dalších) definovat tzv. schémata. Schéma je sada omezení (množina tagů a jejich struktur) aplikovatelná na dokument vyjádřený v tomto schématu. Proti schématům lze kontrolovat validnost (správnost) XML dokumentů. Důležitým rysem XML jsou tzv. jmenné prostory (angl. namespaces), které umožňují v jednom XML dokumentu kombinovat více různých schémat. Nakonec, XML umí kódovat text v Unicode, takže v něm lze zapsat znaky všech abeced. XML poskytuje jednotnou syntaxi (resp. datovou strukturu) pro neomezené množství různých datových formátů (např. RSS, Atom, XHTML, atd.). Třebaže je XML navrženo pro reprezentaci dokumentů se smíšeným obsahem, často se používá k reprezentaci strukturovaných dat, např. právě ve webových API. Příklad dat serializovaných v XML: <person> <firstname>john</firstname> <lastname>smith</lastname> <age>25</age> <address> <streetaddress>21 2nd Street</streetAddress> <city>new York</city> <state>ny</state> <postalcode>10021</postalcode> </address> </person> 9.4 JSON JSON (JavaScript Object Notation) je textový formát založený na zápisu objektů v JavaScriptu, určený pro přenos strukturovaných dat mezi serverem a klientem. Data mohou být v JSON organizována v polích, nebo agregována v objektech. Zápis dat v JSON je obvykle stručnější než zápis ekvivalentních dat v XML. Mimojiné proto se JSON stal populárním ve webových API. Data serializovaná v JSON lze přímo převést na objekty v JavaScriptu. Příklad dat serializovaných v JSON: 26

32 { } "firstname": "John", "lastname": "Smith", "age": 25, "address": { "streetaddress": "21 2nd Street", "city": "New York", "state": "NY", "postalcode": "10021" } 10 Dělení webových API Webová API nejsou jedna konkrétní technologie, která by se pokaždé implementovala stejným způsobem. API využívají množinu stejných technologií (URL, HTTP, XML, JSON a další), ale architektura API, to jak jsou tyto technologie použity, se většinou liší od API k API. Nicméně mezi API lze vysledovat určité skupiny, které jsou vystavěny podobně, tj. mají podobnou architekturu. Existuje několik pokusů o klasifikaci webových API. Klasifikace se různí mírou detailu, se kterým API dělí, jinak jsou v zásadě velmi podobné. Dvě klasifikační schémata pocházejí od Leonarda Richardsona a jeden pokus o klasifikaci API od Jana Algermissena. Klasifikační schémata Leonard Richardson ve své knize RESTful Web Services [10] dělí API do tří kategorií: RPC API, Hybridní RPC-RESTová API a RESTová API Richardsonův model dospělosti webových API dělí API do čtyř úrovní: nultá, první, druhá a třetí úroveň Jan Algermissen v Classification of HTTP-based APIs 1 rozděluje API podrobněji na: Webové Služby (SOAP), RPC-POST (tzv. podomácku implementované Webové Služby ), RPC URI tunelování, HTTP typ I a II, tzv. Bezděčně RESTová API a RESTová API Dělení webových API má za účel ukázat, co lze od jednotlivých druhů API očekávat Richardsonův model dospělosti webových API Richardsonův model dospělosti

33 Autorem Richardsonova modelu dospělosti (RMD) je Leonard Richardson 1, expert na RESTové webové služby a autor knížky na stejné téma [10]. RMD je velmi jednoduché klasifikační schéma webových API, které dělí API do čtyř základních úrovní. RMD rozlišuje úroveň 0 až 3. API náleží do dané úrovně podle toho, jak důsledně ve své implementaci využívají webové technologie (URI a HTTP) a tzv. RESTové principy. Do čím vyšší úrovně API náleží, tím je dospělejší (blíží se plnohodnotné RESTovému API). Protože dělení na úrovně není samo o sobě příliš popisné, rozhodl jsem se jednotlivé úrovně nadepsat podle dělení, které Richardson použil ve své knize [10] doplněné o kategorii Pragmatická REST API, které odpovídá třetí úrovni v RMD: Dělení webových API (Zdroj: Autor) RPC API Nultá úroveň. Nejzákladnější úroveň API je charakteristická užíváním jedné URI (tzv. endpointu) a jedné HTTP metody (typicky GET nebo POST). Například většina Webových Služeb využívá jednu URI jako endpoint a jednu HTTP metodu (POST) pro přenos dat a ignoruje zbytek HTTP metod. XML-RPC a tzv. POX (Plain Old XML) over HTTP (XML předávané prostřednictvím HTTP) fungují podobně: posílají HTTP POST požadavky s XML v těle zprávy na jeden endpoint. Výsledky jsou doručovány zpět jako XML v HTTP odpovědi. Příklady: Freebase API 2 + MQL (Metaweb Query Language), Facebook Graph API 3 + FQL (Facebook Query Language), Webové Služby, XML-RPC a SPARQL endpoint Freebase API Freebase je otevřená, volně editovatelná databáze. Freebase obsahuje přibližně 22,5 millionů entit, 367 miliónů faktů, více než 3000 typů a atributů. Entity ve Freebase patří do několika tématických domén. Nejčetnějšími doménami jsou lidé, místa, organizace (firmy), knihy a filmy