Metadata, dokumentegenskaper

Detta kapitel handlar om dokument och dokumentegenskaper. Kort om olika former att spara dokument och hur man sätter etiketter på dokument. Dokument är ramen för innehåll i form av texter, bilder, kalkyler, filmer eller en blandad kompott. Vi kan inte kalla dessa för filer, eftersom dokument innehåller ”information” som bara kan tolkas av människor emedan filer även kan vara kod eller data format för datorer. Det handlar om information som levereras av med datorer mellan människor. Etiketterna kallas metadata eller dokumentegenskaper och är mycket effektiva för att söka reda på dokument.

- Enkelt, meta med data, agna med dokument!

Metadata är data om data. Det är lika obegränsat som enkelt och därför ibland svårt definiera praktiskt. Men det beskriver innehållet i ett dokument eller ett träd av dokument.

Vad är metadata?

Metadata är ett enkelt sätt att hålla ordning på dokument med hjälp av dokumentets egenskaper. Elementen man väljer att använda som metadata ska fungera i den tillämpning där man avser att dokumentet har sin roll och funktion. En bok på ett bibliotek har metadata i form av ett bibliotekskort och ett styrande dokument i form av status, uppdragsgivare. Det är en balansgång att välja vad som ska vara och inte vara metadata för att fungera nu och i framtiden. XML fyller flera funktioner för att tolka innehållet av ett dokument och att ha kopior eller relationer mellan innehåll och metadata kan lätt bli trassligt.

Microsoft Word och ett bibliotekskort

På samma sätt måste metadata förpackas och fungera utifrån dokumentet och inte ”dokument-systemet” för att vara användbart mellan system och i de vanligaste applikationerna. Även om det är självklart för att dela information så fungerar mycket få system med en sådan öppenhet och standard. Det råder vissa meningsskiljaktigheter om hur det rent tekniskt ska skötas, men så länge informationen finns så är det en god start.

Det finns tre kategorier av metadata i ett dokument:

· Information om dokumentets källa

· Information om innehållet i dokumentet

· Information om den process dokumentet tillhör eller är aktivt inom

Dublin Core, bibliografisk metadata

På ett universitet i Dublin, USA skapades 1995 en standard för bibliografisk metadata som används i stor utsträckning på webbsidor och i dokument med akademiskt eller litterärt innehåll. Elementen som beskrivs i Dublin Core används för att ange författare, källa och andra nycklar till dokumentet. Dublin Core beskriver element för information om källa och innehåll.

Idag har Dublin Core utvecklats till ett forum för metadata som du kan besöka på http://www.dublincore.org/

Elementen i DC är i korthet (på engelska):

