Notater fra møtene i referansegruppen januar 2016

Like dokumenter
Krav til pilot Magasinmodul. MUSIT Ny IT-arkitektur, planleggingsfasen

Brukerveiledning for MUSITbasen

Brukerveiledning for MUSITbasen

Krav til Lånemodul. MUSIT Ny IT-arkitektur

Statusrapport. MUSIT Ny IT-arkitektur Pilot. NØKKELINFORMASJON Rapporteringstidspunkt 17. januar 2017 Rapporteringsperiode Desember 2016

Underlag til møte i referansegruppen

Statusrapport. MUSIT Ny IT-arkitektur Pilot. NØKKELINFORMASJON Rapporteringstidspunkt 3. februar 2017 Rapporteringsperiode Januar 2017

Sak M 8/13. Forslag til rapport for 2012 og planer for 2013 for Tromsø Museum - Universitetsmuseets virksomhet TROMSØ MUSEUM - UNIVERSITETSMUSEET

Integrasjon mot Active Directory i EK 2.37

MUSIT koordineringsgruppe / faggruppe gjenstandsbase

Statusrapport. MUSIT Ny IT-arkitektur Pilot. NØKKELINFORMASJON Rapporteringstidspunkt 06. desember 2016 Rapporteringsperiode November 2016

MUSIT; Felles Koordineringsgruppemøte 2018

Universitetet i Oslo. MUSIT - Universitetsmuseenes IT-organisasjon

Seksjon for samlingsforvaltning. Det relevante museum, oktober 2015 Ann Siri H. Garberg, leder

FSAT. Notat: Campus-funksjonalitet FS

Gjenbruk av rester. Plukk-kontroll: MKB- Brukerveiledninger

I databasen ligger det over 100 tabeller. De henger sammen dels via synlige koder, dels via usynlige interne ID-er. De ser man normalt bare når det

Nasjonal Database (ND) for klassifikasjonssystem for helsebygg

Kulturhistorisk museums magasin på Økern

Riksrevisjonens undersøkelse av bevaringen og sikringen av samlingene ved statlige museer. Dokument nr. 3:10 ( )

Nyheter i Mikromarc. Ny og forbedret funksjonalitet. Innkjøp. Mikromarc november Produkt Versjon Slippdato

Statusrapport. MUSIT Ny IT-arkitektur Pilot. NØKKELINFORMASJON Rapporteringstidspunkt 07. november 2016 Rapporteringsperiode Oktober 2016

Preventiv konservering. Before the unthinkable happens again

Statusrapport. MUSIT Ny IT-arkitektur Pilot. NØKKELINFORMASJON Rapporteringstidspunkt 06. oktober 2016 Rapporteringsperiode September 2016

Brukerveiledning HPV vaksine

Universitetet i Oslo. Plan for avvikling av Delphi-klientene. MUSIT - Universitetsmuseenes IT-organisasjon. Denne rapporten er utarbeidet av:

Endringer fra versjon til 5.7. Primus 5.7

Innhold. 1. Botanikk låneapplikasjonsveiledning Innledning

MUSIT styringsgruppemøte 4. mai 2017

FASILITETSRAPPORT. Institusjonens navn: Utstillingens navn: Tidsrom for utstillingen: Kontaktperson: E-post adresse:

Gå til settings i gruppen ISY Beskrivelse. Velg ønsket lisens og trykk OK. Brukeren må starte Civil 3D på nytt for å aktivere lisens

klasse Tema: Samlingsforvaltning

Hvordan komme i gang med MUSITs applikasjoner

Nyhetsdokument versjon

Statusrapport. MUSIT Ny IT-arkitektur Hovedprosjekt. NØKKELINFORMASJON Rapporteringstidspunkt 6. april 2017 Rapporteringsperiode Februar-Mars 2017

Dette er et lite notat der jeg forsøker å beskrive hvordan innblandinger kan implementeres og visualiseres i MUSIT sine databaser og applikasjoner.

Hvordan lage et sammensatt buevindu med sprosser?

Releaseinfo i Winorg 3.0 FEB-2016

Mammut Bokskred. Instruks for oppdatering av mammutfil og tilhørende mammut-rutiner i CS-Web.

Versjonsbrev - versjon

