Project

General

Profile

Bug #2162

Indekset term.acquisitionDate i brønd 3.5

Added by Steen Larsen over 2 years ago. Updated 3 months ago.

Status:
DBC (waiting)
Priority:
Normal
Assignee:
Estimated time:
URL med eksempel:
Kategorier:
Søgning - Søgeresultat efter søg - Brønd

Description

I brønd 3.5 (FBS) kan indekset term.acquisitionDate ikke benyttes

I brønd 3.0 er indekset baseret på datoer der blev overført i marcposten (096t) men dette sker jo ikke fra FBS.

Men der bliver dog overført data fra FBS til alle holdingsitem-indekserne, så indekset burde kunne gen-etableres igen.

For ét materiale acquisitionDate normalt datoen hvor materialet er modtaget og tilgængeligt.
For ét værk (faustnummer) og det der skal bruges i brønd 3.5 er acquisitionDate den ældste dato for alle materialerne.
Der ses bort fra kasserede materialer.

Med acquisitionDate burde det være muligt at lave en søgning som denne fra ddbcms:

facet.type="lydbog (cd-mp3)" and facet.category=voksenmaterialer not dk=sk not ma=xe and facet.acSource="bibliotekskatalog" and term.acquisitionDate>="2017-01-02"

(som selvfølgelig i FBS automatisk bliver tilføjet filtreringen på holdingsitem-agency)

Sag oprettet til DBC: 50992

History

#1 Updated by Steen Larsen over 2 years ago

DBC mener det er en udviklingsopgave, der skal finansieres og prioriteres, så ønsket skal komme fra DDB (eller Kombit) så jeg kan desværre ikke gøre mere.

Lidt supplerende oplysninger til indekset er at datoen der skal benyttes allerede sendes til DBC via servicen http://holdingsitemsupdate.addi.dk/holdingsitemsupdate-1.0.1/ fra FBS

For hvert materiale bliver bl.a. bibliographicRecordId (faust), accessionDate og status sendt afsted.

acquisitionDate for et givet værk (faustnummer) er den ældste dato blandt accessionDate for de enkelte materialer.

Feltet status skal benyttes f.eks. i forbindelse med kasseret materialet (status = Decommissioned) som ikke skal medtages.
Måske skal der også tages hensyn til andre værdier af status?

accessionDate er normalt den dato hvor materialet er modtaget, men det er bestillingsdatoen der modtages fra FBS.

Det kan selvfølgelig være rigtigt fint, fordi man allerede fra den dag kan søge / reservere materialerne, men hvis accessionDate senere opdateres med en anden dato er det ikke så godt. At der måske kan ske en opdatering skyldes at dette er et krav i IMS, men her er det selvfølgelig en anden service det drejer sig om.
Status for materiale undervejs er status=OnOrder

Hvis accessionDate ændres kan acquisitionDate potentielt ændres sig og det bør helst ikke ske når datoen er nutidig. Jvf den tænkte brug af indekset med materialer.
Dog kan acquisitionDate ændre sig, hvis materiale bliver kasseret men sådan har det jo hele tiden været.

#2 Updated by Rolf Madsen over 2 years ago

  • Status changed from New to DBC (waiting)
  • Assignee set to Rolf Madsen
  • Target version set to DDB CMS - DBC drifts- og infrastrukturudvikling

#3 Updated by Rolf Madsen over 2 years ago

Sagen behandles på det næste Teknisk koordinationsmøde med DBC.

#4 Updated by Rolf Madsen about 1 year ago

  • Description updated (diff)

Der ligger en beslutning om at DBC i Opensearch udvider holdingsitems med et nyt felt:” acquisitiondate” samt et nyt felt: BranchID. Dette kræver ændringer af wsdl.

#5 Updated by Erik Bachmann 6 months ago

acquisitiondate findes desværre ikke i FBS. Data fandtes i DDElibra, men data bliver ikke gemt i FBS

#6 Updated by Steen Larsen 6 months ago

Måske strides vi om begreberne men jeg har antaget:

  • acquisitionDate for et givet værk (faustnummer) er den ældste dato blandt accessionDate for de enkelte materialer.
  • det er kun materialer i beholdning (dvs minus kasserede og bortkomne) der skal tælle med
  • accessionDate for et materiale er modtagelsesdatoen for materiale

 

Datoen kan beregnes i FBS hvis det var nødvendigt.

Datoen kan beregnes ud fra data vi allerede løbende sender til DBC, nemlig til Holdingsitem som indeholder felterne holdingsitem.accessionDate og holdingsitem.status

#7 Updated by Erik Bachmann 6 months ago

Uha - jo det har være en lang diskussion :-D

accessionDate er dynamisk og ændres for hvert nyt eksemplar, der anskaffes - og ændres muligvis også ved opdateringer.

acquisitiondate var dato for allerførste bestilling af materialet og blev gemt på titelposten. 

Er "ældste blandt de anskaffede" anvendelig? Jeg tager problemet med til en snak med Kombit og DBC d 25/4.

#8 Updated by Steen Larsen 6 months ago

Ja, vi er næsten enige så - accessionDate er på materialeniveau og acquisitiondate er på værkniveau (faustnummer)
I ddelibra blev acquisitiondate beregnet ud fra accessionDate som beskrevet ovenfor og sendt til brønden i felt 096t i marcposten.

Og ja, acquisitiondate er det bedste bud på en brugbar værdi baseret på allerede eksisterende gemte data.

#9 Updated by Erik Bachmann 5 months ago

Problemet er nu behandlet på et FBS CAB møde og det lader til at at der kan bygges et index udfra de enkelte eksemplarers tidligste bestillingesdata. Der skal så være én dato for hver post på hvert bibliotek.

Genanskaffelser vil så IKKE udløse en ny acquisionDate.

#10 Updated by Steen Larsen 5 months ago

Bliver det store løsning med udvidelser i både FBS og i Brønden eller den enklere løsning, hvor dato beregnes ud fra data som alleredes sendes fra FBS til Brønden via https://opensource.dbc.dk/services/holdings-items-update ?

#11 Updated by Erik Bachmann 5 months ago

Det bliver klart et tidsstempel beregnet fra Holdings Item Index data. Dvs. acquisitionDate for et givet værk (faustnummer) vil være den tidligste accessionDate blandt alle eksemplarer. Stemplet vil ikke kunne opdateres.

#12 Updated by Gitte Barlach 3 months ago

Er der nogen tidshorisont for hvornår løsningen kan forventes at være implementeret?

#13 Updated by Erik Bachmann 3 months ago

acquisitionDate i holdingsitems er på udviklingsplanen, men som "Ikke prioriteret" i 2019. Grundet afhængigheder i  udviklingsplanen er det næppe sandsyneligt, at projektet bliver udviklet i år.

Also available in: Atom PDF