Element	DC version 1.1 descriptions
Title	A name given to the resource.	Typically, a Title will be a name by which the resource is formally known.
Creator	An entity primarily responsible for making the content of the resource.	Examples of a Creator include a person, an organisation, or a service. Typically, the name of a Creator should be used to indicate the entity.
Subject and Keywords	The topic of the content of the resource.	Typically, a Subject will be expressed as keywords, key phrases or classification codes that describe a topic of the resource. Recommended best practice is to select a value from a controlled vocabulary or formal classification scheme.
Description	An account of the content of the resource.	Description may include but is not limited to: an abstract, table of contents, reference to a graphical representation of content or a free-text account of the content.
Publisher	An entity responsible for making the resource available	Examples of a Publisher include a person, an organisation, or a service. Typically, the name of a Publisher should be used to indicate the entity.
Contributor	An entity responsible for making contributions to the content of the resource.	Examples of a Contributor include a person, an organisation, or a service. Typically, the name of a Contributor should be used to indicate the entity.
Date	A date associated with an event in the life cycle of the resource.	Typically, Date will be associated with the creation or availability of the resource. Recommended best practice for encoding the date value is defined in a profile of ISO 8601 and follows the YYYY-MM-DD format.
Type	The nature or genre of the content of the resource.	Type includes terms describing general categories, functions, genres, or aggregation levels for content. Recommended best practice is to select a value from a controlled vocabulary (for example, the working draft list of Dublin Core Types). To describe the physical or digital manifestation of the resource, use the FORMAT element.
Format	The physical or digital manifestation of the resource.	Typically, Format may include the media-type or dimensions of the resource. Format may be used to determine the software, hardware or other equipment needed to display or operate the resource. Examples of dimensions include size and duration. Recommended best practice is to select a value from a controlled vocabulary (for example, the list of Internet Media Types defining computer media formats).
Identifier	An unambiguous reference to the resource within a given context.	Recommended best practice is to identify the resource by means of a string or number conforming to a formal identification system. Example formal identification systems include the Uniform Resource Identifier (URI) (including the Uniform Resource Locator (URL)), the Digital Object Identifier (DOI) and the International Standard Book Number (ISBN).
Source	A Reference to a resource from which the present resource is derived.	The present resource may be derived from the Source resource in whole or in part. Recommended best practice is to reference the resource by means of a string or number conforming to a formal identification system.
Language	A language of the intellectual content of the resource.	Recommended best practice for the values of the Language element is defined by RFC 1766 which includes a two-letter Language Code (taken from the ISO 639 standard), followed optionally, by a two-letter Country Code (taken from the ISO 3166 standard). For example, 'en' for English, 'fr' for French, or 'en-uk' for English used in the United Kingdom.
Relation	A reference to a related resource.	Recommended best practice is to reference the resource by means of a string or number conforming to a formal identification system.
Coverage	The extent or scope of the content of the resource.	Coverage will typically include spatial location (a place name or geographic coordinates), temporal period (a period label, date, or date range) or jurisdiction (such as a named administrative entity). Recommended best practice is to select a value from a controlled vocabulary (for example, the Thesaurus of Geographic Names [TGN]) and that, where appropriate, named places or time periods be used in preference to numeric identifiers such as sets of coordinates or date ranges.
Rights	Information about rights held in and over the resource.	Typically, a Rights element will contain a rights management statement for the resource, or reference a service providing such information. Rights information often encompasses Intellectual Property Rights (IPR), Copyright, and various Property Rights. If the Rights element is absent, no assumptions can be made about the status of these and other rights with respect to the resource.

Exempel: Safari, forskningsinformation

- Safari projektets symbol, en giraff med översikt!

Det första riktig stora metadataprojektet i Sverige var SAFARI-projektet. Det syftar till att skapa en gemensam plattform för forskningsinformation. Det kom efter ett initiativ från regeringen, eftersom Internet innebar nya möjligheter för höge läroverk att informera allmänheten om forskningen. Att informera allmänheten är en av de tre huvuduppgifterna, de två första är utbildning och forskning.

Eftersom det inte fanns en sökmotor för metada-information över Internet skrev man ett program som hämtar webbsidor till en central databas på högskoleverket.

Du hittar informationen centralt insamlat på: http://www.safari.hsv.se/

”Istället för att behöva besöka varje enskild organisations hemsida för att där söka sig omkring i myllret av sidor kan man i SAFARI skriva in ett eller flera sökord på ett enda ställe och få svar från alla forskande myndigheter. Man får upp en s.k. träfflista med bl.a. de olika dokumentens titlar och klickar man sedan på en titel kommer man direkt till dokumentet som bär titeln, ute på någon organisations server. Har man inget speciellt sökord i huvudet ska man kunna klicka sig ned i ett ämnesträd.”

SAFARI har en egen sökrobot som besöker forskande myndigheters servrar och uppdaterar en central databas.

Exempel på html huvud för Safari-dokument:

</head>

Document Process metadata – ordning bland dokument i organisationen

