natgillin/translations-raw huggingface dataset:
Felt 15.001 skal angive recordens længde og omfatte samtlige tegn i hvert eneste felt samt informationsseparatorerne.
Field 15.001 shall specify the length of the record including every character of every field contained in the record and the information separators.
Dette obligatoriske ASCII-felt anvendes til at identificere det håndfladeaftryksbillede, der er indeholdt i recorden.
This mandatory ASCII field shall be used to identify the palmprint image contained in the record.
Dette obligatoriske en-byte ASCII-felt angiver, hvordan informationen om håndfladeaftryksbilledet blev indsamlet.
This mandatory one-byte ASCII field shall indicate the manner by which the palmprint image information was obtained.
I dette felt indlæses den relevante kode fra tabel 9.
The appropriate code selected from table 9 shall be entered in this field.
Dette obligatoriske ASCII-felt angiver den dato, hvor håndfladeaftrykket blev taget.
This mandatory ASCII field shall contain the date that the palmprint image was captured.
CCYY angiver det år, hvor billedet blev taget; MM angiver måneden; og DD angiver datoen.
The CCYY characters shall represent the year the image was captured; the MM characters shall be the tens and unit values of the month; and the DD characters shall be the tens and units values of the day in the month.
For eksempel angiver 20000229 den 29. februar 2000.
For example, the entry 20000229 represents 29 February 2000.
Ellers angiver det den horisontale komponent af pixelaspektratioen.
Other-wise, it indicates the horizontal component of the pixel aspect ratio.
Tabel 8: Type-15-record: håndefladeaftryk med variabel opløsning
Table 8: Type-15 variable-resolution palmprint record layout
Field 9.140: Delta information (deltainformation) Dette felt består af et subfelt for hvert delta i det oprindelige billede.
IMAGE DESIGNATION CHARACTER
COMPRESSION ALGORITHM
PALMPRINT POSITION
BITS PER PIXEL N 2 3 1 1 10 PLP M 15.013
RSV
Tabel 9: Håndfladeaftrykstype
Table 9: Palm Impression Type
Hvis der indlæses et »NONE« i dette felt angiver det, at dataene i denne record ikke er komprimerede.
An entry of ‘NONE’ in this field indicates that the data contained in this record are uncompressed.
For de billeder, der skal komprimeres, indeholder feltet den foretrukne metode til at komprimere tenprint fingeraftryksbilleder.
For those images that are to be compressed, this field shall contain the preferred method for the compression of tenprint fingerprint images.
Gyldige kompressionskoder findes i tillæg 7.
Valid compression codes are defined in Appendix 7.
Hvis der i dette felt indlæses en værdi højere eller lavere end »8« repræsenterer det en gråtoneværdi med henholdsvis større eller mindre præcision.
Any entry in this field greater than or less than ‘8’ shall represent a greyscale pixel with increased or decreased precision respectively.
Tabel 10: Håndfladekoder, områder og størrelser
Table 10: Palm Codes, Areas and Sizes
Dette obligatoriske mærkede felt angiver håndfladeaftrykkets position, der matcher håndfladeaftryksbilledet.
This mandatory tagged-field shall contain the palmprint position that matches the palmprint image.
Decimalkodenummeret, der skal svare til den kendte eller mest sandsynlige håndfladeaftryksposition, tages fra tabel 10 og indlæses som et tocifret ASCII-subfelt.
The decimal code number corresponding to the known or most probable palmprint position shall be taken from table 10 and entered as a two-character ASCII subfield.
Tabel 10 angiver også de maksimale billedområder og -dimensioner for hver af de mulige håndfladeaftrykspositioner.
Table 10 also lists the maximum image areas and dimensions for each of the possible palmprint positions.
Dette fakultative felt kan anvendes til at indlæse bemærkninger eller anden ASCII-tekstinformation sammen med data vedrørende håndfladeaftryksdata.
This optional field may be used to insert comments or other ASCII text information with the palmprint image data.
Field 15.200-998: User-defined fields (UDF)
Fields 15.200-998: User-defined fields (UDF)
Dette felt indeholder alle data fra et håndfladeaftryksbillede.
This field shall contain all of the data from a captured palmprint image.
For eksempel efterfølges »15.999:« af billeddata i binær repræsentation.
For example, ‘15.999:’ is followed by image data in a binary representation.
Hvis indlæsningen i BPX Felt 15.012 er højere eller lavere end 8, vil det antal bytes, der kræves til at indeholde en pixel, være forskelligt.
If the entry in BPX Field 15.012 is greater or less than 8, the number of bytes required to contain a pixel will be different.
Hvis der anvendes kompression, skal pixeldataene komprimeres i overensstemmelse med den kompressionsteknik, der er angivet i CGA-feltet.
If compression is used, the pixel data shall be compressed in accordance with the compression technique specified in the CGA field.
Afslutning af Type-15-record: håndefladeaftryk med variabel opløsning
End of Type-15 variable-resolution palmprint image record
Af hensyn til sammenhængen skal der umiddelbart efter den sidste databyte i felt 15.999 indsættes en »FS«-separator for at adskille den fra den næste logiske record.
For the sake of consistency, immediately following the last byte of data from Field 15.999 an ‘FS’ separator shall be used to separate it from the next logical record.
Denne separator skal indlæses i længdefeltet i Type-15-recorden.
This separator must be included in the length field of the Type-15 record.
Supplerende Type-15-record: håndefladeaftryk med variabel opløsning
Additional Type-15 variable-resolution palmprint image records
Der kan indlæses yderligere Type-15-records i denne fil.
Additional Type-15 records may be included in the file.
For hvert supplerende håndfladeaftryksbillede kræves der en komplet Type-15 logisk record sammen med en »FS«-separator.
For each additional palmprint image, a complete Type-15 logical record together with the ‘FS’ separator is required.
Tabel 11: Det maksimale antal personer, der accepteres med henblik på kontrol pr. overførsel
Table 11: Maximum numbers of candidates accepted for verification per transmission
Søgningstyper:
Search types:
Tillæg 1 ASCII Separatorkoder
Appendix 1 ASCII Separator Codes
Tillæg 2 Beregning af alfanumeriske kontroltegn
Appendix 2 Calculation of Alpha-Numeric Check Character
For TCN og TCR (Felt 1.09 og 1.10):
For TCN and TCR (Fields 1.09 and 1.10):
Det tal, der svarer til kontroltegnet, findes ved at anvende følgende formel:
The number corresponding to the check character is generated using the following formula:
(YY * 108 + SSSSSSSS) Modulo 23
(YY * 108 + SSSSSSSS) Modulo 23
Hvor YY og SSSSSSSS er numeriske værdier for henholdsvis de sidste to cifre for året og serienummeret.
Where YY and SSSSSSSS are the numerical values of the last two digits of the year and the serial number respectively.
Kontroltegnet findes herefter i opslagstabellen nedenfor.
The check character is then generated from the look-up table given below.
For CRO (Felt 2.010)
For CRO (Field 2.010)
Hvor YY og NNNNNN er numeriske værdier for henholdsvis de to sidste cifre for året og serienummeret.
Where YY and NNNNNN are the numerical values of the last two digits of the year and the serial number respectively.
Opslagstabel for kontroltegn
Check Character Look-up Table
Tillæg 3 Tegnkoder
Appendix 3 Character Codes
7-bit ANSI-kode for informationsudveksling
7-bit ANSI code for information interchange
I kolonnen »Condition«:
Under the Condition Column:
O = Optional (fakultativ); M = Mandatory (obligatorisk); C = Conditional (betinget), hvis transaktionen er et svar til det anmodende agentur.
O = Optional; M = Mandatory; C = Conditional if transaction is a response to the origin agency
Type-2-record (obligatorisk)
Type 2 Record (mandatory)
O = Optional (fakultativ); M = Mandatory (obligatorisk; C = Conditional (betinget) (afhængigt af, om dataene er tilgængelige.
O = Optional; M = Mandatory; C = Conditional if data is available
hvis transmissionen af dataene er i overensstemmelse med national lovgivning (der ikke er omfattet af afgørelse 2008/615/RIA).
if the transmission of the data is in accordance with national law (not covered by the Council Decision 2008/615/JHA)
I kolonnen »Condition«: O = Optional (fakultativ), M = Mandatory (obligatorisk), C = Conditional (betinget).
Under the Condition Column: O = Optional, M = Mandatory, C = Conditional
I kolonnen Character Type (tegntype): A = Alpha, N = Numeric, B = Binary.
Under the Character Type Column: A = Alpha, N = Numeric, B = Binary
Domain Name AN 1.013: INT-IUS4.22GS GMT M 1.014 Greenwich Mean Time AN 1.014:20050101125959Z
Table A.6.1: CPS- and PMS-Transaction
Tabel A.6.2: SRE-transaktion
Table A.6.2: SRE-Transaction
Tabel A.6.3: ERR-transaktion
Table A.6.3: ERR-Transaction
Tabel A.6.4: MPS- og MMS-transaktion
Table A.6.4: MPS- and MMS-Transaction
1* tilladte tegn er: [»0..9«, »A..Z«, »a..z«, »_«,».«, »«, »-«, »,«]
1* allowed characters are [‘0..9’, ‘A..Z’, ‘a..z’, ‘_’, ‘.’, ‘’, ‘-’,‘,’]
Tillæg 7 Gråtonekompressionskoder
Appendix 7 Greyscale Compression Codes
Kompressionskoder
Compression Codes
Algorithm to be used for the compression of grayscale images in Type-4, Type-7 and Type-13 to Type-15 Records.
Algorithm to be used for the compression of greyscale images in Type-4, Type-7 and Type-13 to Type-15 records.
To be used for lossy and losslessly compression of grayscale images in Type-13 to Type-15 Records.
To be used for lossy and losslessly compression of greyscale images in Type-13 to Type-15 records.
Tillæg 8 Mailspecifikation
Appendix 8 Mailspecification
For at forbedre den interne workflow skal »mailsubject« for en PRUEM-transaktion udfyldes med landekoden (CC) for den medlemsstat, der sender mailen og transaktionstypen (TOT Felt 1004).
To improve the internal workflow the mailsubject of a PRUEM transaction has to be filled with the country code (CC) of the Member State that send the message and the Type of Transaction (TOT Field 1.004).
Eksempel: »DE/CPS«
Example: ‘DE/CPS’
Mailens tekstfelt kan være tomt.
The mailbody can be empty.
Definitionerne af henholdsvis de obligatoriske og de fakultative dataelementer, jf. artikel 16, stk. 4, er som følger:
The definitions of mandatory data elements and optional data elements set out in Article 16(4) are as follows:
Obligatoriske (Mandatory (M)):
Mandatory (M):
Dataelementet skal meddeles, når oplysningerne er tilgængelig i en medlemsstats nationale register.
The data element has to be communicated when the information is available in a Member State's national register.
Der er altså en forpligtelse til at udveksle oplysningerne, hvis de er tilgængelige.
Therefore there is an obligation to exchange the information when available.
Fakultative (Optional (O)):
Optional (O):
Dataelementet kan meddeles, når oplysningerne er tilgængelige i en medlemsstats nationale register.
The data element may be communicated when the information is available in a Member State's national register.
Der er altså ingen forpligtelse til at udveksle oplysningerne, selv om de er tilgængelige.
Therefore there is no obligation to exchange the information even when the information is available.
For hvert dataelement markeres det med »Y«, hvis elementet udtrykkelig er udpeget som betydningsfuldt i henhold til afgørelse 2008/615/RIA.
An indication (Y) is given for each element in the data set where the element is specifically identified as important in relation with the Decision 2008/615/JHA.
Søgeelementer
Triggers for the search
Der findes to forskellige måder at søge de oplysninger, der er anført i det følgende afsnit.
There are two different ways to search for the information as defined in the next paragraph:
via stelnummer (VIN), referencedato og -tidspunkt (fakultativt)
by Chassis Number (VIN), Reference Date and Time (optional),
via registreringsnummer, stelnummer (VIN) (kan udelades), referencedato og -tidspunkt (fakultativt).
by License Plate Number, Chassis Number (VIN) (optional), Reference Date and Time (optional).
Ved søgning ud fra disse kriterier fås oplysninger om et enkelt og i visse tilfælde flere køretøjer.
By means of these search criteria, information related to one and sometimes more vehicles will be returned.
Hvis der kun fås oplysninger om et enkelt køretøj, gives alle oplysningerne som et samlet svar.
If information for only one vehicle has to be returned, all the items are returned in one response.
Hvis der findes mere end et køretøj, kan den anmodede stat selv bestemme, hvilke oplysninger der skal gives: alle oplysningerne eller kun oplysninger til indskrænkning af søgningen (f.eks. af hensyn til privatlivets fred eller af tekniske årsager).
If more than one vehicle is found, the requested Member State itself can determine which items will be returned; all items or only the items to refine the search (e.g. because of privacy reasons or because of performance reasons).
Afsnit 1.2.2.1 omhandler de oplysninger, der er nødvendige for at indskrænke søgningen.
The items necessary to refine the search are pictured in paragraph 1.2.2.1.
Afsnit 1.2.2.2 omhandler samtlige oplysninger.
In paragraph 1.2.2.2 the complete information set is described.
Hvis der søges via stelnummer samt referencedato og -tidspunkt, kan søgningen omfatte en eller alle de deltagende medlemsstater.
When the search is done by Chassis Number, Reference Date and Time, the search can be done in one or all of the participating Member States.
Hvis der søges via registreringsnummer samt referencedato og -tidspunkt, skal søgningen omfatte en bestemt medlemsstat.
When the search is done by License Number, Reference Data and Time, the search has to be done in one specific Member State.
Normalt søges der med gældende dato og tidspunkt, men det er muligt at foretage søgninger med referencedatoer og -tidspunkter i fortiden.
Normally the actual Date and Time is used to make a search, but it is possible to conduct a search with a Reference Date and Time in the past.
Hvis der søges med en referencedato og et referencetidspunkt i fortiden, og der ikke foreligger historiske oplysninger i den pågældende medlemsstats register, fordi sådanne oplysninger slet ikke registreres, kan de gældende oplysninger fås med angivelse af, at det drejer sig om gældende oplysninger.
When a search is made with a Reference Date and Time in the past and historical information is not available in the register of the specific Member State because no such information is registered at all, the actual information can be returned with an indication that the information is actual information.
Data
Data set
Oplysninger, der er nødvendige for at indskrænke søgningen
Items to be returned necessary for the refinement of the search
Komplette datasæt
Complete data set
Legal entity
Gender
An identifier that uniquely identifies the person or the company.
individual, association, company, firm, etc.
Y First name M (C.2.2) Y Address M (C.2.3) Y Gender M male, female Y Date of birth M Y Legal entity M individual, association, company, firm etc. Y
e.g. Ford, Opel, Renault, etc.
Ford, Opel, Renault etc.
e.g. Focus, Astra, Megane.
Focus, Astra, Megane
Date of first registration of the vehicle somewhere in the world.
date of first registration of the vehicle somewhere in the world
Date of the registration to which the specific certificate of the vehicle refers.
Capacity
Regular, transito, etc.
regular, transito etc.
The first unique document ID as printed on the vehicle document.
Eucaris-softwareprogrammet sørger for sikker kommunikation med de øvrige medlemsstater og kommunikerer til medlemsstaternes back-end legacy-systemer via XML.
The Eucaris software application handles secure communication to the other Member States and communicates to the back-end legacy systems of Member States using XML.
Medlemsstaterne udveksler meddelelser ved at sende dem direkte til modtageren.
Member States exchange messages by directly sending them to the recipient.
Den enkelte medlemsstats datacenter er forbundet med EU’s Testa-net.
The data centre of a Member State is connected to the TESTA network of EU.
XML-meddelelser, der sendes over nettet, er krypteret.
The XML-messages sent over the network are encrypted.
Teknikken til kryptering af disse meddelelser er SSL.
The technique to encrypt these messages is SSL.
Klienterne identificeres ved hjælp af et bruger-id/en adgangskode eller et brugercertifikat.
The clients will be identified by means of user-id/password or a client certificate.
Forbindelsen til en bruger kan være krypteret, men dette har den enkelte medlemsstat ansvaret for.
This alternative uses XML-signature to sign all messages sent so the server and can authenticate the sender of the message by checking the signature.
Sikkerhedsfeatures i forbindelse med udveksling af meddelelser Sikkerhedssystemet er udformet som en kombination af HTTPS og XML-signatur.
1-sided SSL (only a server certificate) is used to protect the confidentiality and integrity of the message in transit and provides protection against deletion/replay and insertion attacks.
Dette alternativ benytter en XML-signatur til at underskrive alle meddelelser, der sendes til serveren, og kan autentificere afsenderen ved kontrol af signaturen.
Instead of bespoke software development to implement 2-sided SSL, XML-signature is implemented.
Ensidig SSL (kun servercertifikat) bruges til at beskytte meddelelsens fortrolighed og integritet under overførslen og beskytter mod sletnings-/replay- og indsætningsangreb.
Using XML-signature is closer to the web services roadmap than 2-sided SSL and therefore more strategic.
I stedet for skræddersyet software-udvikling til implementering af tosidet SSL, implementeres en XML-signatur. Brug af XML-signatur svarer bedre til køreplanen for webtjenester end tosidet SSL og er derfor mere strategisk.
The XML-signature can be implemented in several ways but the chosen approach is to use XML Signature as part of the Web Services Security (WSS).
XML-signaturen kan implementeres på flere måder, men den valgte tilgang er at anvende XML-signaturen som del af Web Services Security (WSS).
WSS specifies how to use XML-signature.
WSS specificerer, hvordan XML-signaturen skal anvendes. Da WSS bygger på SOAP-standarden, er det logisk så vidt muligt at overholde denne standard.
Since WSS builds upon the SOAP standard, it is logical to adhere to the SOAP standard as much as possible.
Brugerautentificering
Authentication of users
Brugerne af Eucaris-webprogrammet autentificerer sig ved hjælp af et brugernavn og en adgangskode.
The users of the Eucaris web application authenticate themselves using a username and password.
Da der anvendes standard-Windows-autentificering, kan medlemsstaterne om nødvendigt etablere et højere niveau af brugerautentificering ved at anvende brugercertifikater.
Since standard Windows authentication is used, Member States can enhance the level of authentication of users if needed by using client certificates.
Brugerroller
User roles
Eucaris-softwareprogrammet giver mulighed for forskellige brugerroller.
The Eucaris software application supports different user roles.
Hver gruppe af tjenester kræver en speciel autorisation.
Each cluster of services has its own authorisation.
F.eks. kan brugere, der (udelukkende) anvender Eucaristraktatfunktionen, ikke anvende Prümfunktionen.
E.g. (exclusive) users of the ‘“Treaty of Eucaris” — functionality’ may not use the ‘“Prüm” — functionality’.
Administratortjenester er adskilt fra de almindelige slutbrugerroller.
Administrator services are separated from the regular end-user roles.
Logføring og sporing af udveksling af meddelelser
Logging and tracing of message exchange
Eucaris-softwareprogrammet gør det nemt at logføre alle typer meddelelser.
Logging of all message types is facilitated by the Eucaris software application.
En administratorfunktion giver den nationale administrator mulighed for at afgøre, hvilke meddelelser der skal logføres: anmodninger fra slutbrugere, indkommende anmodninger fra andre medlemsstater, oplysninger, der er meddelt fra de nationale registre osv.
An administrator function allows the national administrator to determine which messages are logged: requests from end-users, incoming requests from other Member States, provided information from the national registers, etc.
Programmet kan konfigureres til at anvende enten en intern database til denne logføring eller en ekstern (Oracle) database.
The application can be configured to use an internal database for this logging, or an external (Oracle) database.
Beslutningen om, hvilke meddelelser der skal logføres, afhænger naturligvis af logfaciliteterne andre steder i legacysystemerne og de dermed forbundne brugerprogrammer.
The decision on what messages have to be logged clearly depends on logging facilities elsewhere in the legacy systems and connected client applications.
Den enkelte meddelelses teksthoved indeholder oplysninger om den anmodende medlemsstat, den anmodende organisation i den pågældende medlemsstat og den berørte bruger.
The header of each message contains information on the requesting Member State, the requesting organisation within that Member State and the user involved.
Årsagen til anmodningen er også anført.
Also the reason of the request is indicated.
Ved at sammenholde logføringen i de medlemsstater, der henholdsvis anmoder og besvarer anmodningen, er det muligt fuldt ud at spore alle udvekslinger af meddelelser (f.eks. efter anmodning fra en berørt borger).
By means of the combined logging in the requesting and responding Member State complete tracing of any message exchange is possible (e.g. on request of a citizen involved).
Logføringen konfigureres ved hjælp af Eucaris web client (menu Administration, Logging configuration).
Logging is configured through the Eucaris web client (menu Administration, Logging configuration).
Logføringsfunktionen udføres af det centrale system (Core System).
The logging functionality is performed by the Core System.
Når logføring er aktiveret, lagres hele meddelelsen (teksthovedet og selve teksten) i en enkelt logpost.
When logging is enabled, the complete message (header and body) is stored in one logging record.
Logføringsniveauet kan indstilles i forhold til de definerede tjenester og de meddelelsestyper, der går gennem det centrale system.
Per defined service, and per message type that passes along the Core System, the logging level can be set.
Logføringsniveauer
Logging Levels
Følgende logføringsniveauer er mulige:
The following logging levels are possible:
Privat — meddelelsen logføres: Logføringen er IKKE tilgængelig for udtræk fra logføringstjenesten, men er kun tilgængelig på nationalt niveau med henblik på audit og problemløsning.
Private — Message is logged: The logging is NOT available to the extract logging service but is available on a national level only, for audits and problem solving.
Intet — meddelelsen logføres slet ikke.
None — Message is not logged at all.
Meddelelsestyper
Message Types
Udvekslingen af oplysninger mellem medlemsstaterne omfatter flere forskellige meddelelser; i nedenstående skema findes en skematisk fremstilling af disse.
Information exchange between Member States consists of several messages, of which a schematic representation is given in the figure below.
De mulige meddelelsestyper (i skemaet vist for Eucaris-centralsystemet i medlemsstat X) er som følger:
The possible message types (in the figure shown for the Eucaris Core System of Member State X) are the following:
Følgende udvekslinger af oplysninger vises i diagrammet:
The following information exchanges are shown in the figure:
Anmodning om oplysninger fra medlemsstat X til medlemsstat Y — blå pile.
Information request from Member State X to Member State Y — blue arrows.
Denne anmodning og besvarelse omfatter henholdsvis meddelelsestype 1, 2, 7 og 6.
This request and response consists of message types 1, 2, 7 and 6, respectively,
Anmodning om oplysninger fra medlemsstat Z til medlemsstat X — røde pile.
Information request from Member State Z to Member State X — red arrows.
Denne anmodning og besvarelse omfatter henholdsvis meddelelsestype 3, 4, 9 og 8.
This request and response consists of message types 3, 4, 9 and 8, respectively,