Month: December 2008

Pokud jste někdy řešili úkol tvorby reportů, určitě jste při hledání vhodné technologie neopomenuli prohlédnout nebo dokonce použili JasperReports. Tento framework poskytuje flexibilní šablonovací nástroj založený na vlasním XML formátu, který navíc můžete navrhnout v grafickém WYSIWYG editoru iReport od stejných tvůrců. Škála výstupních formátů je širová – hlavně PDF a XLS budou zajímavé. Pokud se chcete o nástroji dozvědět více, doporučuji krátké představení nástroje a integrace se Springu od Vlasty Vávrů nebo tutorial z ČVUT.

Minulý týden jsem řešil přípravu několika reportů nad Oracle databází. Výhodou bylo, že máme nainstalovaný JasperServer – ten slouží k hostování, správě, automatizovanému spouštění reportů a správě vygenerovaných reportů. Pro editor iReport je vytvořen předinstalovaný plug–in, kterým můžete server spravovat. Stačí přidat adresu a přihlašovací údaje, do widgetu se vám načte kompletní obsah, se kterým můžete manipulovat a vlatní šablony přímo v editoru upravovat. Co nepřidalo na jednoduchosti, byl požadavek na vstupní parametry. Např. volba jedné ze stavů faktury, či omezení časového intervalu. Protože mě to stálo minimálně den pátrání, popíšu, jak vytvořit na JasperServeru znovupoužitelné vstupní komponenty, jejichž výčet hodnot se načítá z databáze.

Základem je mít v šabloně reportu vytvořené vstupní parametry. Jméno vstupní komponenty se musí se jménem parametru shodovat! Máte–li šablonu hotovou, můžete připravit vstupní komponenty. Pro naplnění komponenty daty potřebujete Query (dotaz). Nabídku Add > Query najdete po pravém kliku na některou složku v JS plug–inu. Záložka General vyžaduje vyplnit Name (ID komponenty) a Label (libovolný popisek pro orientaci na JasperServeru). Záložka Query poskytuje volby pro vlastní získání dat. Je třeba zvolit dotazovací jazyk (např. SQL, EJBQL, HQL či XPath), najít již definované spojení na datový zdroj (databázi) a zadat vlastní dotaz.

Máte–li definovaný Dotaz, můžete vytvořit vlastní vstupní komponentu. Dialog najdete pod Add > Input Control. Ze zajímavých voleb uvedu Type, který je třeba nastavit na Single Select Query, dále najít na JasperServeru námi definovaný dotaz a pak, Value Column určuje jméno sloupce s hodnotou. Naopak Visible Query Columns sloupce, které budou v roletce zobrazeny.

Když vytvoříte všechny potřebné komponenty, otevřete si strukturu vašeho reportu (Report Unit) a všechny postupně připojte přes volbu Link an Existing Input Control (pravý klik na Input Controls). V této chvíli jsou již nabízený v komponentách správné hodnoty a report je pak se zvolenými hodnotami předanými přes parametry spuštěn a vygenerován.

RDF, jako klíčová technologie sémantického Webu, umožňuje zápis informací a jejich výměnu. Data jsou zapisována jako trojice (předmět, predikát a objekt) a dohromady pak tvoří graf. Výhodou pak je, že existuje mnoho notací, jak graf zapsat. Nejznámější je určitě RDF/XML nebo třeba Notation 3. Mezi ty méně známé pak jistě patří RDF/JSON vytvářený skupinou Talis. Nabízí se srovnání se dvěma jmenovanými – „výřečností“ může konkurovat XML notaci, ba ji i předčit, ale někdy se může podpora v JSONu hodit. Krátká ukázka N3 a RDF/JSON pro porovnání:

<http://example.org/about>
  <http://purl.org/dc/elements/1.1/title>
  "About page" .

{
  "http://example.org/about": 
  {
    "http://purl.org/dc/elements/1.1/title":
    [
      {
        "type": "literal",
        "value": "About page"
      }
    ]
  }
}

I tuto notaci používá dříve zmiňovaný projekt OpenVocab pro management ontologií.