4. Dynamisk skjemaer (GUI)

Siden Nif sin database er master, er det viktig at denne databasen er oppdatert og riktig.

MUSIT: Handlingsplan for kulturhistorie med ressursforbruk for 2013

Visma Enterprise. Versjon Fakturering Brukerveiledning - enkel utgave

Bevaring i samlingsforvaltning. Douwtje van der Meulen

Registrerings- og katalogiseringsplan

Referat fra MUSIT Felles Koordineringsgruppemøte tirsdag 22. november kl MUSIT/USIT rom 3212.

Digitale depot. Terje Pettersen-Dahl Seksjon for Digitalt Depot Riksarkivet. KAI-konferanse 2013 Balestrand 13. september 2013

Barman Hanssen AS 4. mai iskole. Biblioteksystemet

Lager og Logistikk. Varemottak, ordreplukk, telling med bruk av skanning...

Nytt i GK96 ved oppdatering til versjon. 2.0

Oppgaver til opplæringssamling 2017 EVA Skanning

En bedre måte å håndtere prosjekt, team, oppgaver og innhold

CS-Web Ordrebehandling (T20)

Tilstandsvurdering av museer og samlinger i Nord-Trøndelag

Innst. S. nr ( ) Innstilling til Stortinget fra kontroll- og konstitusjonskomiteen. Dokument nr. 3:10 ( )

Primus Endringer fra versjon til Primus 5.6.4

Vann-Nett og Vannmiljøsystemet

TDT4102 Prosedyre og Objektorientert programmering Vår 2014

Kom i gang med Onix Work

Brukerveiledning TravelLog. Elektronisk Kjørebok

Askeladden Release-logg 30. august 2012

Kartlegging og tilstandsvurdering av kulturhistoriske bygninger ved norske museer

Skanning av dokumenter i Gerica

Naturhistorisk museum Universitetet i Oslo

FYLKESMANNEN I ROGALAND Kurs i spreieareal november 2015

B r u k e r h å n d b o k Sjekklistemodul ver. 16

Idrettskontor. Sluttbrukeropplæring portal

Fjernlån status og framdrift. Seminar ved BIBSYS-konferansen mars 2018 Erling Fossan

Statusrapport. MUSIT Ny IT-arkitektur Pilot. NØKKELINFORMASJON Rapporteringstidspunkt 6. juli 2016 Rapporteringsperiode Juni 2016

Instruksjon for å ta i bruk Digipost i Vivaldi. 1) Aktiver din Digipost-virksomhetskonto

Diskusjon:SportsAdmin Medlemsadministrasjon

Vedlegg 1: Terminologi i DIPS

CabinWeb BRUKERDOKUMENTASJON ET SYSTEM UTVIKLET AV DELFI DATA

SuperOffice Sales & Marketing

Skrevet av: Gunvald Strømme, BIBSYS Til: Mette Krog, UBO Kommentar: Notatet er utarbeidet primært for bruk for koordineringsgruppen ved UBO.

Nasjonal database (ND) for klassifikasjonssystem for helsebygg

VigoVoksen KARRIEREMODULEN Mai 2017

Oppsummering. Thomas Lohne Aanes Thomas Amble

Releaseinfo Winorg januar-2018

Generelle kommentarer

Brukerveiledning. For Naturbase redigeringsapplikasjon. Versjon

ELRAPP System for elektronisk innhenting av rapportdata fra funksjonskontraktentreprenører

CORBA Component Model (CCM)

Bevaring i magasin - ideelt eller akseptabelt?

Versjonsnytt 121 CGM Legevakt

NO Nytt skoleår - guide til brukere og admin

VEDLEGG. Vedlegg 2 til kravspesifikasjon AUTENTISERING OG TILGANGSKONTROLL

Regionale ledersamlinger 2014

Unit4 Web Dokumentarkiv Dokumentarkiv og vedlegg i Unit4 Web

Forvaltning av naturhistoriske museumssamlinger

Statusrapport. MUSIT Ny IT-arkitektur Pilot. NØKKELINFORMASJON Rapporteringstidspunkt 12. august 2016 Rapporteringsperiode Juli 2016

Samlingsforvaltning i statistikken

ONIX PERSONELL HVORFOR BRUKE ONIX PERSONELL? HVEM BRUKER ONIX PERSONELL?

