Aika: 29.4.2020 klo 10-12
Paikka: https://helsinki.zoom.us/j/3233996338
Läsnä:
- Matias Frosterus, Kansalliskirjasto (puhis)
- Jarmo Saarikko, Kansalliskirjasto
- Okko Vainonen, Kansalliskirjasto
- Marja-Liisa Seppälä, Kansalliskirjasto (siht.)
- Mikko Lappalainen, Kansalliskirjasto
- Miia Herrala, Kansallisarkisto
- Leena Furu-Kallio, Kansallismuseo
- Kenneth Ahlfors, Kansallisarkisto
- Tommi Suominen, CSC
- Salla Rimpinen, Museoliitto
Poissa:
- Piia Naukkarinen, Kansalliskirjasto
- Katerina Sornova, Kansalliskirjasto
- Hannu Häkkinen, Museovirasto
Asialista
- Käydään läpi tietomallin luokkia ja ominaisuuksia
- kaaviokuva - lisätty identiteetti ja tunniste omaksi luokakseen. Onko tämä ok mallin kannalta?
- Tunnisteen tyyppi voidaan ilmaista joko yhtenä propertynä, jolloin tyyppi valitaan listalta (koodistosta) tai kullekin tunnisteelle oma propertynsä
- Propertyjen domain - YTI:ssä voidaan luoda kullekin luokalle oma propertynsä esim. "henkilön nimi" vs. yleinen property "nimi", jota voidaan käyttää useissa luokissa.
- Y-välineiden käyttö mallin julkaisuun
- halutaanko jatkaa kokeilua ja kehittää yhdessä?
- edellyttää, että kukin organisaatio liittyy välineen käyttäjäksi, jonka jälkeen voidaan liittää tunnuksia.
- Valitaan minimijoukko entiteettejä, joita tarvitaan prototyypissä
- Toimijakuvailujen yhdistelyssä
- Eri sektorien toimijoiden kuvailussa (sektorikohtaiset pakolliset kentät)
- Mäppäykset muihin tietomalleihin. Prioriteetit, mitkä mäpätään ensin?
- RDA registry - http://www.rdaregistry.info/
- marc21 - http://www.marc21rdf.info/
- Wikidata - https://en.wikipedia.org/wiki/Module:Authority_control/doc
- GND - DNB integrated authority file - https://d-nb.info/standards/elementset/gnd
- ENF - data.bnrf.fr
- EU Core - https://joinup.ec.europa.eu/solution/e-government-core-vocabularies/releases
- bibframe ontology - https://github.com/lcnetdev/bibframe-ontology
- mads/rdf - http://id.loc.gov/ontologies/madsrdf/v1.html
- schema.org
- ISNI - http://www.isni.org/filedepot_download/139/432 - http://www.isni.org/filedepot_download/139/382
- VIAF (OCLC)
- NACO - Name Authority Cooperative Program (LOC) - PCC Program for Cooperative Cataloging https://www.loc.gov/aba/pcc/
- Name Authority Records (NARs) - recommendations - https://www.loc.gov/aba/rda/pdf/lcnaf_rdaphase.pdf
- RDA Decisions, Policies, and Guidelines
- SNAC - https://wiki.harvard.edu/confluence/display/connectingdots/Links
- FAST - http://id.loc.gov/vocabulary/identifiers/fast.html (statistics)
- FOAF - http://xmlns.com/foaf/spec/
- PROV - https://www.w3.org/ns/prov
- Ei avoimesti saatavana
- Share-VDE
- Spectrum
- AHAA
- OCLC Worldcat Identities (Authentication by API key) https://www.oclc.org/developer/develop/web-services/worldcat-registry.en.html
- Varianttinimien esittäminen
- RDA:ssa nomenit ovat "kertakäyttöisiä"
- Jos Henkilö-entiteetillä on vain yksi "varianttinimi-assosiaatio", niin varianttinimen tyyppi voidaan ilmaista Nomen-entiteetin propertynä (koodilista9. Tällöin kullekin "varianttinimi" + "nimen tyyppi" parille luoda oma nomen-entiteetti.
- Jos varianttinimen tyyppi voidaan ilmasta Henkilö-entiteetin assosiaatiolla, riittäisikö yksi Nomen-entiteetti per "nimi"?
Liite:
Kaavioluonnos, jossa nimitietopalvelun tietomallin luokat, attribuutit ja assosiaatiot on järjestelty hieman uudelleen. Pakolliset kentät pyritty merkitsemään punaisella. Laatinut Jarmo Saarikko.
Muistio
Käytiin läpi tietomallia:
- Jarmo esitteli mallia:
- Tietomallissa jo noin 300 ominaisuutta.
- Entiteetit/luokat ovat pyöreäkulmaisissa laatikoissa ja entiteettien/luokkien väliset suhteet ym. ominaisuuksiin ja assosiaatioihin liittyvät asiat teräväkulmaisissa laatikoissa.
- Pakolliset ominaisuudet punaisella tekstillä. Näyttörajoitukselliset ominaisuudet punaisella pohjalla.
- Risuaita ominaisuudet alussa tarkoittaa, että ominaisuus esiintyy KAM-kuvailuryhmän tekemässä alkuperäisessä mallinnuksessa.
- Luokat pääsääntöisesti RDA:n mukaisia, paitsi kaksi alaluokkaa: identiteetti ja tunniste.
- Alaluokka perii yläluokan ominaisuudet, muttei ominaisuuksien arvoja.
- Identiteetti on entiteettinä kuin henkilö.
- Tunnisteen tyyppi -ominaisuudessa on arvona tunnistejärjestelmän koodit.
- Nimissä taas ei ole käytetty tyyppikooditusta vaan jokainen nimi on oma ominaisuutensa eli suhde/assosiaatio toimijan ja nomenin välillä.
- RDA:n tietomallin mukaisesti yksi nomen string voi liittyä vain yhteen toimijaan. Wikidatassa yksi nomen string voi liittyä useaan toimijaan.
- Keskustellut/päätetyt asiat:
- Onko identiteetti oma luokkansa?
- Identiteetin osalta tietomalli on samanlainen kuin Kansallisarkiston AHAA-järjestelmässä. Identiteetin sisältäminen omana luokkanaaa Nimitietopalvelun tietomalliin on ok.
- Periikö identiteetti henkilön kaikki ominaisuudet vai merkitäänkö henkilölle ja identiteetille yhteiset omanaisuudet vain henkilölle?
- Kaikkia henkilön ominaisuuksia voi käyttää identiteetissä muttei tarvitse. Merkitään vain identiteetille keskeiset ominaisuudet identiteettiin. Muut ominaisuudet merkitään henkilöön. Identiteettiluokkaa ei luoda, ilman että henkilöluokka on jo olemassa.
- Onko tunniste pelkkä string ja tyyppi määritellään erillisessä koodistossa?
- Tyyppikoodiston päivittäminen on helpompaa eikä vaadi skeeman muutosta tai koodaustyötä. Eli ratkaisu soveltuu helposti muuttuvaan ominaisuuteen ja on kuvailijan kannalta kevyemmän näköinen.
- Onko jokainen nimi oma ominaisuutensa/suhteensa toimijan ja nomenin välillä?
- Nimen koodaaminen ominaisuutena on kuvailijaa ohjaavampi ja koodaamisen kannalta raskaampi ratkaisu. Ei hierarkkista ratkaisua eri nimityypeille, sillä on liian kontrolloiva. AHAA-järjestelmän ratkaisussa luodaan vain vähän nimiominaisuuksia, jonka arvona on eri nimimuodot (koodilistana). Ainakin yksi ensisijainen nimi on pakollinen. Etu- ja sukunimet ovat omat alaluokkansa. Ollaan päätymässä seuraavaan ratkaisuun:
- Auktorisoitu hakutieto on oma ominaisuutensa eli suhde toimijan ja nomenin välillä.
- Ensisijainen nimi on oma ominaisuutena eli suhde toimijan ja nomenin välillä.
- Variantti nimi on oma ominaisuutena eli suhde toimijan ja nomenin välillä, ja tarkemmat variantti nimen määritykset ovat nomenin tyypin arvoina (koodilistoina).
- Etunimi/sukunimi ovat omat nomen-tyypit, joka yhdistetään ensisijaiseen tai varianttiin nimeen nomenien välisellä part/part of -suhteilla.
- Testataan vielä yo. ratkaisua käytännön esimerkkeinä.
- Nimen koodaaminen ominaisuutena on kuvailijaa ohjaavampi ja koodaamisen kannalta raskaampi ratkaisu. Ei hierarkkista ratkaisua eri nimityypeille, sillä on liian kontrolloiva. AHAA-järjestelmän ratkaisussa luodaan vain vähän nimiominaisuuksia, jonka arvona on eri nimimuodot (koodilistana). Ainakin yksi ensisijainen nimi on pakollinen. Etu- ja sukunimet ovat omat alaluokkansa. Ollaan päätymässä seuraavaan ratkaisuun:
- Otetaanko toimijaentiteetti/luokka mukaan tietomalliin vai mennäänkö suoraan henkilöihin, yhteisön ja suvun tasolle suoraan?
- AHAA-järjestelmässä kuvaillaan vain henkilöitä, yhteisöjä ja sukuja, ei toimijoita. Ei sisällytetä toimijatasoa nimitietopalvelussa vaan mukana on vain henkilö, suku ja yhteisö entiteetteinä/luokkina. Tietomallissa on kuitenkin yleisentiteettin, jossa voidaan ilmaista kaikkiin tietomallin entiteetteihin/luokkiin kuuluvia ominaisuuksia.
- Onko identiteetti oma luokkansa?
Tutustuttiin tietomallin kuvaamiseen Y-alustalla (Yhteentoimivuusalusta):
- Tietomallikuvaan voi tutustua Y-alustalla.
- Ohjeet tunnusten saamiseksi Y-alustalle sivun tietomallit.suomi.fi alalaidassa. Ensin on luotava organisaatiokohtaiset tunnukset/oikeudet ja sitten henkilökohtaiset tunnukset.
- Tietomalli voidaan julkaista koko julkisen sektorin tarkasteltavaksi Y-alustalla. Mahdollistaa tietomallin hyödyntämisen ja oman sovellusprofiilin luomisen tietomalliin pohjautuen.
- Tietomallikuva voi tulla sekavaksi, kun assosiaatiosuhteita on 300, kuten nimitietopalvelun tietomallissa.
Sovittiin ensimmäiseen wikibase-testaukseen ensin sisällytettävistä luokista ja ominaisuuksista:
- Henkilön ja yhteisön pakolliset ominaisuudet mukana ensimmäisessä testauksessa
- Pakolliset ominaisuudet määrittyvät KAM-kuvailuryhmän tietomallimääritysten ja Toiku-verkoston uusien linjausten perusteella.
Keskusteltiin mäppäyksistä ja siltauksista:
- Merkitään kaikkiin mahdollisiin ominaisuuksiin viittaukset RDA Registryn ominaisuuksiin.
- Mäppääminen vaatii toisten tietomallien/käsitemallien URI-tunnisteiden avoimen saatavuuden.
- Tietomalliin Y-alustalla on lisätty mahdollisia mäpättäviä nimiavaruuksia, mikä tukee eri tietomallien yhteentoimivuuden määrittelyä.
- Mäppäykset prisorisoidaan seuraavasti:
- RDA → Schema.org → Dublin Core → Arkistojen RIC
- Muiden mäppäysten priorisointijärjestystä mietitään vielä.