Selvom wiki betyder “hurtig” på Hawaii, betyder det langt fra, at det går hurtigt her i Tranbjerg. Jeg er nu langt om længe nået til en besvarelse af anden del af opgave B. Det har taget virkelig lang tid, men om det er wiki’ens skyld skal jeg lade være usagt…

Min wiki er blevet opdateret med en besvarelse af første del af opgave B.

/HC

Her er linket til min wiki: http://wau08-hchulvej.wikidot.com/

I beskrivelsen af de grundlæggende hypermediesystemer benyttes begreberne knuder (nodes) og links. Et hypermediesystem er en (elektronisk) database af knuder bundet sammen via links, samt en brugerflade, som muliggør at brugeren kan interagere med databasen via en terminal. Det konkrete indhold af knuderne og struktureringen af databasen er forskellig fra system til system, og det samme gør sig gældende for brugerfladen. Jeg vil i denne litteraturøvelse gøre rede for, hvordan de tre systemer KMS (Knowledge Management System), Intermedia og Notecards er designet ift. de ovenstående begreber, ligesom jeg vil kommentere på systemernes tiltænkte brugssituation særligt ift. samarbejdsmuligheder.

KMS

Knuderne i KMS kaldes rammer (frames) og er designet til at kunne vises i deres helhed på en computerskærm, hvor der er plads til at vise op til to rammer ad gangen. Et argument for at holde størrelsen nede på rammerne er, at det samtidig holder den tid, det tager at hente en ny ramme i databasen og vise den på skærmen, nede. Netop det at det går hurtigt (< 1 sek.) at hente nye rammer ind blev anset for at være meget vigtigt af designerne af KMS. En ulempe ved at have så relativt små rammer er at større dokumenter nødvendigvis må deles ud på flere rammer, og risikoen for at miste overblikket over dokumentet er derfor til stede. Alternativet til de små rammer er større enheder, hvor man til gengæld har mulighed for at scrolle gennem hele indholdet. De to andre systemer, Intermedia og Notecards, har valgt denne mulighed i deres design.

I KMS er der kun én type af ramme, som tillige har en fast størrelse. I struktur svarer det næsten til et kanvas, hvor brugeren af systemet kan lægge tekstbidder, grafik og billeder på. Det er den samme applikation, som både viser rammerne og som brugeren bruger til at redigere rammerne. I praksis har udformningen af rammerne den effekt, at en ramme næsten aldrig er fyldt helt op, så evt. samarbejdspartnere kan finde plads til at kommentere indholdet med endnu en tekstbid. En af fordelene ved den ret simple struktur af rammerne er det er let for brugeren at anvende; der er ikke brug for så mange begreber og kommandoer, som hvis man vælger at implementere en mere kompleks struktur.

Måden man navigerer i mængden af rammer på er via links, som i KMS knyttes til de enkelte tekstbidder (eller til grafik eller billeder) som en attribut. Links kan kæde rammerne sammen i træer (der ligesom knuder er et begreb fra grafteorien), og man får på den måde skabt en hierarkisk struktur på sine rammer. Det er blandt andet den måde man kæder de rammer, som hører til et større dokument, sammen på. Links kan også kæde rammer sammen på tværs af de definerede træer vha. såkaldte annotationer. Det er den type af links som bruges, når kolleger eller andre samarbejdspartnere vil kommentere hinandens arbejde i KMS. Endelig er der mulighed for at køre programmer, som er lavet i KMS, via det der kaldes action links. Links markeres i rammerne ved små markeringer ud for de tekstbidder, som udgør udgangspunktet for linket. Forskellige markeringer bruges for at markere de forskellige link-typer.  I KMS og Notecards er linkdestinationen for links, som binder knuder sammen, altid en hel knude, mens Intermedia via såkaldte ankre gør det muligt at linke til bestemte steder indenfor en knude.

Intermedia