Document Process (”DP”) metadat är en modell som kompletterar Dublin Core med element som beskriver dokument och deras roll i flöden. Det innebär att dokument som är ärenden, offerter, protokoll eller beskrivningar ges egenskaper som gör dem enklare att hitta och administrera. På detta vis skapar DP en infrastruktur för att överbrygga systemgränser och organisationsgränser med vanliga dokument i XML, Word, HTML eller andra format. Exempelvis kan ett ärende nås och redovisas oberoende system och därmed användas flera steg som för säljorganisation, ekonomiavdelning, administration samtidigt som underlag för ledning och ansvariga. Klassificeringen med metadata gör även att organisationen slipper drunkna i information – utan snabbt kan hitta mer specifikt och översiktligt bland dokumenten.

Det är Dublin Core tillsammans med Document Process är gammal arkiveringskonst som kompletterar webbens dokumentåtkomst.

Elementen fokuserar på generella flöden och flödesbeskrivningar med elementen:

Element	Contents	Description
DP.CLASS	ERRAND, DEFINITION, OFFER, AGREEMENT, PROTOCOLL, INVITATION, ORDER, PLAN, INFORMATION …	Document class corresponds to DC.TYPE but in a business process relation. This is element has predefined values that can be combined.
DP.STATUS	OPEN, CONFIRMED, ASSIGNED, DISCARDED, HOLD, ACTIVE, CLOSED	Status has different meanings in relation with DP.CLASS and is used with control documents to proceed in process activities.
DP.SUBJECT	Customer or project name	Curresponds to DC.SUBJECT but for the business name rather than the document name/keywords
DP.PROCESS	Core, Control, Support
DP.SYSETEM	System reference	SAP/IFS/OpenDoc/DocuShare
DP.TIME	Date/Time-Range	Open = starting date Closed = staring and end date
DP.OWNER	Process owner/resposible
DP.MEMBERS	All members/groups
DP.CONTACT	Informaton contact

Semantik och översikt

Det semantiska nätverket är iden om ett Internet där informationen är så pass strukturerad att man enkelt kan sammanställa alla källor och referenser till specifika personer, händelser, platser, idéer etc. Men eftersom betydelser och strukturer förändras är det lika svårt som att bygga ett nytt universellt språk. Istället för att skapa det universella språket kan man istället modellera med någorlunda lika mönster och samtidigt skapa referenser till ”min semantik” genom att beskriva den. Vi får därför en semantisk dimension för att söka och navigera dokument utöver de innehållsliga eller kontextuella.

Olika konkurrerande strukturer behövs och behöver inte skapa oordning om man istället hanterar dem som de valmöjligheter eller översikt bland olika de olika modeller som egenskaperna utgör. Genom att inte förutsätta utan att anpassa sökning och gränssnitt efter lokala strukturer kan man utveckla bra interaktion och kunskap ur informationen.

Idag finns XML som gränssnitt mot databaser, protokoll mellan datorer i protokoll och som innehållsformat i Palm, Internet Explorer, Mozilla m.fl. Vad som inte finns är den decentraliserade infrastrukturen för att söka och sortera generell information mellan informationskällor på Internet eller inom intranät.

De närmaste lösningar som finns bygger SQL-databaser och begränsar sig därmed till strikt beskrivna tabeller med information.

En av grundidéerna med Corpus är en generös relation till metadata vilket skapar förutsättningar att ställa frågor till vilken implementation av informationsstrukturer som helst. All metadata blir sökbar genom Corpus och kan sorteras och filtreras med lokala eller globala idéer om hur informationen klassificeras.

Det betyder att man automatiskt får en blandning av flera synsätt och ett utrymme till utveckling av hela domänen på den minsta dokumentnivån.

För att läsa mer ”Web Data” som handlar om semantik på Internet kan du gå till: http://www.w3c.org/1999/04/WebData

Bygg en databas över Internet

Att försöka praktisera det semantiska nätverket är inte fel även om det inte är verklighet på Internet ännu. Det ger fördelar med frihet och kontroll över information ni kan upparbeta. Det krävs en hel del nytänkande (se infrastruktur) för att bygga en hel datalösning decentraliserat med möjlighet att täcka flera format och platser. Dokumentorientering är nog svårare för inkörda databas-konsulter men definitivt enklare för vanliga människor.

