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
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.
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.
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.
Linked Data ......................................................................................................................................................................... 6 2.1
Linked Data principy ............................................................................................................................................ 7
2.2.1
Identifikujte zdroje pomocí URI. .......................................................................................................... 7
2.2.2
Používejte HTTP URI, aby se zdroje daly vyhledat na webu. ................................................ 7
2.2.3
Při HTTP požadavku na danou URI poskytněte RDF reprezentaci zdroje. .................... 7
2.2.4
Reprezentace by měla obsahovat odkazy na související zdroje. ......................................... 8
3
Technologie ......................................................................................................................................................................... 8
Grafový datový model RDF ............................................................................................................................ 11
4.3
RDF je tzv. samopopisné ................................................................................................................................. 11
Ontologické jazyky ............................................................................................................................................. 14
Třídy a vlastnosti ...................................................................................................................................... 15
6.2.2
Definiční obory a obory hodnot vlastností .................................................................................. 15
6.2.3
Subsumpce tříd a vlastností ................................................................................................................ 16
Webová API ...................................................................................................................................................................... 20 7.1
Vývoj webových API .................................................................................................................................................... 22 8.1
Webové Služby ..................................................................................................................................................... 22
8.3
Webová API ............................................................................................................................................................ 23
9
Technologie ...................................................................................................................................................................... 24 9.1
URI .............................................................................................................................................................................. 24
Dělení webových API ............................................................................................................................................. 27
10.1
Richardsonův model dospělosti webových API .................................................................................. 27
10.1.1
RPC API .......................................................................................................................................................... 28
Pragmatická REST API ........................................................................................................................... 30
10.1.4
Plnohodnotná REST API ........................................................................................................................ 30
11
Srovnání ........................................................................................................................................................................ 31
11.1
Datový model ........................................................................................................................................................ 33
Objevitelnost dat ................................................................................................................................................. 35
Indexovatelná data ........................................................................................................................................ 38
Integrace dat z různých zdrojů (mashupy) ...................................................................................... 39
11.16
Identifikace aplikace .................................................................................................................................... 40
Seznámenost programátorů s technologií ........................................................................................ 41
11.20
Licencování dat ............................................................................................................................................... 41
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ř. Wikipedia2, Flickr3, Delicious 4, atd. a v poslední době se sociálními sítěmi jako je Facebook5 a Twitter6. 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 Insight7) 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
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
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 Jentzsch1) 1
http://richard.cyganiak.de/2007/10/lod/
6
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. 2. 3. 4.
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.
2.2.1 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. 2.2.2 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á. 2.2.3 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
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: W3C1) „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 Unicode2). 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 1 2
http://www.w3.org/2007/03/layerCake.png RFC 3987: International Resource Identifiers (IRIs) http://www.ietf.org/rfc/rfc3987.txt
8
(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. → <má rok vydání> → “1937” 2. → <má autora> → <J. R. R. Tolkien> Subjekt je zdroj (např. ), 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ř. “1937”), nebo (2) odkaz na jiný zdroj (např. <J. R. R. Tolkien>).
RDF trojice (Zdroj: DevX.com1) 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
http://www.devx.com/semantic/Article/34816
9
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á NTriples, 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-LD1 (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. 4.1.1
N-Triples serializace:
. "The Hobbit"@en. "The Hobbit, or There and Back Again"@en. < http://xmlns.com/foaf/0.1/creator> . "1937"^^. "310"^^. . .
rdfs:label "The Hobbit"@en; foaf:name "The Hobbit, or There and Back Again"@en; 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 "1999-07-02"; dcterms:modified "2008-01-14"; 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
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
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 dbpedia:Frodo_Baggins dbpedia:Frodo_Baggins dbpedia:Frodo_Baggins dbpedia:Frodo_Baggins
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 (?friend (?friend (?friend (?friend
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 (?character (?character (?character
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 protokolu1, 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 http://dbpedia.org/sparql.
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: 1 2
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
6.2.1 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 dbpedia:The_Hobit
dc:creator
foaf:Person
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. 6.2.2 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 ; 1
http://xmlns.com/foaf/0.1/
15
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. 6.2.3 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
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. 6.3.1 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 http://rdf.freebase.com/ns/en.j_r_r_tolkien a zdroj s HTTP URI http://dbpedia.org/resource/J._R._R._Tolkien 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 http://dbpedia.org/resource/J._R._R._Tolkien a http://rdf.freebase.com/ns/en.j_r_r_tolkien označují stejnou věc: dbpedia:J._R._R._Tolkien owl:sameAs
freebase:j_r_r_tolkien
6.3.2 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 GoodRelations3 – definuje koncepty pro popis produktů, služeb a dalších věcí relevantních pro e-komerci
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 Ontology3 –definuje koncepty pro popis věcí souvisejících s hudbou jako umělci, alba, písně, atd.
6.5 DBpedia DBpedia4 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 400 000 osob, téměř půl milionu míst, sto tisíc hudebních alb, šedesát tisíc filmů, 150 000 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: DBpedie5) Na následující stránce je pro ilustraci uveden infobox z článku o J. R. R. Tolkienovi na Wikipedii (http://en.wikipedia.org/wiki/J._R._R._Tolkien) a strukturovaná data, která z něj byla vyextrahována, převedena do RDF a vystavena jako součást DBpedie (http://dbpedia.org/data/J._R._R._Tolkien). Data jsou zapsána v Turtle syntaxi.
7 Webová API “[Webová] aplikace bez API je jako dům bez dveří.” - Josh Walker, analytik Forrester Research
Webová API1 (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 API2), funkcionalitě (např. Amazon S33) nebo vizualizaci (např. Google Maps API4). 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í. http://www.freebase.com/docs/data 3 http://aws.amazon.com/s3/ 4 http://code.google.com/apis/maps/index.html 2
20
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 7.2.1 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.
1
http://www.w3.org/2002/ws/
21
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). 7.2.2 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 1998.
8.2 Webové Služby Webové Služby se poprvé objevují v roce 1998. 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 1999. 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é 1
http://en.wikipedia.org/wiki/Web_API
22
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 2003. 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 1996. 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 1999.3 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 2005. 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:
http://www.sonic.net/~undoc/perl/talk/webapi1.html http://jonudell.net/archive/xml-rpc.html 3 „Web sites that support CGI-based services implicitly define what I call Web APIs.“ 1 2
23
Popularita klíčových slov REST API a SOAP “web services” ve vyhledávání na Google (Zdroj: Google Insight1) 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 2009. 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 3375. 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 3.
9.1 URI http://www.google.com/insights/search/#cat=05&q=SOAP%20%22web%20services%22%2CREST%20API&cmpt=q 2 http://www.programmableweb.com/ 3 http://www.yaml.org/ 1
24
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: http://dbpedia.org/resource/J._R._R._Tolkien
Příkladem URL je adresa HTML reprezentace J. R. R. Tolkiena v DBpedii: http://dbpedia.org/page/J._R._R._Tolkien
9.2 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/1.0 200 OK Date: Sun, 26 Jun 2011 08:20:25 GMT Server: Apache/1.3.29 (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
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: JohnSmith25 <streetAddress>21 2nd Street New York <state>NY <postalCode>10021
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:
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.
Autorem Richardsonova modelu dospělosti (RMD) je Leonard Richardson1, 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) 10.1.1 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 API3 + 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 30000 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.
Freebase API je implementováno jako API nulté úrovně. Freebase má vyhrazený endpoint http://www.freebase.com/api/service/mqlread, na který se zasílají dotazy v MQL (Metaweb Query Language). MQL je proprietární na JSON založený dotazovací jazyk navržený pro a nasazený jen ve Freebase. Příklad dotazu v MQL: { "type" : "/music/album", "name" : "Synchronicity", "artist" : "The Police", "track" : [{ "name":null, "length":null }] }
Dotaz se snaží získat z Freebase názvy (name) a délku (lenth) písniček z alba “Synchronicity” skupiny “The Police”. Výsledek: { "type" : "/music/album", "name" : "Synchronicity", "artist" : "The Police", "track" : [ {"name":"Synchronicity II", "length":305.066}, {"name":"Every Breath You Take", "length":254.066}, {"name":"King of Pain", "length":299.066}, {"name":"Wrapped Around Your Finger", "length":313.733}, {"name":"Tea in the Sahara", "length":255.44}, {"name":"Walking in Your Footsteps", "length":216.773}, {"name":"Miss Gradenko", "length":120}, {"name":"Murder by Numbers", "length":276.8}, {"name":"O My God", "length":242.226}, {"name":"Synchronicity I", "length":202.866}, {"name":"Mother", "length":185.64} ] }
10.1.2 Hybridní RPC-REST API První úroveň. API, která sama sebe označují za RESTová API, jsou většinou API první úrovně. Webová API na první úrovni vystavují několik URI, stále však využívají jen jednu HTTP metodu, nejčastěji GET. Základním rozdílem mezi API na této úrovni a API nulté úrovně je vystavení několika logických zdrojů, zatímco API na nulté úrovni vystavují jen jeden “velký” zdroj. Pro hybridní API je charakteristické, že “tunelují” operace přes názvy operací a parametry v URI. “URI tunelování” není v souladu s webovými (RESTovými) principy, protože URI identifikují operace, místo aby identifikovaly zdroje, se kterými by se dalo manipulovat prostřednictvím 29
HTTP metod. “URI tunelování” může být použito takovým způsobem, že poruší bezpečnost a idempotenci HTTP metody GET. Příklady: Last.fm API1, Flickr API2 a většina ostatních webových API 10.1.3 Pragmatická REST API Druhá úroveň. API druhé úrovně zpřístupňují několik URI-adresovatelných zdrojů a u každého zdroje podporují více nebo všechny HTTP metody. Tato úroveň zahrnuje takzvané CRUD (Create, Read, Update, Delete) API. Zdroji těchto API lze prostřednictvím HTTP metod vzdáleně manipulovat: vytvářet, aktualizovat a mazat je. Příklady: Amazon S33 a SimpleGeo4 10.1.4 Plnohodnotná REST API Třetí úroveň. Ze všech úrovní API se nejvíce připomínají web. Plnohodnotná RESTová API podporují hypertext pro přechod mezi stavy aplikace (angl. hypermedia as the engine of application state). Reprezentace zdrojů obsahují URI odkazy na související zdroje a API provádí klienta prostřednictvím odkazů mezi různými stavy aplikace. REST jako architektonický styl pro distribuované aplikace definoval ve své dizertační práci5 v roce 2000 Roy Fielding. Fielding odvodil REST z architektury a fungování webu. Příklady: API, které implementují Atom Publishing Protocol6, RSS a Atom kanály, mnoho webových aplikací, zejména těch “jen pro čtení” (například vyhledávače) a všechny statické webové stránky. Plnohodnotná RESTová API “nejen pro čtení” prakticky neexistují.
11 Srovnání “Webová API brání znovupoužití dat.” 1 - David Karger, profesor na MIT Webová API a Linked Data usilují o stejnou věc, zpřístupnění strukturovaných dat na webu, ale používají k tomu velmi odlišné technologie. Zatímco webová API staví na webových technologiích převážně z devadesátých let (URI, HTTP a XML), Linked Data využívají novější technologie navržené přímo pro sdílení strukturovaných dat na webu (RDF a ontologie). To se samozřejmě projevuje na vlastnostech, které obě techniky propůjčují datům, která jsou na webu jejich prostřednictvím vystavena. V následující tabulce se nachází 20 položek, přes které jsou webová API a Linked Data srovnávána. Položky se týkají zejména technologických vlastností webových API a Linked Data (jako např. datový model, rozhraní, atd.). V části, která následuje za tabulkou jsou jednotlivé položky a rozdíly mezi API a Linked Daty podrobně vysvětleny.
Počet (API a linked datasetů) 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í)
Webová API
Linked Data (+endpoint)
Více než 33501 XML, JSON, a další Různé varianty přístupu prostřednictvím HTTP, (SOAP a XML-RPC) Záleží na API – URI nebo např. MusicBrainz ID, ISBN
Více než 2202
Záleží na API
Vždy
Ne
Ano
Ne, nebo konvencí (např. element z Atomu3)
Ano
Ne Ručně
RDF HTTP Vždy (URI)
Ano (owl:sameAs) Ručně, “Follow Your Nose”, sémantické vyhledávače
Vyjímečně
Vždy
Odvozování
Ne
Ano
Generické procházení
Ne
Ano
Indexovatelná data
Ne
Ano
Distribuované dotazování
Ne
Ano
Proprietální jazyky, “URL templates”4
Standardizovaný jazyk SPARQL Automaticky (spojování grafů)
Dotazování dat Integrace dat z různých zdrojů (mashupy)
Ručně
Identifikace aplikace
Velmi často (API klíč5)
Nikdy
Dump6
Vyjímečně
Velmi často
Pro každé API zvláštní knihovna
Pro všechna data jedno RDF API
Velká
Malá
Striktnější
Liberálnější
Programovací knihovny Seznámenost programátorů s technologií Licencování dat
11.1 Datový model RDF se od XML liší v tom, že RDF je narozdíl od XML navrženo pro reprezentaci sémantiky dat. XML není vhodný jazyk pro modelování dat, pokud je naším cílem reprezentovat objekty z problémové domény tak, že tyto korespondují (jedna ku jedné) s konceptuálním modelem objektů v této doméně. Je to dáno tím, že XML reprezentuje vztahy pomocí “vnořování” (angl. containment) elementů. XML je založeno na tzv. předpokladu uzavřeného světa (angl. closed world assumption), a proto není možné rozšiřovat informace v XML dokumentu, které již máme, o informace nové. Nelze spojovat distribuované XML dokumenty. [7] RDF odstraňuje tyto nedostatky a díky tomu umožňuje integraci distribuovaných dat a ve spojení s ontologiemi také automatické odvozování.
11.2 Rozhraní Už jsme si ukázali, že webová API mohou být navržena různými způsoby, jako RPC, hybridní RPC-REST, pragmatický REST a plnohodnotný REST. Přestože všechna API využívají HTTP protokol, k různým API se přistupuje různě. Některá API definují vlastní plnohodnotný dotazovací jazyk, k těm se pak přistupuje přes endpoint, na který se zasílají dotazy v daném jazyce. K hybridním RPC-REST API a pragmatickým REST API se přistupuje prostřednictvím množiny definovaných “URL templatů”, které dohromady tvoří jednoduchý dotazovací jazyk. Pokud uvažujeme i Webové Služby (SOAP) a XML-RPC služby, pak ty jsou sami o sobě zvláštními protokoly, nad kterými jsou definovány metody, prostřednictvím kterých se přistupuje k datům v API. Linked Data a plnohodnotný REST využívají pro přístup k datům prosté HTTP. Vrácené reprezentace v obou případech obsahují odkazy na jiné zdroje, ke kterým víme jak přistupovat – HTTP GET požadavkem na danou HTTP URI.
11.3 Globálně unikátní identifikátory Webová API používají globálně unikátní identifikátory (HTTP URI, nebo jiné, jako např. MusicBrainz ID, nebo ISBN) v závislosti na tom, jak jsou navržena. Nic nebrání tomu, aby API vystavovala entity každou pod zvláštním HTTP URI. Některá tak však z různých důvodů nečiní (některá z tzv. “dotazovacích API”). Např. BBC znovupoužívá MusicBrainz indentifikátory, které jsou globálně unikátní. MusicBrainz identifikátor pro Howarda Shorea (autora hudby k filmové verzi Pána prstenů) je 9b58672ae68e-4972-956e-a8985a165a1f. Data, která má BBC o Howardu Shoreovi, v XML formátu lze získat na URL http://www.bbc.co.uk/music/artists/9b58672a-e68e-4972-956ea8985a165a1f.xml. Stejná data v JSON formátu lze nalézt na URL http://www.bbc.co.uk/music/artists/9b58672a-e68e-4972-956e-a8985a165a1f.json. U Linked Dat je používání globálně unikátních identifikátorů v podobě HTTP URI imperativem. Každá entita je identifikována pomocí HTTP URI. Např. identifikátor J. R. R. Tolkiena v DBpedii je .
33
11.4 “Dereferencovatelné”identifikátory Pokud API vystavuje entity každou pod zvláštním HTTP URI, tak má “dereferencovatelné” identifikátory. Tj. dané URI lze vyhledat na webu, jinými slovy provést HTTP GET požadavek na danou HTTP URI a získat zpět reprezentaci entity. Některá API umožňují tzv. vyjednávání o obsahu (angl. content negotiation), kdy klient v HTTP hlavičce uvede preferovaný formát odpovědi (např. Accept: application/xml pro XML) a server mu podle možností vrátí data ve zvoleném formátu. Pro Linked Data opět platí, že všechny HTTP URI identifikátory jsou “dereferencovatelné”. Linked Data navíc často umožňují “vyjednat si” RDF reprezentaci v různých serializacích. “Dereferencovatelná” Linked Data URI defaultně vrací RDF/XML.
11.5 Rozlišení zdroje a jeho reprezentace Webová API nemají standardní mechanismus pro rozlišení mezi zdrojem a jeho reprezentací. Proto u webových API je zdroj totožný s jeho reprezentací. Díky tomu webová API nemohou tvrdit něco o reprezentaci samotné. Např. nemohou říci pod jakou licencí jsou data vystavena, nebo kdo je autorem reprezentace, kdy reprezentace vznikla, atd. Jinými slovy webová API neumožňují přidávat k datům metadata. Linked Data naproti tomu mají standardní mechanismus pro rozlišení mezi zdrojem a jeho reprezentací. Zdrojům a jejim reprezentacím přiřazují různá URI a na základě “vyjednávání o obsahu” poskytují odpovídající reprezentaci. Např. zdroj J. R. R. Tolkien má v DBpedii identifikátor . DBpedie pak nabízí různé reprezentace zdroje Tolkien. Např. HTML reprezentaci pod URL a RDF reprezentaci (v různých serializacích) pod URL . Linked Data díky tomu nejen umožňují, ale přímo vyžadují aby reprezentace obsahovala metadata (např. právě licenci dat, autora, datum vzniku reprezentace, atd.).
11.6 Odkazy Webová API využívají pro reprezentaci dat XML, JSON, případně YAML a další formáty. Žádný z těchto formátů není “hypertextovým formátem”. Tzn. žádný z nich neposkytuje standardní mechanismus pro vyjádření odkazů. Existují různé konvence pro přidání odkazů, nejrozšířenější z nich je pravděpodobně, pro XML, element ze schématu Atom (Atom Syndication Format)1. Nicméně jsou to jen konvence, tj. nemůžeme s nimi stoprocentně počítat. Navíc většina webových API, pokud někam odkazují, používá vlastní konstrukty pro vyjádření odkazů, např. element ve vlastním jmenném prostoru. Podobně pro JSON a YAML. Linked Data na druhou stranu využívají pro reprezentaci dat RDF a v RDF je odkazem každá trojice, která nemá v objektu literál. RDF je “hypertextový formát”. Odkazy jsou tedy přirozenou součástí Linked Data. A nejen to, podle čtvrtého z Linked Data principů je žádoucí, aby data odkazovala na související data z jiných linked datasetů. Tímto způsobem Linked Data vytváří odkazy propletený informační prostor – tzv. web dat.
11.7 Ekvivalentnost zdrojů
1
http://en.wikipedia.org/wiki/Atom_(standard)
34
Různá API, resp. datasety, obsahují informace o stejných entitách. Pokud tedy víme, že dvě entity jsou shodné, můžeme získat kombinací dat z různých API, nebo datasetů, více informací o dané entitě. Proto je žádoucí, aby existoval způsob, jakým bychom mohli deklarovat, že dvě entity jsou shodné. Webová API žádný mechanismus, který by toto umožňoval neposkytují. Linked Data k tomuto využívají vlastnost z ontologického jazyka OWL owl:sameAs. owl:sameAs nám dovoluje říci, že dvě entity jsou totožné. Např. DBpedie tvrdí, že zdroj dbpedia:J._R._R._Tolkien je totožný se zdrojem , který reprezentuje J. R. R. Tolkiena ve Freebase databázi: dbpedia:J._R._R._Tolkien owl:sameAs .
Víme-li, že dva zdroje jsou shodné, můžeme data o nich zkombinovat a získat tak úplnější pohled na danou entitu.
11.8 Objevitelnost dat V případě webových API můžeme data objevovat jen prostřednictím dotazů, nebo procházením API. Dotazování a procházení API se obecně nedá, díky jejich diverzitě, automatizovat, takže je musíme provádět manuálně. Najdeme API, které obsahuje data, která nás zajímají (např. prostřednictvím katalogu API ProgrammableWeb.com) a individuální položky dat objevujeme dotazováním a procházením daného API. Linked Data můžeme objevovat třemi způsoby. Podobně jako u webových API, můžeme “ručně” najít linked dataset, který obsahuje data, která nás zajímají (k tomu můžeme využít např. katalog CKAN1 nebo seznam datasetů na wiki stránce W3C2). Nebo můžeme data objevovat ručně, či automaticky procházením (sledováním odkazů, tzv. Follow Your Nose) napříč datasety (takovýmto způsobem pracuje např. SQUIN3, tzv. link traversal query engine). Třetí možností je použít sémantický vyhledávač, např. Sindice4. Sindice indexuje RDF dokumenty tak, že prochází odkazy mezi linked datasety. Na Sindice můžeme vyhledávat pomocí klíčových slov, nebo jednoduchých “vzorů trojic”, které známe ze SPARQL. Sindice vrací seznam URL RDF dokumentů, která obsahují námi hledaná slova, nebo trojice. Data samotná získáme z těchto dokumentů.
11.9 Znovupoužívání schémat (ontologií) Znovupoužívání schémat je u webových API poměrně výjimečné. Několika výjimkami jsou RSS (prakticky výhradně ve verzi 2.0)5 a Atom6 pro syndikaci zpráv, s tím, že Atom se používá také jako tzv. kanonický formát v některých implementacích RESTových API. Méně často se můžeme setkat s OpenSearch7, formátem pro popis výsledků vyhledávání, a např. GeoJSON8, JSON formátem pro popis geografických dat.
V případě Linked Dat je znovupoužívání ontologií základním předpokladem. Nejpoužívanějšími ontologiemi jsou Dublin Core, metadatové schéma pro popis knih, digitálních artefaktů, atd., FOAF (Friend of a Friend), ontologie pro popis lidí, jejich vztahů a organizací, Good Relations, ontologie pro popis nabídek produktů a mnoho dalších. Znovupoužívání ontologií umožňuje porozumění datům. Pokud jsou data vyjádřena pomocí ontologie, které rozumíme, tak rozumíme i těmto datům, bez ohledu na to odkud data pochází, nebo kdo je vytvořil.
11.10 Odvozování Webová API nemají ekvivalent odvozování, který mají Linked Data. Data, která nejsou na webových API explicitně uvedena neexistují. Linked Data naproti tomu díky ontologiím umožňují z “explicitních” dat odvodit data nová, která z nich logicky vyplývají. Odvozování nám umožnuje např. najít odpověď na dotaz, který s pouhou znalostí explicitních dat není možné zodpovědět. Ukažme si, jak nám odvozování umožní odpovědět na dotaz “Najdi všechny přátele autorů článku ”. Zapsán ve SPARQL by náš dotaz vypadal SELECT ?friend WHERE { dc:creator ?author. ?author foaf:knows ?friend. ?friend rdf:type foaf:Person. }
Databáze publikační činnosti DBLP1 obsahuje záznam k článku Tima Bernerse-Leeho “Linked Data - The Story So Far” rdf:type swrc:Article; dc:creator . foaf:homepage .
FOAF profil Tima Bernerse-Leeho obsahuje foaf:homepage ; foaf:knows .
S pouhou znalostí těchto dat nedokážeme náš dotaz zodpovědět. Naše data totiž používají různé identifikátory pro Tima Bernerse-Leeho (nevíme, že identifikují stejný zdroj) a nikde není řečeno, že Dan Brickley je člověk (foaf:Person) a tedy přítel (přítel je vždy člověk). Protože jsou naše data popsána pomocí ontologie (v našem případě FOAF), můžeme z nich odvodit data potřebná k zodpovězení našeho dotazu.
Z dat ve FOAF profilu Tima Berners-Leeho a definice vlastnosti foaf:knows dokážeme odvodit rdf:type foaf:Person.
Dále z FOAF profilu Tima Bernerse-Leeho a DBLP záznamu víme foaf:homepage . foaf:homepage .
FOAF ontologie definuje vlastnost foaf:homepage jako foaf:homepage rdfs:type owl:InverseFunctionalProperty.
Z těchto dat a definice vlastnosti foaf:homepage dokážeme odvodit, že zdroje a jsou shodné owl:sameAs .
Díky těmto nově odvozeným datům máme nyní dostatek informací, abychom mohli zodpovědět náš původní (SPARQL) dotaz. Jedním z výsledků bude Dan Brickley (). Víme totiž, ze Tim BernersLee je autorem (dc:creator) článku “Linked Data - The Story So Far”, že zná (foaf:knows) Dana Brickleyho a že Dan Brickley je člověk (foaf:Person) a tedy může být přítelem.
11.11 Generické procházení Genericky procházet data v API není možné z důvodu heterogenity jednotlivých API. Webová API definují různé přístupové mechanismy (vlastní dotazovací jazyk, různé „URL templaty“), využívají různé datové modely a neobsahují odkazy, resp. používají různé konvence pro vyjádření odkazů. Z těchto důvodů nemůžeme data z API procházet podobně jako procházíme web. Linked Data můžeme procházet tak jako procházíme web, tj. genericky. Všechna Linked Data jsou vyjádřena prostřednictvím jednoho datového modelu (RDF), který umožňuje odkazovat mezi daty z různých datasetů. Můžeme se tak plynule přesouvat mezi jednotlivými položkami dat (zdroji) a různými datasety, podobně jako se na webu v prohlížeči plynule přesunujeme
37
z jedné stránky na druhou a z jednoho serveru na jiný server. Podobně procházet Linked Data (resp. web dat) můžeme pomocí generických prohlížečů Tabulator1, Marbles2 a dalších.
11.12 Indexovatelná data Podmínkou indexovatelných dat je, že data jsou genericky procházitelná. Webová API nelze, jak jsme si vysvětlili, z různých důvodů genericky procházet a proto je nelze ani indexovat. Linked Data lze genericky procházet a díky tomu i indexovat. Indexování umožňuje objevovat Linked Data novými způsoby: vyhledáváním podle klíčových slov nebo jednoduchých “vzorů trojic” (viz. příklad se Sindice výše) a nebo SPARQL dotazováním se zagregovaných dat. Sindice např. zpřístupňuje zagregovaná data na SPARQL endpointu http://sparql.sindice.com/. Sindice endpoint aktuálně obsahuje 12 miliard RDF trojic, které byly získány procházením a agregováním webu dat.
11.13 Distribuované dotazování Distribuované (jinak také federované) dotazování je způsob dotazování se dat tak, že jeden dotaz je buď poslán do několika databází, nebo jsou různé části dotazu poslány do různých databází. Výsledek je pak získán v unifikované formě, vůči klientovi se distribuované dotazování tváří stejně, jako by se klient dotazoval do jedné databáze. Distribuované dotazováni je důležité zejména pro aplikace, které využívají data z několika zdrojů, a které potřebují, aby tato data byla v každé situaci aktuální. Distribuované dotazování totiž nevyžaduje lokální agregaci dat, která typicky vede k neaktuálnosti dotazovaných dat. Webová API z důvodu různorodosti přístupových mechanismů (vlastní dotazovací jazyk, různé “URL templaty”) a rozdílných schémat neumožňují provádět distribuované dotazování nad několika různými API. Pokud je společně s Linked Daty vystaven i SPARQL endpoint, tak je možné tyto data dotazovat distribuovaně. SPARQL ve verzi 1.1 zavedl speciální syntaxi, která umožňuje určit, na jaký endpoint se má daná část dotazu poslat. Pro ilustraci si ukažme příklad jednoduchého distribovaného SPARQL dotazu. Chceme získat jména a data narození lidí, kteří napsali článek společně s Timem Bernersem-Leem . První část dotazu, která získá jména všech spoluautorů Bernerse-Leeho, posíláme na SPARQL endpoint databáze publikační činnosti DBLP http://dblp.l3s.de/d2r/sparql. Druhou část, která získá data narození Berners-Leeho spoluautorů nalezených v první části dotazu, posíláme na SPARQL endpoint encyklopedie DBpedie http://dbpedia.org/sparql. SELECT ?name ?birthdate WHERE { SERVICE { ?paper dc:creator . ?paper dc:creator ?coauthor. ?coauthor foaf:name ?name. }
SERVICE { ?person foaf:name ?name. ?person dbpedia:birth ?birthdate. } }
Distribuované dotazování umožňují nebo využívají např. dotazovací stroj (angl. query engine) DARQ1 nebo aplikace SemaPlorer 2. [15]
11.14 Dotazování dat Webová API definují jednoduchá dotazovací rozhraní, která jsou typicky tvořena několika “URL templaty”, do kterých klient doplňuje požadované hodnoty (např. klíčová slova, identifikátory, nebo různé parametry pro filtrování výsledků jako např. rok). Rozhraní webových API mají často omezené vyjadřovací schopnosti, tj . schopnost formulovat jak jednoduché, tak komplexní dotazy. Tj. zpřístupňovaná data jsou často bohatší, než dotazy, které lze pomocí API vyjádřit. Výjimkou jsou webová API, která definují vlastní plnohodnotný dotazovací jazyk, jako např. Freebase a její MQL3 (Metaweb Query Language). Dotazovacím jazykem pro Linked Data je SPARQL. SPARQL je standardizovaný plnohodnotný dotazovací jazyk, který pracuje na principu tzv. porovnávání grafů. Ve SPARQLu můžeme formulovat libovolně složité dotazy (do úrovně složitosti, kterou SPARQL podporuje) a nejsme tedy omezeni jen na předpřipravený soubor dotazů (“URL templatů”) jako u webových API.
11.15 Integrace dat z různých zdrojů (mashupy) Mashupy jsou nejviditelnější aplikací webových API. Definice mashupu je, že jde o webovou aplikaci, která kombinuje data ze dvou a více různých zdrojů.4 Mashupy, které konzumují data z webových API, musí tyto data integrovat programově (tj. musíme napsat zvláštní kód, který data zintegruje). Integrace dat z více zdrojů zahrnuje tzv. disambiguaci entit, tj. rozpoznání, že dvě různé datové položky ze dvou různých API ve skutečnosti popisují tutéž entitu. To je integrace dat na úrovni instancí. Data ale integrujeme také na úrovni datového modelu a schématu. Pokud chceme s daty smysluplně pracovat, musí být data vyjádřena v jednotném datovém modelu a schématu. Tzn. pokud jsou data v různých API reprezentována v různých datových modelech a schématech (už dříve jsme si řekli, že většinou jsou), tak je musíme v rámci integrace převést do jednotného datového modelu a schématu. Prostřednictvím tohoto datového modelu a schématu pak s daty manipulujeme. Jestliže integrujeme data z webových API, musíme si oba druhy integrace napsat sami. Už jsme si řekli, že webová API nemají žádný mechanismus pro vyjádření ekvivalence (tj. vyjádření již provedené disambiguace) a odkazů (což je opět forma zápisu provedené disambiguace). Narozdíl od webových API při integraci Linked Dat nemusíme nutně provádět disambiguaci entit, protože je pravděpodobné, že ji již někdo provedl za nás (např. v podobě owl:sameAs
ekvivalencí mezi různými zdroji1). A protože Linked Data umožňují odkazovat mezi zdroji, vazby mezi zdroji jsou tím pádem také disambiguované. Integrace na úrovni schématu zahrnuje v případě API převod dat získaných z API do vlastních předpřipravených datových struktur a práci s daty prostřednictvím těchto struktur na úrovni programovacího jazyka. U Linked Dat díky jednotnému datovému modelu (RDF) a znovupoužívání ontologií v určitých případech nemusíme provádět žádné transformace a s daty můžeme pracovat přímo pomocí RDF API. Pokud potřebujeme data převádět mezi ontologiemi, můžeme k tomu využít již existující mapování, nebo pokud mapování neexistuje, můžeme si jej nadeklarovat (a poté třeba sdílet s ostatními na webu) v ontologickém jazyce OWL. Data transformujeme do zvolené ontologie tak, že nad nimi provedeme odvození s odpovídajícím mapováním (OWL ontologií). S Linked Daty pracujeme programově prostřednictvím RDF API.
11.16 Identifikace aplikace Webová API velmi často požadují od klienta registraci tzv. API klíče2. Registrace vyžaduje vyplnění HTML formuláře, e-mail a většinou základní informace o aplikaci, která má API využívat (název, krátký popisek a URL aplikace). Někdy je registrace odbavena okamžitě automaticky, jindy registraci schvaluje ručně poskytovatel API, což může trvat několik dní. API klíč je unikátní identifikátor klienta, který klient posílá společně s každým požadavkem na webové API. V závislosti na API se API klíč připojuje na konec každého “URL templatu” nebo se posílá v HTTP hlavičce. Díky klíči může poskytovatel API sledovat, jak klient zatěžuje API, zda klient nevyčerpal přidělený limit dotazů (většina poskytovatelů API omezuje počet volání, která může klient provést za den), atd. Příklad dotazu do Last.fm API s připojeným API klíčem: http://ws.audioscrobbler.com/2.0/?method=artist.getinfo&artist=Howard%20Shore&api_ key=b25b959554ed76058ac220b7b2e0a026
Linked Data, ani SPARQL endpointy nevyžadují žádnou identifikaci klienta.
11.17 Dump Dump je datový soubor, který obsahuje všechna data, která se nachází v databázi. Slouží k exportu a přenosu dat mezi databázemi. Webová API z různých důvodů ve většině případů neposkytují dump svých dat. Linked Data naproti tomu poskytují dump velmi často. Linked data by měla být na webu ideálně vystavena ve třech podobách – jako Linked Data, tj. jako “dereferencovatelné” entity, jako data dostupná na SPARQL endpointu a jako dump soubor, který obsahuje všechna data z endpointu. RDF dump má navíc tu výhodu, že data lze přímo nahrát do RDF databáze a ihned s nimi pracovat. Např. RDF dump dat z GeoNames lze najít na adrese http://download.geonames.org/allgeonames-rdf.zip.
Pokud chceme s webovým API rozumně pracovat, potřebujeme k tomu vysokoúrovňovou knihovnu. S webovým API se dá sice pracovat přímo prostřednictvím HTTP knihovny a XML nebo JSON parseru, klient ale typicky nekomunikuje s API na této úrovni. S HTTP a parsery pracuje knihovna, která umožňuje klientovi přístup k API na vyšší úrovni abstrakce. Podstatné je, že při práci s každým API používáme vždy zvláštní knihovnu. Vytváříme-li např. mashup, kde využíváme data ze tří API, pracujeme se třemi různými knihovnami. Navíc pro každý programovací jazyk musí existovat zvláštní knihovna. Poskytovatel API tedy musí vyvinout speciální knihovnu pro každý programovací jazyk. Twitter např. poskytuje knihovny pro 13 programovacích jazyků. Naproti tomu pro práci s jakýmikoli Linked Daty potřebujeme jen jedno RDF API. Poskytovatel Linked Dat nemusí vyvíjet žádné knihovny, protože RDF API již existují.
11.19 Seznámenost programátorů s technologií Programátoři jsou většinou dobře obeznámeni s technologiemi, které využívají webová API, tj. URI, HTTP a XML nebo JSON. Na těchto technologiích není v principu nic složitého, nic programátorsky neintuitivního a jsou dobře zdokumentované. Protože jde o technologie poměrně staré, existují pro práci s nimi vyspělé nástroje. O technologiích, které využívají Linked Data se to samé říci nedá. Linked Data využívají kromě známých technologií webu URI a HTTP i méně známé a hůře srozumitelné technologie sémantického webu RDF a ontologické jazyky RDFS a OWL. Protože se jedná o technologie relativně nové, tak nástroje pro práci s nimi nejsou vždy úplně vyspělé. Nicméně situace na této frontě se rychle zlepšuje.
11.20 Licencování dat Obecně se dá říci, že licence pro znovupoužívání dat z webových API jsou striktnější než licence pro Linked Data. API sama o sobě, jak jsme si vysvětlili, technologicky omezují znovupoužívání dat. Pokud tedy poskytovatel chce data zveřejnit pod striktnější licencí, může si do určité míry vynutit dodržování této licence tím, že je zpřístupní pomocí webového API. Např. Wordnik1 API2 zakazuje lokálně ukládat svá data, tzn. pokud chceme s daty pracovat, musíme si je pokaždé znovu vyžádat na Wordnik API. API také velmi často limitují počet volání, která může klient denně provést. Tím dále omezují znovupoužívání svých dat. Linked Data technologicky podporují znovupoužívání dat a to je reflektováno i v licencích, pod kterými jsou linked datasety zveřejňovány a které jsou spíše liberální.
1 2
Wordnik je anglický výkladový metaslovník. http://developer.wordnik.com/
41
12 Závěr Z provedeného srovnání je na první pohled zřejmé, že Linked Data po technologické stránce daleko převyšují webová API. Linked Data lze např. objevovat automaticky, zatímco webová API jde nalézt jen ručně, procházením katalogů API jako je např. ProgrammableWeb.com. Webová API narozdíl od Linked Data neškálují, tj. čím více různých API existuje a s čím větším počtem API potřebuje programátor pracovat, tím více různých API (tj. dotazovacích jazyků, “URL templatů”), schémat a pomocných programovacích knhihoven se musí naučit. V případě Linked Data mu stačí znát jeden datový model (RDF), jeden dotazovací jazyk (SPARQL), jedno RDF API pro programovou manipulaci s daty a několik málo často používaných ontologií. Toto všechno činí z Linked Dat znovupoužitelnější data, než jakými jsou data dostupná prostřednictvím webových API. Nicméně web je kromě technologického prostředí také prostředím sociálním a ekonomickým. Přestože jsou Linked Data technologicky vyspělejší než webová API, zažívají webová API narozdíl od Linked Dat exponenciální růst. Tomu vděčí za svou jednoduchost a také za to, že využívají technologie, které většina webových vývojářů dobře zná. Linked Data naproti tomu využívají sice pokročilejší, ale pro běžné programátory méně známé a hůře srozumitelné technologie. Důležitým aspektem je také to, že poskytovatelé dat si nad nimi často chtějí zachovat větší kontrolu, v tom případě je pro ně lepší vystavit data pomocí webového API, která technologicky omezují znovupoužitelnost dat. V blízké budoucnosti to bude pravděpodobně vypadat tak, že webová API budou pokračovat v prudkém růstu a Linked Data budou zaostávat. To se ale může změnit ve střednědobém horizontu, až bude prostřednictvím API na webu dostupných velké množství kvalitních strukturovaných dat a vývojaři začnou chtít integrovat data z většího množství API. V takovém případě se začne projevovat, že webová API neškálují. Přirozenou odpovědí by pak mohlo být začít vystavovat data na webu jako Linked Data. Nadějí pro Linked Data je do budoucna také vývoj a existence lepších nástrojů pro práci s nimi. Zde Linked Data pořád i přes svou technologickou nadřazenost zaostávají.
42
Literatura [1] Allemang, D., Hendler, J.: Semantic Web for the Working Ontologist: Modelling in RDF, RDFS and OWL. Burlington: Morgan Kaufmann, 2009. 330 s. ISBN 978-0-12-373556-0 [2] Berners-Lee, T., Fischetti, M.: Weaving the Web: The Original Design and Ultimate Destiny of the World Wide Web by Its Inventor. New York: HarpersCollins Publishers, 2000. 246 s. ISBN 0-06-251587-X [3] Berners-Lee, T.: Linked Data, 2009 Dostupný z WWW: http://www.w3.org/DesignIssues/LinkedData.html [4] Bizer, Ch., Cyganiak, R., Heath, T.: How to publish Linked Data on the Web , 2007 Dostupný z WWW: http://www4.wiwiss.fu-berlin.de/bizer/pub/LinkedDataTutorial/ [5] Bizer, Ch., Heath, T., Berners-Lee, T.: Linked Data - The Story So Far, 2009 Dostupný z WWW: http://eprints.ecs.soton.ac.uk/21285/1/bizer-heath-berners-lee-ijswis-linkeddata.pdf [6] Fielding, R.: Architectural Styles andthe Design of Network-based Software Architectures, 2000 Dostupný z WWW: http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm [7] Langegger, A.: A Flexible Architecture for Virtual Information Integration based on Semantic Web Concepts, 2010 Dostupný z WWW: http://www.langegger.at/papers/Langegger-phdthesis.pdf [8] Heath, T., Bizer, Ch.: Linked Data: Evolving the Web into a Global Data Space, 2011 Dostupný z WWW: http://linkeddatabook.com/editions/1.0/ [9] Pollock, J.: Semantic Web for Dummies. Indianapolis: Willey Publishing, 2009. 412 s. ISBN 978-0-470-39679-7 [10] Richardson, L., Ruby, S.: RESTful Web Services. Sebastopol: O’Reilly Media, 2007. 419 s. ISBN 0-596-52926-0 [11] Svátek, V.: Ontologie a WWW, 2002 Dostupný z WWW: http://nb.vse.cz/~svatek/ontowww.doc [12] Svátek, V., Vacura, M.: Ontologické inženýrství, 2007 Dostupný z WWW: http://nb.vse.cz/~svatek/dkon07final.pdf [13] Webber, J., Parastatidis, S., Robinson, I.: REST in Practice. Sebastopol: O’Reilly Media, 2010. 428 s. ISBN 978-0-596-80582-1 [14] Zemánek, J., Svátek V.: Webová API a Linked Data: Výhody publikování strukturovaných dat na webu v souladu s tzv. Linked Data principy. Sborník konference Znalosti 2011. 338 s. ISBN 978-80-248-2369-0 [15] Zemánek, J., Schenk, S., Svátek, V.: Optimizing SPARQL Queries over Disparate RDF DataSources through Distributed Semi-joins, 2008 Dostupný z http://sunsite.informatik.rwth-aachen.de/Publications/CEUR-WS/Vol401/iswc2008pd_submission_69.pdf [16] Zemánek, J., Mynarz, J.: Úvod k linked data, 2010 Dostupný z WWW: http://knihovna.nkp.cz/knihovnaplus101/myna.htm