Godkjent. Godkjent. Referat. Styremøte mandag 5.mai Sted: Bjørklygården, Sørkjosen klokken 11.00

1. SAMMENDRAG BAKGRUNN OG INNLEDNING Mål Organisering av arbeidet LØSNING Innhold

Regionale ledersamlinger 2014

For å bruke NILS-Mobil trenger man følgende utstyr og tilkoblinger.

Utstyrsportalen versjon 5.4. Idar Johansen / Yngve Eiring

Transkript:

Notater fra møtene i referansegruppen januar 2016 Struktur Må kunne registrere hierarki, som i dag, med minst mulig begrensninger i strukturen (kan ha gjenstand i bygg, hylle i skuff osv) Må minst ha nivåene Museum (skjult node) og Bygg, kan velge fritt under dette Referansegruppen må beslutte om det skal være helt fritt fram eller ikke. Ønske om å videreføre dagens begrensning relatert til reoler og seksjoner. Referansegruppen må beslutte om denne begrensningen skal implementeres, samt om det kan være behov for andre begrensninger. (Det har vært utilsiktet begrensning i dagens system som gjorde det umulig å opprette boks i boks, dette ønsker man ikke i nytt system) Fra møte i referansegruppen 8. januar: Museum som toppnode skal ikke være skjult Det ble besluttet at det ikke er behov for videreføring av begrensning/regler relatert til seksjon og reol (strukturen er reol-seksjon-hylle), men skal kunne registrere fritt i hierarkiet Det er behov for egne egenskaper knyttet til rom, noe som betyr at vi må vite typen. Men det skal ikke være noen tvang om bruk av rom, dvs. trenger ikke registrere noder type rom i hierarkiet dersom man ikke ønsker det. o Dette betyr at dersom man ikke registrerer noder av type rom, vil man ikke dra nytte av funksjonalitet knyttet til denne typen node (som rapportering av hvor mye som er tilfredsstillende sikret). Det ble besluttet at strukturen blir Museum Bygg, deretter er det fritt frem hvordan hierarkiet bygges opp (men det vil være en fordel å registrere rom for å få full nytte av rapporteringen) Det må være mulig å registrere eksterne steder/adresser som del av nodehierarkiet (i forbindelse med utlån, analyse osv.) Innspill om funksjonalitet: Ved tilbakeføring til magasin: ønsker valg enten tilbake til samme plassering som før, eller ny plass i magasinet. Museum omdøpes til Organisasjon, det vil si at toppnoden i hierarkiet vil være Organisasjon. Dette for å ivareta eksterne adresser steder/adresser som del av nodehierarkiet. Egenskaper Presisering: Konserveringsmodulen info. knyttet til gjenstand i samlingen Magasinmodulen info. knyttet til rom, hylle, boks (flere gjenstander i samlingen) Følgende informasjon (egenskapsdata) må kunne registreres pr. node i magasinet: Adresse (gjelder kun bygg) Notater fra møtene i referansegruppen januar 2016.docx Side 1

