Introduktion
Språkbanken utvecklar och tillhandahåller omfattande språkteknologiska lexikonresurser, d.v.s. datamängder innehållande strukturerad information om språkliga lexikonenheter (ord och lexikaliserade flerordsenheter) som ska kunna användas i olika tillämpningar för automatisk språkbearbetning, huvudsakligen för svenska. Exempel på sådana tillämpningar är maskinöversättning, informationssökning, automatisk sammanfattning av text, datorstödd språkinlärning, dialogsystem, taligenkännings- och talgenereringssystem, alternativ och kompletterande kommunikation (AKK), frågebesvarande system, språkteknologibaserad e-vetenskap, m.fl.
Lexikonresurserna omfattar för närvarande (sep 2014) 23 olika lexikon med sammanlagt närmare 700.000 ingångar. De moderna lexikonen är flest, störst och innehåller den rikaste och mest mångfacetterade informationen. Vidare pågår kontinuerligt arbete med att utvidga och utöka lexikonresurserna. För närvarande bearbetas ytterligare 5 lexikon som så småningom kommer att läggas till. Idag är Språkbankens lexikonresurser tillgängliga på tre sätt:
- Genom onlinesökning i ett webbgränssnitt Karp
- Genom programanrop till ett REST-baserat nättjänst-API
- Genom nerladdning av hela resurser i LMF-format (ISO 2008) under licensen CC-BY
I tillägg till detta utvecklar DART, i samverkan med tekniska konsulter vid Conceptcoding.org, den multimodala begreppsdatabasen CCF (Concept Coding Framework) -- f.n. med stöd för bliss- och ARASAAC-symboler -- med inriktning mot både AKK och bredare behov av språkliga stödresurser. Dessa lexikala resurser är idag något provisoriskt kopplade till de två lexikonreurserna Princeton WordNet och Saldo. De erbjuds via fria programvaruimplementationer servertjänster (GPL och andra licensalternativ) via www.conceptcoding.org, samt via hittills preliminärt definierade och dokumenterade API:er för tredjepartsutvecklare.
Målet med LTLOD@SB-projektet var att tillgängliggöra Språkbankens och DARTs lexikonresurser även som länkade öppna data. Därmed blir de både användbarare och fler kan använda dem, vilket är rimligt med tanke på de stora summor offentliga medel och de omfattande arbetsinsatser som har lagts ner på deras utveckling.
Inom ramen för länkande öppna data identifierar vi resurser (det vill säga strukturerad information) med hjälp av Uniform Resource Identifiers (URIs). Resource Description Framework (RDF), den modell som har tagits fram av W3C, är en mekanism byggd på URIs för att beskriva strukturerad information i den semantiska webben. Med denna mekanism beskrivs informationen i form av tripplar. Varje trippel består av två noder och ett attribut som beskriver relationen mellan noderna.
Relationerna mellan noderna är väldigt viktiga för att representera informationen i fråga. För representationen av lingvistiska resurser är RDF-modellen inte tillräcklig. Den är mycket elementär och behöver därför kompletteras med andra modeller, i vårt fall en modell som är lämplig för att representera de lexikal-semantiska resurserna.
lemon (LExicon Model for ONtologies) är en modell för att definiera LOD-format för språkliga data och har sedan 2011 varit i fokus för W3C OntoLex grupp. Modellen har framgångsrikt använts för att representera flera existerande lexikala resurser, den största av dem är Princeton WordNet. En annan fördel med lemon är att den bygger på Lexical Markup Framework (LMF) -- ett av representationsformaten för Språkbankens lexikala resurser.
Informationsinhämtning och specifikationen av RDF-formatet
Vårt arbete och våra resurser ställer speciella krav på LOD-formatet. Detta gäller dels innehållet, där somliga av våra lexikon har en struktur som avviker från de typer av lexikonresurser som hittills har diskuterats i dessa sammanhang. Dels gäller det även rent tekniska lösningar i samband med uppdateringar. I detta projekt har vi tittat på fyra av de moderna lexikonen: Saldo, Saldom (Saldos morfologi), SweFN och Lexin.
Språkbankens lexikonresurser är kopplade till Saldos ingångar. Därför var ett naturligt första steg i specifikationensprocessen att börja med RDF-formatet av Saldo-lexikonet, inklusive Saldos morfologiska komponent, dvs. Saldom.
lemon är uppbyggd kring lexikala enheter. De mest centrala enheterna är LexicalSense och LexicalEntry. LexicalSense representerar kopplingen mellan lexikonet och andra ontologienheter. LexicalEntry representerar orden, deras morfologi och syntaktiska beteende. lemon är strukturerad så att varje LexicalEntry bara kan ha en canonicalForm. Utmaningen med denna principen har varit att representera Saldo-ingångar som har en betydelseidentifierare och en lemgram-identifierare och där relationerna mellan dessa identifierare är flera till flera: flera betydelser kan ha en eller flera lemgram, flera lemgram ha en eller flera betydelser.
Vår lösning var ett tillägg av en '#Lemma' tag associerad med Saldos lemgram-id. Saldos lemgram-id specificeras med "lemon:LexicalEntry" och genom detta bli "lemon:canonicalForm" unik för varje ingång. Ett exempel på en specifikation av Saldos lemgram "idag..ab..1" är följande:
<lemon:LexicalEntry rdf:about="idag..ab.1">
<lemon:canonicalForm>
<lemon:Form rdf:about="idag..ab.1#Lemma">
...
<lemon:canonicalForm>
<lemon:sense>
<lemon:LexicalSense rdf:about="i_dag..1">
<saldo:primary rdf:resource="dag..1"/>
<saldo:secondary rdf:resource="nu..1"/>
</lemon:LexicalSense>
För att separera mellan vokabulären och klassifikationsscheman, har vi definerat en ontologi för Språkbankens lexikonresurser. Ontologin följer OWL DL med uttrycksfullhet AL och finns tillgänglig här.
Var och en av de fyra lexikonresurserna vi har tittat på har en unik struktur och specifik data som kräver dels modifiering och dels anpassning av vokabulären till andra modeller. lemon innehåller redan vidare länkning till andra modeller: LexInfo, ISOcat, och OLiA. Somliga är uttryckta i RDF-formatet. Dessutom har vi kompletterat modellen med andra välkända vokabulärer och metadata som till exempel Dublin Core och Uby för maximal återanvändning av termer som förekommer i Lexin och SweFN.
Till exempel SweFN "coreType" och "semanticRole" specificeras med lemonUby specifik vokabulär, det vill säga "uby:coreType" och "uby:semanticRole". Nedan följer ett exempel ur SweFN på hur ramen "Abandonment" specificeras enligt lemon och lemonUby specifikationer. Vi ser att "BFNID", "semanticType" och "domain" är specifika för SweFN.
<lemon:LexicalEntry rdf:about="swefn--Abandonment#Entry">
<lemon:sense>
<lemon:LexicalSense rdf:about="swefn--Abandonment">
<swefn:BFNID>Abandonment <swefn:BFNID>
<swefn:semanticType>Relational_act </swefn:semanticType>
<swefn:domain>Gen </swefn:domain>
<lemon:semArg>
<lemon:Argument rdf:about="swefn--Abandonment#coreElement-Agent">
<uby:coreType rdf:resource="http://purl.org/olia/ubyCat.owl#core"/>
<uby:semanticRole>Agent </uby:semanticRole>
</lemon:Argument>
</lemon:semArg>
...
</lemon:sense>
Som vi nämnde tidigare, relationerna i varje resurs är specifika för den resursen. I Saldo representeras till exempel den lexikala ingången "i_dag..1" med lemons LexicalSense-relation, men betydelserelationerna "primary" och "secondary" kvarstår som Saldo-relationer.
<lemon:sense>
<lemon:LexicalSense rdf:about="i_dag..1">
<saldo:primary rdf:resource="dag..1"/>
<saldo:secondary rdf:resource="nu..1"/>
</lemon:LexicalSense>
</lemon:sense>
Samma ingång i Lexin har andra egenskaper som representeras med Lexins relationer, som till exempel: "lexinVariantID" och "lexinLexemeNumber". Ingången är i sin tur kopplad till Saldos resurser med "owl:sameAs" relationen, som tillhör W3C vokabulär.
<lemon:sense>
<lemon:LexicalSense rdf:about="lexin--i_dag..1">
<lexin:lexinVariantID>7434</lexin:lexinVariantID>
<lexin:lexinLexemeNumber>1</lexin:lexinLexemeNumber>
...
<owl:sameAs rdf:resource="i_dag..1"/>
<owl:sameAs rdf:resource="i_dag..2"/>
</lemon:LexicalSense>
</lemon:sense>
Tekniska lösningar
Vi har en lokal RDF databas för att lagra RDF resurserna som en stor datamängd. Programvaran 4store är den vi använder för detta ändamål. Med 4store kan man enkelt ladda upp, uppdatera och ta bort data från ett HTTP-gränssnitt. 4store SPARQL server är tillgänglig via ett HTML-formulär och ett HTTP-gränssnitt.
Ett arbete med Jena semantiskt ramverk i Karp har påbörjats.
Implementering av konverteringsfunktionalitet till RDF-formatet
En fördel med att både lemon och Språkbankens lexikonresurser följer LMF standarden är möjligheten att använda sig av andra standarder för konverteringsendamålet. Vi har följt Extensible Stylesheet Language (XSL) Transformation standarden för att konvertera Saldo, Saldomi, Lexin och SweFN från LMF till RDF med hjälp av lemon.
Som vi har visat i föregående avsnitt, mycket av den datan och relationerna som beskrivs i de olika lexikal-sematiska resurserna är specifika för varje resurs, följaktligen avviker RDF formatet från en resurs till en annan. Sammanlagt har vi fyra RDF filer for de olika resursers vi har konverterat: saldo.rdf, saldom.rdf, lexin.rdf, och swefn.rdf.
Språkbankens och DARTs metadata struktureras med hjälp av Dublin Core (DC) klassifikationsvokabulär. Dessutom följer Språkbanken Meta-Share klassifikationsvokabulär. För att presentera dessa klassifikationer i RDF har vi valt att följa MetaShare mapping schema.
Språkbankens lexikonresurser uppdateras och utvidgas ständigt. Tekniskt sett görs alla ändringar och tillägg på ett ställe, en grundversion, från vilken sedan andra versioner genereras automatiskt. På samma sätt genereras LOD-versionen av resurserna automatiskt. RDF-formatet av resurserna genereras från LMF grundversionen, uppdateringen görs i sin tur i RDF-databasen via HTTP-gränssnittet. Uppdateringen sker regelbundet.
LOD lösningen
SPARQL är frågespråket för att komma åt RDF-data. Vi har implementerat två SPARQL-ingångar för att möjliggöra sökningar bland vår länkande data. Ingångarna bygger på SPARQL 1.1 som tillåter användaren att formulera avancerade frågor mot den semantiskt strukturerad datamängden.
Nedan följer några möjliga frågor som kan testas mot våra resurser via: (I) Språkbankens SPARQL-ingången (exempel 1--4); (II) REST-tjänsten (exempel 5); (III) yuzu gränssnittet där frågorna är lexikoningångar (exempel 6).
(1)
PREFIX rdf:
PREFIX rdfs:
PREFIX saldo:
SELECT ?s WHERE { ?o saldo:primary ?s } LIMIT 10
(2)
PREFIX rdf:
PREFIX rdfs:
PREFIX saldo:
SELECT * WHERE { ?s saldo:primary saldo:djur..1 } LIMIT 10
(3)
PREFIX rdf:
PREFIX rdfs:
PREFIX saldo:
SELECT * WHERE { ?s saldo:primary saldo:PRIM..1 }
(4)
PREFIX rdf:
PREFIX rdfs:
PREFIX lemon:
SELECT ?s WHERE { ?a lemon:writtenRep ?s } LIMIT 10
(5)
url --digest --verbose --url "http://lod.conceptcoding.org:8001/sparql/?query=SELECT * WHERE %7B ?s ?p ?o %7D LIMIT 10"
(6)
(6a) idag..ab.1
(6b) lexin--i_dag..1
(6c) swefn--Abandonment#Entry