Opgave 2:DeVise Hypermedia (DHM)
From Wau
Devise Hypermedia (DHM) er et åbenthypermediesystem, udviklet på datalogisk institut (DAIMI) på Århus universitet i årene 1991-95, og det blev brugt af overordnede ingeniører under bygningen af Storebæltsforbindelsen. Udgangspunkter for DHM var at lave et system, der byggede på retningslinjerne i Dexter-modellen. DHM baserede sig da også fra begyndelsen på opdelingen i lag, multi-headed tovejslinks og compositetanken.
Contents |
[edit] Dangling links
Det var dog også væsentlig for folkene bag DHM at ændre eller udvide systemet i forhold til Dexter-modellen, hvor denne ikke var hensigtsmæssig. Et punkt var dangling links, dvs. links med et eller ingen endepunkter. Dette var ikke tilladt i følge Dexter-modellen, men blev tilladt i DHM for at understøtte at atomic components og anchors i endepunkter kunne opdateres både før og efter genereringen af links. Herved kunne man bibeholde strukturen, også når man ikke havde kontrol over endepunkterne, man kunne arbejde med strukturer før indholdet var på plads, og man kunne ændre i endepunkter uden at slette hele links, hvis der var tale om et multi-headed link.
[edit] Anchors
Også omkring anchors er der en udvidelse i DHM i forhold til Dexter-modellen. DHM opererer med tre typer af anchors:
- Whole-component anchor: Denne type anchor benyttes, når man har behov for at et helt dokument skal være et anchor - f.eks. hvis man ikke vil linke til et specifikt sted i dokumentet.
- Marked anchor svarer til det, man i Dexter-modellen kalder for link marker. Et marked anchor benyttes til at sætte et anchor et specifikt sted i en component. Et marked anchor sættes manuelt og forbliver på samme sted til det fjernes manuelt igen.
- Unmarked anchor: Denne type anchor udregnes automatisk, og sættes når der f.eks. er foretaget en søgning.
[edit] Composites
I DHM såvel som i Dexter kan composites indeholde alle typer af components - både atomic, links og andre composites. Herforuden er der også på dette område en udvidelse i forhold til Dexter-modellen, idet composites, ligesom andre components, kan være virtuelle, og dermed ikke nødvendigvis blive gemt i databasen. Composites kan ligeledes, som andre components, udregnes automatisk, hvilket åbner for, at man f.eks. kan have composits, der indeholder søgeresultater. Dataobjekter, der bruges i composites eller atomic component, kan i DHM enten være indlejret i hypermediesystemet eller ligge eksternt i forhold til dette. Selv om composites var meget brugt allerede i 2.generationshypermediesystemerne (f.eks. corpus i Intermedia og fileboxes i NoteCard) er det ikke en selvfølge, at det er implementeret i alle de åbne hypermediesystemer. Dette er f.eks. ikke tilfældet i Microcosm, hvilket formentlig har at gøre med den enkelhed, der er valgt i dette system for at muliggøre en meget bred vifte af integrationer med andre applikationer.
[edit] Samarbejde
DHM var jo et system udviklet specifikt til de overordnede ingeniører ved bygningen af Storebæltsforbindelsen, og således var der også i systemet indtænkt disse ingeniørers behov for at kunne samarbejde i systemet. Hvor Microcosm primært er et enkeltbrugersystem uden disse muligheder, kunne brugerne af DHM f.eks. få besked, når der skete bestemte ændringer i systemet. Desuden understøttede DHM, at brugerne kunne gruppere sig og danne sessions, som medlemmer kunne optages i eller forlade efter behov. Endelig var det muligt at låse objekter, så de ikke kunne ændres af andre brugere.
Alt i alt er DHM et yderst fleksibelt hypermediesystem med megen funktionalitet for brugerne. Dette gjorde det selvfølgelig sværere at implementere end Microcosm, da der i tredjepartsapplikationen nødvendigvis skulle være et macrosprog til stede for at kommunikere med DHM og for at gøre det muligt at ændre på brugerinterfacet. Alligevel er det lykkedes at integrere DHM med en del større applikationer.