Navn Prevantiv konservering o Miljødata informasjon om ønsket klima/miljø for noden, viktig for oppbevaring av gjenstandene (gjelder nodetypene rom, monter, tank, fryseboks, skap, safe) Temperatur Fuktighet Inertluft (lavoksygen) Renhold o Skadedyrkontroll må kunne registrere at rom el. er inspisert, samt enten om ingenting funnet eller funn av skadedyr Identifikasjon, livssyklus, antall, kommentar, tiltak o Kontroll av beholder må kunne registrere at beholder el. er inspisert, samt eventuell observasjon/mangel/funn Beredskap NB tilhører egentlig eiendom eller teknisk avdeling, skal dette være med i magasinmodulen? o Kontroll med tanke på lekkasjer, skadeverk, brann, røyk Kvalitetsnivå (jf. Rapportering til KD, fire nivåer som sier noe om kvaliteten, rapporteringen gjelder kun for rommene i magasinet) Skal vi begrense dette kun til rom, eller skal dette være mulig å registrere på andre nodetyper? Skal kun tall på kvalitetsnivået (0-3) registreres, eller skal parametre som benyttes for å utlede kvalitetsnivået registreres? Oppbevaringsforhold (benchmarking) Areal, høyde NB informasjon om rommenes areal og høyde finnes i eiendomsavdelingens systemer Fyllingsgrad (estimat i prosent?) Type node (museum, bygg, rom, reol, seksjon jf. egenskaper spesielt for disse typene) Referansegruppen må beslutte hvilke typer som skal være mulig å registrere. Mulige typer noder i magasinet: museum, bygg, rom, etasje, seksjon, reol, hylle, skuff, beholder (boks, glass, krukke, tank), container, skap, safe, fryseboks, pall UUID (automatisk generert) Fra møte i referansegruppen 8. januar: Rapportering til KD: det er nødvendig å ha med egenskapene som brukes for å vurdere kvaliteten, ikke bare nivå på oppbevaringen. Det ble besluttet at denne informasjonen kun skal gjelde for noder av type rom. o Sjekket i etterkant av møtet (basert på informasjon mottatt fra Monika og Karsten): o Det er egentlig to rapporteringer, en til Kunnskapsdepartementet (KD), og en til Kulturdepartementet (KUD) o KUD vil vite hvor stor prosentandel av samlingen som oppbevares under forhold som er «svært gode», «tilfredsstillende», «ikke tilfredsstillende», «dårlige» o KD vil vite hvor stor prosentandel (av totalt areal) som er tilfredsstillende sikret (ja/nei). Forholdene som skal vurderes er: skallsikring, tyverisikring, brannsikring, vannskaderisiko, rutiner&beredskap o KD vil også vite hvor stor prosentandel av samlingen som er tilfredsstillende bevart. Bevaringsforhold som luftfuktighet, temperatur, lysforhold og (delvis) preventiv konservering vil være naturlig å hente fra magasinmodulen. o Dette medfører at det er behov for å kunne registrere kvalitetsnivå på to forskjellige måter for å kunne ta ut de forskjellige rapportene. Notater fra møtene i referansegruppen januar 2016.docx Side 2

o Dette bør diskuteres og endelig besluttes på neste møte. Har behov for å kunne angi lysforhold i monter osv, dette tas med som del av miljødata som kan registreres på nodene Registrering av Pestisider diskutert, men det ble besluttet at dette tilhører gjenstanden, ikke magasinet, og derfor ikke skal inn i magasinmodulen Areal og høyde er først og fremst nødvendig å kunne registrere på rom, men ser ikke noe behov for å begrense dette kun til rom. Det ble derfor besluttet at dette skal være mulig å registrere på alle typer noder. Det ble diskutert mulig behov for å kunne registrere teknisk informasjon om reoler, beholdere osv., men det ble besluttet at dette ikke tas med i denne versjonen Det ble besluttet at det skal finnes følgende typer noder i magasinet: o museum, bygg, rom, lagringsenhet der lagringsenhet er fellesbenevnelse på alt som ikke er museum, bygg eller rom. Spritkontroll ble diskutert, og det ble besluttet at det må være mulig å registrere på nodene at spritkontroll er utført. Eventuelle tiltak registreres på gjenstandene, og er derfor ikke del av magasinmodulen. På sikt kan man se for seg mulighet for varsling når neste kontroll bør utføres osv. Oppbevaringsforhold (benchmarking) ble ikke diskutert, dette må ev. diskuteres på neste møte. Benchmarking (oppbevaringsforhold) diskutert, besluttet at dette ikke er del av magasinmodul, men at dette eventuelt kan sees på som del av felles system for rutiner Rapport til KD; dagens rapport har kun eksistert siden 2011, usikkert hvor lenge den vil vare, hvilke endringer de finner på (rapporteringen har endret seg), men det vil uansett være nyttig å registrere de egenskapene som rapporteres til KD i dag. o Rapporteringen som gjelder sikring av samlinger (skallsikring, tyverisikring, brannsikring, vannskaderisiko, rutiner&beredskap) tilhører rommene, og er derfor naturlig å legge til magasinmodulen. To mulige løsninger ble diskutert: Parameterne kan kun registreres på rom Parameterne kan registreres på rom eller høyere nivå, nodene arver fra høyere nivåer dersom det er ufylt der, men kan overstyres ved manuell registrering på lavere nivå o Besluttet at parametere for sikring kun kan registreres på noder av type av rom, og at det som skal registreres er om de forskjellige sikringsparameterne er tilfredsstillende eller ikke. o Rapporteringen som gjelder bevaring av samlinger kan ikke plasseres like enkelt: Lysforhold, samt luftfuktighet&temperatur er informasjon som tilhører rommene, og vil derfor være naturlig å legge til magasinmodulen. Aktiv konservering tilhører gjenstandene, dvs skal ikke inn i magasinmodulen. Preventiv konservering tilhører delvis rommene, delvis gjenstandene. Det er derfor naturlig å ta med denne parameteren i magasinmodulen (på sikt må dette også kunne utledes fra gjenstandene) Andel av samlingen som er digitalisert og andel tilgjengelig på WEB tilhører samlingen, og skal ikke inn i magasinmodulen. (Det må på sikt bli mulig å registrere total størrelse på samlingen i det nye systemet.) o Det ble besluttet at det må være mulig å registrere om luftfuktighet&temperatur, lysforhold og preventiv konservering er tilfredsstillende eller ikke på noder av type rom. Notater fra møtene i referansegruppen januar 2016.docx Side 3

