opendata.lv un eazyBI

05.08.2011

Ilgu laiku šeit nebiju neko rakstījis un iespējams, ka arī vairs ļoti aktīvi šeit neraksīšu. Jo savu latviskās blogošanas aktivitāti tuvākajā laikā veltīšu “open data” jeb “atvērto datu” jomai un šim nolūkam esmu sācis jaunu blogu opendata.lv. Tā ka lūdzu apmeklēt to un ielikt savos RSS lasītājos!

opendata.lv piemēros es daudz izmantošu eazyBI datu analīzes web aplikāciju, pie kuras pēdējos mēnešos esmu aktīvi strādājis. Ja jums ir dati, ko analizēt, un vēlaties vienkāršu, bet ērti lietojamu datu analīzes rīku, tad lūdzu izmēģiniet, vai eazyBI jums var noderēt.

Advertisements

Padomi jaunajam e-me īpašniekam

29.07.2009

e-bardaks.png
Esmu jau agrāk rakstījis par maniem piedzīvojumiem ar e-me jeb e-paraksta sertifikācijas pakalpojumu sniedzēju. Kā daudzi no jums jau droši vien zin, tad nesen e-me ir mainījis īpašnieku un tagad tas ir LVRTC. Gribētos cerēt, ka šīs izmaiņas mainīs ar e-paraksta izplatību Latvijā, bet diemžēl pirmās aktivitātes neko labu neliecina.

Komunikācija ar klientiem

Ja gadījumā kāds no e-me lietotājiem nebija pamanījis, ka e-me īpašnieks tagad ir LVRTC, tad viņi parūpējās par šiem klientiem izsūtot e-pasta vēstuli ar sekojošu saturu:

Nosūtu Jums dokumentu, kas parakstīts ar drošu elektronisko parakstu (paplašinājums- *.edoc), kas apliecina tā juridisko spēku.

Ievērojot Ministru kabineta 28.06.2005. noteikumu Nr. 473 “Elektronisko dokumentu izstrādāšanas, noformēšanas, glabāšanas un aprites kārtība valsts un pašvaldību iestādēs un kārtība, kādā notiek elektronisko dokumentu aprite starp valsts un pašvaldību iestādēm vai starp šīm iestādēm un fiziskajām un juridiskajām personām” 17. punkta prasības, VAS Latvijas Valsts radio un televīzijas centrs lūdz Jūs vienas darbdienas laikā nosūtīt paziņojumu par elektroniskā dokumenta saņemšanu.

Pirmajā brīdī šāda vēstule izskatās pēc izsaukuma uz policiju vai tiesu. Un papildus pieminētie noteikumi attiecas tikai uz valsts vai pašvaldību iestādēm un man tie nekādus pienākumus neuzliek atbildēt vienas dienas laikā. Un pašā pievienotajā dokumentā (kuru man jāatver vispirms ar eParakstītāja aplikāciju un pēc tam ar MS Word, ir tikai informācija par to, ka ir nomainījusies līguma kontakpersona).

Nākamā “laža” ir tāda, ka e-pasts ir izsūtīts iekļaujot pārsimt klientu e-pasta adreses To: laukā, kā rezultātā visi saņēmēji redz visu pārējo saņēmēju e-pasta adreses. Tas gan ir nezolīdi no personas datu aizsardzības viedokļa, gan arī šādi e-pasti ir kandidāti automātiskai nokļūšanai e-pastu “spam” mapēs.

Nosūtīju atbildi uz šo e-pastu norādot šos trūkumus, diemžēl atbildi nesaņēmu.

Padoms: Lūdzu iemācieties Interneta komunikāciju “netiķeti” pirms izsūtiet šādus masveida e-pastus. Un lūdzu iemācīties klientiem draudzīgu komunikācijas veidu, nevis lietojiet stīvo, formālo un atbaidošo stilu.

Grib samaksu gan par vistām, gan olām

E-paraksta projekta neveiksmes cēlonis pēdējā gada laikā tika raksturots kā “vistas un olas” problēma – 1) nav pietiekoši daudz e-paraksta lietotāji, kas būtu gatavi maksāt par pakalpojumu, jo nav pietiekoši daudz e-pakalpojumi, 2) nav pietiekoši daudz e-pakalpojumu, jo potenciālie pakalpojumu sniedzēji neredz ieguvumu no tik maza lietotāju skaita.

