Page Comparison

Occupations fra Escostarservicen (Sp. 9. februar)

Q: Netcompany

A: STAR

Vi har nu 3 services der kan give os en OrganisationTypeCodeList

Den kan hentes via codelistservice v5 (SOAP), under JobSearch.CodeListService og nu også under Taxonomy.codelistService

I skriver bl.a. for JobSearch.CodeListsService (2020-4) at: ”Kodelisterne er dog gyldige på tværs af alle forretningsområder.”

Betyder det, at hvis vi henter den ene kodeliste ned i vores system, så er der ingen grund til at hente den fra de 2 andre services ?

Vi kan ikke på noget tidspunkt komme ud for, at kodeliste fra Taxonomy servicen komme til at indeholde en organisationstype, som ikke returneres med de andre services ?

Occupations fra Escostarservicen (Sp. 9. februar)

Q: Netcompany

A: STAR

Ang. Metoden GetDiscoAms08ConceptUriMapping der tager discoAms08Id som input.

( wiki beskrivelse )

Er det korrekte forstået at der ALTID vil være en oversættelse fra discoAms til EscoStar tilgængelig.

J.fr. rapporten fra Deloitte:

Image Added

Der vil altså altid blive oprettet en ESCO_STAR kode for hver DISCOAMS stillingskode (niveau 3) – også selvom der ikke er en ESCO kode der i dag matcher.

Metoden vil derfor kun kunne returnere fejl, hvis man kommer med en invalid DISCOAMS stillingskode  - og det vil så være en der ikke eksisterer, ELLER en på niveau 1 eller 2 ?

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.

1. angiver at det er et "nyt", dansk alias. I dette tilfælde er originConceptUriEu NULL.

2. angiver at det er en EU ESCO stillingsbetegnelse, originConceptUriEu indeholder den (originale) EU URI for den fravalgte stilling.

3. angiver at det er en EU ESCO stillingsbetegnelse, originConceptUriEu indeholder den (originale) EU URI for den fravalgte stilling.

Carsten/Rolf: Hvordan ser det ud i miljøet?