Rapport til KUD; det ble besluttet at det ikke er behov for å registrere disse kvalitetsnivåene, da man kan bruke rapporten til KD som utgangspunkt for vurdering av nivå på oppbevaringen. Det må være mulig å registrere kontroll/observasjoner for alle miljøparametrene (temperatur, luftfuktighet, inertluft, renhold, lysforhold), i tillegg til de kontrollene som allerede er diskutert. Alle kontrollene må ha mulighet for registrering av tiltak (også spritkontroll). Om dette skal være fritekst eller predefinerte valg fra liste, vil bli diskutert på neste møte. Det må være UUID på alle nivåer Det ble diskutert om det er behov for andre typer kontroller (i tillegg til skadedyrkontroll, spritkontroll, miljøkontroll, kontroll av beholder) o Besluttet at det ikke er behov for flere typer kontroller, men må kunne registrere noen flere observasjoner Det ble diskutert hvilke typer observasjoner det er behov for, samt om dette skal være fritekst eller ikke o Alle de forskjellige miljøparameterne må kunne registreres som observasjon (temperatur, fuktighet, inertluft, lysforhold, renhold) o Har behov for å kunne registrere observasjon av gass og mugg som del av miljøkontroll. o Det ble besluttet at det er fornuftig å beholde listen som den er, men legge til gass og mugg som mulige observasjoner Det ble besluttet å legge til parameter for feller som del av skadedyrkontroll Det ble diskutert om tiltak skal dette være fritekst eller predefinerte verdier o Tiltak skal være fritekst, da det ikke finnes noen oversikt over hvilke tiltak som kan være aktuelle. Kapasitet/fyllingsgrad Må kunne registrere areal og høyde pr. node NB eiendomsavdelingens systemer har denne informasjon om rommene, kan være fremtidig kandidat for integrasjon. Må kunne registrere fyllingsgrad (som estimat i prosent?) pr. node. Ikke mulig å utlede fyllingsgrad basert på volum og innhold, da gjenstandene kan ha veldig ulik størrelse og fasong. Fyllingsgraden vil derfor være et manuelt estimat. Er dette egentlig bare egenskaper ved nodene, det vil si at vi ikke trenger å ha «Kapasitet/fyllingsgrad» som egen del? Fra møte i referansegruppen 8. januar: Litt forskjellige behov, noen ønsker å kunne registrere fyllingsgrad i prosent på overordnet nivå, men bare si om det er ledig kapasitet eller ikke på lavere nivå, andre mener det vil være veldig vanskelig å vedlikeholde, og at informasjonen derfor etter hvert vil bli verdiløs. Usikkert hvordan dette skal håndteres i forbindelse med rapportering, skal eventuelle verdier på overordnet nivå overstyre de lavere nivå, eller motsatt, hvordan håndtere noder der dette ikke er registrert (betyr det at det er tomt eller at informasjonen bare mangler?) Areal og høyde vil være egenskaper som registreres på de enkelte nodene, trenger ikke egen del for dette, se Egenskaper. Notater fra møtene i referansegruppen januar 2016.docx Side 4

