Fedora Content Model en XSLT Fedora op Klompen, Amsterdam, Egbert Gramsbergen TU Delft Library / Digital Product Development

Motivatie •De meeste datastreams zijn xml •De meeste disseminaties zijn x(ht)ml •xml -> x(ht)ml : XSLT •Fedora heeft interne xslt service •Gebouwd met Saxon, ondersteunt xslt2.0 •XSLT zelf kan als datastream in Fedora object •Werkende disseminaties door enkele objecten, zonder programmeren

XSLT processing model XML parameters secundaire input documenten secundaire output documenten Voor Fedora context: relevant gewenst niet relevant extension: Java classes

Overige ingrediënten •Content Model Architecture (Fedora 3.x) –data object heeft alleen relatie met Content Model –alle gedrag (disseminaties) wordt van daaruit geregeld •RDF (RI index) –gevuld uit DC en RELS-EXT datastreams –RELS-EXT voor relaties tussen objecten –queries via REST API •REST API (API-A-LITE) –in: URI, uit: (meestal) xml –datastreams, disseminaties, queries –alles te gebruiken als secundair input document xslt

Toepassingen Van alles. Gewoon html genereren maar ook… •Navigatie tussen gerelateerde objecten •Aggregatie van content of metadata van gerelateerde objecten Bijvoorbeeld… •Een profiel van persoon verrijken met links naar zijn/haar artikelen en gegevens van zijn/haar organisatie •Datasets aanvullen met gegevens over apparaat, studie, lokatie, links naar gerelateerde datasets •“Jump-off” pagina’s maken voor collecties, instituten, hele repositories •“Dumbed-down” Dublin Core samenstellen voor OAI-MPH (+ namespace reparatie) •ORE Resource Maps genereren

Content Model Architecture welke datastreams?welke services? <= abstract (hieruit volgen URIs van disseminaties) <= implementie data object koppeling met web services, bijv. Saxon Object RDF in RELS-EXT van vertrekpunt pijl

URI’s in CMA • /fedora/get/ / • /fedora/get/ / / [?params] Service Deployment komt hier niet in voor! N.B. Alle relaties in CMA zijn n-n Dus bijv: •n SDefs voor 1 Content Model •n SDeps voor 1 SDef (bijv. verschillend per Content Model) •n Content Models voor data object TODO experiment: wat als zich meer SDeps aanbieden?

XSLT 2.0 vs. 1.0 XSLT 1.0 was goed in manipulatie van XML trees (nodesets) XSLT 2.0 voegt toe: •Text manupulatie –Regex, uri’s, date/time, allerlei extra functies •xPath 2.0 (ook basis van xQuery) –Sequences i.p.v. nodesets –Conditionals, iteratie, set operations •Multipass processing •Type system (gebaseerd op xml Schema) •Functies (toegang vanuit xPath) •Semi-gestructureerde data structureren •Multiple output docs •Standaard extensie mechanisme Resultaat: glijdende schaal van simpel template naar bijna complete (declaratieve) programmeertaal

Voorbeeld xslt fragment URI bakken voor query in RI index: <![CDATA[ select $id $title from <= ITQL, een RDF query taaltje where $doc $title and $doc $id and $doc ]]> en even verderop het resultaat verwerken:

Resultaat

Wat nog ontbreekt XSLT parameters setten Kan met Saxon, maar niet geïmplementeerd in service (feature request ingediend) Dus wat nog niet kan (bijv): •Query resultaten pagineren •Een lijst maken van leden van een collectie die tevens voldoen aan een bepaald Content Model •De schaal of range van een grafiek aanpassen En nog een foutje: MIME type (anders dan HTML) wordt genegeerd

3TU Datacentrum (ontwikkelsite) •Repository navigatorRepository navigator •Dynamic DCDynamic DC