I systemet Intermedia hedder knuderne dokumenter (documents), og de vises i vinduer, som minder en del om de vinduer, vi kender fra f.eks. Apple- og Windows-styresystemer. Det er muligt at vise mange overlappende vinduer på en gang, og det er muligt at scrolle i indholdet af vinduerne, så størrelsen af dokumenterne kan være meget større end i KMS. Til redigering af indholdet af dokumenterne har systemet en række af integrerede applikationer, som f.eks. InterText (tekst), InterDraw (grafik) og  InterVal (tidslinjer).

Håndteringen af links funger anderledes i Intermedia end i KMS. I Intermedia anvendes såkaldte blokke (blocks) som ankre for links, og blokkene kan variere i størrelse fra et enkelt punkt til et afsnit til et helt dokument. Denne konstruktion giver altså en udvidet funktionalitet i forhold til KMS og Notecards, som kun tillader hele knuder som linkdestinationer. Blokke markeres i dokumenterne ved enten fremhævning af tekst eller via ikoner, og brugerne kan navngive sine links og dermed skabe sine egne link-typer, ligesom det er muligt at tilføje attributter som f.eks. datoen for oprettelsen til sine links.

Noget som er specielt for Intermedia ift. de to andre systemer er de såkaldte webs. Et web er en samling af links, som afgrænser en bestemt del af hele systemet. En bruger kan åbne ét web ad gangen, og når han har et web åbent, så kan i de dokumenter, han har åbne, se de links, som er gemt i netop dette web, men ikke links fra andre webs. En fordel ved denne konstruktion er, at den hjælper brugeren med at bevare overblikket, da kun de formodentlig relevante links fra webbet optræder i dokumenterne. En ulempe ved den konkrete implementering er, at brugeren ikke kan have mere end ét web åbent ad gangen, og han er derfor afskåret fra at krydsreferere mellem to webs.

Notecards

Knuderne i systemet Notecards er, som navnet antyder, kartotekskort (notecards) eller bare kort i det følgende. Ud over de almindelige kort (notecards), som kan være af forskellig type afhængigt af indholdet, er der også browser-kort, som indeholder oplysninger om strukturen af en delmængde af det samlede system, altså oplysninger om, hvordan de forskellige kort er knyttede til hinanden via links. Herudover er der kartotekskasser (fileboxes), som samler flere kort under én paraply. Det minder om de biblioteker, som vi kender fra de moderne styresystemer, dog med den væsentlige forskel, at i Notecards kan samme kort tilhøre flere forskellige kartotekskasser.

Selvom navngivningen antyder, at kortene er små kartotekskort, er der ingen begrænsning på mængden af indholdet per kort. Som i Intermedia vises flere (overlappende) kort ad gangen på skærmen og det er muligt at scrolle i vinduerne. Redigering af kort foregår i et særligt redigeringsvindue, som brugeren kan kalde frem.

Links i Notecards er type-bestemte via en brugervalgt etiket (label), og de har altid et helt kort som destination. Links markeres med et ikon, som kan placeres et vilkårligt sted på kortet, og dette ikon anvendes som anker for linket. Denne type linking giver flere muligheder en det meget simple link-system i KMS, men det er ikke så fleksibelt som Intermedias håndtering af links. Notecards har dog den fordel, at det er fuldt integreret med Xerox Lisp programmerings-platformen, hvilket giver en lang række af muligheder for at skræddersy systemet, herunder sine links.

Tiltænkt brugssituation og samarbejdsmuligheder