Det ble besluttet på møte i referansegruppen 8. januar at «Kapasitet/fyllingsgrad» utsettes til senere faser, det vil si at dette ikke vil være del av piloten. Magasin administrasjon Innspill om at det er litt for enkelt å flytte på noder i dagens system, det må derfor gis en advarsel ved flytting eller sletting av noder i hierarkiet. Det skal ikke være mulig å slette noder som inneholder gjenstander (gjenstandene må flyttes til andre noder først). Det ble diskutert behov for å kunne registrere hvem som har fysisk tilgang, men besluttet at dette ikke skal inn i magasinmodulen Det ble konkludert med at det ikke er behov for ytterligere funksjonalitet enn det som finnes i dagens magasinløsning for arkitektur og etnografi o Alle egenskapsdata må være mulig å registrere og endre (ikke bare navn) Magasinering All innplassering, flytting og uthenting skal være flyttehendelser o Trenger ikke egen funksjon for innplassering, uthenting og flytting, kun plassering o Må kunne flytte noe fra ingenting til en node (ved første gangs plassering av gjenstander eller etter at tapt gjenstand er funnet), mellom noder og fra en node til ingenting (ved avhending eller tap av gjenstander). Det ble presisert følgende: o Hendelsen er flytting o Aktiviteten er plassering Må kunne plassere enkeltgjenstander Må kunne plassere et helt søkeresultat, eller bare deler av søket Må kunne plassere og flytte en eller flere gjenstander ved hjelp av strekkoder/qr-koder Må kunne flytte enkeltgjenstander Må kunne flytte flere gjenstander Må kunne flytte internt på museet Må kunne flytte ut av museet (ved lån) Må kunne flytte inn til museet (ved tilbakeføring) Ved tilbakeføring etter lån, må bruker få valg om å plassere gjenstanden tilbake til sist registrerte lokasjon, eller nytt sted. Integrasjon til gammelt system: o Utlånsmodulen har et eget flyttesteg, og er dermed kandidat for integrasjon. For resten av hendelsene som kan føre til at lokasjonen til gjenstanden endres, må flyttingen gjøres manuelt i magasinmodulen. Må kunne registrere at gjenstand ikke lenger har noen plassering, f.eks. ved tap, bortkommen, kassering osv. Dette er del av forvaltningen av gjenstandene, og ikke magasinmodulen. Det er tilstrekkelig at man i magasinmodulen kan angi at en gjenstand ikke lenger har en plassering i magasinet, ikke hvorfor. Må kunne finne lokasjon til en eller flere gjenstander (basert på strekkode, QR-kode, Id) Må kunne finne lokasjon til et sett med gjenstander basert på forskjellige søkeparametre (type eller lignende) Notater fra møtene i referansegruppen januar 2016.docx Side 5

Må kunne se liste over alle gjenstander på en node Må kunne se antall gjenstander på en node, samt totalt antall gjenstander på underliggende noder Det må være mulig å lese strekkode/qr-kode for et sett med gjenstander, som man deretter kan velge å gjøre en felles operasjon på (f.eks. plassering i magasin). Dette vil være en generell plukkfunksjonalitet som kan brukes til mange typer hendelser. o I dagens system er det mulig å knytte mange gjenstander til en hendelse (ved å søke opp gjenstander og knytte disse til en opprettet hendelse), dette må videreføres, men i tillegg gi mulighet til å lage liste over gjenstander ved å scanne strekkode eller QR-kode. Det må være mulig å få generert liste over alle gjenstander som mangler lokasjon o Skille på gjenstander som aldri har hatt lokasjon, og gjenstander som ikke lenger har en lokasjon Søkelister og gjenstandsvinduer i gammelt system må kunne vise lokasjon til gjenstandene i nytt system (dersom bruker har innsyn i magasinmodulen) Objekter som består av flere deler og dermed kan befinne seg på flere steder, må håndteres ved at objektet splittes i flere deler i systemet, som hver får en UUID og dermed kan ha forskjellige plasseringer. Det må være mulig å registrere at et objekt er plassert sammen med et annet objekt (f.eks. der to ulike arter er plassert sammen i en konvolutt eller herbarieark). Innlån av gjenstander: For å kunne plassere gjenstander som er lånt av andre, må disse kunne registreres som objekter i systemet, uten at de inngår som del av samlingen. Dette er ikke krav til magasinmodulen, og må håndteres senere. Plassering av objekter som består av flere deler: Det må være mulig å plassere hovedobjektet, men også kunne registrere forskjellige lokasjoner for underobjektene. Statistikk og rapport Rapporterer hvert år følgende (relatert til magasin): o størrelse på rommene i magasinet o fyllingsgrad i prosent o hvor mange prosent av samlingen som er forsvarlig oppbevart Ikke diskutert eksplisitt i møtet, men indirekte, se punkt om rapportering til KD under «Egenskaper» Det må være mulig å ta ut rapport til KD, se Egenskaper. Denne skal vise hvor stor prosentandel av samlingen som er forsvarlig oppbevart (sikret og bevart). o I første omgang vil rapporten kun ta med sikringsdelen, da dette er i forhold til totalt areal i magasinet, mens bevaringen er i forhold til størrelsen på samlingen, noe vi ikke vil ha tilgjengelig i det nye systemet (som foreløpig kun vil bestå av magasinmodulen) Notater fra møtene i referansegruppen januar 2016.docx Side 6

