Podes prosjektblogg

Tre år med Pode

Postet den 22. February 2011 | Skrevet av Anne-Lena | 4 kommentarer

Etter nesten tre år er Podeprosjektet nå avsluttet. Pode har gjennomgående hatt ett hovedfokus: brukeren og brukertjenester.

Utgangspunktet for prosjektet var ønsket om å presentere og formidle bibliotekenes katalogdata på nye og bedre måter, koblet med data fra eksterne kilder. I praksis har prosjektet jobbet like mye med å tilgjengeliggjøre katalogdataene på fornuftige måter og å se på kvaliteten på dataene for ny bruk og presentasjon.

Vi har jobbet med konkret praktisk utprøving og har laget prototyper for flere tjenester:

Alle prototypene er dokumentert, og kildekoden ligger fritt tilgjengelig for gjenbruk og tilpasning til egen bibliotekkatalog. Kildekoden er delt under en GPL-lisens på Podes konto på GitHub.

Vi har vist:

  • At det er mulig å uttrykke katalogdata i andre formater enn MARC (vi har brukt RDF)
  • At det er noe å tjene på å uttrykke katalogdata i et annet format enn MARC
    o Bedre strukturering
    o Flere søkemuligheter
    o Større uttrykksfullhet
    o Bedre formidling/presentasjon
    o Bedre tilgjengelighet
  • At det er mulig å få til en FRBR-presentasjon av trefflister og dermed kunne presentere rene forfatterbibliografier
  • At det er mulig å utnytte egne katalogdata i samspill med eksterne data på en fornuftig måte

Arbeidet med bibliotekkatalogen har avdekket flere utfordringer knyttet til metadataformatet som er standard i bibliotekene. MARC-formatet oppleves både som utdatert og lite fleksibelt. Bibliotekene sitter på en mengde strukturerte metadata, men formatet utilgjengeliggjør informasjon som er lagret. Et eksempel på dette er bruk av notefelter. Dette er informasjon som er les- og tolkbart for bibliotekarer som leser posten, men ikke for en datamaskin som skal behandle store mengder informasjon på en enhetlig måte for så å presentere det ut til brukeren.

Det siste året har vi jobbet med semantiske teknologier (RDF/SPARQL) og Linked data. Etter konvertering av to datasett til RDF og arbeid med å presentere disse dataene ut til brukeren, ser vi ingen hindringer i å lagre katalogpostene som RDF. Vi får uttrykt alt vi gjør i MARC, men vi får også så mye mer.

Vi har erfart:

  • At enhetlige metadata med god kvalitet er viktig
  • At forholdet mellom katalogreglene (AACR II) og MARC-formatet byr på en del utfordringer
  • At katalogene kan inneholde klassifikasjonskoder fra ulike kilder (DDK4, DDK5, DDC 21, DDC22, diverse utgaver av Arnesens klassifikasjon, samt UDK).
  • At forskjellige varianter av MARC-formatet nasjonalt og internasjonalt vil gjøre det mer krevende å bygge tjenester på toppen av dataene. Bare i lille Norge har vi et utall forskjellige varianter av NORMARC, f.eks. BSMARC (Biblioteksentralen), Bibliofil-MARC og Bibsys-MARC.
  • At det er på høy tid å få et koordinert og fremtidsrettet format tilpasset dagens og morgendagens teknologiske muligheter. Å tilgjengeliggjøre bibliotekkatalogen for brukerne krever andre egenskaper av katalogdataene enn det som er tilfelle i dag.

Basert på arbeidet i prosjektet, har vi kommet frem til en trepunkts ønskeliste. Her utfordres Nasjonalbiblioteket, katalogfaglige komiteer på nasjonalt (og internasjonalt) plan og biblioteksystemleverandørene til å komme på banen.

Podes ønskeliste:

  • Åpen dokumentert tilgang til alle katalogdata
  • Et moderne metadataformat som er åpent og fleksibelt
  • Nasjonalt autoritetsregister og åpne, nasjonale unike ID-er for verk og forfattere

Les mer om resultatene på nettsiden vår eller bruk kategorilisten her på bloggen til å finne temaer som interesserer deg!