Tādēļ patlaban e-paraksta lietotāji nav kļuvuši vairāk par tiem pārdesmit tūkstošiem, kuriem e-paraksta kartes iegādājās ar valsts pasūtījumu. Savukārt e-pakalpojumu sniedzēju saraksts, kur var izmantot e-parakstu, tā arī ir palicis ļoti neliels (daži, piemēram, Swedbank, pat ir pazuduši no saraksta).

Šādos apstākļos būtu jāizvēlas viena no divām stratēģijām:

  1. Vai nu ir jāstimulē e-paraksta lietotāju pieaugums, būtiskipazeminot cenas lietotājiem (jo patreizējā cena ne privātajiem, ne biznesa lietotāji nelikās pārāk pievilcīga) un tad domājot kā iegūt ieņēmumus no potenciālajiem pakalpojumu sniedzējiem
  2. Vai arī ir jāstimulē pakalpojumu radīšana, nodrošinot izstrādātājiem bez maksas visus nepieciešamos rīkus pakalpojumu radīšanai un mērķtiecīgi strādājot ar potenciālajiem pakalpojumu sniedzējiem, lai panāktu pēc iespējas lielāku pakalpojumu klāstu. Tad arī e-paraksta lietotāji varētu saredzēt ieguvumu no e-paraksta pakalpojumiem un būtu gatavi par to maksāt.

Tā vietā jaunie e-me saimnieki ir izvēlējušies mūsu budžeta lāpīšanas politiku – ja naudas nav, tad jāpaaugstina nodokļi. Nākotnē ir paredzēts, ka par e-paraksta bibliotēku (kas nepieciešama e-paraksta integrācijai trešo pušu sistēmās) izmantošanu būs jāmaksā gan izstrādātāja licence, gan arī lietošanas licence. Un cik ir redzēts, tad šīs summas ir paredzētas diezgan iespaidīgas, lai pēc iespējas atsistu izstrādātāju vēlmi izstrādāt integrāciju ar e-parakstu savās sistēmās.

Ja no nodokļiem izvairīties ir grūtāk, tad no e-paraksta izmantošanas izvairīties cenu celšanas gadījumā ir stipri vieglāk. Un ja vēl ņem vērā, ka parādās arī alternatīvi piedāvājumi ar potenciāli mazākām izmaksām lietotājiem, tad pastāv risks, ka e-pakalpojumu potenciālie sniedzēji var sākt vairāk izmantot šos alternatīvos risinājumus.

Padoms: Ja jums tiešām ir tik dārgi uzturēt šīs e-paraksta integrācijas bibliotēkas, tad pareizāk būtu tās nopublicēt kā atvērtā koda programmatūru un tad izstrādātāji paši veiksmīgi tās varētu uzturēt tālāk un visi būtu laimīgi.

Labā ziņa Mac lietotājiem

Staigājot pa e-me.lv lapām arī atradu ko iepriecinošu – beidzot ir pieejami viedkaršu lasītāju draiveri Mac OS X operētājsistēmai, kā rezultātā kopā ar SignAnywhere Free programmu beidzot ir iespējams lietot e-parakstu arī uz Mac datora.

Diemžēl ar Firefox pārlūkprogrammu un šiem viedkaršu draiveriem nav iespējams autentificēties visās minētajās e-pakalpojumu lapās. Man izdevās veiksmīgi autentificēties Nordea internetbankā, bet e-me.lv un latvija.lv lapās neizdevās – tās izskatās joprojām ir paredzētas tikai izredzētajiem Windows un Internet Explorer lietotājiem. e-me.lv izdod kļūdas paziņojumu

Ja Jūs izmantojiet tīmekļa pārlūku Mozilla Firefox, lūdzu izlasiet informāciju par tā konfigurāciju izmantošanai kopā ar Е-МЕ autentifikācijas sertifikātiem

bet norādītajā saitē nav nekādas informācijas par Mozilla Firefox 😦


E-pakalpojums URN:IVIS:100001:EP-EP00-v1-4

05.02.2008

latvijalv.gifIr pienācis ilgi gaidītais brīdis un www.latvija.lv ir pieejams pirmais e-pakalpojums ar identifikatoru URN:IVIS:100001:EP-EP00-v1-4 jeb garāk izsakoties “Ziņas par personām, kurām manā īpašumā ir spēkā reģistrācija dzīvesvietā”. Sākotnēji gan bija solīts, ka vajadzēja jau būt šādiem 26 e-pakalpojumi, bet labāk jau ir, ka vispirms tiek palaists pirmais eksperimentālais kucēns, kuru var arī noslīcināt, lai pēc tam nākošos uztaisītu vēl labāk.