Metadata och dokumentparadigmen är förvånansvärt likt objektorienterad systemering och kan också beskrivas med de dokument man hanterar dagligen och de processer som organisationen arbetar med.

Det är ett stort kliv från den komplicerade och ibland helt objektfientliga modell som är resultatet från SQL-databaser. Det beror på att SQL inte har någon analogi mellan tabeller och klasser i programmeringen, vilket gör det svårt att optimera och generalisera lösningar.

Metadata-/dokumentsystemering fungerar bara bättre för information som kan ses som objekt eller som dokument. SQL är fortfarande mer effektivt när man vill arbeta med information som listor eller tabeller med siffror och koder.

Det arbete vi har genomfört på Stockholms Universitet med distribuerad ärendehantering är en distribuerad databas.

Resource Description Framework

XML har en standard för beskrivning av relationer och förhållanden i information. Resurser beskrivna i RDF kan vara allt från träd av dokument eller ett dokument till en del av ett dokument. Egenskaper för resurser (dokument) deklareras, regleras och styrs i relation till andra resurser. På så sätt skapar RDF en beskrivning över egenskaper och deras beroenden ungefär som SQL kan beskriva relationer mellan tabeller och kolumner.

Om ett dokument har en egenskap t.ex; ”dc.creator: Jonas Bosson” kan vi med RDF koppla ”dc.creator” till ett objekt med namnet ”Jonas Bosson”. I samma RDF beskrivs att ”Jonas Bosson” kan ha e-post- och adressegenskaper, där adressegenskaperna har gatunamn m.fl. Nu är dock ”Jonas Bosson” inget objekt man kan adressera utan att göra om det till en URI som man använder för resurser eller dokument. Så, ”dc.creator” får peka på en webbadress …/staff/Jonas.xml med mer information om ”Jonas Bosson”.

En ”RDF”, resursbeskrivning har subjekt, predikat och objekt t.ex: dokument, författat av, och författaren. Dessutom en typ som anges som en resurslänk och identifierar namn eller text beroende av standard.

Kort kan man sammanfatta RDF som en extra fil eller en del av ett XML dokument som på ett noggrant sätt kan beskriva relationerna mellan dokumentet som resurs och andra resursobjekt på ett sätt som gör det möjligt att tolka relationerna med program.

Läs mer om RDF och RDF filer på adressen: http://www.w3c.org/RDF/

Under utvecklingsarbetet med Corpus hade förmånen att samarbeta med SISU och professor William Song, och diskuterade flera möjliga RDF projekt med Corpus som fortfarande är aktuella. Vi hoppas arbeta vidare med dessa framöver.

Lagring och val av metadata

Det finns många åsikter om vad som ska vara metadata och hur man ska lagra metadata. Den mer traditionell metod är att metadata hanteras utanför från dokumentet och absolut inte hanterar innehållet i dokumentet. JC Herlitz har givit mig tillstånd att publicera en diskussion vi har tillsammans som tar upp de centrala delarna.

JC Herlitz på ExcoSoft AB skriver:

Det finns många olika uppfattningar om vad meta-data är. Det vanligaste är nog att folk har en väldigt luddig uppfattning. Jag tillhör själv de som haft en mycket oklar bild av meta-data men har under det senaste året arbetat en hel del med frågan. Med detta brev vill jag förmedla det jag kommit fram till.

I ett arbete tillsammans med Sweco Position tog vi under våren fram ett standardiserings-förslag för meta-data inom bygg-branschen. Syftet med förslaget var att möjliggöra utväxling av dokument och deras meta-data mellan olika system. Typiskt för bygg-branschen är just att dokument hanteras av olika intressenter med olika system under bygg-projektets gång. Varje system har sina meta-data med sina namn. Genom att definiera en central standard behöver varje system endast realisera en (1) import- och en (1) exportfunktion.

