JEFFREY LICHT: Hei der. Jeg er Jeffrey Licht. Og jeg er her for å snakke med deg om Harvard Library og bygge morgendagens bibliotek i dag, tror jeg. Så bakgrunnen her, banen for denne økten er i det vesentlige at det er mye av bibliografisk data tilgjengelig i Harvard bibliotekene. Og det er en mulighet, gjennom noen av verktøyene og et prosjekt som er under utvikling, for å få tilgang til informasjonen og ta det med til steder som det Harvard Library er ikke å gjøre akkurat nå, gjøre nye ting med det, eksperiment og leke seg med det. Så poenget inntreden i dette er en API kalt Harvard Library Cloud, som er en åpen metadata-server, som jeg vil snakke om nå. Slik at bakgrunnen er at det er en masse ting i Harvard biblioteket. Vi har over 13 millioner bibliografisk poster, millioner av bilder, og tusenvis av å finne hjelpemidler som er i hovedsak dokumenter som beskriver samlinger, si hva er i dem, esker med papirer og så videre som representerer over en million enkeltdokumenter. Og det er også en rekke informasjon som biblioteket har om hvordan innholdet blir brukt som kan være av interesse for folk som kanskje har lyst til å jobbe med det. Så all informasjon Biblioteket har metadata. Så metadata er data om data. Så når vi snakker om den informasjonen som er tilgjengelig gjennom biblioteket sky som er tilgjengelig, det er ikke nødvendigvis selve dokumentene seg selv, ikke nødvendigvis den fulle tekst av bøker eller hele bilder, men som faktisk kan være tilfelle. Men det er egentlig informasjon om dataene. Så du kan tenke på katalogisering informasjon, telefonnumre, fag, hvor mange kopier av bok det er, hva er de utgavene, hva er det formater, forfatterne, og så videre. Så det er mye informasjon om informasjonen i samlingen som, i seg selv, er slags iboende nyttig. Og selv om du er gjøre grundige undersøkelser, du åpenbart ønsker å komme til den faktiske innhold i seg selv og se på dataene, metadataene er nyttig når det gjelder både analysere corpus som en helhet, som hva ting er i samlingen. Hvordan forholder de? Det hjelper du virkelig finne andre ting, som er egentlig det viktigste formålet med det. Poenget med metadata og katalog er å hjelpe deg å finne alle den informasjonen som er tilgjengelig innen samlingene. Så dette er et eksempel på metadata for en bok i Harvard Library. Så det er der. Og du kan se det er faktisk moderat kompleks. Og en del av verdien av metadata innenfor Harvard Library system er at det har vært sort av bygget opp av catalogers og settes sammen av personer som søker mye kompetanse og ferdighet og tenkte å det over tid, som har mye av verdi. Så hvis du tar en titt på denne posten for The Annotated Alice, kan du finne ut du har fått tittelen, som skrev den, forfatter, og alle de forskjellige fagene som folk har katalogisert den inn. Og du kan se det er også, i tillegg til mye god informasjon her er det noen duplisering. Det er mye av kompleksiteten som er reflekteres gjennom metadata som du har. Så man tittelen på denne boken er Alice i Eventyrland. Så dette er en annotert versjon av den boken. Men det er også kalt The Annotated Alice, Alice i Eventyr in Wonderland fordi det er noe som Martin Gardner skrev og kommentert boken. Og det er mye god informasjon om logiske oppgaver og ting innenfor Alice at du sannsynligvis ikke visste om. Så du bør gå lese det. Men du kan se det er en masse detaljer her, inkludert identifikatorer, når det ble opprettet, hvor det kom fra, i form av Harvard systemet, og så videre. Så dette er et eksempel på typen av metadata som du kan se etter en bok i Harvard Bibliotekets samling. Dette er noe helt annet. Så det er et system som heter VIA Harvard, som i utgangspunktet katalogiserer bilder og kunstgjenstander og visuelle ting hele Harvard, og legge noen metadata til dem, klassifisere dem, og, i noen tilfeller, å gi små miniatyrbilder at du kan ta en se på hvis du ønsker det. Slik at dette er et eksempel på den metadata som du har for en plate fra, formodentlig, Alice in Wonderland. Og du kan se det er mindre metadata her. Det er bare en annen type objekt. Og så det er mindre informasjon. Du har stort sett det faktum at en samtale nummer, i hovedsak som skapte den, - Vi vet ikke når det ble opprettet. --og en tittel. Et annet eksempel. Dette er en oppdagelse hjelpemiddel. Så det er en samling av Lewis Carroll papirer ved Harvard. Så dette beskriver hva er i denne samling. Så noen har gått gjennom og kikket gjennom alle boksene og katalogisert det, gitt noen bakgrunn, skrevet en oppsummering av hva som er her. Og hvis du skulle se videre på dette, dette går for sider og sider og sider, men vil fortelle deg hva bokstaver og hva datoer fra hvilke bokser eksistert hele samlingen. Men dette er noe at hvis du er på Harvard, du kan gå og faktisk fysisk se opp og, formodentlig, ta en titt på. Så dette er alt flott. Dette metadata utnytt. Det står i Harvard Library system. Det finnes verktøy på nettet hvor du kan gå og ta en titt på det, og se det, og søke i den. Og du kan skjære den og terninger det i mange forskjellige måter. Men det er egentlig bare tilgjengelig hvis du er et menneske sitte ned på din nettleser eller noe eller telefonen og navigerer gjennom det. Det er egentlig ikke tilgjengelig i noen form for bruk mote for andre systemer eller andre datamaskiner til å bruke, ikke med systemer innen Harvard Library, men systemer i verden utenfor, bare andre mennesker generelt. Så spørsmålet er, hvordan kan vi gjøre det tilgjengelig for datamaskiner slik at vi kan gjøre mer interessant ting med det enn bare surfing det selv? Så hvorfor skulle du ønske å gjøre dette? Det er mange muligheter. Det ene er at du kan bygge en helt annen måte surfing innholdet som er tilgjengelig gjennom Harvard Libraries. Jeg skal vise deg en senere kalt Stacklife, som har en helt annen ta på utkikk etter innhold. Du kan bygge en anbefaling motor. Så Harvard Library er ikke i virksomhet for å si, du liker denne boken. Deretter går du ta en titt på disse 17 andre bøker som du kan være interessert i eller disse 18 andre bilder. Men som sikkert kunne være en verdifull funksjon. Og gitt metadata, kan det være mulig å sette det sammen. Du har kanskje ulike behov i vilkårene for å søke på innhold, som kanskje tross verktøyene som er tilgjengelig som biblioteket gjør tilgjengelig, vil du kanskje for å søke på en annen måte eller optimalisere for en bestemt bruk tilfellet, som kanskje det er svært spesialiserte. Kanskje er det bare et fåtall mennesker i verden som ønsker å søke på innhold på denne måten, men det ville være flott om vi kunne la dem gjøre det. Det er mye av analytics på bare hvordan folk bruke innholdet som ville være veldig interessant å vite om, finne ut hvilke bøker som blir brukt, det ikke er det, og så videre. Og så er det mye mulighet til å integrere med andre opplysninger som er der ute på nettet. Så vi have-- For eksempel har NPR en bokan segment, hvor de intervjuer forfattere om bøker. Og så det ville være flott om du var leter opp en bok i Harvard Bibliotek, og du sier, OK, det er vært et intervju med forfatteren. La oss ta en titt på det. Eller det er en Wikipedia-side, som en autoritativ, vitenskapelig referanse om denne boken som du kan det være lurt å ta en titt på. Det er disse typer av kilder spredt over hele nettet. Og bringe dem sammen kan være en stor bruk til noen som ser på den innhold, på jakt etter noe. Men det er heller ikke den type ting du hadde ønsker biblioteket å være ansvarlig for å gå ned og jakte ned alle disse forskjellige kilder og koble dem sammen fordi de er i kontinuerlig endring. Og hva de synes er viktig mai ikke være hva du synes er viktig. Og enda mer så, i utgangspunktet er det en masse ting vi ikke har tenkt på ennå. Så hvis vi kan åpne dette opp, mer mennesker foruten et halvt dusin eller så, som ser på dette på en regelmessig basis kan tenke på ideer og massere dataene, og gjøre hva de vil med det. Så vi ønsker å gjøre dette data tilgjengelig for hele verden. Vel, det er et par komplikasjoner. Det ene er at dette metadata er i forskjellige systemer. Det er i forskjellige formater. Så det er noen normalisering som må skje, som normalisering blir fremgangs bringe ting fra forskjellige formater og kartlegge dem til et enkelt format slik at feltene vil matche opp. Det er noen restriksjoner om opphavsrett. Merkelig nok, katalogoppføring om en bok er ansvarlig for opphavsrett. Så selv om det er bare informasjon hentet fra boken, det er opphavsrettsbeskyttet. Og avhengig av hvem som faktisk opprettet som metadata, Det kan være restriksjoner for hvem kan distribuere det, ligner to-- Jeg vet ikke. Det kan eller kan ikke være lik situasjonen for de sangtekster, f.eks. Så vi vet alle hvordan det kokekar ut. Så du trenger for å komme rundt dette problemet. Og deretter en annen brikke er at det er mye data. Så hvis jeg er noen som ønsker å jobbe med dataene eller har en kul idé, håndtere 14 millioner poster på min laptop kan være problematisk og vanskelig å administrere. Så vi ønsker å redusere barrierene for folk å være i stand til å arbeide med dataene. Så den tilnærmingen som forhåpentligvis adresser alle disse bekymringene er to deler. Den ene er å bygge en plattform som tar data fra alle disse ulike kilder og forverrer det, normaliserer, beriker det, og gjør det tilgjengelig på ett sted. Og det gjør den tilgjengelig gjennom en offentlig API som folk kan ringe. Så en API er et program Programming Interface. Og det i utgangspunktet refererer til en endepunkt som et system eller teknologi kan ringe og få data tilbake i et strukturert format på en måte at den kan brukes. Så det er ikke avhengig på å gå til et nettsted og skraping data off av det, f.eks. Så dette er hjemmesiden til Biblioteket Cloud Element API, som i hovedsak sin versjon to. Så det er den andre iterasjon av prøver å gjøre alt dette data tilgjengelig for hele verden. Så det er http://api.lib.harvard.edu/v2/items. Og bare for å bryte dette ned litt, hva dette betyr er at dette er versjon to av API. Det er en versjon en, som Jeg kommer ikke til å snakke om. Men det er en versjon en. Og hvis du ringer dette API, du får elementer. Og en del av ideen om en API er et API er en kontrakt. Det er noe som er ikke kommer til å endre seg. Så for eksempel, - Og grunnen er at hvis jeg bygge noen form for system som kommer til å bruke et bibliotek sky API å vise bøker eller hjelpe folk med å finne informasjon på unike måter, hva vi ikke vil skal skje er for oss å gå endre hvordan at API fungerer, og plutselig alt bryter på brukersiden. Så en del av hvis du gjør API tilgjengelig for hele verden, er det god praksis for å sette en versjonsnummeret i den slik at folk vet hvilken versjon de arbeider med. Så hvis vi bestemmer oss for vi finne en bedre måte for å gjøre denne informasjonen tilgjengelig, vi kan endre det til kalle det versjon tre. Så alle som er fremdeles bruker versjon to, vil det fortsatt arbeid. Men versjon tre ville har alle de nye ting. Så dette er en API, men dette virkelig ser ut som en URL. Og så hva dette er en eksempel på er hva som er kalt en hvile API, som er tilgjengelig over bare en vanlig web-tilkobling. Og kan du faktisk gå til det i en nettleser. Så her har jeg nettopp åpnet opp Firefox og gått til api.lib.harvard.edu/v2/items. Og så hva jeg får her er utgangspunktet den første siden av resultater fra hele satt av elementer som vi har fått. Og det er her i XML-format. Og det har også vært prettified av Firefox. Det trenger faktisk ikke ha alle disse lite utvide og entreprenør doohickeys her. Dette er liksom en bedre versjon måte å se på det. Men hva dette forteller oss er Jeg har bedt om at alle elementene. Så det er 13289475 elementer. Og jeg ser på det første 10, som starter ved posisjon null fordi i informatikk Vi starter alltid på null. Og hva jeg har her, hvis jeg bare kollapse dette, vil du se jeg har 10 elementer. Og hvis jeg tar en titt på et element, kan jeg se at jeg har fått informasjon om det. Og dette er i det som kalles MODS skjema. Og så kommer jeg til å bytte tilbake hit for et øyeblikk. OK. Så la oss søke etter noe i spesifikk fordi det første elementet som skjer for å komme opp når du ser gjennom hele samlingen er, per definisjon, tilfeldig. Så la oss se på noen donuts. Oh. OK. Så donuts. Så fant vi det er 80 elementer i samlingen som referanse donuts. Vi ser på de første 10 av dem. Nå kan du se her måten Jeg sa jeg leter etter donuts, Jeg har nettopp lagt noe til søkestrengen av nettadressen. Så q lik donuts, som du kan se litt lettere her. Og dette betyr i utgangspunktet det er en spec for API, som definerer hva alle disse parametrene mener. Og dette betyr at vi kommer til å søke alt for donuts. Så det første elementet her vi har du kan se tittelen er Donuts, og det er en undertittel som heter An American Passion, som er, tror jeg, hensiktsmessig. Det finnes en rekke different-- Når du kommer til det punktet for å få data, det er mange forskjellige formater som du kan få det til. Og det finnes forskjellige styrker og svakheter for dem alle. Så denne, kan du se her, er denne formen veldig rik. Og det er standardisert. Så det er en bestemt tittel felt, en undertittel felt. Det er en alternativ tittel, An American Passion. Det er navnet knyttet til den. Type ressursen er tekst. Det er mye informasjon her i dette formatet. Men det er en gjeng av forskjellige formater. Så det vi var bare ser på er et format kalt MODS, som står for Metadata Object Beskrivelse Service, potensielt. Jeg er faktisk ikke helt sikker på om S. Men det er en ganske kompleks format. Det er standardformatet. Men det er den som holder rikdom av alle data at biblioteket har fordi det er svært nær til hva Biblioteket bruker internt. Det er en standard som er brukes over hele landet, over hele verden i fagbibliotek. Og det er veldig interoperable. Så hvis du har et dokument som er i MODS format, du kan gi den til noen andre som har systemer som forstår MODS, og de kan importere den. Så det er en standard. Det er veldig godt definert, svært spesifikke. Og det er det som gjør det interoperable fordi hvis noen sier, dette er den alternative tittelen på en posten, alle vet hva det betyr. På baksiden, er det svært komplisert. Så hvis du tar en titt på denne posten her, hvis jeg bare ønsker å få Tittelen på dette dokumentet, av denne boken, som sannsynligvis Donuts, En amerikansk Passion, parsing det ut er et lite involvert. Mens det er en annen format kalt Dublin Core, som er en mye enklere format. Og så du ser her, er det ingen tittel, undertittel, alternative tittelen. Det er bare tittelen, Donuts, An American Passion, og en annen tittel, amerikansk Passion. Så når du ser på hvilken form Ønsker du å få dataene ut av, mye avhenger av hvordan du kommer til å bruke den. Bruker du for interoperabilitet eller har du vil ha noe enkelt som kan være lettere å jobbe med? På baksiden, mye av detaljer blir liksom klemt ned. Du kan miste nyansene av hva et bestemt felt middel hvis du arbeider med Dublin Core, som du ikke ville få med MODS. Så de er to av formatene du kan få ut av API. Og i utgangspunktet holder vi det bak kulissene i MODS. Men vi kan gi deg den i MODS og Dublin Core og noe annet også. Det andre hensynet når du ser i data er du kan få det som enten JSON, som står for Javascript Object Notation, eller XML, som står for Extensible Markup Language. Og disse data representasjoner både har nøyaktig de samme dataene, nøyaktig de samme feltene. Men de er bare syntaktisk forskjellig. Så dette er a-- Vel, la oss bare slå. Så dette er vår spørring for donuts i XML-format. Hvis jeg bare slå dette å være JSON, Jeg kan se det ser annerledes ut. Så nå er dette det samme innholdet, men en annen struktur. Det er færre vinkelparenteser. Det er mindre ordrik. Og dette er et format som, hvis du arbeider i nettmiljøet, du er mest sannsynlig kommer å ønske å bruke fordi man av de fine tingene om JSON er den er kompatibel med Javascript. Så hvis jeg skriver web app, kan jeg trekke i JSON og bare jobbe med det direkte. Mens med XML, er det en litt mer komplisert. Så igjen, disse er både nyttig. De bare er ulike brukstilfeller hvor folk kanskje ønsker å bruke dem. OK. Så tilbake til API. Slik at vi kan søke for-- Jeg gir et eksempel på søker etter donuts. Vi kan også søke bare i en bestemt felt innenfor her. Så i stedet for å lete hele posten, Jeg kan bare søke på tittel-feltet. Og så nå er det 25 ting som har donuts i tittelen, hvorav den ene handler om å gjenopprette våtmarker i ledelse av hullet i smultring program, som sannsynligvis er ikke nødvendigvis det vi leter for når vi søker etter donuts. Du kan også, når du er arbeider med en API-- Del av å ha en API er å gi mennesker tilgang til store datasett. Og det er et par forskjellige verktøy du kan bruke til å gjøre det. Det ene er, veldig enkelt, du kan bla gjennom dataene. Så akkurat som om du gjør en spørring gjennom et webgrensesnitt, du kan se på side en, side to, side tre. Du kan gjøre det samme ting gjennom API. Du trenger bare å være eksplisitt i hvordan du gjør det. Så for eksempel, hvis jeg ser på min første spørring her, hvor jeg gjør et søk etter ting med donuts i tittelen, kan jeg si, og grense lik 20, noe som innebærer gi meg de første 20 postene, ikke de første 10, som er standard, fordi jeg ønsker å se på 20 om gangen. Eller jeg kan si, sett starte lik 20 og begrense lik 20, noe som vil gi Me Records 21 gjennom 40. Så jeg antar det å ta bort her er at vi bruker de søkestrenger å sette parametre på spørringen. Og det lar deg kontroll hva du får tilbake. Et annet verktøy som du kan bruke, - Og dette er virkelig nyttig i vilkårene for å utforske dataene. --is noe som heter face. Så begrepet face er ikke nødvendigvis vanlig. Men du har alle sett det før. Hvis du tar en titt på Amazon, for eksempel, og du gjør et søk etter donuts i bøkene, her de har fått en rekke bøker, og de er gruppert etter kategori, og du får de forskjellige kategoriene, og hvor mange bøker i hver kategori dukke opp. Så dette er i utgangspunktet en fasett. Du tar alle sine bøker, den 1800 bøker som passer donuts på Amazon. 12 av dem er i frokost kategori. 21 i bakverk og baking, og så videre og så videre. Så dette er virkelig en nyttig verktøy for å utforske innhold i biblioteket i tillegg fordi når du ser på en fasett, det gir deg en idé om hvilke fag eksisterer, som hva slags fag er mest populære i søket sett. Og det hjelper deg kjøre av og utforske. Slik at vi kan gjøre det samme. Hvis vi ønsker å bruke API og se på fasetter, legger vi til en parameter til vår venn søkestrengen. Så fasetter tilsvarer en kommaseparert liste over hva vi ønsker å fasett på. Så en av de fasetter kan være gjenstand. En annen kan være språk. Og så hvis vi kjøre denne spørringen, vi get-- Det ser ganske mye det samme her. Men vi har lagt til på slutten av listen et sett med fasetter. Så vi har en fasett kalt emne. Så dette er å fortelle oss at hvis jeg ser på min 80 resultater fra smultring spørring, 13 av dem har utsette USA. Tre har faget donuts. Tre har faget av våtmarks restaurering, som kan være vår hull i smultring. To av dem, The Simpsons, og så videre og så videre. Så dette kan være nyttig hvis du ønsker å begrense søket ditt. Det kan hjelpe deg å gjøre det. Spesielt hvis du har mer enn, si, 80 resultater. Tilsvarende har vi også bedt om for fasetter på språket. Så hvis vi ser på våre resultater, ser vi 76 av dem er på engelsk, fire i fransk, to i spansk, to, jeg tror det er udefinert eller ukjent, nederlandsk og latin. Så jeg tror det latinske smultring resultat igjen har ingenting å gjøre med bakevarer. Men det du går. Så dette er liksom viser deg hvordan du kan trekke innholdet tilbake fra API bare gjennom nettleser, som er flott. Men det er egentlig ikke hva du ville normalt være å bruke i API for det. Så ett eksempel på hvordan du faktisk kunne gjøre dette er jeg har skrevet en super lite program, som igjen gjør min donut søk og velger et par felt og viser dem i en tabell. Så dette er veldig mye samme innhold som vi bare sag med noen få felt trukket ut. Slik liste med titler, de Plasseringen av det boken handler om, språket, og så videre og så videre. Så hvordan dette faktisk skjedde, siden Jeg tror vi må se på noen kode, er-- Hva vi har her er en enkel HTML side, som viser teksten, Velkommen til biblioteket sky og deretter viser en tabell over resultatene. Og det er åpenbart ingen resultater i bordet når siden blir lastet. Men hva vi gjør er først av alt, vi legger et bibliotek kalt jQuery, som er utgangspunktet en Javascript-bibliotek, som gjør det meget lett å manipulere Java problemfritt, HTML, og lage websider, klientsiden logikk og websider. Så det vi har her er jQuery har en metode som kalles Get, som i alt vesentlig vil gå til en URL-adresse, som i dette tilfellet er dette kjent ute URL. Og vil da få innholdet fra at URL og deretter kjøre en funksjon på den. Så vi sa gå til api.lib.harvard / edu. Søk etter donuts. Gi oss 20 poster. Og deretter kjøre denne funksjonen, som Jeg har valgt, passerer det dataene. Og dataene er JSON som fikk returnert fra API. Og så skal vi si, innenfor det data er det et felt som heter element. Og hvis jeg går ta en titt tilbake på en av disse resultatene som er her, det er noe called-- Vel, det heter element. Slik at det kan være at. Og hva det gjør er det går gjennom hvert element og deretter kaller en annen funksjon på hvert element. Og at funksjonen i utgangspunktet tar verdien av elementet, som er hovedsak den enkelte posten og tillater oss å trekke ut tittelen, dekningen og språket. Så vi kaller en funksjon på hver element som vi kom tilbake fra API. Og hvis du bare ta en titt på dette stykket akkurat her, hva vi gjør er vi skaper en streng, som er egentlig litt HTML markup rundt et bord, med value.title, som er tittelen på objekt, value.coverage, som er dekningen, - Og vi gjør en sjekk her for å se hvem som er udefinert og skjule det hvis det står udefinert, fordi vi er egentlig ikke interessert i det. --og deretter språket. Og så hva vi er gjør er å legge det til bordet som er identifisert av denne strengen her. Og hvordan jQuery fungerer er hva dette sier er å se etter tabellen med ideen resultater og legge til denne teksten til det. Og dette er bordet med ideen resultater. Så hva du ender opp med er denne siden her. Og for å vise source-- Vel, er kilden faktisk ikke oppdatert når det skjedde. Så du kan se den faktiske Resultatene av tabellen her skjønt. Så det er bare et enkelt eksempel på gjør en svært grunnleggende spørring mot API og fremvisning av informasjon på annen form, og ikke gjør noe for fancy. Nå er et annet eksempel som en applikasjon skrevet av David Weinberger som en demo av dette, noe som hovedsak viser deg hvordan du kan mash opp resultatene du er komme fra biblioteket sky API med, sier Google Books. Og tenker her er at jeg kan kjøre en spørring mot Google Books, få et fulltekstsøk, få noen resultater tilbake, finne ut hvilke av disse elementene faktisk eksisterer i Hollis, biblioteksystemet, og deretter gi meg linker tilbake til disse elementene. Så hvis jeg søker etter, det var en mørk og stormfull natt, jeg få tilbake en haug med resultater fra Google, og deretter ett resultat som er A Wrinkle in Time. Og disse er linker til bøker som eksisterer innenfor Harvard Library system. Så jeg antar poenget her er ikke så mye at dette kanskje eller kanskje ikke være slik at du vil ha å søke biblioteket, men det er en helt annen måte som ikke var tilgjengelig for deg før, som om du hadde ingen måte å gjøre fulltekst søker på bøker som selv var en del av Harvard Library system. Så nå er dette en måte at du kan gjøre det. Og du kan vise dem i det formatet du ønsker. Så poenget her er, i utgangspunktet, vi åpner opp for nye måter for folk å arbeide med dataene. En annen del av bibliotek sky er at det hjelper utsette noen av de databruk at biblioteket har. Så hvis du går til biblioteket, og du er på jakt etter bøker, Du trenger ikke nødvendigvis faktisk har en idé om, for alle elementene i en bestemt emne, hva er folk i samfunnet, enten det er definert som Harvard eller land eller klassen din, hva har de fant mest nyttig? Og biblioteket har faktisk en massevis av informasjon om hva er de nyttige fordi dersom en masse av folk sjekker ut en bok, som forteller deg noe. Det må ha vært en eller annen grunn de ønsker å sjekke det ut. Mange satte den på reserve. Hvis den er på reservelisten for mye av klasser, som forteller deg noe. Hvis fakultetet medlemmer skal sjekke det ut mye og studenter ikke er det, som forteller meg noe. Vice versa, som også forteller deg noe. Så det ville være veldig interessant å sette det informasjon der ute og la folk bruker den til å hjelpe dem med å finne arbeider innenfor biblioteksystemet. Baksiden av dette er det er noen alvorlige personvernet bekymring fordi en av sentrale grunnprinsippene i biblioteket er vi ikke kommer til å fortelle folk hva andre folk leser. Og selv om du sier dette Boken ble sjekket ut fire ganger i en bestemt måned som kan benyttes å lenke tilbake til en bestemt person ved de-anonymiserer data og finne ut hvem som sjekket det ut. Så den måten at vi kan avoid-- Den måten at vi kan prøve å trekke ut noen signaler fra all informasjon uten å krenke alles personvern er egentlig vi ser på 10 års bruksdata, - Derfor er det over en lang tidsperiode. --og si, OK, la oss se hvordan mange ganger dette arbeidet ble brukt, og av hvem i denne perioden tid, og deretter i utgangspunktet gi tilbake et tall, som vi kaller en stabel score, som i utgangspunktet representerer hvor mye det er blitt brukt. Og at number-- En rekke ulike beregninger gå inn i dette nummeret. --men det er en veldig grov beregning som gir deg noen ide om hvordan samfunnet kan verdi som fungerer. Og så en annen form for selv mer fleshed ut søknad som utnytter av dette er noe kalt Stacklife, som faktisk er tilgjengelig gjennom hoved Harvard Bibliotekportalen. Så du går til library.harvard.edu. Du vil se en rekke ulike måter å søke biblioteket. Og en av dem heter Stacklife. Og dette er et program som blar innholdet av biblioteket, men er fullstendig bygget på toppen av disse API-er. Så det er ingen spesiell ting skjer bak kulissene. Det er ingen tilgang til data som du ikke har. Det er ved hjelp av APIer for å gi deg med en helt annen surfing erfaring. Så hvis jeg søker etter Alice in Wonderland i dette tilfellet, Jeg får et resultat som ser ut som dette, noe som er ganske much-- Det er veldig likt andre søk du kan gjøre, bortsett fra i dette tilfellet vi kårer de elementene ved stackscore, som gir deg noen ide om hvor populære disse elementer var innenfor fellesskapet. Og så klart, Alice in Wonderland av Walt Disney er svært populære. Men du kan også se de fire beste her er de du kanskje ikke actually-- Ting som er sterkt brukt, men du kan ikke umiddelbart få kontakt med Alice in Wonderland. Så vår gamle venn The Annotated Alice er her. Så jeg kan ta en titt på den. Og nå det jeg leter på er egentlig et sett of-- Jeg kan ha The Annotated Alice akkurat her. Jeg har informasjon om det. Og jeg har også en stackscore av, i dette tilfelle 26. Og dette forteller meg liksom omtrent hvordan vi kom til denne stackscore, lignende som sjekket det ut, som hvordan mange ganger det ble sjekket ut, som fakultetet eller grads, hvordan mange kopier biblioteket har, og så videre og så videre. Og du kan også, interessant nok her, bla gjennom stabler nesten. Så dataene her, denne viser du liksom av en virtuell representasjon av hva sokkelen makt se ut som om du skulle ta alle bibliotekets beholdning og sette dem sammen på en uendelig sokkel. Og det fine er at vi can-- Først av alt, metadata om disse bøkene ofte forteller deg når den ble publisert. Den forteller deg hvor mange sider det har. Det kan fortelle deg dimensjonene. Så du kan se som gjenspeiles her når det gjelder størrelsen på bøkene. Og så kan vi bruke stable score for å markere bøkene som har høyere stack score. Så hvis det er mørkere, betyr det at antagelig er det brukt oftere. Så i dette tilfellet, er jeg kommer til å gjette at dette er versjonen av Alice in Wonderland som er svært vanlig, og de fleste nås, biblioteket har flest eksemplarer av. Så hvis du leter for Alice in Wonderland, dette kan være et godt sted å begynne. Og så her kan du også koble ut til, sier Amazon å kjøpe boken, og så videre og så videre. Poenget her, igjen, er ikke så mye at denne er den beste måten å bla i biblioteket eller det riktige verktøyet for enhver anledning. Men det er en annen måte å gjøre det. Og ved å gjøre data tilgjengelig gjennom et API, som er laget av meget enkle byggestenene, som lar deg søke i innholdet, du kan bygge noe som dette som kan være used verdifull for noen mennesker. Så det er liksom så mye som jeg ønsker å si egentlig om hva API er og hva det utsetter, det er en hel haug med ting bak kulissene, som Jeg kommer bare til å røre på kort bare fordi det liksom kommer på dette fra en helt annen vinkel gjelder hvordan gjør noe som dette få satt på plass? Så en API er et standard grensesnitt til alt dette innholdet. Men for å få det der, første vi måtte gjøre ble trekke sammen informasjon av bøker og bilder og finne hjelpemidler, samlingen dokument fra ulike Harvard-systemer. Aleph, VIA, og OASIS er navnene på de systemer. Og de i hovedsak går inn i en rørledningen, en behandling rørledning. Så først av alt, vi får eksport filer fra alle disse systemer. Vi dele dem opp i enkeltelementer. Så vi har en fil, som er en gigabyte, som har en million poster i den. Så vi dele den opp i enkeltelementer. Så, for hvert element, vi konvertere den i MODS, fordi noen av disse er problemfritt MODS, noen av dem er det ikke. Så vi får dem alle til være i samme format. Så er det ulike berikelse trinn, hvor vi legge til mer informasjon til data enn det som var tilgjengelig i biblioteket. Så vi må legge til, først av alt vi har det biblioteker holder det. Vi går gjennom et trinn av beregne stackscore. Vi går gjennom et nytt skritt av legge til flere metadata i form av hva samlinger folk kanskje har lagt dette-- Mennesker skaper samlinger av elementer. Hva samlinger hører det til? Hvordan har folk merket dette innholdet i det siste? Så du filtrere ut, og du begrense postene fordi, som jeg nevnte, det er noen poster som, på grunn av opphavsrettslige grunner, kan vi ikke vise. Og da vi laster dem inn i noe som kalles Solr, som ikke er en stavefeil, men er navnet på et stykke programvare som gjør søk indeksering, som driver alle søke bak API. Og så blir det tilgjengelig for API, og folk kan bruke den. Så dette er som en ganske grei prosess. En av de interessante ting om det er at vi har å gjøre med 13 millioner plater og vi kommer til å være håndtere eller mer. Og vi ønsker å være i stand til å håndtere disse i en relativt rask måte. Det tar lang tid å behandle 13 millioner plater. Så hvordan denne rørledningen er satt opp er at du can-- Jeg antar nytte av rørledningen, problemet at vi er prøver å løse her, er at alle transformasjoner, alle disse trinnene i denne rørledning kan skilles. Det er ingen avhengighet. Hvis du behandler en registrering av en bok, det er ingen avhengighet i at mellom en annen bok. Så det vi kan gjøre er utgangspunktet, ved hvert trinn i rørledningen, vi sette det inn i en kø i skyen. Jeg var tilfeldigvis på Amazon Web Services. Så det er en liste over, si, 10.000 elementer som trenger å være normalisert og konvertert til MODS format. Og vi spinner opp så mange servere som vi ønsker, kanskje 10 servere. Og hver av disse serverne bare sitter der, ser i denne køen, ser at det er en som trenger å bearbeides, trekker den av køen, behandler den, og pinner den på den neste køen. Og så hva som gjør oss å gjøre er å søke, i hovedsak, så mye maskinvare som vi ønsker å dette Problemet for en meget kort periode å behandle dataene så raskt som mulig, hvilket er noe som bare nå i verden av cloud computing Vi kan bestemmelsen servere hovedsak umiddelbart, er det nyttig. Så vi ikke trenger å ha en giganten serveren sitter rundt hele tiden for å gjøre behandlingen som kan skje bare en gang i uken. Så det er stort sett det. Det finnes dokumentasjon tilgjengelig for bibliotek Cloud Element API på denne nettadressen, som vil være tilgjengelig senere. Og vær så snill gå ta en titt på det å se om det er noe, du har noen ideer. Leke med den. Tøyse rundt. Og forhåpentligvis kan du komme opp med noe stort. Takk.