Pode søkte om prosjektmidler fra Nasjonalbiblioteket til videreføring i 2011, men fikk ikke tilslag.

Improving the presentation of library data using FRBR and linked data

Postet den 8. February 2011 | Skrevet av Asgeir | Ingen kommentarer

The Pode project at Oslo Public Library has experimented on the automated FRBRizing of catalogue records, as well as expressing bibliographic descriptions as linked data to enrich catalogue browsing with information from external sources. The experiment has been conducted on the productions of two Norwegian authors: Knut Hamsun and Per Petterson.

Finding the way through libary hitlists

Knut Hamsun (1859-1952) is Norway’s most prominent novelist and one of three Norwegian Nobel laureates in literature. His literary production includes some 30 novels, a few plays and collections of short stories, one collection of poetry and some non-fiction and biographical writings. Altogether Hamsun’s production counts a total of 40 works; it is a lucid bibliography that a library user should be able to browse easily.

However, the image that meets the library user is quite different. In the online catalogue at Oslo Public Library, a qualified search for “Hamsun, Knut” as author will produce a list of 588 hits (as of February 8th, 2011):

Online catalogue search for “Hamsun, Knut” as author

588 is way to many hits to provide for an author who wrote 40 books. It probably doesn’t help the library user that the first 14 hits, due to sorting method, aren’t books written by Hamsun at all. In fact, the first novel in Norwegian by this Norwegian novelist doesn’t occur until no. 24 in the list. Notice that this is the result of an advanced qualified search. A more typical simple search provides a much longer list than this, even, where no work by Knut Hamsun is to be found in the first two pages or 100 hits.

Several things could be said about sorting and presentation of hitlists in these particular cases. But on a more fundamental level, it is a problem that the traditional library catalogue only describes manifestations of works. Each edition of a book is given a separate record, and there are no functional connections between manifestations of the same work. A library user who searches the online catalogue for a particular title, might therefore sign up on a waiting list to borrow a classic novel, without realizing that numerous other editions of the same book are already available. Another user might end up not getting the book at all, if he accidentally picked an edition that no longer has available copies. Our impression is that library users are typically interested in finding a particular title, not a particular edition of that title. This is especially the case when it comes to fictional works, where different editions usually have identical content. Ideally a user should be able to make a reservation for a title, without having to choose between different editions. Of course, those who do care about editions, should still have the opportunity to specify this, but why should everyone else be forced to pick?

Shrinking lists

The Pode project used a method of automated FRBRization of catalogue records, in which different types of bibliographical data are considered to apply to different group 1 entities from the FRBR-model. For example the original title and author of a book are properties that apply to the Work entity, while data about publisher, date and physical features apply to the Manifestation entity. In this way, we can cluster bibliographical records that are related to the same expressions or works.

The first attempts at FRBRizing catalogue records had results that were far from perfect. This was mainly due to missing information in the bibliographic records and inconsistent cataloguing practice. To move on with the experiment, we had to wash a considerable number of records, in order to get data that were sufficiently expressive and consistent. This eventually resulted in lists of works that corresponded with the bibliography of the chosen authors.

Enriching catalogue records

The next step was to convert the datasets into RDF and to link data to other sources. Works were linked to instances in DBpedia and Project Gutenberg, while persons were linked to instances in DBpedia and VIAF. This allowed the application to display biographical information about the authors, as well as linking to digital fulltext versions of the works. This also opens for new ways of browsing the library collection, as outside sources might provide relations between works, persons and subjects, that are not expressed in the catalogue records.

The Linked authors web application

The experiment eventually led to a light web application that demonstrates how library records can be grouped and browsed by FRBR entities Work, Expression and Manifestation:

http://bibpode.no/linkedauthors/

The interface is only available in Norwegian language. Choose an author from the first drop-down list to get the works by that author. Then click to find the different parts or expressions of a work, and the different manifestations of an expression. The application uses SPARQL queries against an RDF dataset to fetch data. Biographical information on the right side of the screen are fetched from DBpedia, also using SPARQL queries.

