Merk: Dette er et midlertidig dokument!

Plan for 2.0, metadata og søking

I utganspunktet er hovedmålsetningen for denne versjonen av vortex er å lage gjennomtenkte, generelle løsninger for søking i ressursers veldefinerte og kontrollerte innhold og egenskaper.

For å få til dette, er vi nødt til å gjennomgå måten vi forholder oss til innhold og egenskaper på i systemet. Vi må lage et rammeverk for å få bedre kontroll over og sammenheng mellom egenskaper vi forholder oss til i forskjellige deler av systemet. Ikke bare at søkesystemet ikke definerer metadata på ressurser uavhengig av andre deler av systemet, egenskapene må være enhetlig definerte og tilgjengelige i alle deler av systemet.

Metadataarbeidet for 2.0 er grovt estimert til 16 uv., men det er en del usikkerhet knyttet til dette estimatet. Gitt at fundamentale problemer ikke oppstår bør  arbeidet kunne ferdigstilles til 20. mars.

Dagens løsning

Vi har idag en rekke forskjellige måter å forholde oss til innhold og egenskaper på. Gradvis har vi utviklet forskjellige løsninger, som har det til felles at de stort sett har introdusert nye spesifikke måter å definere og kontrollere egenskaper på. For at søking på egenskaper skal kunne fungere som en del av en helhetlig løsning, trenger vi mer enhetlige definisjoner av egenskaper og hvordan de brukes. Derfor kan det være nyttig med en overordnet kikk på systemet slik det er nå.

Innhold

For innhold har vi til nå primært forholdt oss til xml-dokumenter definert med utgangspunkt i applikasjonen for web-redigering. I denne modellen har innholdet delvis vært uttrykt i et schema, delvis i redigerings-xsl. Visning har primært vært håndtert innenfor enkeltdokumentet med visnings-xsl, med eventuelle avhengigheter mellom ressurser definert som 'hardkodede' document()-oppslag der det har vært nødvendig. Den mest avanserte mekanismen for avhengigheter har vært id-baserte referanser, løst med batch-genererte mapping-filer som det så gjøres document()-oppslag på.

Vi har også til en viss grad forholdt oss til innhold definert i html. Dette har i praksis vært begrenset til å implementere en java-versjon av uhtml, slik at vi har kunnet legge på uio-profil på visning av dokumenter.

Properties

Properties er idag brukt på en rekke forskjellige måter i systemet. Vi har noen basale propeties satt av systemet. Dette er ting som lengde på innholdet, eier, o.l. I tillegg finnes det et sett med standard brukerredigerbare properties; mime-type, språk og tegnkoding.

For xml-dokumenter har vi definert system-oppførsel (transformering ved visning, web-redigering, tekst-redigering) som brukersatte egenskaper på dokumentene.

uhtml-metadata er definert som et sett properties som kan settes både på mapper, xml- og html-dokumenter. Dette settet er et alternativ til å definere uhtml-dataene internt i dokumentet, og har i tillegg den fordelen at det kan arves av mapper oppover i strukturen. Om data skal arves er også en property som settes på ressursen.

Vi har også noen eksempler på at vi har definert annen spesiell funksjonalitet. At en mappe er en mappeinnleveringsmappe, settes med en property.  Mapper hvor det skal kunne opprettes nye emner, er et annet eksempel.

Indexer

I to sammenhenger har vi begynt å indeksere egenskaper ved ressurser, for søking på indeksene. Dette gjelder tavle og mappeinnlevering. Mappeinnlevering indekserer stort sett egenskaper definert som properties på ressurser, mens tavle er basert på ekstrahering av innhold til indeksen.

Hver spesifikke bruk har sin egen indeks, med muligheter for søking i de dataene som er lagt i indeksen. Egenskapene som indekseres er dels unike (de kan ikke leses noe annet sted enn fra indeksen), dels svarer de til innhold i eller properties på ressurser.

Den største begrensningen slik det er gjort idag, er at man må definere egne indexer, med et egendefinert sett metadata og egne søkebegrensninger, i hver sammenheng hvor man ønsker å søke.

Problemet med dagens løsning

Som beskrevet over, har vi allerede et utall måter å forholde oss til egenskaper og innhold på ressurser. Dette er et problem i seg selv, men vil bli bli merkbart mindre håndterbart når vi får en større bruk av søking. Søking innebærer en alternativ måte å aksessere ressurser på, i forhold til det ordinære repository-apiet. Når det defineres metadata uavhengig av andre kontekster, som  det ikke er mulig å få tilgang til på andre måter enn gjennom søk, får man et system som blir stadig vanskligere å vedlikeholde og videreutvikle.

Personer involvert

Gorm: 3 uv.
Jo: 3 uv.
Tomm: 2 uv.
Øyvind: 3 uv.
Kaj: 2 uv.
Even: 2 uv.
Oddmund: 1 uv.

Skisse over arbeidet

Refaktorere ressurs og property

• lage jcr-aktige interfaces for property og ressurs
• bygge inn validering av (og begrense skriverett på) property-verdier
• kontrollere property-oppretting i ressurs-interfacet (innfører binding til repo)

1 uv.

Lage manager for ressurstypedefinisjoner

• api-er for index/ressurs
  
• ressurstype = properties-navnerom
  
• "kontrollerte" properties defineres på ressurstype-nivå
• Bygge live properties-håndtering

3 uv.

Lage definisjonsformat for ressurtype-definisjoner

• property-typing
• constraints
• live-håndtering
• ekstrahering
• Innføre mulighet for begrensning på hvem som kan redigere properties

3 uv.

Definere v2.0 property-sett/regler innenfor ressurstreet

1 uv.

Ekstraheringsrammeverk

1 uv.

Indeksering

• hvor mange indekser/duplisering av data...
  
• reindeksering
• redundans

2 uv.

Lage søke-api

• skrive api, søkesyntaks
  
• definere brukskrav
• indeks-mapping

2 uv.

Vurdere problematiske properties

• Author...
• Title/displayname/coll-name-in-path
  
• Publisering (fra/til)

1-2 uv.

Databaseendringer

• restrukturering
• "konvertering"

1 uv.

---

Redaksjon: Vortex
Dokument opprettet: 08.02.2006, endret: 20.02.2006Administrer dette dokumentet