Förslaget vi tog fram blev en sorts summa av allt man kan tänka sig. Det blev således en stor mängd meta-data, närmare bestämt 79 stycken. En relevant fråga, som inte ännu är besvarad, var hur ett system skall hantera meta-data som det inte förstår.

Vårt arbete handlade primärt om utväxling av meta-data och de problem detta innebär. Det gav dock många tillfällen till att fråga sig vad meta-data egentligen är. Min uppfattning är sålunda:

· Meta-data ligger INTE inne i dokumenten - de ligger i dokumenthanteringssystemet. Ett dokument kan innehålla vad som helst (en gif-bild, exekverbar kod, XML, ljud). Innerhållet kan också vara oläsligt därför att det är krypterat. Egentligen behöver inte ens dokumentet existera elektroniskt utan systemet kan referera till ett fysiskt exemplar.

· Meta-data är samma som egenskaper ("properties") i WebDAV-standarden. Med denna standard (som stöds av allt fler inklusive Microsoft, Oracle och Adobe) kan man hantera meta-data på mappar och filer.

· Meta-data är samma som fält eller attribut i dokumenthanteringssystemen. Ett system hanterar olika objekt (dokument, dokumentversioner, personer, projekt, etc) och dessa har normalt attribut (datum, versionsbeteckning, telefonnummer, projektansvarig).

Nu kommer man till den intressanta frågan hur man skall designa ett dokumenthanteringssystem, d.v.s. vilka objekt som skall finnas och vilka meta-data som varje objekt skall kunna ha? Det är inte alls självklart vad som skall få vara objekt och vad som "bara" skall få vara meta-data.

Ett objekt lever ett eget liv, har en unik identitet och har normalt relationer till andra objekt. Till ett objekt hör ett antal metadata. Naturliga exempel på objekt är dokument och personer. Vad är en dokumentversion? Den bör vara ett eget objekt eftersom den skapas, används, fryses och har naturliga meta-data knutna till sig. Vad med ett datum? Idag verkar det rimligt att ett datum är ett meta-data men man kan faktiskt tänka sig objektet 2001-05-17 som ett eget objekt som har relationer till andra objekt.

Om en dokumentversion är författad av en viss person, hur skall detta representeras i systemet? Ett alternativ är att dokumentversionen har ett meta-data som heter Author som innehåller författarens namn. När man skriver ut dokumentet vill man också att författarens avdelningsbeteckning skall finnas i en viss ruta i huvudet varför man även kan tänka sig att dokumentversionen har ett meta-data AuthorOrg. Detta verkar dock inte vara en bra strategi. Varför just avdelningsbeteckningen? Varför inte telefonnummer, epost-adress, etc? Dokumentversionen checkades in vid ett visst tillfälle som en följd av att någon godkänt versionen. Detta skedde vid en viss tidpunkt. Skall data om godkännaren också lagras som meta-data. Vad händer om flera fungerade som godkännare?

I stället för att hitta på ett antal meta-data för dokumentversionen synes en bättre design vara att dokumentversionen har ett antal relationer till andra objekt. För att få mera data får man således ställa frågor till de andra objekten.

Om vi definierar objekten dokumentversion, person, avdelning och händelse får vi ett mycket mer flexibelt och objektorienterat system. Dokumentversionen har en författar relation till en viss person, personen har en tillhör-relation till en viss avdelning, dokumentversionen har en relation till en viss händelse, till en händelsen finns en godkännanderelation till en person.

Notera t.ex. att ett godkännande skulle kunna inbegripa flera personer utan att dokumentversionen påverkas (genom att händelse-objektet får möjligheten att ha relationer till flera personer).

Hur kan då detta implementeras? Först och främst skall meta-data inte finnas inne i objekten; meta-data hämtas genom att ställa frågor till dokumenthanteringssystemet.

När man frågar efter meta-data får man ofta inte värdet direkt utan en referens till ett annat objekt. Följande bild visar ett exempel:

Dokument:

Version <-------------!
DokumentVersion <-----!
Namn = "1.6"
Godkänd <----------------
Författare <--------- ! !
                      ! !