The experiment has shown that even traditional MARC records contain the necessary information to provide the library user with ways of presenting library collections that are far more lucid and user friendly than the lists we are given today. This does, however, depend on a conscious and consitent catalouging practice. Furthermore, we think it seems that there is a lot to be gained from expressing library data in a format that can link to and interact with data from other sources. Sources like DBpedia contains immense amounts of information, that can enrich our own data and provide new and interesting ways of browsing and presenting our collections. Choosing to stick with library specific formats is in a way to choose not to take advantage of these opportunities.

Fremtidens biblioteksystem

Postet den 3. February 2011 | Skrevet av Anne-Lena | Ingen kommentarer

Pode ble presentert på DDE Libras brukergruppemøte i København i dag. Libra er levert av Axiell. 

Temaet for dagen var “Fremtidens biblioteksystem”. Pode delte podium :) med Marshall Breeding som snakket om trender i biblioteksystemer, Magnus Enger fra Libriotech som snakket om fri programvare og Elisabeth Robinson fra OCLC som snakket om biblioteksystemer i skyen og det som skal bli Bibsys’ nye biblioteksystem.

Invitasjonen kom fra Esben Fjord fra Gladsaxe bibliotekene, som presenterte flere interessante prosjekter på fjorårets Internet Librarian International konferanse. Mobilappen er tidligere omtalt på bloggen til Digitalt bibliotek.

View more presentations from The Podeproject .

Kunnskapsorganisasjonsdagene 2011

Postet den 26. January 2011 | Skrevet av Anne-Lena | 2 kommentarer

Ut og vaske poster – FRBRisering i Podeprosjektet er tittelen på Podes presentasjon på årets KORG-dager

Trond Aalberg presenterer FRBR og arbeidet med FRBRiseringen av Podes data, før vi presenterer hva vi har gjort med dataene og hvordan vi kan utnytte de. Katalogavdelingen på Deichman deler sine tanker og synspunkter om arbeidet og hvilke utfordringer vi har i forhold til katalogregler og -praksis.

View more presentations from The Podeproject .

Presentasjonen finner du også på vår Slideshareprofil.

Vi vil gjerne ha dine innspill – og om noen har lyst til å samarbeide videre ber vi dere ta kontakt!

Dokumentasjon for LinkedAuthors og LinkedNonFiction

Postet den 11. January 2011 | Skrevet av Magnus | Ingen kommentarer

Høsten 2010 utviklet Pode to applikasjoner/mashups baserte på semantiske data, og nå er alt av dokumentasjon og kildekode tilgjengelig for begge to. For begge prosjektene vil det være to kildekode-repositorier, et for den innledende databehandlingen og et for web-presentasjonen:

For å klone kildekode med Git kan følgende kommando brukes:

git clone git://github.com/pode/LinkedAuthors.git

LinkedAuthors kan byttes ut med en av disse, etter behov: LinkedAuthorsWeb, LinkedNonFiction, LinkedNonFictionWeb.

Tradisjonell v.s. semantisk mashup

Postet den 7. January 2011 | Skrevet av Magnus | 1 kommentar

Jeg har i løpet av de siste par årene hatt gleden av å bidra på 4 ulike mashups for Pode, to basert på tradisjonelle APIer og to helt eller delvis basert på SPARQL endpoints. Denne bloggposten prøver å si noe om fordeler og ulemper med disse to typene av datakilder.

Kort fortalt tror jeg tradisjonelle APIer er lettere å forholde seg til enn et SPARQL endpoint når man skal lage sin første mashup. Stort sett handler det da om å finne ut hvilke parametere en tjeneste kan ta i mot, og hvilke verdier de kan ha. Med REST-fulle tjenester er det så enkelt som å konstruere en URL med de ønskede parameterne.

Ulempene med tradisjonelle APIer oppdager man etter hvert som man tar i bruk flere: alle har sine egne parametere med egne tillatte verdier, og man må finne ut av alt sammen fra bunnen av igjen for hvert nye API man prøver seg på. Dette i motsetning til SPARQL endpoints som alle sammen tilbyr den samme “mekanismen” for å hente ut data. SPARQL har en brattere læringskurve enn de fleste APIer, men når man først har lært seg det kan man overføre lærdommen fra en datakilde til en annen.