Na informace o projektu OpenVocab jsem narazil nedávno a už představení jeho současných i plánovaných funkcí mne zaujalo. O co jde? Sémantický Web je založen zejména na strojově čitelných datech a jejich výměně. Ty musí být kódovaný použitím nějakého schématu (RDFS) či lépe ontologie (OWL). Existuje mnoho „standardů“ jako FOAF, DOAP, Dublin Core… V některých případech ale potřebujete vytvořit vlastní koncepty (třídy) či atributy. Pak máte na výběr buď vytvořit jejich popis v některé z notací RDF (obvykle RDF/XML), přemýšlet nad tvarem URIref jednotlivých konceptů a následně vše publikovat, a nebo je zde právě OpenVocab.

Ve zkratce se jedná o kolaborativní hosting a tvorbu pojmů z ontologií, kdy data lze tvořit, sdílet a upravovat v rámci otevřeného systému. Ten pak poskytuje unifikovaný tvar adres, koncepty jsou zpřístupněny jako Linked Data a také v rozličných formátech – RDF, XHTML, JSON, Turtle. Linked Data znamená, že každá URIref (URL adresa) označující termín vrací na požadavky hlavičku HTTP 303 See Other a přesměrování na jinou prezentační verzi s informacemi o tomto konceptu. A to podle preferencí agenta (obvykle RDF pro stroje a XHTML pro prohlížeče).

Technicky, data jsou uložena v RDF úložišti Talis Platform a jsou přístupná přes SPARQL. Zdrojové kódy a dokumentaci projektu najdete na Google Code. Projekt navazuje na původní vocab.org, který pouze poskytoval prostor a neměnnou doménu pro různé ontologie, ale posunuje celou ideu dál. Zajímalo by mne, jestli autor bude ontologie publikované na vocab.org migrovat do nového systému.

Během práce na komunitní stránce Knowledge Engineering Group, která je kompletně implementována nad RDF úložištěm, jsem narazil na jeden problém s nekompatibilitou se standardem SPARQL. Používali jsme framework RDF API for PHP, což je téměř zažitý standard pro PHP aplikace pracující s RDF. Nyní popíšu náš případ užití. Měli jsme v úložišti několik instancí typu foaf:Group; některé měly jeden atribut foaf:name, jehož hodnotou bylo jméno v anglickém jazyce a jiné měly dva atributy foaf:name, jeden v angličtině a druhý v češtině. Jedním dotazem jsme chtěli zvolit obě jména a zobrazit je v XHTML editoru. SPARQL dotaz vypadal následovně:

PREFIX foaf: <http://xmlns.com/foaf/0.1/>
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
SELECT ?group ?nameEn ?nameCs
WHERE {
  ?group rdf:type foaf:Group .
  ?group foaf:name ?nameEn .
  OPTIONAL {
    ?group foaf:name ?nameCs .
    FILTER (lang(?nameCs) = "cs") 
  }
  FILTER (lang(?nameEn) = "en")
}

Když jsem však spustil dotaz vůči databázovému úložišti RAP, dostal jsem chybný výsledek dotazu – ten obsahoval pouze zdroje, které měly obě dvě jména. Dvě hodiny jsem opravoval dotaz, než mi Aristo potvrdil, že je správně. Navíc, služba OpenLink Virtuoso hostovaná na DBpedii vrátila korektní výsledek. Protože se zdá, že RAP je zmražený projekt, rozhodli jsme se migrovat náš kód z RAPu na ARC2 s očekáváním, že tento dotaz bez chyb spustíme a získáme správný výsledek. Bohužel, přepis kódu do ARCu náš problém nevyřešil. Po znovu spuštění skriptu jsme dostali jiný, avšak opět nesprávný výsledek. Toto nás donutilo prozatím vypustit česká jména z naší implementace a hledat zdroj či vysvětlení potíží. Alespoň stručnou odpověď jsme získali z přehledového reportu implementací SPARQLu od W3C. RAP ani ARC nepodporují 100% OPTIONAL promněnné. Navíc, z nejznámějších RDF frameworků má kompletní podporu pro SPARQL pouze Jena a Sesame2. ARC budeme používat v dalším vývoji a doufat, že podpora SPARQLu bude někdy kompletní…