Wikipedia:Gjenbruk

Gjenbruk i Wikipedia henspeiler på de vurderinger som må gjøres for at stoffet skal kunne tilpasses andre formater og bruksområder enn det som umiddelbart er opplagt, nemlig bruk i Wikipedia og på HTML-kodet form. Både den overordnede formen på artikkelen er viktig, hvordan malverket brukes, hvordan malverket defineres og hvordan dette bruker html-koden.

En mulig implementasjon av de etterfølgende prinsippene er beskrevet på undersiden Wikipedia:Gjenbruk/Schema.

Prinsipper

Gjenbruk skjer på flere nivåer; både ved å endre drakter i Mediawiki, ved at nettstedet vises frem på plattformer som har andre krav til det som skal presenteres, ved at innhold bakes sammen med annet materiale og lignende. Noen typer gjenbruk er det enkelt å forberede for, mens andre typer gjenbruk er vanskelig å forberede innenfor rammen av de eksisterende løsningene.

Det er viktig at innhold kan beskrives både som fysiske strukturer og som logiske strukturer, og at plattformene for fremvisning har fysiske og logiske føringer. En visuell presentasjon skjer som følge av at alle disse føringene interakterer.

Visuell presentasjon

Bruk av attributter for visuell presentasjon som låser verdier bør unngås hvis mulig, det samme gjelder style-attributtet som også bør unngås fordi de vanskelig kan overstyres. Når verdier settes på dette viset så låses verdien og en ikke tilpasse siden og innhold til endret presentasjon og kontekst. For å gjøre det mulig å tilpasse presentasjoner senere bør fremvisning standardiseres og legges inn i stylesheets for de respektive drakter. Det viktige er ikke hvilke stildefinisjoner som blir knyttet til klasser og identifikatorer, det viktige er at disse klassene og identifikatorene enkelt kan overstyres.

Markup for stil skal ikke gjøres som i dette eksempelet

<table width="270">…<tr><th style="background-color: #eee">Navn</th><td>Oslo</td></tr>…</table>

Derimot så skal det gjøres som i dette eksempelet

<table class="city">…<tr class="name"><th>Navn</th><td>Oslo</td></tr>…</table>

Med et tilhørende stylesheet