Når det er sagt er det et par potensielt problematiske sider ved SPARQL også: Det ene er at måten dataene er beskrevet på kan variere fra endpoint til endpoint, dvs hvilke ontologier som er brukt, og kanskje også hvordan de er brukt. Man har strengt tatt ingen garantier for at de om står bak har en felles forståelse av hvordan en ontologi skal brukes. (Vi får imidlertid håpe at det her vil foregå prosesser som gjør at man beveger seg mot økende grad av konsensus, ikke mot økende kaos…) Foreløpig virker det også noe tungvint å orientere seg i en et ukjent endpoint, for å danne seg et bilde av hvilke data som finnes der og hvordan de er beskrevet (med mindre det finnes dokumentasjon som gir gode svar på dette). Dette kan skyldes undertegnedes korte erfaring med SPARQL og det kan også vise seg at dette blir avhjulpet etter hvert av verktøy som kan gjøre det lettere å få oversikten over hva som er i en triplestore og hvordan det er beskrevet.

Et annet potensielt problem med SPARQL vil oppstå dersom vi etter hvert får

  • mange ulike versjoner av SPARQL – i dag har vi versjon 1.0 og 1.1 er på vei, men hvem vet hvor langt vi har kommet om 10 år?
  • ulike og mangelfulle implementasjoner av SPARQL, slik at man blir sittende og lure på hvilke operasjoner et endpoint støtter, omtrent slik man jakter på parametere for tradisjonelle APIer.
  • tjenester som ikke oppdateres etter hvert som det kommer nye versjoner av SPARQL og/eller triplestore-programvare.

Vi kan i og for seg se tendensene til disse problemene med den triplestoren Pode har benyttet (ARC), som støtter SPARQL og noe de omtaler som SPARQL+, som later til å være en forsmak på funksjonalitet som er planlagt i SPARQL 1.1. Forhåpentligvis vil de færreste prosjekter velge å selv implementere sin egen SPARQL-funksjonalitet når de skal gjøre data tilgjengelig, men heller gjenbruke eksisterende systemer, slik at antallet ulike implementasjoner blir så lavt som mulig. Tilstedeværelsen av gode triplestores/endpoints som er tilgjengelige som fri programvare vil forhåpentligvis bidra til dette.

En annen stor fordel med SPARQL som semantisk datakilde er at det innebærer et helt spørrespråk (query language), i motsetning til en liste med parametere i tradisjonelle APIer. Hvis man tenker seg parameterne i et tradisjonelt API som forhåndsdefinerte spørsmål det er mulig å stille til en tjeneste, så åpner SPARQL opp for en mye større fleksibilitet, i og med at det blir mulig for utviklere å stille en tjeneste “spørsmål” som de som står bak tjenesten aldri ville tenkt på å gjøre det mulig å stille gjennom et tradisjonelt API.

Konklusjon? Semantiske datakilder innebærer større muligheter for gjøre interessante ting med data enn det man får gjennom tradisjonelle APIer, men de innebærer også en brattere læringskurve. Alle som er involvert i utviklingen av semantiske datakilder bør jobbe bevisst for å unngå fragmentering av de semantiske datakildene, og bidra til en enhetlig utvikling gjennom åpne standarder, konsensusløsninger og fri programvare.

Vi lever i spennende tider!

KBs ‘SveLitt’

Postet den 30. December 2010 | Skrevet av Berit | Ingen kommentarer

På starten av 2000-tallet jobbet Kungliga Biblioteket i Stockholm med et prosjekt for å FRBRisere forfatterskapet til Selma Lagerlöf. Nettsidene til prosjektet inneholdt dokumentasjon på hva de har gjort og hvorfor. Sidene er ikke lenger tilgjengelige fra KBs egen server, men kan leses via Internet Archive.

Målet med projektet är att tillgängliggöra den svenska skönlitteraturen på ett sådant sätt att allt av och om en författare redovisas i en överskådlig och navigerbar sammanställning. Detta görs genom att varje författares litterära verk samlas för sig med uppgifter om upplagor, utgåvor och översättningar sorterade efter år och språk så att man får en överskådlig presentation.

