natgillin/translations-raw huggingface dataset:
Med henblik på evaluering af resultaterne af spørgeskemaet gennemføres der et evalueringsbesøg i den medlemsstat, der ønsker at begynde at udveksle data.
With a view to evaluating the results of the questionnaire, an evaluation visit shall take place in the Member State that wishes to start sharing data.
Vilkårene for og de nærmere bestemmelser om besøget identificeres af den relevante arbejdsgruppe og baseres på forudgående aftale mellem den pågældende medlemsstat og evalueringsgruppen.
The conditions and arrangement for this visit will be identified by the relevant Working Group and be based upon prior individual agreement between the concerned Member State and the evaluation team.
Den pågældende medlemsstat giver evalueringsgruppen mulighed for at kontrollere den elektroniske dataudveksling i den eller de datakategorier, der skal evalueres, navnlig ved at tilrettelægge et program for besøget, som tager hensyn til evalueringsgruppens ønsker.
The concerned Member State will enable the evaluation team to check the automated exchange of data in the data category or categories to be evaluated, in particular by organising a programme for the visit which takes into account the requests of the evaluation team.
Inden en måned fremlægger evalueringsgruppen en rapport om evalueringsbesøget, som den sender til den pågældende medlemsstat med henblik på bemærkninger.
Within one month, the evaluation team will produce a report on the evaluation visit and will forward it to the Member State concerned for its comments.
Gruppen vil i givet fald revidere denne rapport på baggrund af medlemsstatens bemærkninger.
If appropriate, this report will be revised by the evaluation team on the basis of the Member State's comments.
Evalueringsgruppen består af højst 3 eksperter, der udpeges af de medlemsstater, der deltager i den elektroniske dataudveksling i de datakategorier, der skal evalueres, og som har erfaringer med hensyn til den pågældende datakategori, relevant national sikkerhedsgodkendelse til at behandle disse spørgsmål og er rede til at deltage i mindst et evalueringsbesøg i en anden medlemsstat.
The evaluation team will consist of no more than three experts, designated by the Member States taking part in the automated data exchange in the data categories to be evaluated, who have experience regarding the concerned data category, have the appropriate national security clearance to deal with these matters and are willing to take part in at least one evaluation visit in another Member State.
Kommissionen vil blive indbudt til at deltage i evalueringsgruppen som observatør.
The Commission will be invited to join the evaluation team as observer.
Medlemmerne af evalueringsgruppen respekterer den fortrolige karakter af de oplysninger, de kommer i besiddelse af, når de varetager deres opgave.
The members of the evaluation team will respect the confidential nature of the information they acquire when carrying out their task.
Rådet forelægges en samlet evalueringsrapport, som opsummerer resultaterne af spørgeskemaerne, evalueringsbesøget og forsøgsfasen, med henblik på Rådets afgørelse i henhold til artikel 25, stk. 2, i afgørelse 2008/615/RIA.
An overall evaluation report, summarising the results of the questionnaires, the evaluation visit and the pilot run, will be presented to the Council for its decision pursuant to Article 25(2) of Decision 2008/615/JHA.
Statistikker og rapport
Statistics and report
Hver medlemsstat indsamlet statistikker om resultaterne af den elektroniske dataudveksling.
Each Member State will compile statistics on the results of the automated data exchange.
For at sikre, at statistikkerne er sammenlignelige, vil den relevante arbejdsgruppe i Rådet udarbejde statistikmodellen.
In order to ensure comparability, the model for statistics will be compiled by the relevant Council Working Group.
Statistikkerne sendes hvert år til generalsekretariatet, der udarbejder en sammenfattende oversigt over det forgangne år, og til Kommissionen.
These statistics will be forwarded annually to the General Secretariat, which will produce a summary overview for the elapsed year, and to the Commission.
Medlemsstaterne vil desuden regelmæssigt, men højst én gang hvert år, blive anmodet om at forelægge yderligere oplysninger om den administrative, tekniske og finansielle gennemførelse af elektronisk dataudveksling, som er nødvendig for at analysere og forbedre processen.
In addition, Member States will be requested on a regular basis not to exceed once per year to provide further information on the administrative, technical and financial implementation of automated data exchange as needed to analyse and improve the process.
Der vil på grundlag af disse oplysninger blive udarbejdet en rapport til Rådet.
On the basis of this information, a report will be produced for the Council.
Inden for en rimelig frist undersøger Rådet den her beskrevne evalueringsmekanisme og reviderer den i givet fald.
Within reasonable time, the Council will examine the evaluation mechanism described here and revise it as necessary.
Eksperterne mødes regelmæssigt i den relevante arbejdsgruppe i Rådet med henblik på at tilrettelægge og gennemføre ovennævnte evalueringsprocedurer, udveksle erfaringer og drøfte mulige forbedringer.
Within the relevant Council Working Group, experts will meet regularly to organise and implement the abovementioned evaluation procedures as well as to share experience and discuss possible improvements.
Resultaterne af disse ekspertdrøftelser vil eventuelt blive indarbejdet i den rapport, der nævnes i punkt 2.1.
Where applicable, the results of these expert discussions will be incorporated into the report referred to in 2.1.
»Fulde udpegede« betyder, at behandlingen af sjældne allelværdier er medtaget.
‘Full designated’ means the handling of rare allelle values is included.
Harmonised document abbreviation, see Council Directive 1999/37/E of, 29.4.1999.
Harmonised document abbreviation, see Council Directive 1999/37/EC of 29 April 1999.
In Luxembourg two separate vehicle registration document ID’s are used.
In Luxembourg two separate vehicle registration document ID's are used.
data
datas
Arkitekturen er baseret på en alle-til-alle kommunikationsmodel.
The architecture is based upon an any-to-any communication model.
Der findes hverken en central computerserver eller en centraliseret database, hvor dna-profilerne opbevares.
There exists neither a central computer server nor a centralised database to hold DNA profiles.
Som følge af de uafhængige faciliteter, der skal indføres for at få adgang til de indekserede databaser, der indeholder de dna-profiler, der er omfattet af afgørelse 2008/615/RIA, kan hver medlemsstat frit vælge sin hardware- og sin softwareplatform, herunder databasesystem og styresystem.
Because of the independent features to be implemented to get access to indexed databases containing DNA profiles covered by Decision 2008/615/JHA, each Member State can freely select its hardware and software platform, including database and operating systems. A prototype for the DNA Data Exchange has been developed and successfully tested over the existing common network. The version 1.0 has been deployed in the productive environment and is used for daily operations.
En prototype for udveksling af dna-oplysninger er blevet udviklet og testet med gode resultater via det eksisterende fælles netværk.
Member States may use the jointly developed product but may also develop their own products. The common product components will be maintained, customised and further developed according to changing IT, forensic and/or functional police requirements. Figure 2: Overview Application Topology
Version 1.0 er blevet installeret i det aktive miljø og benyttes til de daglige operationer.
Case 1
Medlemsstaterne kan anvende det produkt, der er udarbejdet i fællesskab, men også udvikle deres egne produkter. De fælles produktelementer vil blive vedligeholdt, tilpasset og videreudviklet i takt med it-udviklingen og udviklingen inden for retsmedicin og/eller politiets funktionelle behov.
a logical view
Index Profile National env.
National env.
a logical view National env.
Index Profile
Udvekslingen af dna-oplysninger vil fuldt ud udnytte XML-schema som attachment til SMTP e-mail-meddelelser. eXtensible Markup Language (XML) er et W3C-anbefalet multifunktionelt opmærkningssprog til udformning af formålsspecifikke opmærkningssprog, som kan beskrive mange forskellige former for data.
The DNA data exchange will fully exploit XML-schema as attachment to SMTP e-mail messages. The eXtensible Markup Language (XML) is a W3C-recommended general-purpose markup language for creating special-purpose markup languages, capable of describing many different kinds of data.
En særskilt klasse C subnetblok er indtil videre blevet tildelt til TESTA af den europæiske IP-registreringsmyndighed (RIPE).
A dedicated block of C class subnet has currently been allocated by the European IP registration authority (RIPE) to TESTA.
TESTA vil efter behov kunne få tildelt yderligere adresseblokke på et senere tidspunkt.
Further address blocks may be allocated to TESTA in the future if required.
Underdomæner
Sub Domains
Formålet med dette »grænsefladekontroldokument« er at fastsætte, hvilke krav der skal være opfyldt i forbindelse med udveksling af fingertryksoplysninger mellem medlemsstaternes automatiske fingeraftryksidentifikationssystemer (AFIS).
The purpose of the following document interface Control Document is to define the requirements for the exchange of dactyloscopic information between the Automated Fingerprint Identification Systems (AFIS) of the Member States. It is based on the Interpol-Implementation of ANSI/NIST-ITL 1-2000 (INT-I, Version 4.22b).
En fingeraftryksfil består af flere logiske records.
A dactyloscopic file consists of several logical records. There are sixteen types of record specified in the original ANSI/NIST-ITL 1-2000 standard. Appropriate ASCII separation characters are used between each record and the fields and subfields within the records. Only 6 record types are used to exchange information between the originating and the destination agency:
Modsat hvad der gælder for mærkede felter, indeholder en Type-4 record kun binære data, der er registreret som ordnede binære felter med fast længde.
In contrast to the tagged-field concept, the Type-4 record contains only binary data recorded as ordered fixed-length binary fields. The entire length of the record shall be recorded in the first four-byte binary field of each record.
Hertil kommer, at da alle felterne i denne record enten har fast eller specificeret længde, skal ingen af de fire separatortegn (»US«, »RS«, »GS«, eller »FS«) fortolkes som andet end binære data.
For the binary record, the ‘FS’ character shall not be used as a record separator or transaction terminating character. 3. Type-1 Logical Record: the File Header
I den binære record skal tegnet »FS« ikke benyttes som recordseparator eller som transaktionsafslutningstegn.
This record describes the structure of the file, the type of the file, and other important information. The character set used for Type-1 fields shall contain only the 7-bit ANSI code for information interchange.
Field 1.001: Den logiske records længde (LEN)
This field contains the total count of the number of bytes in the whole Type-1 logical record. The field begins with ‘1.001:’, followed by the total length of the record including every character of every field and the information separators.
Feltet begynder med »1001:« efterfulgt af recordens samlede længde, hvori medtages samtlige tegn i hvert eneste felt og informationsseparatorerne.
To ensure that users know which version of the ANSI/NIST standard is being used, this four byte field specifies the version number of the standard being implemented by the software or system creating the file. The first two bytes specify the major version reference number, the second two the minor revision number.
Eksempelvis anses den oprindelige 1986-standard for at være den første version, der angives som »0100«, medens den nuværende ANSI/NIST-ITL 1-2000 standard angives som »0300«.
Field 1.003: File Content (CNT) This field lists each of the records in the file by record type and the order in which the records appear in the logical file. It consists of one or more subfields, each of which in turn contains two information items describing a single logical record found in the current file. The subfields are entered in the same order in which the records are recorded and transmitted.
Subfelterne angives i den rækkefølge, som de pågældende records er registreret og sendt i.
This number is also equal to the count of the remaining subfields of field 1.003. Each of the remaining subfields is associated with one record within the file, and the sequence of subfields corresponds to the sequence of records. Each subfield contains two items of information. The first is to identify the Type of the record. The second is the record's IDC. The ‘US’ character shall be used to separate the two information items.
1 Type-1 Record
1 Type-2 Record. In case of a HIT, the following logical records will be returned:
I tilfælde af No-HIT (ingen overensstemmelse), vil følgende logiske records blive sendt tilbage:
In case of a No-HIT, the following logical records will be returned: 1 Type-1 Record,
1 Type-13 Record
The PMS TOT is summarised in Table A.6.1 (Appendix 6). MPS: Latent-to-Print Search. This transaction is used when a latent is to be searched against a Prints database. The latent minutiæ information and the image (WSQ-compressed) must be included in the file. In case of a No-HIT, the following logical records will be returned:
Field 1.008: Originating Agency Identifier (ORI)
Field 1.008: Originating Agency Identifier (ORI) This field specifies the file originator and has the same format as the DAI (Field 1.007).
Når en søgning er sendt af sted, og dette svar kommer tilbage, vil dette fakultative felt indeholde søgningsmeddelelsens transaktionskontrolnummer.
Where a request was sent out, to which this is the response, this optional field will contain the transaction control number of the request message. It therefore has the same format as TCN (Field 1.009).
Dette felt på fem byte angiver den nominelle overførselsopløsning for de billeder, der overføres.
This five-byte field specifies the nominal transmitting resolution for the images being transmitted. The resolution is expressed in pixels/mm in the same format as NSR (Field 1.011).
De registrerede vinkler åbner bagud langs forhøjningen for en forhøjningsafslutning og i retning mod fordybningens midte for en bifurcation.
Recorded angles are in the direction pointing back along the ridge for a ridge ending and toward the centre of the valley for a bifurcation. This convention is 180 degrees opposite of the angle convention described in the definitions of the Type 9 in the ANSI/NIST-ITL 1-2000.
Denne værdi skal være ikke-negativ mellem 0 og 179.
This value shall be nonnegative between 0 and 179. The fifth information item is the minutiae type.
»0« angiver minutiae af typen »OTHER«, »1« en linjeafslutning (ridge ending) og »2« en linjebifurcation.
The sixth information item represents the quality of each minutiae. This value shall range from 1 as a minimum to 100 as a maximum.
Sjette informationselement angiver kvaliteten af hver minutiae.
A value of ‘0’ indicates that no quality value is available. Each subfield shall be separated from the next with the use of the separator character.
Denne værdi går fra 1 som minimum og 100 som maksimum.
Field 9.138: Ridge count information This field consists of a series of subfields each containing three information items.
Field 9.138: Ridge count information
A ‘1’ indicates that for each centre minutiae, ridge count data was extracted to the nearest neighbouring minutiae in four quadrants, and ridge counts for each centre minutia are listed together. A ‘2’ indicates that for each centre minutiae, ridge count data was extracted to the nearest neighbouring minutiae in eight octants, and ridge counts for each centre minutia are listed together.
Dette felt består af en række subfelter, der hver især indeholder tre informationselementer.
The remaining two information items of the first subfield shall both contain ‘0’. Information items shall be separated by the separator character.
»0« angiver, at det ikke vides, hvilken metode der er brugt til ekstraktion af linjeantallet eller deres rækkefølge i recorden.
Subfields shall be separated by the separator character. 6.2.18. Field 9.139: Core information
»1« angiver, at der for hver central minutiae blev ekstraheret data om linjeantal til nærmeste minutiae i fire kvadranter, og linjeantal for hver centrale minutiae opgives samlet.
This field will consist of one subfield for each core present in the original image. Each subfield consists of three information items.
»2« angiver, at der for hver centrale minutiae blev ekstraheret data om linjeantal til nærmeste minutiae i otte oktanter, og linjeantal for hver centrale minutiae opgives samlet.
The first two items contain the ‘x’ and ‘y’ coordinate positions in pixel units. The third information item contains the angle of the core recorded in units of 2 degrees.
De resterende to informationselementer i første subfelt skal begge indeholde »0«.
The value shall be a nonnegative value between 0 and 179. Multiple cores will be separated by the separator character. 6.2.19. Field 9.140: Delta information
Informationselementer adskilles med -separatortegnet.
This field will consist of one subfield for each delta present in the original image. Each subfield consists of three information items.
Efterfølgende subfelter vil indeholde indeksnummeret for den centrale minutiae som første informationselement, indeksnummeret for nærliggende minutiae som andet informationselement og antallet af linjer, der krydses, som tredje informationselement.
The first two items contain the ‘x’ and ‘y’ coordinate positions in pixel units. The third information item contains the angle of the delta recorded in units of 2 degrees.
Dette felt består af et subfelt for hver kerne i det oprindelige billede.
Type-13 variable-resolution latent image record The Type-13 tagged-field logical record shall contain image data acquired from latent images.
Hvert subfelt består af tre informationselementer.
These images are intended to be transmitted to agencies that will automatically extract or provide human intervention and processing to extract the desired feature information from the images. Information regarding the scanning resolution used, the image size, and other parameters required to process the image, are recorded as tagged-fields within the record.
De første to elementer indeholder x- og y-koordinatpositionerne i pixelenheder.
Table 7: Type-13 variable-resolution latent record layout Ident Cond. code Field Number Field name Char type Field size per occurrence Occur count Max byte count min. max. min max LEN M 13.001 LOGICAL RECORD LENGTH N 4 8 1 1 15 IDC M
16 HLL
VERTICAL LINE LENGTH
VLL
SCALE UNITS N 2 2 1 1 9
VERTICAL LINE LENGTH
HORIZONTAL PIXEL SCALE
SCALE UNITS
VERTICAL PIXEL SCALE
HORIZONTAL PIXEL SCALE N
COMPRESSION ALGORITHM
CGA
BPX
VERTICAL PIXEL SCALE
BITS PER PIXEL
BITS PER PIXEL N 2 3 1 1 10
FGP
Da logiske billed-records med mærkede felter kun kan indeholde et binært felt, kræves der en enkelt Type-15-record for hver lillefingerbalde og en eller to Type-15-record(s) for hver fulde håndflade.
Since a tagged-field logical image record may contain only one binary field, a single Type-15 record will be required for each writer's palm and one or two Type-15 records for each full palm.
Derfor kræves der 4-6 Type-15-record til at repræsentere personens håndfladeaftryk i en normal håndfladeaftrykstransaktion.
Therefore, four to six Type-15 records will be required to represent the subject's palmprints in a normal palmprint transaction.
I Type-15 logiske records skal indlæsninger foretages i nummererede felter.
Within a Type-15 logical record, entries shall be provided in numbered fields.
IMP
PCD
IMPRESSION TYPE
PALMPRINT CAPTURE DATE
SRC
HLL
SOURCE AGENCY/ORI
HORIZONTAL LINE LENGTH
PCD
VLL
PALMPRINT CAPTURE DATE
VERTICAL LINE LENGTH N
VLL
HPS
SLC
VPS
HPS
CGA
CGA
PLP
Tillæg 4 Transaktionsresumé
Appendix 4 Transaction Summary Type 1 Record (mandatory) Identifier Field number Field name CPS/PMS SRE ERR LEN 1.001 Logical Record Length M M M VER 1.002 Version Number M M M CNT
VER
File Content
LEN
TOT
Logical Record Length
Type of Transaction M M M
VER
PRY
Type of Transaction
Priority
DAT
DAI
Date
Destination Agency
PRY
ORI
Priority
Originating Agency
DAI
TCN
Destination Agency
Transaction Control Number
ORI
TCR
Originating Agency
Transaction Control Reference
TCN
NSR
Transaction Control Number
Native Scanning Resolution
TCR
NTR
Transaction Control Reference
Nominal Transmitting Resolution
NSR
DOM
Tillæg 5 Definitioner i Type-1-record
Appendix 5 Type-1 Record Definitions Identifier Condition
Tillæg 6 Definitioner af Type-2-records
Field number
Tabel A.6.1: CPS- og PMS-transaktion
Field name
Identifier Condition
Character type
Field Name
Example data LEN M 1.001
Character Type
Logical Record Length N
LEN
VER
Logical Record Length
1.002:0300GS CNT
Version Number N
1.003:1US15RS2US00RS4US01RS4US02RS4US03RS4US04RS4US05RS4US06RS4US07RS4US08RS4US09RS4US10RS4US11RS4US12RS4US13RS4US14GS
File Content
Type of Transaction
1.003:1US15RS2US00RS4US01RS4US02RS4US03RS4US04RS4US05RS4US06RS4US07RS4US08RS4US09RS4US10RS4US11RS4US12RS4US13RS4US14GS
1.004:CPSGS DAT M 1.005 Date N
1.007:DE/BKAGS
1.009:0200000004FGS
1.008:NL/NAFISGS
1.010:0200000004FGS
Native Scanning Resolution
Domain Name
NTR
GMT
Nominal Transmitting Resolution
Greenwich Mean Time
DOM
Under the Character Type Column: A = Alpha, N = Numeric, B = Binary 1* allowed characters for agency name are [‘0..9’, ‘A..Z’, ‘a..z’, ‘_’, ‘.’, ‘’, ‘-’]
I kolonnen »Condition«: O = Optional (fakultativ), M = Mandatory (obligatorisk), C = Conditional (betinget). I kolonnen Character Type: A = Alpha, N = Numeric, B = Binary
Identifier
1* tilladte tegn for agenturnavn er [»0..9«, »A..Z«, »a..z«, »_«, ».«, »«, »-«]
Condition
Field Number Field Name
Example data
Character Type
LEN
2.074: 201: IDC - 1 FIELD 1009 WRONG CONTROL CHARACTER LF 115: IDC 0 FIELD 2.003 INVALID SYSTEM INFORMATION GS
2.074: 201: IDC - 1 FIELD 1.009 WRONG CONTROL CHARACTER LF 115: IDC 0 FIELD 2.003 INVALID SYSTEM INFORMATION GS
[7]) The data refer to the holder of the specific registration certificate.
[7]) The data refer to the holder of the specific registration certificate. Registration holders' (company) name M (C.1.1.)
Registration holders’ (company) name
separate fields will be used for surname, infixes, titles, etc., and the name in printable format will be communicated Y
Male, female
Address
separate fields for first name(s) and initials will be used,
Start date of the holdership of the car. This date will often be the same as printed under (I) on the registration certificate of the vehicle. N End date holdership O
and
End data of the holdership of the car. N Type of holder O
the name in printable format will be communicated
If there is no owner of the vehicle (C.2) the reference to the fact that the holder of the registration certificate: is the vehicle owner,
Address
is not identified by the registration certificate as being the vehicle owner. N Data relating to owners of the vehicle (C.2)
the Address in printable format will be communicated
First name
individual, association, company, firm etc.
male, female
Place of birth
Date of birth
ID Number
Legal entity
Type of ID Number O
Place of Birth
Start date holdership
ID Number
Start date of the holdership of the car. This date will often be the same as printed under (I) on the registration certificate of the vehicle.
An identifier that uniquely identifies the person or the company.
End date holdership
Type of ID Number
End data of the holdership of the car.
The type of ID Number (e.g. passport number).
Type of holder
Start date ownership
If there is no owner of the vehicle (C.2) the reference to the fact that the holder of the registration certificate:
Start date of the ownership of the car. N
is the vehicle owner
End date ownership O
is not the vehicle owner
End data of the ownership of the car. N