Person <--------------! !
Förnamn = "Jan"        ! !
Efternamn = "Herlitz" ! !
Tel = "633 29 01"      ! !
Avdelning <---------- ! !
                      ! !
Avdelning <-----------! !
Namn = "H/Su"          ! !
Händelse <---------------
Datum = "2001-05-17"
Person <--- ...

Sett ur ett web-perspektiv (och WebDAV) används naturligtvis URLer som referens till objekt. Det här är så långt jag kommit nu men mycket återstår. Det skulle vara intressant att diskutera frågan med dig och andra. / JC Herlitz

Mitt svar till Johan:

Precis så har jag också tänkt och jag har varit på RDF och andra format för att hantera strukturerade beskrivningar. Resonemanget går hela vägen till att bygga upp en ontologi för alla beskrivningar i språket som kan vara av strukturellt värde. Om man ska använda LDAP-syntax, e-post eller namn på en person eller referera till objektet är viktiga frågor. Detta är i högsta grad beroende av den infrastrukturnivå som är standard i nätverken.

Idag är infrastrukturen dokument utan andra egenskaper än de visuella. Med XML kan man se till att innehållet går att söka med en x-path match. Men oftast är informationen helt utan markeringar, och därför ger vi dem enklare egenskaper "oppepå".

Om man däremot inte ser till lagringen eller formatet överhuvudtaget så är metadata (liksom egenskaper på filer i win2000) etiketter man klistrar utan på namngivna "saker". Sakerna i sig kan vara applikationer, dokument eller gränssnitt till dokumentdatabaser eller XSLT. Jag ser det i huvudsak som två olika varianter av metadataåkomst idag:

· "Fysiska" ettiketter som finns i databas/filsystem eller i dokumentet åtkomligt på genrellt sätt. (Man kan precis som Microsoft replikera egenskaper mellan dokument och system)

· Gränssnitt som genom "gateway" eller deklarerad XSLT genererar "metadata" live från innehåll.

Skälen till att man skulle tvinga sig till att ha metadata i en separat databas tycker jag inte är självklara. Dels för att dokument blir svåra att kopiera och dels för att metadata ofta redan finns i innehållet, främst i sidhuvuden men även kan ses som visuella element i dokumentet. Sedan missar man även möjligheten att skapa nya XSLT vyer för "ny" metadata "on demand".

Jag ser gärna metadata som "SQL på en högre nivå", när man vill arbeta med dokument mellan dokumentsystem och dela resurser med helt olika ursprung. Nyckelordet för mig är tillämpning, där metadata är ett gränssnitt för att hitta och sortera. Det finns givetvis oändligt med tillämpningar men samtidigt en del patterns som man kan bygga strukturer kring. Som DP.

Metadata är förvirrat, precis som du säger, men metadata fyller en funktion. Problemet är att jag inte vet om det finns ett bättre begrepp för det vi försöker bygga vår tillämpning på utan att gå från semantik till dataformat.

Sammanfattning

Med metadata kan man bygga semantisk infrastruktur oberoende av dokumentformat både internt men även tillsammans med partners över Internet.

Det finns olika lösningar för att lagra metadata i dokument eller i databaser med dokument-databaser. Webbmappar erbjuder möjligheter att lagra metadata kopplat till dokument i ”properties”.

Det finns en defacto-standard i from av bibliografiska element framarbetade i Dublin Core projektet. Det finns andra förslag för att utveckla egenskaper för styrande dokument eller dokument på arbetsplatsen som jag själv är involverad i. Men vilka metadata ni har behov av internt måste ni själva avgöra.

För att beskriva relationer och processer kan man I XML använda sig av RDF (Resource Description Framework) eller I process använda sig av UML (Universal Modeling Language).

Man kan välja att lagra metadata inuti eller utanför dokumentet, eller alternativt spara på flera ställen. Huvudsaken är att det är lätt att hantera dokumenten samtidigt som det är lätt att söka bland dokument och utnyttja metadata som en relationsdatabas.