.city { width: 270px; }
.city .name th { background-color: #eee; }

Plattformtilpassing

Tilpassing til de enkelte mediatyper vil normalt bli håndtert via at-rules, eller via innlenkede stilark tilhørende spesifikke mediatyper. Disse er imidlertid veldig grove slik at i mange tilfeller vil det være ønskelig å ha ytterligere informasjon om de fysiske egenskapene ved mediet. Som oftest vil dette bestå i nokså enkle analyseresultater, men tilstrekkelig eksakte til at styleregler kan brukes for ytterligere tilpassing av den visuelle presentasjonen.

Innhold tilpasses plattform gjennom media-attributtet i link-elementet eller ved bruk av at-regler i stilarkene. Disse reglene er nokså grove og gir ingen granularitet innenfor de enkelte plattformene.

@all {}

For å få mer fingranulert tilpassing så kan det legges til klasser i body-elementet eller i html-elementet. Typisk vil disse beskrive noen av de fysiske parametrene for plattformen.

@all{ .$1280x1024 { background-color: #eee; } }

Navigere innholdet

Ved å bruke klasser og identifikatorer som attributter for de enkelte elementer så kan innholdet navigeres. Den produserte HTML-siden mangler mange av egenskapene som gjør det enkelt å gjenbruke innhold tagget med XML, men vi kan langt på vei oppnå det samme ved å bruke «microformat». Når innhold tagges med XML så er det de enkelte taggnavn som formidler de enkelte fragmentenes rolle. Når vi skal tagge med HTML så mangler vi disse mulighetene. Vi kan derimot merke taggene og det er dette vi gjør med klasser og identifikatorer.

Normalt ville en navigere innhold med en path-like Xpath-streng, men fordi vi bruker klasser og identifikatorer så vil Xpath-strengen bli noe uvanlig. Hvis data for eksempel er lagret i en tabellrad så kan HTML-koden se ut som følger

<table class="city">…<tr class="name"><th>Navn</th><td>Oslo</td></tr>…</table>

For å navigere til datafeltet i denne konstruksjonen så vil en bruke en Xpath-konstruksjon ala

table[class~="city"]/tr[class~="name"/td

Avansert

For å forenkle gjenbruk ut over det som kan oppnås ved å fjerne hardkodet stil og manipulere med klassebegreper, så kan dagens parser modifiseres slik at isteden for at HTML produseres direkte så produseres det et mellomresultat i XML. Dette mellomresultatet kan så brukes for å lage en fullstendig HTML-side på serverne eller det kan leveres til nettleserne som så bruker XSLT for å produsere endelig HTML-kode. Dette er analogt med hva som skjer idag når SVG brukes for å lage grafikk, kan nettleseren håndtere SVG så genereres presentasjonen i nettleseren.

Parseren produserer allerede XML, men da et format for å forenkle intern prosessering. Skal vi gå over til å bruke mer omfattende mellomresultater i XML så forutsetter dette at det blir gjort en utviklingsjobb av moderat størrelse.

Ingress

I ingressen (section 0) så må artikkelens hovedtrekk oppsummeres. Første setning oppsummerer hovedtrekkene ved artikkelen, deretter vil påfølgende setninger være mer og mer beskrivende for spesialiserte felt ved det omtalte. I denne innledende teksten så kan en med fordel ta utgangspunkt i hva som ville blitt tatt med i et konversasjonsleksikon. Ta utgangspunkt i informasjonen, men skriv uten forkortinger.

Innenfor rammen av en SMS (140 tegn) skal tilstrekkelig informasjon presenteres til at en leser kan avgjøre om oppslaget er riktig. Slike tjenester blir levert av flere aktører internasjonalt. Det er også flere aktører som ser på ompakking av Wikipedia for nye plattformer og da er disse innlednignene stadig viktigere for å oppnå rask og presis navigering.

Fordi ingressen skal brukes i situasjoner hvor referanseverket ikke er tilgjengelig så bør den ikke inneholde referanser. Det som fremkommer i ingressen bør dokumenteres senere i artikkelen. Ingressen skal kun inneholde det som er essensielt og som kan beskrives innenfor de begrensede rammene. Merk at det er mulig å lage maler som under gitte vilkår utelater referanser.

Tekst i ingressen kan bli omskrevet av automatiske algoritmer for å forkorte den ytterligere. Det forutsetter at artiklers ingress er entydig skrevet og uten unødig lange og kronglete setninger.

Hvis for mye tekst legges i ingressen så brukes <onlyinclude> til å merke hva som er essensielt.

Infobokser

Infobokser har en rolle hvor faktamateriale legges ut metodisk i en boks i artikkelen. Dette materialet er det svært viktig å gjøre tilgjengelig andre, og for å få til dette brukes det parametriserte kall til et malverk. Selve malen innehar presentasjonsrollen mens parametrene former malens kontrakt med artiklene.

Malverk som bruker {{Infoboks start}} bør angi en typeparamter slik at infoboksene kan gjenkjennes etter prosessering ved at de får et klasseattributt, {{Infoboks katedral}} får en klasse «katedral», eller hvis denne parameteren mangler så bør den legges inn på riktig sted i malverket. I tillegg bør infobokser angi den overordnede typen i klasseattributtet, det vil si «infoboks».

Infobokser legges foran ingressen (section 0) slik at de blir tilgjengelig selv om kun artikkelens innledning lastes ned via APIet.

Parametre

For å forenkle skifte fra og til forskjellige maler bør begrepsapparatet holdes mest mulig likt innenfor et tema. Infobokser som har overlappende felt bør derfor bruke samme navn på disse feltene i de forskjellige malene. For eksempel blir det vanskelig å skifte fra en mal til en annen om «posisjon» blir til «georef». Bruk av nummererte felt bør unngås, og også bruk av oppføringer uten tilhørende tittel. Entydig navngivelse av parametre er spesielt viktig for å forenkle parsing av selve wikikoden.

Brødtekst

Når plattformen krever det så bør brødtekst settes i flere spalter for å gjøre den enklere å lese. Dagens formatering plasserer paragrafer flatt i en div som har alt innhold. Dette gjør det vanskelig å formatere brødtekst i flere spalter. Hvis section-taggen fra html5 tas ibruk så er det å håpe at den vil innkapsle brødtekst på et slikt vis at det blir enklere å fordele tekst over flere spalter. Dette er spesielt aktuelt ved presentasjon på andre formater enn i en tradisjonell nettleser.

For presentasjonsformål kan det være aktuelt å bruke et script for å samle brødtekst hørende til en seksjon på h2-nivå i et section-element. Omfattende parsing i nettleseren bør imidlertid unngås om det er mulig da det forsinker den endelige rendringen av siden og gir en dårlig leseropplevelse.

Tabeller

Svært mange av Wikipedias tabeller er hardkodet til bestemte utlegg og bestemte presentasjoner. Disse vil ofte gi et godt resultat på skribentens egen skjerm, mens den kan gi et helt ubrukelig, eller noe nær ubrukelig utlegg på andre plattformer. Typiske gjengangere er hardkodet farge og/elelr fonter og/eller bredde og høyde, både på enkelte tabellelementer og på tabellen som hele. I mange tilfeller er også utlegget varierende gjennom tabellen, med mye bruk av colspan og rowspan, noe som gjør det vanskelig å parse tabellen i etterkant. Veldig mange av problemene som oppstår er knyttet til hva de enkelte parametre og attributter betyr når en tar ut spesifikke slices og/eller transponerer tabellen.

Det bør lages noen klasser som løser de mest typiske problemene knyttet til formatering av tabeller. Det kan også med fordel lages et script som setter noen standardklasser om det ikke er satt andre klasser, gitt at det er overveiende sannsynlig at tabellen brukes for innhold på siden. Slik automatisk setting av klasser vil kunne redusere behovet for manuell formatering og gjøre det mer attraktivt å bruke ferdige løsninger. Det bør også i større grad legges inn tester i de enkelte scriptene som slår av funksjonalitet når tabeller settes opp slik at scriptene vil feile.

Lister

Lange lister i en kolonne når det er tilgjengelig større bredde på plattformen som brukes for fremvisning er uheldig. Dette avhjelpes ofte ved å angi at de skal settes i et nummerert antall spalter, men dette blir feil når plattformen har andre og gjerne smale dimensjoner. Det bør derfor legges opp til andre og mer fleksible løsninger.

Et eksempel på en mal som legger opp til å sette antall antall spalter er {{reflist}}. Denne malen kan også sette en spaltebredde, men dette er upålitelig i enkelte nettlesere. Enkelte nettlesere overser også styling i flere spalter overhodet, og eneste mulighet for å få utlegg i flere kolonner er å kode om presentasjonen for disse nettleserne og plattformene.

Det bør legges opp til å angi listas krav til minste spaltebredde, slik at dette kan kombineres med innholdets bredde på den aktuelle plattformen. Lister med uspesifisert bredde settes utfra innholdets bredde på den aktuelle plattformen. I tillegg kan det være en fordel å bruke script for å påvise hvorvidt det er ønskelig å fordele stoff over flere spalter, det vil si om antall oppføringer i lista er for lite til at dette er hensiktsmessig.

Navigasjonbokser

Dagens navigasjonsbokser bruker flere strategier for hvilken lenker som tas med og hvordan de presenteres. I prinsippet virker det som om de fungerer som en eller flere emneinnganger til materialet, ofte på tvers av eksisterende kategoriseringer, eller som snitt mellom kategorier, eller som utdrag av snitt mellom kategorier. Fordi de er nokså arbeidskrevende å lage om enn enkle å bruke, så blir de stort sett bare lagd når utvalget kan listes opp entydig. Hvis innholdet endrer seg over tid så blir de stort sett ikke laget.

Navigasjonsbokser bør angi typen uttrekk i tillegg til å angi den visuelle presentasjonen. For eksempel kan en i en title-attributt angi «lakes» for en navigasjonsmal for innsjøer, til forskjell fra en infoboks som bør identifiseres som «lake». Hvordan det skal angis at det er et uttrekk av innsjøer i for eksempel Finnmark er uklart, men det er kanskje underforstått av artikkelens kategorisering.

Geografisk navigasjon

Det brukes en del geografisk navigering via forskjellige interne og eksterne verktøy. Disse fremstår nå som nokså ustrukturerte og vanskelig gjenbrukbare. Det er brukt flere forskjellige måter å presentere geografisk informasjon, både når det gjelder koordinatsystem og tildels datum.

Det foreslås at det ses på hvorvidt noen av de mest aktuelle koordinatsystemene kan konverteres til et felles koordinatsystem og datum, og at endringer til andre koordinatsystem og datum, og lenking videre til nett-tjenester blir gjort via script. Dette vil gjøre at koordinatsystem og datum er forutsigelig og entydig i HTML-koden.

For å forenkle gjenbruk i de tilfellene hvor kun artikkelens innledning lastes ned så foreslås det at geografisk posisjon legges i en mal som plasseres i starten av artikkelen (seksjon 0).

Kildemaler

I kildemaler bør alle felt tagges slik at det er mulig å traversere referanseseksjonen etter at den er gitt en HTML-form. det betyr at enkeltfelt slik som forlagshus pakkes inn et span-element som så merkes med klassen publisher. Tilsvarende kan andre felt merkes med klasser som beskriver deres funksjon.

Forskjellige brukere har forskjellige ønsker om hvordan kilder skal presenteres. Det gjør at kildelistene blir uforutsigelige. Det vil derfor være en fordel om kilder tagges på entydig vis og at alternative utlegg løses gjennom script som slås på via Special:Innstillinger.

Fordi det er masse kilder som brukes hvor skribentene ikke bruker kildemalene så bør det lages en eller annen løsning som gjør det mulig å innlemme disse på en enkel måte.

Relaterte initiativ

Det finnes flere initiativ som vil påvirke hva som er teknisk mulig å få til, og hva som kan implementeres via eksterne og effektive mekanismer. Slike mekanismer er ikke nødvendigvis førende for hva som bør implementeres på Wikipeia, men det vil være uheldig om det blir gjort metodevalg som gjør de forskjellige løsningene inkompatible eller vanskelige å bruke.

Schema.org

Sett av formater brukt for å merke data som gjenkjennes av flere søkemotorer. Strukturen de har beskrevet er nokså omfattende.^[1] For å transportere strukturen brukes microdata. Denne løsningen er ikke støttet i Wikipedia, men kan slås på. Som en foreløpig løsning kan de samme typene brukes i microformat, og så kan en eventuelt legge til microdata senere.

Wikipedia:WikiProject Microformats

Commons:Microformats Project

Wikitravel:Microformats

Dataset Publishing Language

Dataset Publishing Language^[2] er et konsept og verktøy brukt av Google for å gjøre det enklere å gjenbruke datasett, spesielt at de enkelt kan brukes for visualiseringer. Løsningen baserer seg på opplasting av spesielt formaterte CSV-filer med tilhørende XML-filer for metadata og andre tjenester må da kunne lage disse og laste de opp. Wikipedia er ikke forberedt for slik opplasting og direkte bruk av tjenesten for visualiseringsformål er derfor vanskelig. Infoboksene må for eksempel ha tilhørende metadata som beskriver de, og slike metadata finnes ikke.

Datasettene er derimot tilgjengelige og gjenbruk av disse i Wikipedia kan være aktuelt. Wikipedia mangler metoder for enkelt gjenbruk av slike publiserte data, men om ikke annet så kan dette skje via Javascript – om ikke annet under redigering av sider.

I forbindelse med DSPL er det utviklet noen Canonical Concepts^[3] og disse er nyttige når vi skal lage identifikatorer for infobokser i Wikipedia. Disse er entity, geo, geo.us, quantity, time og unit. Vi bygger da videre på disse mer grunnleggende definisjonene for å skape nye og mer spesifikke definisjoner. Vær spesielt oppmerksom på unit som kan gis mange avvikende varianter selv om den faktiske størrelsen er den samme. Husk også på at dette er måleenheten, mens selve måleverdien ligger i CSV-fila. En infoboks vil ha både måleenhet og måleverdi i samme boks. Vær også oppmerksom på at geo opererer med latitude og longitude desimalgrader, mens store deler av Wikipedia opererer med bueminutter og -sekunder. I tillegg er det vanlig med UTM i Europa. Det er heller ikke oppgitt datum, noe som gir en viss usikkerhet om hva som faktisk oppgis.

SPARQL

SPARQL er et RDF spørrespråk for å hente ut og slå sammen informasjon fra nettsider.

Yahoo! Query Language

Yahoo! Query Language^[4] er et konsept og verktøy brukt av Yahoo! for å hente inn data fra frittstående sider på nettet. Løsningen baserer seg på flere former for spørrespråk (blant annet CSS-selektorer og Xpath) hvoretter data fra flere kilder kan kombineres via konstruksjoner i YQL som i sin tur minner om SQL. Dette gjør det spesielt attraktivt å bruke løsningen når data fra forskjellige domener skal kombineres for å lage nye aggregeringer, da blant annet Javascript har sandboxing av AJAX og aktivt hindrer slik aggregering. Istedenfor å bruke AJAX i klienten henter en da resultatene fra Yahoo! sin YQL-server som spesielt formaterte scriptfiler, såkalt JSONP.

Bruk av YQL forutsetter at de aktuelle nettsidene er rimelig velformede. Løsningen vil forsøke å parse sidene selv med mye feil, men da sidene ryddes ved å kjøre de gjennom verktøyet tidy før de parses så kan sidene få en noe annerledes struktur enn det en selv observerer. Det gjør at det kan være vanskelig å skrive fungerende CSS-selektorer eller Xpath-uttrykk. Dette vil også gjøre at en del uryddig koding av infobokser vil feile, den resulterende koden er noe annet enn det en tror, selv om sider fra Wikipedia rydes med tidy før publisering. Sjekk den resulterende koden, det er ikke sikkert formen er den du trodde du skulle få.

YQL mangler en del funksjonalitet en normalt skulle forvente at var tilgjengelig. Spesielt bør en være oppmerksom på at løsningen ikke klarer å identifisere enkeltstående klasser i class attributtet, elelr tilsvarende i andre attributter. Det gjør at skal YQL fungere tilfredsstillende så må strenger som brukes for å identifisere roller og egenskaper skilles ut i egne attributter. En rad i en infoboks som identifiserer «høyde» kan da ikke stå sammen med andre klasser i class, den må settes i en annen attributt. Typisk vil en da spesifisere egenskapen «høyde» via title og kalle den «altitude».

Eksempler

(console, jsonp) select * from html where url="http://se.wikipedia.org/wiki/M%C3%A1ze" and xpath='//div[@class="infobox"]/*/caption'
(console, jsonp) select * from html where url="http://no.wikipedia.org/wiki/Fagernes" and xpath='//table[@class="infoboks geografi"]'
(console, jsonp) select * from xml where url="http://en.wikipedia.org/w/api.php?action=opensearch&search=Bagn&format=xml"

Merk at YQL har problemer med å gi XML-formaterte svar, bruk JSON-format (aka JSONP).

Merk også at siste eksempel nå løses enklest ved bruk av JSONP direkte i APIet til Wikipedia, og at formatet på dette kallet er udokumentert.

Microformat

Et tidlig initiativ på å embedde maskinlesbar informasjon i HTML-kode er microformat. Dette formatet er det som kanskje har fått størst utbredelse. Det pågår et arbeid for å lage et malverk Hjelp:HBox som bruker dette formatet. Ulempen med formatene er hovedsakelig at de krever en del koordinering i og med at dette baserer seg på gjenkjennbare klassenavn.

Microdata

Microdata i HTML5 er iferd med å bli formalisert via HTML Microdata – W3C Working Draft 13 January 2011.^[5] Dette utkastet introduserer flere nye konsepter og metoder og kan erstatte eller utvide mekanismene som er foreslått brukt i dette dokumentet. Microdata har flere forskjeller fra Microformat, hvor Microformat er basert på eksisterende standarder mens Microdata er en ny og noe avvikende standard. Det er viktig å merke seg at dette er work in progress og at et fåtall nettlesere (ingen?) støtter de foreslåtte metodene.

Arbeidsutkastet sentrerer rundt bruk av attributter itemid, itemprop, itemref, itemscope og itemtype. Verdien til de enkelte oppføringer kommer fra implisitte regler som henter ut verdier fra de tilhørende elementene. Ekstraherte data blir plassert i et parallelt DOM-tre, i en JSON-struktur eller i et RDF-tre. Det er mulig å bruke både lokalt definerte typer, typer definert innenfor et nettsted og globale typer. For de to siste bruke URLer som identifikatorer, for den første brukes navn.

RDFa

Embedded RDF

Aktuelle verktøy

Firefox

Referanser

Eksterne lenker

[1] Schema.org: The Type Hierarchy

[2] Dataset Publishing Language: Describe your data to enable powerful visualizations

[3] Dataset Publishing Language: Canonical Concepts

[4] Yahoo! Query Language

[5] W3C: HTML Microdata: W3C Working Draft 13 January 2011

[1]