Utfordringer med metadata

Med neste versjon av Vortex, vil metadata, og søk i disse, bli tilgjengelig som en basistjeneste på UiOs nettsted. Dette gir en rekke nye muligheter, men aktualiserer også mange problemstillinger som har blitt liggende en stund.

Samtidig som vi får et nytt sett med verktøy på UiOs nettsted, er kvaliteten på, og nytten av, disse tjenestene avhengig av at prosessen rundt strukturering og tematisering av nettstedet får klarere målsetninger og en tydeligere strategi. Vi trenger å kunne vurdere utfordringer som dukker opp mot hvor vi vil med strukturen på nettstedet. Under følger noen raske punkter om disse utfordringene.

Tematisering av nettstedet

For å kunne plassere og vise fram enkeltressurser i en kontekst trenger vi å 

• vite mest mulig om denne konteksten
• dekorere nettsidene med elementer som nyttiggjør seg denne kunnskapen

Offisielle sider på nettstedet har idag en kontekst hovedsaklig begrenset til enhet og tema. Denne kunnskapen om dokumentene har vært avhengig av at den enkelte utlegger har lagt denne informasjonen inn i dokumentet. En del nettsider, hovedsaklig framvist av egenutviklede applikasjoner, har ikke hatt denne konteksten, engang.

Ønsker vi å bygge bedre kontekstualisering av informasjonen og bedre muligheter for innganger til informasjonen, krever dette en stor utvidelse av hva vi vet om dokumentene.

Støttet infrastruktur

Å støtte et utvidet metadata-sett på UiOs nettsted er en stor utfordring. Idag er det slik at filer servet med apache og vortex, kan få pålagt den visuelle profilen. Andre løsninger opererer stort sett med en dekorering som ligner profilen, uten metadataene knyttet til.

Hva slags verktøy og løsninger ønsker man å integrere i nettstedet og dets metadata-håndtering?

Eksempler på verktøy og løsninger:

• Egenutviklede web-applikasjoner (SAUS)
• Egenutviklede web-applikasjoner (Andre)
• Uklare (DUO, Frida, Studentweb, ...)
• Innkjøpte applikasjoner (Alumnus)
• Innkjøpte systemer (Classfronter)
• Småapplikasjoner (php, andre ting)
• Flate filer med Apache
• dagens metadata-løsning
• Vortex
• muligheter for utvidet metadata-løsning
• ...

Sentralisert kontroll med ontologien

For å komme igang med en prosess rundt metadata, trenger vi et enkelt system for å holde oversikten over metadata, forholdet mellom dem, vokabularer o.s.v.

Innhenting av metainformasjon (med Vortex)

Grovt sett har vi fire mulige strategier for å bygge metainformasjon om ressurser på UiOs nettsted, basert på vortex.

• metainformasjonen hentes fra dokumentene selv
• metadata registreres manuelt utenfor dokumentene
• registrering på ressursen med properties
• plassering innebærer metainformasjon
  

Registrering utenfor dokumentene

Noen steder vil mye av verdien ligge i en redaksjonell utvelgelse av ressurser. Som en generell mekanisme er ikke dette låst til å gjøres utenfor dokumentene, men noen steder vil det være en aktuell mulighet. Generelt blir metadataene mindre nyttige hvis de ikke er tilgjengelige der dokumentene de beskriver skal vises eller redigeres, men det som et supplement kan det være nødvendig.

Redaksjonell kontroll krever fort relativt store ressurser og et gjennomtenkt system for hvordan det skal gjøres. Hovedgevinsten er den redaksjonelle kvalitetssikringen dette innebærer, noe som gjør det aktuelt i noen sammenhenger, som på viktige oversikter.

Ekstrahering av metainformasjon

For generelle filer på nettsidene er det begrenset med metainformasjon som kan hentes ut fra dokumentet. Fra HTML-dokumenter begrenser det seg stort sett til at det er ett html-dokument, tittel og kanskje tegnsett.

For domener hvor det er gjort en spesifikk utviklingsjobb, i form av XML-dokumenttyper, er det derimot mulig å hente ut mye informasjon. Det viktigste er kanskje selve dokumenttypen, men de fleste dokumenttypene vil også inneholde annen informasjon som beskriver sitt domene.

Properties

Med vortex står vi relativt fritt til å utvikle metadata-sett som kan beskrive ressurser uavhengig av format, plassering og så videre. Styrken til properties er at de nettopp er uavhengige av innholdet, de kan registreres på mapper, html- og xml-dokumenter om hverandre.