Det kom ingen innspill om andre/flere rapporter enn de som allerede er diskutert på tidligere møter. Etikettering Ved å bruke Acrobat Pro kan brukerne selv lage de etikettene de ønsker med egenvalgt innhold og design. Dette kan brukes for å lage alle mulige typer etiketter. Det må være mulig å skrive ut etiketter (med og uten strekkoder/qr-koder) fra magasinmodulen for en eller flere gjenstander Det må være mulig å skrive ut etiketter (med og uten strekkoder/qr-koder) for alle typer noder i magasinet, for en eller flere noder Ved utskrift av flere etiketter må systemet etterstrebe å utnytte hele plassen på arkene (for å spare papir) Det er behov for å kunne skrive ut etiketter for gjenstander allerede ved aksesjon. Dette er ikke del av magasinmodulen og må sees på senere. Ønsker mulighet for å kunne skrive ut etiketter på gjenstander, hyller (noder) osv. som er endret (flyttet eller lignende) sisten sist utskrift av etiketter. Dette må diskuteres på neste møte. Karsten lager liste over hvilke endringer det skal tas hensyn til. Det må være mulig å opprette, endre og slette etikettmaler Mulighet for utskrift av etiketter basert på hva som er endret siden sist ble diskutert o I dag: brukes bare på samleglass og hyller o Det kom fram noe usikkerhet om funksjonaliteten vil være nødvendig eller ikke o Om vi i det nye systemet tar vare på tidspunkt for siste utskrift, kan dette kombineres med forskjellige søkekriterier for å lage plukklister for utskrift av etiketter o Det ble besluttet at vi venter med dette, og at eventuelt behov vurderes etter at systemet er tatt i bruk. Viktig at etiketten «Hovedetikett botanikk» videreføres i det nye systemet, da det er lagt ned mye jobb i spesifiseringen av etiketten. Generelt Det ble besluttet følgende tilgangsnivåer til magasinmodulen: o Administrasjon (strukturelle endringer) o Bruk o Lesetilgang (innsyn, men ikke endringer) Brukere som ikke har lesetilgang til magasinet skal ikke få opp plassering på lavere nivå enn Organisasjon ved søk etter gjenstander, visning av gjenstander osv. Presisering: Bør benytte begrepet «objekt» istedenfor «gjenstander», da dette er mer dekkende. På sikt må det defineres hva vi mener med et objekt (blant annet med tanke på telling av objekter i samlingen). Det ble diskutert om tilgangsstyringen skal være på museumsnivå eller romnivå. Notater fra møtene i referansegruppen januar 2016.docx Side 7

o Besluttet at tilgangen skal være på romnivå. Det ble diskutert om det er behov for lesetilgang til magasinmodulen. Konkludert med at det er fornuftig å beholde de tre nivåene. o Brukere som ikke har lesetilgang, vil kun se objektets tilhørighet, ikke plassering. Begrepsbruk: Bruke «eksisterende system» og «eksisterende database» istedenfor «gammelt system» og «gammel database» Notater fra møtene i referansegruppen januar 2016.docx Side 8