FRBRiseringsprosedyren består av seks trinn, der trinn 1-3 utgjør grunnlaget. Dersom postene som hører til verket er riktig laget, bør lenkingen kunne gjøres automatisk.

Trinn 1: Det lages en post over verkets 1. opplag på originalspråket, kalt «FRBR-posten».

Om det ikke finnes en slik katalogpost, må den lages. Den gis en kode «frbr» i felt 042.

Alle innganger på personer og institusjoner må være validert og autorisert. Funksjonskoder i felt 7XX er viktig!

«Uniform titel» = standardtittel, defineres som  «den titel under vilken ett verk är mest känd». I de fleste tilfeller identisk med hovedtittelen i 245, hvis ikke, må den registreres i 240.

Det må registreres korrekte koder for innhold/materialtype og språk.  Det legges relativt stor vekt på klassifikasjon, emneord og genretermer. (emne-entiteter). De hentes fra autoritative og autoriserte kilder.

Trinn 2: Det lages autoritetspost (navn + tittel) for verket.

I felt 100 aForfatternavn med uniform tittel (standardtittel) i delfelt t.

I felt 400 legges alternativ form for verkets tittel.

100 1/ _a Lagerlöf, Selma, _d 1858-1940. _t Nils Holgerssons
          underbara resa genom Sverige
400 1/ _a Lagerlöf, Selma, _d 1858-1940. _t Nils Holgerssons
          underbara resa

Det lages se også-henvisning mellom relaterte verk, f.eks. verk i serie, bearbeidede verk (f.eks. filmatisering), verk som kommenterer et annet verk (f.eks. parafrase).

Trinn 3: Opphavsmannens autoritetspost.

Trinn 4: Uttrykk og manifestasjoner av samme verk

På postene som representerer uttrykk og manifestasjoner, er det spesielt viktig at det er registrert korrekte koder materialtype og fysisk form, samt språk for dokumentet. Dersom hovedtittelen skiller seg fra standard-tittelen, må standardtittel registreres i 240. Det gjelder også oversatte titler, der originaltittelen registreres i 240 (+indikator) etterfulgt av språket i dokumentet. Eksempel:

1. Originaltitel med tillägg av översättningens språk.
Exempel:
100 1/ _a Guillou, Jan, _d 1944-
240 1/0 _a Ondskan. _l Danska
245 Onskaben / _c Jan Guillou ; bearbejdet af…

2. Uniform titel i de fall titeln i boken är en annan.
Exempel:
100 0_a Lagerlöf, Selma, _d 1858-1940
240 _a Nils Holgerssons underbara resa genom Sverige
245 _a Nils Holgerssons underbara resa

Trinn 5: Andre verk av og med samme opphavsmann.

700 med funksjonskode!

Trinn 6: Verk som omhandler opphavsmann og verk

Det tas altså utgangspunkt i en post basert på 1. utgave/opplag av verket. Dette er en annen måte å gjøre det på enn den Pode valgte, der alle postene hadde samme status.

Videre lages verks-autoriteter. Dette behovet kom frem i Podes FRBRiseringsforsøk, men vi hadde ikke noe verktøy for håndtering av noe slikt.

Vi konkluderte med at et register over slike verksautorieter bør opprettes på nasjonalt nivå.

Ellers er det noe uklart hva standardtittelen egentlig er i et hvert tilfelle. Hvilket navn et verk er mest kjent under, kan det herske tvil om.

Pode valgte å holde seg til den tittelen verket opprinnelig var utgitt under, slik NORMARC legger opp til i eksempelet under 240. Dette er uomtvistelig, men på ingen måte nødvendigvis den tittelen verket er mest kjent under.

Hvem skal i så fall bestemme det?

MARC for machinekind

Postet den 30. December 2010 | Skrevet av Anne Karine | 1 kommentar

Design a thing considering in its next largest context – a chair in a room, a room in a house, a house in an environment, an environment in a city plan.  Eliel Saarinen (architect)

or

