@Ferrix @bergie heititte OmaOulussa, että datan tyypistä riippuen (esim. finanssidata...) voi suositella parhaita formaatteja [säie]
posted to #dataopas 15.01.2010 (fi)
@Ferrix @bergie heititte OmaOulussa, että datan tyypistä riippuen (esim. finanssidata...) voi suositella parhaita formaatteja [säie]
@ferrix tuolla oon pyöriny, mutta siellä ei ole oiken datan siirto/strukturointiformaatteja... en tiedä, onko tämä käsitteellisesti eri asia tai puhunku terminä ihan puuta heinää, mutta tyyliin RSS geoRSS XBRL finanssidatalle, JSON, RDF??
valoa pimeyteen ? :)
Puhut toki rakenteellisesta datasta ja mutta niitä formaatteja mä en tunne kovinkaan laajasti. Toisaalta kaikki strukturoitu data tuntuis olevan XML:ää ja siitä voi olla W3-konsortiolla joistakin tietoa. Periaatteessa semanttisen webin utopia, jossa kaikkeen voidaan viitata URL:lla kattaa myös tämän datan ja taas toisaalta mikään ei pakota tuota dataa olemaan järkevässä formaatissa tai ilman kirjautumista saatavilla.
@apoikola Tässä yksi esimerkki. Jos pitäisi tehdä sähköinen lasku, pitää olla yhteisesti sovittu muoto. XML on hyvä lähtökohta, mutta kuka speksaa tagit? Jos se on kansainvälinen taho, voi olla, että sillä ei saadakaan esitettyä meidän kansallisia juttuja. Toki niihin voidaan määritellä osuuksia "omille lisäyksille", mutta sen jälkeen idea osittain häviää, kun homma ei olekaan enää standardia ja yksinkertaista.
Maailmalla on joitain laskuformaattistandardeja, mutta suomessa on käytössä kai 3, joista itse tunnen kaksi:
Näitä on siis kolme erilaista. Verkkolaskuoperaattorit osaavat tehdä muunnoksia noiden välillä, mutta haasteita oli ainakin muutama vuosi sitten, kun jokainen järjesstelmä tulkitsee speksiä vähän omalla tavallaan -- Itse asiassa speksit eivät määrittele kaikkia asioita.
Esimerkkejä ongelmista (heittelen taginimet hatusta, idea selviää):
1) TEAPPSissa laskun etumerkki määritellään erittäin kummallisesti: Se ei ole datassa, vaan tagin attribuutissa. Esim. <AMOUNT SIGN="+">20</AMOUNT> tarkoittaa +20 euroa, <AMOUNT SIGN="-">20</AMOUNT>. Käytännössä esim. jokin laskunkierrätysjärjestelmä ei osaa lukea tagin attribuuttia, vaan vaatii etumerkin dataan. Joku saattaa siksi lähettää <AMOUNT SIGN="-">-20</AMOUNT>, jolloin oikein toimivassa järjestelmässä hyvityslaskusta tuleekin maksettavaa
2) TEAPPSissa laskun loppusummasta on sekä verollinen että veroton. Sekin on päätetty hoitaa tagin attribuuteilla, esim. <AMOUNT VAT="excluded">100</AMOUNT><AMOUNT VAT="inluded">122</AMOUNT>. Kävi ilmi, että eräs järjestelmä ei osannut lukea tagia tietyllä attribuutilla, mutta se luki aina järjestyksessään saman. Homma siis näytti toimivan, mutta koska näiden tagien järjestystä ei ole määrätty, summat meni väärin, kun jokin toinen järjestelmä lähetti ko. tiedot eri järjestyksessä
3) Kentät on kyllä määritelty, mutta esim. se, että onko desimaaliluvuissa piste vai pilkku, sitä ei ole määritelty
Datojen "standardointi" (rakenne) ei yksistään riitä. Se on hyvä alku, mutta aiheuttaa sen, että jokainen joutuu tekemään omat toteutukset. Voin vain arvailla, monessako yrityksessä on tilailtu toimittajilta erilaisia finvoice / teapps-toteutuksia. Olisi hyvä, jos ko. datastandardien ympärille syntyisi myös opensource-kirjastoja, joilla ko. matskuja luetaan/kirjoitetaan. Tämä osaltaan ratkoisi noita kuvaamiani ongelmia (se oli vain pieni pintaraapaisi niihin).
Eräs ongelma on se, että kun teet jotain uutta juttua, mistä tiedät, mitä maailmalta jo voisi löytyä? Jos pitäisi vaikka tehdä XML-rakenne tekstiviestille, mistä lähdet liikkeelle? Laitapa Googleen "SMS XML" ja kerro, minkä niistä valitsisit? Mistä tietää, mikä on uskottavin, ehkä jo laajassa käytössä jne?
Olisipa jokin palvelu, johon voisi rekisteröidä linkkejä eri XML-rakenteisiin aihealueittain, joita voisi sitten peukutella...
kiitos @Ile esimerkistä ja problematiikan avaamisesta. @bergie tunnetko ketään noita SECO-porukoita? Suomessahan on semanttista webiä tutkittu vaikka kuinka paljon, aiheen ympäriltä pahin hype on laantunut, mutta käsittääkseni hommat ovat silti edenneet ja jotain oikeasti toimivaakin alkaa olla, vai?
@apoikola @bergie Surffailin tuota suomen ontologiapankkia: http://www.yso.fi/onki/yso/
Voisko tuosta olla iloa tagittamiseen? Eli jos lyöt tagia jollekin tiedolle, tuolta huomattaisiin, että sana esiintyy monessa eri merkityksessä ja kysyttäisiin viitettä, mitä asiayhteyttä tarkoitat.
Vähän samaan tapaan kuin delissä...
@apoikola en tunne, toistaiseksi kytkyt semanttisiin asioihin lähinnä KV-puolella. Mutta tilannetta olisi tarkoitus lähiaikoina #iks-project :in tiimoilta parantaa :-)
Meillä kirjastolaisilla on aika sanoisinko läheisiä suhteita noihin sema-juttuihin, ja toi @ile:n kuvailema tapa jolla järjestelmä kyselee että mitäs oikein tarkoitat tulee (toivottavasti) olemaan juuri sellaista jolla kirjastolaiset kuvailevat julkaisuja. Meillä on tosin aivan hemmetisti perinteistä painolastia, jonka kanssa eletään vielä kauan ja joka toimii rakennuspohjana tuollaiselle "tagittelulle".
Täällä jo mainittujen linkkien kautta asiaa selvitellään, ja tässä tekemässäni räkäisessä videossa annotointia esitellään Kirjasampo-hankkeen kannalta.
Ainiin ja nyt alkaa jo olla turhan kaukana aiheesta ja turhan lähellä kirjastojuttuja, mutta Kansallinen Digitaalinen Kirjasto on julkaissut (aiheeseen vain löyhästi liittyvän) "standardisalkun" suositelluista dataformaateista sen omassa viitekehyksessä. Open data -hommissa jostain vastaavasta voisi olla iloa. Saispa noita FINNonto -tyyppejä jotenki houkuteltua tänne joko suoraan juttelemaan tai ainaki viittaamaan keskeisiin dokumentteihin kis kis
@mace kirjastokeloista pitäisi muutenkin ottaa vielä tiukempi ote ennen oppaan julkaisua, saatanpa tulla lankoja pitkin kyselemään jotain, jahka kerkeän.
Tällä haavaa oma mututuntumani on, että tulemme puhumaan kirjassa lämpimästi ns. linked datan puolesta, joka on hyvää kelaa datan julkaisuun silloin, kun ei ole motivaatiota lähteä ontologioita pyörittelemään.
Tosin mm. näissä asioissa en ole ihan kovin tiukka ammattilainen, siksipä huutelen mm. täällä qaikussa. Juridiikka on kanssa aika kinkkinen... onko qaikussa juristeja?
Heittelin tätä linkkiä hieman ympäriinsä ja Juha Hakala Kansalliskirjastolta pyysi välittämään tällaisen:
---8<---8<---
Mikael af Hällström Verohallituksesta vetää JHS Sanastotyö-hanketta joka pohtii metadatanyhtenäistämistä julkishallinnon sisällä. Ryhmän laatimasta suosituksesta toivotaan palautetta, ks. http://www.jhs-suositukset.fi/web/gue...
Väärinkäsitysten välttämiseksi, ryhmä ei keskustele sanastoista siinä mielessä kuin kirjastoalalla tuo termi perinteisesti ymmärretään. Tavoite on pikemminkin määritellä metadatarekisteri eli väline jonka avulla voidaan esimerkiksi määritellä mitä tietoelementtejä tarvitaan sellaisessa viestissä jossa kansalaisen henkilötiedot siirretään virastosta toiseen.
Tämänkaltaisten viestien syntaksi on periaatteessa julkishallinnossa jo määritelty JHS 170 -suosituksessa nimeltänsä Julkishallinnon XML-skeemat, tässä toisessa työryhmässä on mietitty enemmänkin semantiikkaa. Minä ja muut työryhmän jäsenet toivomme kovasti saavamme runsaasti palautetta.
Sanastot ja ontologiat ovat olleet FinnONTO:n heiniä, mutta Olli-Pekka Rissanen kollegoineen valmistelee VM:ssä parhaillaan lainsäädäntöä joka luo perustan julkishallinnon käytössä olevien sanastojen ja ontologioiden jatkuvalle kehittämiselle ja ylläpidolle. Lähtökohtana olisi tietysti FinnONTO:ssa tehty työ.
Metadataformaattien mappauksen ja ontologiakehityksen yhdistää mielenkiintoisella tavalla Vocabulary Mapping Framework –hanke. Se on luonut VMF matrix –nimisen ontologian, jonka joulukuussa 2009 julkistettuun ensimmäiseen versioon sisältyvät jo esimerkiksi MARC 21, Dublin Core sekä museoalan CIDOC CRM. Ontologian ja muuta hankkeeseen liittyvää aineistoa löytää osoitteesta http://cdlr.strath.ac.uk/VMF/index.ht...
Matriisi on vapaasti käytettävissä ja sitä voidaan laajentaa periaatteessa rajattomasti, myös erilaisiin hankekohtaisiin metadataformaatteihin kuten Europeana Semantic Elements’iin, joka löytyy osoitteesta http://version1.europeana.eu/c/docume...
--->8--->8---
@apoikola do you dig it?
PS onko qaikussa jotain blockquote-syntaksia? kokeilin rivien aloittamista välilyönnillä sekä suurempi kuin-merkillä.
@mace I kind of get it. Omasta näkökulmastani olennainen kysymys on, että miten yhdistää syvää uurtava ja tarpeellinen, mutta työläs harmonisointi-ontologisointi-sanastotyö nykymaailman ketterään ja hajautettuun loosely coupled meininkiin.
Eli tyyliin, miten dataa saataisiin avattua kevyemmin ja päästäisiin iteratiivisesti kokeilemaan, mitä datalla voidaan hajautetusti tehdä jo ennen, kuin JHS:ssä tai muualla päästään yhteisymmärykseen tietoarkkitehtuurista sanastoista yms.
@Samuel viittasi JHS 170:een täällä: http://www.qaiku.com/channels/show/TK...
@apoikola ontologisointi yhdistyy kevyempään meininkiin, kun käsitteille annetaan URIt (ensimmäinen TBL:n Linked Data -muistion neljästä säännöstä).
Kevyesti ja ketterästi voisi syntyä vaikka FOAF, joka määrittelee käsitteen Person. Jos haluan www-sivulla, xml-skeemassa tai omassa ontologiassani sanoa jonkun otuksen olevan henkilö, viittaan käsitteeseen foaf:Person.
Syvän ontologiatyön kautta Suomessa voi syntyä käsite Henkilö. Voin sanoa oman otukseni olevan myös fin:Henkilö.
Kevyesti ja nopeasti päästäisiin liikkeelle, kun kaikki organisaatiot rupeaisivat antamaan URI-tunnisteita itselleen tärkeille käsitteille. Moni määrittelisi samoja käsitteitä päällekkäin, mutta Darwin pitää huolen siitä, että jotkut määritykset nousevat ajan myötä ylitse muiden.
@Samuel lurkit siis samalla listalla, jossa minä kyselen tyhmiä :)
Kovasti yritän runnoa tuota linked-data asiaa opaskirjaan ja selvittää itselleni, mistä on kysymys. Kädet savessa kokemusta ei itselläni ole ja esimerkit liikkuvat aina teoreettisella tasolla.
@Samuel Tennisonin blogin lukeminen ja ymmärtäminen on ollut to-do listallani...
One of the features of the UK Government’s approach to freeing data is the emphasis on using linked data. What I don’t think has really been articulated is either what that means or why we should take this approach. From what I’ve seen, developers seem to think:
None of these are true. In fact, the UK government is committed to publishing data as linked data because they are convinced it is the best approach available for publishing data in a hugely diverse and distributed environment, in a gradual and sustainable way.
Minua kiinnostaa nimenomaan noiden argumenttien objektiivinen evaluointi, siis onko linked-data oikeasti hyvä juttu, mitkä ovat vaihtoehdot jne. Tämä sen takia, etten halua tarjota opaskirjan lukijoille vain yksisilmäistä tee näin pläjäystä, koska sellaiset yleensä aiheuttavat vastareaktioita, mieluummin avata asiaa ja antaa lukijan tehdä itse johtopäätöksensä.
Luin Jenin artikkelit Creating Linked Data - Part I - V äskettäin. Niissä oli mielestäni hyvin kuvattu vaiheet, joiden kautta datan saa Linked Dataksi.
Minulle ainakin avautui se, että ei tarvitse valita OWLin, SKOSin tms. välillä vaan kustakin voi poimia tarkoitukseen parhaiten sopivia rakenteita.
Loppujen lopuksi semanttisen Linked Datan tuottaminen ei poikkea kovin paljoa esim. JSON/REST-tyyppisen rajapinnan toteutuksesta.
Itse olen sitä mieltä, että toistaiseksi Linked Datan hyödyntäminen on hankalaa työkalujen kehittymättömyyden vuoksi. Tarvitaan helppokäyttöinen datan selailuohjelmisto - Linked Datan Mosaic.
Copyright Rohea Oy 2010 | Mobile version | Feedback | API | Terms of Service | Applications and tools