Iepriekš biju jau rakstījis, ka man radās aizdomas, ka valsts informācijas sistēmu integrācija tiek taisīta pārāk sarežģīti. Tādēļ interesēja, kā tas viss izskatīsies no gala lietotāju viedokļa – vismaz gala lietotājiem visu to XML shēmu sarežģītību nevajadzētu attēlot.

Pēc nosaukuma šis e-pakalpojums izklausās diezgan vienkāršs – man vajadzētu sevi autentificēt un pēc tam ar viena klikšķa paldzību vajadzētu saņemt sarakstu ar personām, kuri ir deklarējuši dzīvesvietu manos īpašumos. Tādēļ uzreiz ķēros pie šī e-pakalpojuma izmēģināšanas.

Lasīt pārējo šī ieraksta daļu »


Sex un XML

28.05.2007

Meklējot informāciju par topošo Integrēto valsts informācijas sistēmu (IVIS), ko sola kaut kad šogad piestartēt, atradu, ka testa režīmā jau ir pieejams IVIS portāls. Īsti gan nav skaidrs, kādēļ tas ir publiski pieejams, jo pagaidām tas izskatas diezgan zaļš.

IVIS tiek veidots ļoti aktīvi izmantojot XML un dažnedažādus WS-* standartus web servisu veidošanā, lai to pēc tam izmantotu dažādu valsts reģistru integrācijā un e-pakalpojumu nodrošināšanā. Nu un lai e-pakalpojuma saņēmējs saprastu, kādus datus viņam e-pakalpojumu sniedzējs sūta, tiek definēta kaudze ar XML shēmām, kas apraksta metadatus par šiem e-pakalpojumiem.

Bet paskatoties uz patreiz pieejamajām XML shēmām rodas sajūta, ka tiek producēts pārāk daudz XMLa, kas nevienam īpaši nav vajadzīgs.

Kā piemēru apskatījos sexa definīciju (jeb latviski runājot personas dzimuma definīciju) :