KMS er et hypermediesystem, som er designet til at hjælpe organisationer med at holde styr på deres viden. Derfor er det helt naturligt, at systemet tilbyder brugerne gode samarbejdsmuligheder. Det er muligt for mange brugere at arbejde med den samme database af rammer og links ad gangen. En af fordelene i denne sammenhæng ved opsplitningen af dokumenter i små bidder, som passer i en ramme, er at sandsynligheden for at to kolleger arbejder på den samme ramme på det samme tidspunkt er ret lille, hvilket minimerer risikoen for konflikter. Da en del af designfilosofien er, at det skal være nemt for kolleger at arbejde sammen om det samme projekt, er normen, at man appellerer til hinandens sunde fornuft frem for at afskære andre mulighed for at redigere ens rammer. Da hver ramme har en ejer, er der dog mulighed for at forhindre andre brugere i at se og redigere de rammer, man er ejer af, men der lægges op til, at man i praksis stoler på sine samarbejdspartnere.

Denne type af samarbejde kræver, at man er en tæt kreds af betroede samarbejdspartnere, som f.eks. et team, som arbejder på et fælles projekt. I et kæmpestort hypermediesystem som WWW er det klart, at denne type af åbenhed aldrig ville kunne fungere.

Intermedia er ligesom KMS designet til at understøttet samarbejde. Det er tænkt som et hjælpeværktøj for forfattere og undervisere til at skabe overblik over en række dokumenter via links og til at kommentere på hinandens arbejde, og derfor er der også som en naturlig del af systemet mulighed for samarbejde. I praksis har systemet været brugt af både studerende og undervisere på Brown University i USA, hvilket naturligt stiller lidt højere krav til sikkerheden i forbindelse med redigering af andres dokumenter. Den måde den øgede sikkerhed er blevet implementeret er via dokumentrettigheder. En bruger kan have enten læse-, annotations- eller skriverettigheder til et givet dokument. Hvert dokument og hvert web har en ejer, som tildeler brugerne rettigheder. Endnu en fordel ved Intermedias web-struktur er at flere grupper kan arbejde uafhængigt af hinanden med links på de samme dokumenter blot de har hver deres web åbent.

Ideen med at give forskellige brugere hhv. læse og skriverettigheder er velkendt fra WWW, hvor det typisk er administratoren af en bestemt side eller af et bestemt site, som har skriverettigheder, mens den almindelige surfer kun har læserettigheder. Annotationsrettigheder kendes bla. fra blogs, hvor man har mulighed for at kommentere på blogindehaverens indlæg, men hvor man ikke har mulighed for at redigere dem.

Notecards blev designet til at være et enbruger-system, hvor man forestillede sig, at samarbejdet skulle foregå udenfor systemet, f.eks. som samtale, via e-mail eller ved udveksling af udskrevne dokumenter. Der er derfor ikke særlig gode muligheder for at samarbejde om et fælles projekt i Notecards.

Frank Halasz, som dels er en af designerne af Notecards og forfatteren til “Seven Issues”-artiklen, nævner netop dette som en alvorlig mangel i Notecards, og forudser at fremtidige hypermediesystemer er nødt til at understøtte flerbrugersamarbejde – også i højere grad end KMS og Intermedia, for at vinde indpas som generelt anvendelige værktøjer. Et andet problem ved de tre hypermediesystemer er deres “monolitiske” natur, dvs. deres manglende evne til at integrere sig med andre systemer og formater. Karakteristisk for mere moderne hypermediesystemer som f.eks. DeVise Hypermedia er en høj grad af understøttelse af flerbrugersamarbejde samt integration med applikationer og formater udenfor systemerne.

Sammenfattende kan vi sige, at de tre systemer, KMS, Intermedia og Notecards, som alle tre er det, man kalder 2.-generations hypermediesystemer, er gode eksempler på, hvordan den grundlæggende hypermediemodel kan implementeres, men at de samtidig hver især har deres begrænsninger. Erfaringerne fra de tre systemer har betydet at hypermediebegrebet er blevet udviklet og forbedret, så vi i dag har en langt bedre ide om, hvad man bør forvente af et moderne hypermediesystem.

Modellen deler et hypermediesystem i tre dele:

• “within-component layer” (beskriver hvad der foregår “inden i” komponenterne, egentlig udenfor modellen)
• “storage layer” (består af en “database” af komponenter (components) og links mellem dem)
• “run-time layer” (brugerfladen, interaktion mellem run-time og storage)

Storage layer:

• komponenter
  • atomare [~nodes], links, sammensatte (hierarki via ikke-cyklisk orienteret graf)
  • entydighed via UID
  • inddeling i indhold og information om komponenten (fra P13)
    • information: attributter, præsentationsspecifikation, ankre (anchors)
  • accessorfunktion (1-1 UID->komponent) og resolverfunktion (oplysning om komponentegenskab-> alle UID’er som opfylder betingelserne)
  • anker: id (entydighed indenfor komponenten) og værdi (peger på en del af komponenten), kæder within-component layer og storage layer sammen
  • præsentationsspecifikation: kæder storage layer og run-time layer sammen
• links
  • specifier (komponentspecifikation og anker id [information som identificerer et "link-endepunkt"], retning [FROM, TO, BIDIRECT, NONE], præsentationspecifikation)
  • et link er selv en komponent indeholdende mindst to specifiers (muligt at linke til andre links)
  • linksystemet skal være konsistent

Run-time layer:

• instantiation af en komponent (præsentation af komponent)
  • entydighed via IID (within-session)
  • ankre instantieres som linkmarkører (link marker)
• session
  • indeholder hypertexten (mængde af komponenter, inkl. linkkomponenter), f:IID->komponent, historik, realizer function: instantiation->ny komponent med evt. ændringer (den nye komponent kan erstatte den originale komponent i storage layer)

XML:

• <element>…</element>, <! declaration element>, <? processing instruction element ?>
• well-formed
  • starter med en <?xml …?>
  • der er ét rodelement
  • elementerne “overlapper” ikke hinanden

DTD, XML Schema:

• regler som begrænser strukturen af et XML-dokument

ENTITY:

• ???

Namespaces:

• deklareres med xmlns:xlink=”…” som attribut i starttagget for rodelementet (altid?)

Xpath:

• syntax til at pege “ind” i et XML-document
• “sti”, som kan pege på et (nul) eller flere elementer eller dele af elementer

XLink:

• en udvidelse af det “gamle” http-link (som er “inlined, uni-directional and untyped”)

XPointer:

• “peger” ind i et XML-dokument (pt. uklart hvad forskellen på XPath og Xpointer er)

XSL:

• stylesheet sprog med langt større muligheder end CSS (bruger XPath)
• kan bruges sammen med CSS til at style et XML-dokument

SVG:

• grafikformat (minder om PostScript?)

Selvom hypermediebegrebet har over 25 år på bagen, er det ikke slået igennem som et anvendeligt værktøj i det daglige arbejde for vidensarbejdere. Meyrowitz peger på, at hovedårsagen er systemernes lukkethed ([they] are insular [and] monolithic). Niels Olof brugte metaforen “en lukket have” i forelæsningen.

Meyrowitz opstiller fire “succeskriterier”, som skal opfyldes før hypermediesystemerne bliver almindeligt udbredte (fire kriterier, som “copy-cut-paste” funktionaliteten opfylder):

1. det skal være et effektivt værktøj (powerful things could be done)

2. det skal være let at se anvendeligheden af og at bruge (extremely easy to motivate and teach end-users)

3.  dem, der skal sælge softwaren, skal synes, at det er vigtigt (toolbox vendors touted [it] as an important integrating factor)

4. det skal være relativt let for udviklere at integrere de ønskede funktionaliteter i deres software (f.eks. ved at stille et framework til rådighed)

Meyrowitz påpeger at systemernes lukkethed udelukker punkt 4 (og dermed reelt punkt 3).

Dette er den blog, jeg vil bruge i forbindelse med min deltagelse i kurset Hypermedier og Web under masteruddannelsen i IT – http://www.itev.dk.