Hovedproblemet med properties er hvis avstanden mellom redigeringen av innholdet og property-ene oppleves som stor av brukeren. For et nettsted som UiO, er man avhengig at forholdet mellom opplevd nytte av å registrere metadataene oppleves som større en kostnadene for de som lager innholdet.

Filstruktur

Hvis filstrukturen kan bygges slik at den reflekterer viktige kontekster for dokumenter på UiOs web, gir dette store gevinster. Et enkelt eksempel er for eksempel at vi kan vite at en pensumliste som ligger i en emnemappe, gjelder for dette emnet.

Hvilke kategoriseringer som eventuelt skal ligge i filstrukturen, og hvordan, er ikke noen enkel problemstilling å ta fatt på.

• hvilke kategorier er akseptable å synliggjøre på denne måten (for eksempel med hierarkisk sti)
• hvilke typer kategorier skal være primære (øverst) og hvilke skal være underkategorier
  
• hvordan skal vi forholde oss til kategorier som finnes flere steder (www.uio.no/studier og www.enhet.uio.no/studier)?

Men gevinstene er samtidig åpenbare. Utleggere av informasjon vil få synlige ekstragevinster uten at det stiller store krav til dem:

• Profil, både gjenkjennbar som en del av UiOs web og utvidbar med kontekstualiserte elementer
  
• Navigasjonselementer til viktige kategorier kan legges på automatisk
• Stier
• Navigasjon til relaterte temaer
• Oversiktssider kan genereres og ved hjelp av kontekstinformasjon gjøres oversiktlige

Men det viktigste er at det gjør det mulig å tenke seg større sentralistert kontroll over nettsidene, uten at det krever mer av de lokale miljøene enn nødvendig. Det representerer en mulighet for å bedre tematiseringen og opplevelsen av webben, og for spesifikke områder, uten at dette setter store krav på den som legger ut den enkelte side. Dette vil forhåpentligvis innebære at kvaliteten på metainformasjonen blir god.

Filstrukturen har med andre ord potensiale til å gi

• metainformasjon av høy kvalitet
• uten et arbeidskrevende og kompliserende system
• med synlige gevinster for utleggere og lokale enheter
  
• uten store krav til utleggere og lokale løsninger
  
• gir verdi i tillegg til andre mekanismer
  

Kontekster i filstrukturen

En kontekst er en meningsbærende plassering i filstrukturen.

Eksempler fra dagens system

• enheter og temaer
• kan arves, slik at dokumenter under en mappe får disse egenskapene satt
  
• emne, studieprogram osv.
• brukes aktivt som kontekster i den spesifikke studinfoløsningen
  
• disputas, prøveforelesning, arrangement osv.
• grupperer oppslag i kategorier
  

Søk og visning på tvers av kontekster

Visning av oversiktssider basert på søk, er tenkt som en generell tjeneste på UiOs nett. En slik tjeneste er avhengig av eksistensen og kvaliteten på metadata vi skal søke i. Når søkeresultater skal vises frem utenfor enkeltressursenes kontekst, må denne konteksten vises som en del av resultatet. Eksempler som illustrerer dette:

• Semesterside må identifiseres av emne, når det vises utenfor konteksten emne
• En disputas må identifiseres som disputas når den vises sammen med andre arrangementer
• En nyhet må identifiseres med "publikasjon" (apollon, uniforum), når den er utenfor publikasjonenen.
  

Utfordringen er at vi må gi alle søkeresultater et felles sett med egenskaper å vise fram. Den eneste realistiske måten å gjøre dette på er å bruk filstrukturen for de viktigste egenskapene.

Huskeliste

Kontekst kontra metadata på enkeltressurser

• Kontekst innebærer mye det samme som arv av properties (kontekster istd.for arv?)
• Formalisering av koblingen mellom en kontekst (emne) og index-fila (beskrivelsen)
  

Webben som enkel filstruktur

• kontekstualisering krever kontroll og begrensning av mulighetene til å se på strukturen som en enkel filstruktur.
• Låser kontekstene mer inn i systemet
• Enkeltressurser kan behandles friere (ikke like avhengig av at systemet bevarer properties på ressursene)
  

Trenger vi noe mer enn ledelsesrapporter og datavarehus?

---

Enhet: USIT, webredaksjon@usit.uio.no
Dokument opprettet: 31.05.2006, endret: 20.06.2006Administrer dette dokumentet