Make your catalogue records available as objects coded for the world wide web in a format meant for machines. If all libraries do this, we might regain our position as metadata providers and be able to create better services based on external metadata. At this years Online information conference in London  Karen Coyle came up with the following challenge for libraries:  if we all learned some RDF we could become quite powerful and even more so if our metadata is available as RDF.

The Pode project is all about metadata, and creating mashups based on our metadata in order to give our end-users a better experience of our services. Over the years the project has run, we have created mashups based on library specific protocols (z39.50 & SRU) and MARC-data, frbrised two authorships and converted this frbrised dataset to RDF and Linked data.

The first mashups we created tested the access we have to our data, thus testing the protocols more than the MARC-format. Though the MARC format is a standard, the application of the standard is not necessarily standardised.

The idea that “MARC must die” isn’t ours and has been around for a number of years. The topic becomes even hotter now that the web Linked data is emerging. For details regarding the issues of why MARC must die visit the Marc must die wiki: http://marc-must-die.info/index.php/Main_Page

The dialects of MARC are numerous and in Norway alone we have three slightly different dialects of MARC: BSMARC (public libraries), BIBSYS-MARC (university libraries) and NORMARC (the official standard used by whom?). Others are better at explaining the differences between the three dialects, but a standard which allows so many interpretations and local adjustments, must at some point collapse.

If the library catalogue is to play a role on the web in the future we have to design our systems/standards in the next largest context – the web. Making the catalogue records available in another format than MARC might lead to greater use of our metadata.

MARC is short for “Machine readable cataloging”. This is the purpose of the format: to be machine readable.

Nevertheless the format has so many limitations, that it can’t be said to fulfill this purpose. Many of these limitations are there for reasons that shouldn’t have the same impact today as they had when the format was created. For example MARC data are a lot less expressive and uniform than it could be. The main reason for this is probably a several decades old need to minimize the use of diskspace, an issue which is a lot less pressing now. It isn’t easy to explain to outsiders why the XML tag that annotates the author of a book is called “<datafield tag=”100″>” instead of simply “<author>”. Also it isn’t easy to explain why library records simply don’t have a field that uniquely express something as basic as the author of a book. As the machine reads the MARC record, there is no semantic difference between the author of a book, the performer or the composer of a music album. The correct interpretation of what information the field contains depends on context.

Another problem is that a lot of the data contained in a MARC record, isn’t really machine readable at all, at least it’s not machine understandable. The extent of machine readability is limited to what is necessary for a machine to produce a human readable presentation of a record. The machine can put the data that make up a library record together in a way that makes it meaningful to a human reader, but for itself, it has very limited possibilities to interpret and make use of the data. This is especially a problem with the content of the note fields 500-599. These fields might contain important and useful information about a document; the problem is that the information is typically expressed in the form of human readable text. As a result, many possibilities for searching, sorting, presenting and enriching library data are made unavailable, even though all the necessary information might be contained in the records.

LinkedNonFictionWeb

Postet den 28. December 2010 | Skrevet av Magnus | Ingen kommentarer

LinkedNonFiction er Pode sitt prosjekt for RDFisering av bibliografiske poster fra det flerspråklige biblioteket. LinkedNonFictionWeb er et Web-grensesnitt for presentasjon av disse dataene, i kombinasjon med data fra andre kilder. LinkedNonFictionWeb gjør i hovedsak tre ting:

1. Presentasjon av de tre øverste nivåene i Dewey desimalklassifikasjonen, basert på data hentet fra dewey.info. Denne tjenesten gjør tilgjengelig de tre øverste nivåene i Dewey, på 11 ulike språk. Dataene kan hentes fra et SPARQL endpoint, blant annet i JSON-format som er det LinkedNonFictionWeb bruker. I første omgang viser LinkedNonFictionWeb det øverste Dewey-nivået på engelsk, og det er så mulig å klikke på et emne for å se de underliggende emnene på 2. og 3. nivå.

2. Klikker man på et emne på 3. nivå utføres det et søk i de RDFisert katalogpostene etter poster med det valgte Dewey-nummeret. De postene som tilfredsstiller søkekriteriene vises i en treffliste.

