Page History

...

• 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. Identiteettiluokkaa ei luoda, ilman että henkilöluokka on jo olemassa.
  • 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ä.
  • 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.

...