<?xml version="1.0" encoding="utf-8"?>
<xs:schema xmlns="http://ivis.eps.gov.lv/XMLSchemas/100001/Person/v1-0" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:pers="http://ivis.eps.gov.lv/XMLSchemas/100001/Person/v1-0" targetNamespace="http://ivis.eps.gov.lv/XMLSchemas/100001/Person/v1-0" elementFormDefault="qualified" attributeFormDefault="unqualified" version="1.0" id="Sex.xsd">
    <xs:annotation>
        <xs:appinfo>
            <ivis:Metadata xmlns:pers="http://ivis.eps.gov.lv/XMLSchemas/100001/Person/v1-0" xmlns:ivis="http://ivis.eps.gov.lv/XMLSchemas/100001/IVIS/v1-0">
                <ivis:Contributor href="http://www.rixtechnologies.lv" CodeListID="Authority" CodeListAgencyID="100001" CodeListAgencyName="ĪUMEPLS" CodeListLanguageID="lv" CodeListCodeValue="100002">SIA "RIX Technologies"</ivis:Contributor>
                <ivis:Contributor href="http://www.pmlp.gov.lv" CodeListID="Authority" CodeListAgencyID="100001" CodeListAgencyName="ĪUMEPLS" CodeListLanguageID="lv" CodeListCodeValue="100010">Pilsonības un Migrācijas Lietas Pārvalde</ivis:Contributor>
                <ivis:Creator href="http://www.eps.gov.lv" CodeListID="Authority" CodeListAgencyID="100001" CodeListAgencyName="ĪUMEPLS" CodeListLanguageID="lv" CodeListCodeValue="100001">Īpašu uzdevumu ministra e-pārvaldes lietās sekretariāts</ivis:Creator>
                <ivis:Date>
                    <ivis:Created>2007-05-02</ivis:Created>
                    <ivis:Declared>2007-05-02</ivis:Declared>
                    <ivis:Modified>2007-05-02</ivis:Modified>
                </ivis:Date>
                <ivis:Description>
                    <ivis:Default>Apraksta personas dzimumu</ivis:Default>
                </ivis:Description>
                <ivis:Format>
                    <ivis:Default>text/xml</ivis:Default>
                </ivis:Format>
                <ivis:Identifier Scheme="URN">URN:IVIS:100001:XSD-Person-Sex-v1-0</ivis:Identifier>
                <ivis:Language>LV</ivis:Language>
                <ivis:Publisher CodeListID="Authority" CodeListAgencyID="100001" CodeListAgencyName="ĪUMEPLS" CodeListLanguageID="lv" CodeListCodeValue="100001" href="https://ivis.eps.gov.lv/">ĪUMEPLS</ivis:Publisher>
                <ivis:Relation>
                    <ivis:ConformsTo href="URN:IVIS:100001:DOC-FR-XML-V1.00">XML shēmu izstrādes vadlīnijas</ivis:ConformsTo>
                    <ivis:ConformsTo>ISO/IEC 5218:2004</ivis:ConformsTo>
                </ivis:Relation>
                <ivis:Status>
                    <ivis:Default>PUBLISHED</ivis:Default>
                    <ivis:Version>v1.0</ivis:Version>
                </ivis:Status>
                <ivis:Subject>
                    <ivis:Category CodeListID="XMLSchemaType" CodeListAgencyID="100001" CodeListAgencyName="ĪUMEPLS" CodeListLanguageID="lv" CodeListCodeValue="1">Infrastruktūras XML shēma</ivis:Category>
                    <ivis:Keyword>IVIS</ivis:Keyword>
                    <ivis:Keyword>XML shēma</ivis:Keyword>
                    <ivis:Keyword>personas dzimums</ivis:Keyword>
                    <ivis:Project>Person</ivis:Project>
                </ivis:Subject>
                <ivis:Title>
                    <ivis:Default>Personas dzimums</ivis:Default>
                </ivis:Title>
            </ivis:Metadata>
        </xs:appinfo>
    </xs:annotation>
    <xs:complexType name="PersonSexStructure">
        <xs:annotation>
            <xs:documentation>Personas dzimuma struktūra</xs:documentation>
        </xs:annotation>
        <xs:sequence>
            <xs:element name="PersonSexCode" type="PersonSexCodeType">
                <xs:annotation>
                    <xs:documentation xml:lang="lv">Personas dzimuma kods</xs:documentation>
                </xs:annotation>
            </xs:element>
            <xs:element name="PersonSex" type="PersonSexType">
                <xs:annotation>
                    <xs:documentation xml:lang="lv">Personas dzimums</xs:documentation>
                </xs:annotation>
            </xs:element>
        </xs:sequence>
    </xs:complexType>
    <xs:simpleType name="PersonSexCodeType">
        <xs:annotation>
            <xs:documentation xml:lang="lv">Personas dzimuma koda tips</xs:documentation>
        </xs:annotation>
        <xs:restriction base="xs:string">
            <xs:enumeration value="N" />
            <xs:enumeration value="V" />
            <xs:enumeration value="S" />
            <xs:enumeration value="Z" />
        </xs:restriction>
    </xs:simpleType>
    <xs:simpleType name="PersonSexType">
        <xs:annotation>
            <xs:documentation xml:lang="lv">Personas dzimuma tipa atšifrejums</xs:documentation>
        </xs:annotation>
        <xs:restriction base="xs:string">
            <xs:enumeration value="nezināma" id="N" />
            <xs:enumeration value="vīrietis" id="V" />
            <xs:enumeration value="sieviete" id="S" />
            <xs:enumeration value="neizvēlēta" id="Z" />
        </xs:restriction>
    </xs:simpleType>
</xs:schema>

Šajā XML dokumentā 83 rindiņās ir aprakstīts klasifikators, kas sastāv no 4 rindiņām. Vai tiešām to nevar aprakstīt kaut kā vienkāršāk? Jo saturīgā informācija šeit parādās tikai pēdējās rindiņās.

Citur plašajā internetā tiek diskutēts par to, ka dažnedāžādie WS-* standarti ir noveduši pie tā, ka web servisu veidošana un uzturēšana kļūst ļoti sarežģīta un ka sākotnējais “vienkāršais” SOAP nemaz vairs nav “Simple”. Tādēļ bieži sarežģīto WS-* standartu vietā tiek izmantota vienkāršākā REST pieeja web servisu veidošanai.

Augstākminētais piemērs pēc REST pieejas varētu izskatīties aptuveni sekojoši – uz pieprasījumu http://ivis.eps.gov.lv/sexes tiktu atgriezts

<sexes description="Personas dzimums">
  <sex><id>N</id><value>nezināma</value></sex>
  <sex><id>V</id><value>vīrietis</value></sex>
  <sex><id>S</id><value>sieviete</value></sex>
  <sex><id>Z</id><value>neizvēlēta</value></sex>
</sexes>

Būtu taču viss skaidrs arī no šāda vienkārša apraksta?