3. Klikker man på en post i trefflista vises detaljene for posten i en dialog som legger seg over den øvrige siden. Dersom LinkedNonFictionWeb finner et omslagsbilde hos Bokkilden eller Open Library vises dette sammen med de øvrige detaljene.

I tillegg til funksjonene ovenfor er det også mulig å avgrense visningen til dokumenter på et gitt språk, ved å velge språk fra en liste som inneholder språkene som er representert i de bibliografiske postene systemet baserer seg på.

Kildekoden til LinkedNonFictionWeb er tilgjengelig under en fri lisens.

Berikelse av RDF-data etter import

Postet den 23. December 2010 | Skrevet av Asgeir | Ingen kommentarer

Etter import av konverterte RDF-data for Hamsuns og Pettersons FRBRiserte forfatterskap er det gjort noe arbeid med å forbedre og berike data:

Mer brukervennlige IDer for verk

I konverteringen gjenbrukte vi de unike IDene som ble generert av FRBRiserings-verktøyet. Disse var lange, kompliserte og lite brukervennlige. Vi erstattet derfor disse med mer uttrykksfulle verks-IDer basert på tittel og opphavsperson.

Lenking til eksterne datasett

Person- og verksinstanser er relatert til ressurser i DBpedia med egenskapen owl:sameAs. Denne egenskapen uttrykker at to URIer beskriver samme ting, og at det som finnes om informasjon om en ting i ett datasett, også vil gjelde for samme ting i det andre. I de tilfellene hvor uttrykk i vårt datasett har en korresponderende digital fulltekstutgave hos Project Gutenberg, er denne sammenhengen uttrykt med frbr:embodiment.

Årstall for førsteutgivelse

Vi ønsket å presentere verksliste kronologisk etter førsteutgivelse. Dette er informasjon som ofte legges inn i MARC-felt 503. Dette er imidlertid et notefelt hvor årstallet vil ligge i løpende tekst, og det er derfor vanskelig tilgjengelig. Feltet brukes dessuten også for andre typer oppslysninger om utgavehistorikk. Denne informasjonen er derfor senere lagt til som pode:firstEdition ved help av SPARQL.

Deler av verk

Hamsuns novellesamlinger «Kratskog», «Siesta» og «Stridende Liv» er oppført med biinnførsler for de enkelte novellene i MARC-postene, men dette er ikke tilfelle for diktsamlingen «Det vilde Kor». Her la vi inn egne verksinstanser for de enkelte dikt og relaterte dem til verket som representerer samlingen. Dette omfatter også deler av dikt.

Oppfølgere

Core FRBR-vokabularet inneholder egenskaper for å uttrykke at et verk har en oppfølger, eller at det er en oppfølger av et annet verk. Dette er informasjon som er vanskelig tilgjengelig fra MARC-postene, fordi den ligger som løpende tekst i notefelt. Vi la derfor på relasjoner av typene frbr:successor og frbr:successorOf ved hjelp av SPARQL.

Filmatiseringer og tonesettinger

Opplysninger om at en film er basert på et litterært verk vil i bibliotekkatalogen ofte finnes i notefelt i katalogposter for filmen, mens det ikke finnes noe motsvarende informasjon på katalogposter for bøker, som sier at denne boka er filmatisert. Tilsvarende gjelder for musikkstykker som er tonesettinger av dikt eller andre litterære tekster. I vårt datasett har vi brukt SPARQL for å uttrykke slike relasjoner begge veier. Til dette har vi brukt relasjoner fra Core FRBR (frbr:adaptation, frbr:adaptationOf), Linked Movie database (movie:relatedBook) og eget vokabular (pode:musicalSetting, pode:musicalSettingOf).

keep looking »
  • RSS Linked data

  • RSS Semantic web

  • RSS FRBR

  • RSS Eksempler på mashups

  • RSS Tilgjengelig innhold

  • RSS Eksempler på katalogsøk (både trad og sosiale SOPAC

  • RSS Eksempler på systemer/produkter i bruk

  • RSS Fakta om/dokumentasjon av systemer/produkter

  • RSS Eksempler på biblioteksider