Emner (nye spørgsmål) | Hvem | Hvad (spørgsmål) | Svar |
|---|---|---|---|
Occupations fra Escostarservicen (Sp. 8. februar) | Q: Netcompany A: STAR | Vi har nu haft held med at få hentet occupations in fra EscoStarServicen 😊 Men vi mangler en relationType i aliasser: Vi har anvendt: https://taxonomyt3.startest.dk/swagger/EscoStar-v1/swagger.json Og får eksempelvis: "aliases": [ { "aliasIdentifier": "fe6ecdca-14b8-450d-979c-c2063766ccf9", "conceptUriDa": "http://data.europa.eu/esco/occupation/c3cae318-8b15-4339-a617-1a66b9ff6609", "originConceptUriEu": "http://data.europa.eu/esco/occupation/c3cae318-8b15-4339-a617-1a66b9ff6609", "alternativeLabelEu": "dieselmotorbygger", "alternativeLabelDa": "dieselmotorbygger", "origin": 2, "escoStarStatus": 1 }, Ifølge Taxonomy.EscoStarService (Version 1, 2021-1) skulle der være en relationType efter ”origin” - den får vi ikke p.t. Er det fordi det fortsat er 2020-4 version af servicen der udstilles på T3 ? Vil det være Taxonomy.EscoStarService (Version 1, 2021-1) beskrivelsen der er den mest rigtige at rette sig efter ? Altså den der vil blive udstillet med 2021-1 ? | Rent datamæssigt hænger det således sammen:, ""origin": 2" - kommer fra før Escostaraliasrelationtype blev introduceret. Carsten/Rolf ved nok mere. Der arbejdes lige nu med Escostaraliasrelationtype i indlæsningen af data. ... der kan antage værdien 1-3. angiver at det er EU alias. Denne type er fravalgt af STAR.
Carsten/Rolf: Hvordan ser det ud i miljøet? |
Emne (Historisk) | Hvem | Hvad (Spørgsmål) | Svar |
|---|---|---|---|
976.8 (Sp. til 5. februar) | Q: Netcompany A: STAR | Jeg har tilføjet en kommentar til epic 976.8 – fordi jeg synes, det er svært at finde det sted hvor der præcist står hvilken service/metode vi skal anvende for at få hentet ESCO-STAR koderne ind og de underliggende kodelister. Det jeg efterlyser er nok en kobling mellem de epics vi skal give tilsagn til, og så den virkelighed der er for de services i har implementeret. Hvis jeg alene læser det der står i epic 976.8 synes jeg det er svært at gennemskue hvordan I har implementeret taxonomi delen. Når jeg så går ”på opdagelse” på jeres service beskrivelser på wiki, så får jeg et mere klart billede af det – men jeg vil gerne være sikker på, at jeg kigger de rigtige steder, og ikke selv får strikket en forkert historie sammen. Det jeg kort fortalt efterlyser er, hvilken epic omhandler selve indlæsningen af Occupations fra Taxonomy servicen ? | A: RMA og CO 04-02-2021 I epic vil der typisk være link til de nye serviceversioner med ESCO STAR f.eks. for 976.8 findes der link til de nye serviceversioner for: UnemploymentEnrollmentService (Version 8 [UDV], 2021-2) og JobSearch.CvService (Version 2 [UDV], 2021-2) Her er ændringerne vist i forhold til snitfladen. På de tilhørende forretningssider vil vi opdater forretningsreglerene. disse er pt. kun nævnt i epic. A: KPP 04.02.2021: Den aktuelle status for den ny version af UnemployentEnrollmentService (v8) fremgår på siden UnemploymentEnrollmentService (Version 8, 2021-1) (der afspejler den kodede snitflade). |
Indlæsning/Udtræk af taxonomy data (Sp. til 5 feb.) | Q: Eksterne A: STAR | Hvornår bliver taxonomy tilgængelig på testmiljøerne? | BIs foretager dataindlæsning på T3 (p.t planlagt til torsdag d. 11. februar), hvorefter man kan kalde servicen direkte og gemme returneringen af data til fil, for derefter at sende dette. Indeholder alle felterne I vil få ud af servicen, og kan bruges til at få et overblik over, udformning af data, Der er tale om testdata der kan ændre sig. Note: RMA og CO 04-02-2021. Data kan stadig ændre sig da STAR, BI og Deloitte arbejder med at QA nomenklaturen |
976.8 (Sp. til 5. februar) | Q: Netcompany A: STAR | 976.8 er en stor epic, der beskriver de fleste ændringer i forhold til ESCO-STAR stillingskodernes påvirkning på de services hvor koderne anvendes. Jeg synes ikke ar den særlig godt beskriver selve introduktionen af Taxonomy.EscoStarService (2021-1) - det skal man finde som et under punkt for epic. Hvorfor er dette ikke beskrevet enten i en separat epic, eller taget med i 976.8? - med korrekte på virkninger til snitflader. | Se svar nedenfor. |
976.8 (Sp. til 5. februar) | Q: Netcompany A: STAR | I epic 976.8 er der nævnt en ”Taxonomy,CodeListService.GetOccupations” kodeliste, der efter min overbevisning ikke kommer til at eksistere? Som jeg forstår det, ud fra det jeg kan tyde på wiki beskrivelsen af servicer under: Taxonomy services Så er følgende services ”i spil”:
Under Taxonomy.Codelist (Taxonomy.CodeLists ) Står beskrevet i de mere ”simple” kodelister vedrørende taxonomy - men altså ikke occupations. Så det forvirrer mig lidt, når der er så mange muligheder, og jeg har svært ved at finde det sted, hvor der står bøjet i neon, at du som a-kasse leverandør skal anvende XX servicen til at hente ESCO-STAR stillingskoder ind i det system. | A (RMA og KPP 05.02.2021): Det er Taxonomy.EscoStarService.GetOccupation og Taxonomy.EscoStarService.GetOccupations, der udstiller hhv. en konkret og alle stillingsbetegnelser. Der er i epics nu indsat link med intro bl.a. disse 2 metoder. Se eksempe i E 976.8: https://starwiki.atlassian.net/wiki/spaces/ISB/pages/1617363060/976.8+Udrulning+af+ESCO+STAR+p+Tilmelding+CV+Jeg+s+ger+job+som+raskmelding+og+automatch+inkl.+EURES#id-976.8UdrulningafESCOSTARp%C3%A5Tilmelding,CV (linket springer desværre ikke til afsnittet) |
976.10 CV-kvalifikationer (Sp. til 5. feb.) | Q: KMD A: STAR | Jeg tænker vi snart bliver indkaldt til forretningsmøde ang. 976.10 om ændringer til ”kvalifikationer”? | Epic kommer ud i tilsagnbølge 2 i 2021-2. |
976.10 CV-kvalifikationer (Sp. til 5. feb.) | Q: KMD A: STAR | Når jeg skriver ”Forretningsmøde”, så er det fordi at den epic er væsentlig anderledes en det normale mønster for opdateringer af kodelister. Det burde måske have været taget med på det seneste WS møde. Jeg tænker at Kasper måske kan bringe lidt lys på emnet på fredag. Eks. er det planen at alle kodelister skal omlægges. Frekvens, opdatere WSRM på kode eller liste niveau (Opret/ret/…)… | Har du mulighed for at uddybe hvad du har brug for bliver belyst (Kasper)? Epic kommer ud i tilsagnbølge 2 i 2021-2. |
976.10 CV-kvalifikationer (Sp. til 5. feb.) | Q: KMD A: STAR | At en kodeliste bliver opdateret via WSRM er et nyt mønster som vi alle skal generalisere en implementering af. Derfor vil det være på sin plads at vi lige gennemgår metodikken bag sådan en udstilling. Eks. Vil kodelister fremover skifte antal af Attributter… eller er ESCO blot en undtagelse? Hvilke oplysninger vil en WSRM besked om en kodeliste have? Er vi på ID niveau? Er det behov for en varsling ved ændring af /tilføjelse af forekomster i en kodeliste? Eks. hvor lang tid må det gå fra en kode tilføjes til den reelt kan benyttes… og dermed at den også skal være tilgængelig i alle systemet som kan modtage/behandle objekter med den omhandlende kodetype. | Epic kommer ud i tilsagnbølge 2 i 2021-2. |
976.10 CV-kvalifikationer (Sp. til 5. feb.) | Q: Netcompany A: STAR | Vi har kigget i denne epic, selv om den endnu ikke er sendt i tilsagn. Vi har en del spørgsmål ang. CV kvalifikationer. De er måske lidt på grænsen mellem forretning og teknik. Vi er lidt i tvivl om hvor vigtige kvalifikationer er for os, og hvad kvalifikationer er for størrelse. Har CV kvalifikationer noget at gøre med ”Søjle 3” Uddannelse(Qualifications) i ESCO ? (Den som Ditte (Netcompany) spurgte ind til i manuscript sag: 214971) | Epic kommer ud i tilsagnbølge 2 i 2021-2. Nej, ESCOs søjle 2 omhandler færdigheder og kompetencer, søjle tre Uddannelse, men ingen af disse er en del af ESCO-STAR-projektet. p.t. Søjle 2 og 3 er endnu ikke obligatorisk for medlemslandende. |
976.10 CV-kvalifikationer (Sp. til 5. feb.) | Q: Netcompany A: STAR | I Epic står der at kvalifikationer tidligere refererede til DISCOAMS (Stillingskoder?) og nu skal referere til ESCO-STAR. Men det er ikke ESCO-STAR stillingskoder vel? (Tidligere var det jo et statisk kodeliste med elementer der ikke var stillingskoder) (OccupationQualificationsTypeIdentifier ) Kvalifikationer der returneres i den nye QualificationService.GetQualifications - står som (ConceptUriDaType) – er det et stillingskode id? | Epic kommer ud i tilsagnbølge 2 i 2021-2. Eksisterende kvalifikationer flyttes over i taxonomy siloen og som noget nyt vil de ikke længere linkes op til DiscoAms, men op til de tilsvarende ESCO-STAR koder for stillingsbetegnelser. |
976.10 CV-kvalifikationer (Sp. til 5. feb.) | Q: Netcompany A: STAR | Hvorfor er kvalifikationer vigtige for os som a-kasse at kunne håndtere? | Epic kommer ud i tilsagnbølge 2 i 2021-2. Koblingen mellem en kvalifikation og en ESCO-STAR stillingsbetegnelser bruges primært af STAR ift. CV’er i relation til rådgivning af borgere om valg, men der er ikke noget i vejen for at I har adgang til data. |
976.10 CV-kvalifikationer (Sp. til 5. feb.) | Q: Netcompany A: STAR | Hvorfor kommer der en ny hændelse til kvalifikationer?
| Epic kommer ud i tilsagnbølge 2 i 2021-2. |
976.10 CV-kvalifikationer (Sp. til 5. feb.) | Q: Netcompany A: STAR | Vil WSRM kun indeholde et id (kodeliste id) og for at kunne oversætte det til noget forståeligt skal vi så indlæses alle kvalifikationer. | Epic kommer ud i tilsagnbølge 2 i 2021-2. |
976.10 CV-kvalifikationer (Sp. til 5. feb.) | Q: Netcompany A: STAR | Er der vigtige ting der skal håndteres, når kvalifikationer ændrer sig? | Epic kommer ud i tilsagnbølge 2 i 2021-2. |
976.10 CV-kvalifikationer (Sp. til 5. feb.) | Q: Netcompany A: STAR | Er kvalifikationer også dækket af CvUpdate hændelsen? | Epic kommer ud i tilsagnbølge 2 i 2021-2. |
976.15 Dashboard (Sp. til 5. februar) | Q: Netcompany A: STAR | Vi har brug for en lidt mere info om tanker/beslutninger omkring den nye service EscoStarDataService(Version 1) som nævnes i epicen. Der lægges op til, at det er en ny version af DiscoCodesService (om-navngivning i stedet for version 7?). I "Oversigt over berørte webservices" nævnes det i sidste kolonne i tabellen, at der kommer en ny service der overtager fra DiscoCodesService, men der står at der stadig mangler afklaring omkring placering, er det blevet endeligt besluttet nu? | |
976.15 Dashboard (Sp. til 5. februar) | Q: Netcompany A: STAR | Vi har ikke tidligere benyttet DiscoCodesService, så som udgangspunkt berøres vores systemer ikke af overgangen til EscoStarDataService, men vi vil evt. gerne informere vores kunder om de potentielle muligheder der kan være i servicen. | |
976.15 Dashboard (Sp. til 5. februar) | Q: Netcompany A: STAR | Hvad er relationen til Dashboard og BIDataService? | |
Taxonomy (Sp. til 5. februar) | Q: KMD A: STAR | Udpegning af ESCO instanser som kan benyttes ved indberetning af en ”stillingsbetegnelse” i andre DFDG service. Det jeg prøver at finde ud af……. er den simple formel for at udpege hvilke ”ConceptUriDa”, ud af alle dem som findes bag servicen, der kan indberettes som en stillingsbetegnelse via eks. tilmeldeservicen. Min revurderede antagelse er, at hvis både IscoGroup og IscoCode er udfyldt og status er” Aktiv”, da kan den pågældende ”ConceptUriDa” anses for at være en valid stillingsbetegnelse der kan benytte ved eks. en tilmelding. Er dette korrekt? Jeg vil gerne anbefale at strukturen til taxonomien tilføjes et simpelt flag som kan angive ovenstående tilstand. Det vil sikre at serviceaftagere bedre forstå indhold og brugen af taxonomien. | Det er et testdata-issue, hvor alle stillingsbetegnelser er markeret med status=1 lige nu. Aktive, danske stillingsbetegnelser kodes med status=1 i tabellerne, ikke-aktive stillingsbetegnelser (mange ESCO-stillingsbetegnelser fra EU konverteres til aliaser for aktive stillinger, andre fravælges) markeres som fravalgt med status=3. EscoStarStatus=1 vil udpege en aktiv stilling i den danske taksonomi, 2 vil pege på en EU-inaktiveret stilling (jeg tror ikke vi har den slags endnu), 3 en markering for en stilling, der er fravalgt i den danske taksonomi - dem vil der i øvrigt være mange af, så jeg forstår forvirringen. IscoCode skal ikke bruges til noget i min optik. En stilling vil referere til en firecifret ISCO08-gruppe, det har mest statistiske implikationer.. |
Taxonomy (Sp. til 5. februar) | Q: KMD A: STAR | For at kunne kode op til STAR 2021-2 skal vi implementere vores egen lokale kopi af ESCOSTAR med tilhørende operationer til at fremsøge og udstille relevante ”Stillingsbetegnelser” til brug for oprettelse af eks. tilmelding fra vores egen applikation. På samme måde som Jobnet skal hjælpe borgeren, ved at vise relevante/mulige stillingsbetegnelser, når borgeren tilmelder sig via Jobnet. Hvis min antagelse i første spørgsmål er korrekt, så vil vi gerne vide, om der som en del af omlægningen vil komme være services, hvor det forventes at der skal kunne indsende ESCOSTAR ”koder” som ikke lever op til ”spørgsmål 1”. Her tænker jeg specielt på ”Planmål”. | Følger af svaret ovenfor (Nikolaj). |
Flere epics (Tidligere spørgsmål) | Q: FOA A: STAR | Hvem konverterer hvad? | STAR konverterer i blandt andet DFDG, hvor det er aftager selv der skal konvertere, hvis der er lokalt data. |
Flere epics (Tidligere spørgsmål) | Q: FOA A: STAR | Er der tale om kodelister vi kan abonnere på, eller skal der ske opslag hver gang? | Der er tale om en avanceret kodeliste, hvor I vil få WSRM-besked ved ændringer. |
Flere epics (Tidligere spørgsmål) | Q: FOA A: STAR | IT ønsker en konverteringstabel, men syntes ikke, de kan læse ud af materialet om STAR stiller det til rådighed? | Der vil være en servicemetode der vil kunne benyttes: For enkelt: Taxonomy.EscoStarService (Version 1, 2021-1) For alle: |
Flere epics (Tidligere spørgsmål) | Q: FOA A: STAR | I har i noterne til jeres mail skrevet, at ”Det vil være en simpel én til én udskiftning af et DiscoAms felt til fremadrettet at være et ESCO-STAR felt.”, kan I oplyse om/hvordan det besvarer spørgsmålene? A: Du kan se eksempel på dette nedenstående for UnemploymentEnrollmentService.UnemploymentEnrollment: UnemploymentEnrollmentService (Version 8 [UDV], 2021-2) Vi mener, at kunne konstatere, at i det omfang vi ikke abonnerer på WSRM-beskeder, som er en kopi af, hvad vi selv har sendt til DFDG, så er vi nødt til selv at konvertere lokalt gemte data (f.eks. JobSearchDefinition). Kan det bekræftes? Dvs. Hvis a-kassens data vedr. jobsøgningskrav ikke matcher DFDGs datasæt om jobsøgningskrav (efter release 2021-2), fordi a-kassen kun sender data til DFDG, men ikke får dem retur herfra, og fordi DFDG har konverteret data i f.t. stillingsbetegnelser, så skal vi/a-kasserne vel også ”gøre noget” (fx konvertere data) for at have samme data som DFDG vedr. jobsøgningskrav. Da jeg læste epic sidst, var der intet acceptkriterium omkring dette. Vi skal konvertere lokale data, men det forekommer mig, at der var andre løsninger fremme: vi kunne hente jobsøgningskrav fra DFDG efter de var konverteret her. Det er også derfor, jeg synes epic 976.3 er relevant for a-kasser. | Hvorfor skulle der ikke det i 2021-2?, epic er placeret i 2021-3. Epic 976.9. |
Flere epics (Tidligere spørgsmål) | Q: FOA A: STAR | Er der andre løsninger? Vi/FOAs A-kasse er jo netop ikke aftagere af disse data. Vi opretter dem selv, sender dem til DFDG og så gør vi ikke mere (i dag). Jeg spurgte på WS-mødet, om der var en løsning i at vi abonnerede på WSRM-beskeder vedr. disse data, som jo kommer fra os selv. Det var der ikke så meget fidus til, fordi vi ikke kan sikre, at få alle data opdateret på den måde.
| Ja det er der mulighed for, hvis det er det man abonnere på det, dog skal aftagere, der registrerer data, fremadrettet benytte sig af ESCO-STAR. A: KPP 05.02.2021: Konkret er der dog ikke WSRM’er, der indeholder de indberettede krav til jobsøgning. |
Flere epics (Tidligere spørgsmål) | Q: FOA A: STAR | Vi bliver nødt til at ændre i vores afsendelse af aktiviteter, fordi vi ikke må bruge den version, som er i drift nu, og der skal ændres i hentning af aktiviteter af samme årsag - kan det undgås? | STAR bestemmer om man vil kunne indbygge nogle valideringer så KSSer ikke kan kalde den "gamle version". |
Flere epics (Tidligere spørgsmål) | Q: FOA A: STAR | Det handler om ActivityServiceVersion4. Spørgsmålet er om DFDG kunne leve med, at undlade at skifte versionsnr., fordi a-kasser kun sender kursusaktiviteter, hvor der ingen stillingsbetegnelser er. Alle a-kasser skal altså løse opgaver vedr. afsendelse af aktiviteter, som de absolut ingen glæde har af, hvis der skal skiftes version. Man kunne lade den nugældende version leve videre for a-kasser? | At forblive på version 4 og lave ændringer direkte i denne er ikke en mulighed, da der er snitflade ændringer fremadrettet. Aktiviteter er en del af 976.14 Min plan mål, inkl udkast til Min plan, VITAS m.v. Som først er sat til at blive udviklet i 2021-3. A: KPP 05.02.2021: Det er ikke en mulighed at holde v4 åben. Konkret vil FOA skulle skifte til v6 og ophøre med at bruge v3, v4 og v5, der alle bruges af FOA i dag. Bl.a. vil GetActivity fremover indholde ESCOSTAR stillingsbetegnelser mod i dag DISCOAMS. |
Flere epics (Tidligere spørgsmål) | Q: FOA A: STAR | Som Sagsbehandler eller jobkonsulent vil jeg kunne angive ESCO-STAR ved - Collection profession gøres til null – er der en erstatning? | Der ændres ikke i snitflader og regler i forhold til professionTypeCollection, det skal angives ved tilmelding, ud over at det fremadrettet skal angives som ESCO-STAR fremfor DiscoAms08, AliasIdentifier er optionelt. |
Flere epics (Tidligere spørgsmål) | Q: FOA A: STAR | 976.9 KSS og a-kasser ibrugtager i 2021-3 nye versioner af webservices med ESCO-STAR – hvad ligger der i det acceptkriterie? 976.9.2, hvor A-kasser skal indberette ESCO-STAR fremfor DiscoAms ved, krav til jobsøgning. 976.17 Vi tilslutter os bemærkningerne fra Schultz af 3. dec. 976.13, 15, 16, 18, 20 Som det fremgår af epic er nogle ikke relevant for a-kasser. | 15, 20: Ja, hvis ikke i gør brug af tidligere frivillige services. 16: : Ja, hvis ikke i gør brug af tidligere frivillige services. 18: Som det fremgår af epic er denne ikke relevant for a-kasser. |
Flere epics (Tidligere spørgsmål) | Q: FOA A: STAR | Vi synes, at I bør ”reklamere” mere for 976.3, hvor der findes nogle svar på strukturelle/tabelmæssige ændringer, som ligger til grund for flere andre epics.) | 976.3 er en intern epic. |