Paikka: Kansalliskirjasto, Yliopistonkatu 1, 1. krs Pohto, (koputa ikkunaan oven oikealla puolella, jos tulet myöhässä). Etäkokous Zoomilla <linkki lähetetty osallistujille>

Aika: klo 12-14.

Ilmoittautunut:  Jarmo Saarikko , Okko Vainonen user-99b6a , Anssi Lampela (Kansallisarkisto), Tommi Suominen (CSC), Mikko Lappalainen , user-ad065 , Jerry Jantunen , Piia Johanna Naukkarinen 

Poissa: Matias Frosterus , Marja-Liisa Seppälä , Salla Rimpinen, Leena Furu-Kallio, Katerina Sornová

Aihe

Käydään läpi tietomalli ja siitä Jarmo Saarikon tekemä kaavio mallin luokista ja propertyistä.  Keskeisenä aiheena henkilön, henkilön identiteettien ja henkilön nimien väliset suhteet. Alla joitakin toteamuksia luonnostellusta mallista sekä niihin liittyviä kysymyksiä.

Tavoite: (alustava) päätös: Miten identiteetit kuvataan NTP-tietomallissa? Mitkä RDA:n nimientiteetit otetaan mukaan malliin?

Asialista - voi täydentyä tai tarkentua ennen kokousta

Taustaa

  • Leena Furu-Kallio tiedusteli onko ollut keskusteluja Seco:n käyttämästä tietomallista ja järjestelmistä? 
    • JarmoS: Matias on esitellyt projektia Heldigissä.  Biografiasampo, Kirjasampo ja Sotasampo ainakin käsittelevät henkilöitä laajasti ja pohjautuvat mm. kirjastodataan. Ensivaikutelmani on, että ainakaan pseudonyymejä ei ole käsitelty.  Jatkokeskusteluja käydään ja vertaillaan malleja, kun oma yhteinen RDA:han pohjautuva mallimme on tarkemmin kuvattu.
  • Marja-Liisa Seppälä toivoo, että yhtenä kokouksen tuloksena saataisiin lista niistä tietomalliasioista, joita voitaisiin käsitellä KAM-kuvailuryhmän kokouksessa 23.3. 
  • Huom. katso myös kommenttiketjut sivun lopussa.

Alla kuvatussa kaaviossa olevan tietomallin selitys Nomenin osalta

  • RDA-mallissa person -> nomen -> identiteetti. Personista viitataan nomeniin
  • identiteetit ovat vain nomeneita
  • jokaisesta merkkijonosta tehdään oma kohde, joka voidaan linkittää henkilöön
    • etu- ja sukunimi voidaan linkittää henkilöön
    • voiko sama merkkijono olla useampaan tyyppiä: esim. lempi- ja etunimi samat?
    • sama nimi, joka yhdistyy useampaan kaimaan? Nopeampi hakea?
      • riippuu teknisistä ratkaisuista: SQL, Wikidata, Opendata
  • Jokainen nimenä käytetty merkkijono muodostaa oman Nomen-luokkaan kuuluvan kohteen.
    • Kysymys: kirjataanko kukin "merkkijono" malliin vain kerran? Esim. sukunimi. 
  • Henkilöllä on ominaisuuksia, joiden Range on Nomen.
    • Nämä relaatiot tehdään Nomeneihin, joilla on vastaava tyyppi.
    • Mikäli Nomen on tyyppiä, jolla ei ole vastaavan nimistä relaatiota, niin relaatio tehdään varianttinimenä.
    • Kysymys:  Voiko sama nomenin merkkijono olla yhtaikaa eri tyyppiä? (kts. esimerkki alla #n6 vs #n25 sekä #n16)
    • Ellei voi, niin miten nimen tyyppi ilmaistaan luomatta jokaiselle omaa propertyä, mikä olisi loogisin ratkaisu. Kaikki voidaan luoda varianttinimi propertyn alapropertyinä.


Liitteenä keskeneräinen kaavio tietomallin luokista ja ominaisuuksista (3.3.2020)

nimitietopalvelun tietomallin entiteettejä (keskeneräinen luonnos 3.3.2020)


RDA

  • RDA:n mukaan kuvailitaisiin vain yksi Person -tyypin entiteetti ja jokainen nimi omana Nomen entiteettinään. Kaikki muut tiedot olisivat näiden liittyviä tai näiden välisiä ominaisuuksia (propertyjä).
  • Nimien "perustyypit":  nimi, ensisijainen nimi, varianttinimi, hakutieto, varianttihakutieto, auktorisoitu hakutieto.
  • RDA http://rdaregistry.info/Elements/a/P50111: A "name of person" may be a real name, a pseudonym, a term of rank of nobility, a nickname, initials of a name, an assigned name.  

  • A name may be categorized as: Person: preferred name of person or Person: variant name of person.  A name not chosen as a preferred name may be recorded as a variant name.  Record this element as a value of a Nomen entity.

  • Marja-Liisa Seppälä ehdottaa, että RDA:n henkilön nimistä otettaisiin malliin "ensisijainen nimi", "varianttinimi" sekä "auktorisoitu hakutieto". 

Identiteettien käsittely

  • Henkilöllä on yksi "todellinen identiteetti". Muut henkilön identiteetit ovat kaikki tyyppiä "toinen identiteetti"
    • Huom! Kirjastosektorilla voi myös pseudonyymi olla henkilön "pääidentiteetti".  Todellinen nimi olisi tällöin identiteetin varianttinimi.
    • Kuhunkin identiteettiin liittyy prefLabel (auktorisoitu hakumuoto) ja mahdollisesti muita nimiä
    • Kysymys: Onko "identieetti" -property "henkilön"  vai "nimen" ominaisuus? Tämä kysymys toistuu tässä useita kertoja.
  • Auktorisoidut nimet vs. muut nimet
    • Rajoitus: henkilön auktorisoitu nimimuoto voi liittyä vain yhteen henkilöön.  
    • Erilaiset nimityypit.
      • Henkilöllä on vain yksi auktorisoitu nimimuoto.
      • Vain osa nimistä auktorisoidaan, muut ovat varianttinimiä.
      • Nimen tyyppi voidaan ilmoittaa omassa propetyssä
    • Pitääkö jokainsen nimen kuulua johonkin henkilön "identiteettiin"?
      • Entä eri henkilöiden yhteiset nimet →  Jaetut identiteetit!
      • Sama "Nomen" voi liittyä useaan henkilöön tai olla yhden henkilön todellinen identiteetti ja toisen henkilön pseudonyymi
      • kompleksiset esitykset: yksi entiteetti, joka kuvaa useita erillisiä identiteettejä?
  • Kuvataanko henkilön identieetit nimitietopalvelun tietomallissa omana luokkana vai henkilöiden ja nimien välisinä viittauksina (propertyinä)?
  • RDA
    • Person entiteetiin propertyt, henkilöstä viitataan nimeen (Range: Nomen)
      • P50428 "henkilön toinen identiteetti", "has alternate identitety of person", "alternate identity". — Nomen, joka on pseudonyymi tai muu henkilön käyttämä nimitys.  "Aquired identity"
      • P50429 "henkilön todellinen identiteetti", "real identity of person".  — Nomen, joka on toista nomenia käyttävän henkilön todellinen nimitys.  "Given identity"

      • P50428 ja P50429 ovat subPropertyjä propertylle P50348: "henkilöön liittyvä nomen", "related nomen of person" —  Nomen, joka liittyy henkilöön.

    • Nomen entiteetin propertyt, nimestä viitataan henkilöön (Range: Person)
      • P80157 "toinen identiteetti henkilölle", "alternate identity of person of".  —  Henkilö, jonka nimitys on pseudonyymi tai muu oletettu identiteetti. 
      • P80158 "todellinen identiteetti henkilölle", "real identity of person". —  Henkilö, jonka nimitys on todellinen identiteetti.
    • JS: Huomioita
      • Henkilöstä on viittauksia monenlaisiin nomeneihin. 
      • Voiko Nomen olla samalla kertaa "toinen identiteetti henkilölle" ja esim. varianttinimi?
      • Voidaanko yksi nomen liittää vain yhteen henkilööön?   Miten kuvataan, kunusealla henkilöllä on yhteinen jaettu pseudonyymi (esim. Outsider, Erin Hunter)?
      • Miten samaan identieettiin kuuluvat varianttinimet voidaan ryhmitellä yhteen?
        • voidaanko tällöin käyttää esim. Nomenin propertyjä
        • rdan:P80060 "johdos", "derivation" (Nomen, joka perustuu toiseen nomeniin)
        • rdan:P80061 "johdos nomenista", #derivation of" (Nomen, joka on toisen nomenin perusta)
        • rdan:P80113 "vastaava nomen", "equivalent to" (Nomen, joka on saman entiteetin nimitys kuin toinen nomen)
  • GND https://d-nb.info/standards/elementset/gnd
    • :realIdentity a owl:ObjectProperty , rdf:Property ;  rdfs:subPropertyOf rdaa:P50106 , :relatedPerson ;  rdfs:range :Person ; owl:inverseOf :pseudonym .
      • "Links an identity under which one or more persons act, e. g. write, compose or create art, but that is not their real name (i. e. a pseudonym) to their real identity."
    • :pseudonym a rdf:Property , owl:ObjectProperty ; rdfs:range :Person ; rdfs:subPropertyOf rdaa:P50105 , :relatedPerson ; rdfs:domain :Person ; owl:inverseOf :realIdentity ;
      • "Links a person's real identity to an identity under which one or more persons act, e. g. write, compose or create art, but that is not the person's real name (i. e. a pseudonym)."
    • :relatedPerson a owl:ObjectProperty , rdf:Property ; rdfs:domain:  :AuthorityResource  ; rdfs:range :Person ; rdfs:subPropertyOf  rdaa:P50220 agrelon#relatedAgent  ,
    • :Person  a rdfs:Class , owl:Class ; rdfs:subClassOf :AuthorityResource ; owl:equivalentClass foaf:Person , rdac::C10004  .
    • JS: Huomioita
      • identiteetti on Person luokan property, joka viittaa toiseen Person luokan entiteettiin. (yllä oleva on hieman muokattu kuvaus)
      • Mikäli identiteetti-property viittaa toiseen henkilöön, tämä property ei vielä kerro mikä on tuon toisen identiteetin käyttämä nimi. 
  • AHAA
    • Jokaisesta henkilötoimijan omaksumasta julkisesta identiteetistä voidaan laatia erillinen toimijakuvailu.
    • Toimijaan voi liittyä eri identiteettejä ja identiteetin tulee aina liittyä johonkin toimijaan.
      • Todellinen identiteetti = Toisen identiteetin omaksuneen henkilön todellinen identiteetti.
      • Toinen identiteetti = Henkilön omaksuma toinen (julkinen) identiteetti. Omaksutusta julkisesta identiteetistä voidaan luoda erillinen kuvailu, jolloin luodaan suhde henkilön todelliseen identiteettiin.
      • Toimijan kuvailussa kerrotaan parametrilla kumman tyyppinen identiteetti on kyseessä (Boolean muuttuja?)


Huom!  Katso erillisellä alasivulla tarkempia esimerkkejä ja keskustelua personien ja nomenien suhteista 

Yhteentoimivuusalusta

Projektiryhmän kokouksessa manittiin, että KAM-sektorin yhteisen toimija(nimi)tietopalvelun tietomalli voitaisiin julkaista myös yhteentoimivuusalustalla, kun täällä on saman tyyppisiä tietokomponentteja.

Yhteentoimivuusalustalla on Tommin laatima Tutkimustietovarannon tutkijan tiedot ym. aiheeseen liittyvää, johon voidaan linkittää mallia rakennettaessa.

  • https://tietomallit.suomi.fi/model/ttv_tt/Tutkija/ - lisätietoja Tommi Suominen , CSC
    • tason verran abstraktimpi versio tutkimustietovarannon tietokantamallista, jota Tommi esitteli (kts. alla)
    • "Nimi"-propertyt: jhs:kokonimi, jhs:sukunimi, jhs:etunimi, jhs:etunimet, jhs:kutsumanimi, jhs:vaihtoehtoinennimi  
    • kts. myös semcerif:Researcher  , mrd:Person
      • tietomallissa tapahtumassa siirtymä entity-relationshipista linked opendataan
    • https://tietomallit.suomi.fi/model/tutkimus sisältää tietokomponentit
      • henkilö otettu JHS:stä
  • yhteentoimivuuden API: https://tietomallit.suomi.fi/model/iow/ ( Interoperability Workbench)
  • Suostumustenhallintapalvelun tietomalli: https://tietomallit.suomi.fi/model/consent/ 
  • Julkishallinnon tietokomponentit:
  • Julkishallinnon yhteinen sanasto http://uri.suomi.fi/terminology/jhs/
    • henkilö,  jhs:J754 voimassa
      • toimija, joka on ihminen
    • luonnollinen henkilö jhs:J7
      • oikeussubjekti, joka on ihminen. Luonnollisen henkilön synonyyminä käytettävää henkilö-termiä voidaan käyttää myös toimija-käsitteen alakäsitettä edustavana terminä. 
      • alakäsitteitä opiskelija, leski, asianhoitaja, haltija, oikeussubjekti, yksityinen elinkeinonharjoittaja
    • toimija,  jhs:J231 voimassa
      • Määritelmä: keskinäisessä toiminnassa mukana oleva aktiivinen osallinen, joka voidaan yksilöidä
      • Huomautus: Toimijat ovat yleensä oikeussubjekteja. Rekisteröimätön yhdistys on esimerkki toimijasta, joka ei ole oikeussubjekti.
      • alakäsitteitä henkilö, organisaatio, osallinen, palvelunkäyttäjä, palvelunantaja, asianosainen, laillinen eudstaja
    • organisaatio jhs::J132
      • Määritelmä: toimija, joka on henkilöiden muodostama yhteenliittymä ja jolla on yhteinen tavoite ja tarkoituksenmukainen rakenne
      • Huomautus: Organisaatio voi muodostua useasta eri organisaatiosta. Esimerkkinä keskusjärjestö, joka koostuu useammasta alajärjestöstä tai kansanliike, joka koostuu sekä henkilöistä että organisaatioista. Organisaatio voi olla rakenteeltaan jäsentymätön, kuten kaljakellunta tai ravintolapäivä.
      • Muutoshistoria: YSR 16.12.2016: Vanha määritelmä oli laadittu jo vuosia sitten, viittausta sosiaaliseen järjestelmään ei koettu mielekkäänä. Käsite:organisaatio haluttiin käsite:toimija alikäsitteeksi vastinpariksi käsite:henkilö:lle. Vanhasta määritelmästä säilytettiin tavoite ja rakenne.
      • alakäsitteitä ryhmä, liikelaitos, aliorganisaatio, osasto

Keskustelua

Tommi S esitteli tutkimustietovarannon tietokantamallia:

  • sisältää rahoituspäätökset
  • PIDit keskeisessä roolissa, erityisesti ORCID
  • ei identiteettitietoa vaan vain nimitieto rahoituspäätöksissä
    • jos ei ORCIDia on vain pelkkä nimi eikä muodostu identiteettiä
  • laki tutkimustietovarannosta tullee voimaan ensi vuonna
  • dim_name = identiteettömiä nimiä
    • tällaisia ilmentymismuotoa miljoonittain
    • kaksi henkilöä, jolla sama nimi, ei voi yhdistää, koska virhemahdollisuus
  • dim_known_person
    • ORCID tiedossa
    • linkitetään dim_nameen
  • dim_pid: yhden suhde moneen, henkilöllä voi olla monta tunnistetta
  • yliopisto lisää tutkijan avulla ORCIDeja useampaan teokseen
    • useampi dim_name yhdistetään dim_known_personiin
  • fact_contribution
    • taulu, joka yhdistelee tekijän tieoja
    • dim_publication_id
    • dim_name_id
    • dim_organisation_id = affiliaatio
  • Samalla id:llä voi olla useampia nimiä, ei tarvitse ottaa kantaa, mitä niistä käytetään
  • Finto päälähteenä organisaatioiden edeltäjille ja seuraajille
  • Kenneth A.: faktaa, että samoista henkilöstä tulee olemaan useampia tietueita, mutta niitä yhdistellään

Muu keskustelu:

  • Tommi: onko mahdollista, että on nimiä, jota ei linkitetä identiteettiin?
  • Piia: yksi vaihtoehto: jos tiedetään vain nimi, tehdään toimija, josta ei oteta kantaa onko todellinen/toinen identiteetti
  • Tommi: jos ei luoda identiteettiä, kun ei tiedetä henkilöllisyyttä→ ei tehdä virheitä
  • Piia loisi toimijan, mutta ei ottaisi kantaa identiteettiin
  • Mikko: kirjastossa ei tehdä auktoriteettia jokaisesta tekijästä
  • Kenneth: jos tehdään toimijatietokantaa, ei voida ulkoistaa identiteettikontrollia, kuten nyt tutkimustietovarannossa
  • Anssi: mitä toimijoita viedään, mitkä on minimitiedot?
  • Jarmo ajatellut, että kaikki tunnistetut tekijät auktorisoidaan
  • Okko: ISNI-projektissa havaittu, että mahdollisimman täydellinen metadata auttaa yhdistelemään tekijöitä. ISNIssä myös teostietoja, mutta niitä ei tässä NTP-mallissa ole
  • Tommi: Google Scholar käyttää algoritmia: kenen kanssa joku julkaisee, näillä verkostoilla käytetään todennäköisyyspohjaista vertailua
  • Jarmo: luodaan pseudonyymille myös todellinen identiteetti, kun sellainen löytyy
  • Jokaiselle (etu-, suku- ja koko)nimelle oma kohteensa?
    • Kenneth: kuulostaa tekniseltä ratkaisulta
    • Mikko: mikä toteutettavissa master-tietokannassa ja mikä kuvailujärjestelmien kannalta?
    • ylläpito?
  • Anssi: AHAA-palvelussa keskusteltua: kun arkistoon luovutettu aineisto, luovuttaja halunnut salata todellisen identiteettinsä

Päätökset

  • Miten identiteetit kuvataan NTP-tietomallissa? 
    • luodaan samaan tapaan kuin Saksan GND- ja AHAA-mallissa, joissa jokaisesta julkisesta identiteetistä laaditaan oma toimijakuvailu
    • ei oteta kantaa identiteettiin (todellinen/toinen), jos se ei ole tiedossa
  • Mitkä RDA:n nimientiteetit otetaan mukaan malliin?
    • ensisijainen nimi, varianttinimi, auktorisoitu hakutieto
    • varianttinimien eri tyypit voidaan määritellä eri propertyillä
  • Miia ja Kenneth esittelevät edellä olevat kaksi kohtaa KAM-kuvailuryhmän kokouksella 23.3.2020

Seuraava kokous

  • 28.4. klo 10-12.   Mitkä ominaisuudet muodostavat ehdottoman minimin yhteisten auktoriteettien kuvaamiseen?
  • Eli mitkä olisivat "pakolliset kentät"?  Osa näisät oliskin jo mainittuna tietomallissa (MVP, minimium viable product) 



12 Comments

  1. Marja-Liisa Seppälä

    Kannattaisin henkilö-identiteetti-nimi-ongelmavyyhdissä sitä ratkaisua, joka oli esillä jossain tietomallikokouksessamme Kansalliskirjastossa. Ratkaisussa identiteetti oli oma luokkansa, jolla olisi suhde sekä henkilöön että nimeen. Tällöin jokaiselle nimelle ei tarvitsisi määritellä, kuuluuko se todelliseen vai toiseen identiteettiin vaan suhde nimen ja identiteetin välille muodostettaisiin tarvittaessa. Ja samoin henkilön ja identiteetin välillä: identiteetin (jolla olisi suhde tiettyihin nimimuotoihin) ja henkilön välille muodostettaisiin suhde vain tarvittaessa.

    1. Jarmo Saarikko

      Voisiko tällöin "Identiteetti" olla person-luokan alaluokkana (eli perisi sen ominaisuudet)?   Pitää tutkiskella miten muissa wikibase-pohjaisissa malleissa tuo on toteutettu eli mihin RDA:n identiteettiin liittyvät propertyt on mäpätty. 

      Huom! Katsokaa alasivulla olevia esimerkkejä.

  2. Marja-Liisa Seppälä

    Identiteetti-luokalla ei tarvitsisi olla mitään muuta ominaisuutta kuin identiteetin tyyppi/kategoria, jonka arvo olisi joko todellinen tai toinen. Identiteettihän ei ole kuvailun kohteena vaan henkilö. Identiteetti on vain yksi lisänäkökulma henkilöön.

    1. Jarmo Saarikko

      yritin avata tätäkin tuolla esimerkkisivulla. 
      Uudessa RDAssahan tämä on näin: 

      •  http://rdaregistry.info/Elements/a/P50429 "real identity of person"  
      • domain: Person ja  Range: Nomen  eli henkilön property, joka liittää henkilön johonkin Nomeniin. 
      • Vastaava MARC21 Authority 500 1* $a  ; 500 0* $a

      Wikidatassa muuten on kuvailtu kukin etunimi ja sukunimi omina kohteinaan, mutta ei joka henkilön nomenia erikseen.   kts . esim. Mika Waltari: https://www.wikidata.org/wiki/Q193111  

      Samoin alkukirjaimet on kuvattu erillisinä kohteina, joihin on linkitetty esimerkiksi silloin, kun etunimi ei ole ollut tiedossa.

      Mika Waltari muualla:




    2. Jarmo Saarikko

      These differing approaches manifest throughout our processes, one example being the treatment of pseudonyms.

      • Wikipedia collects all pseudonyms together with a person's real name.
      • Libraries vary; some treat pseudonyms as separate identities and some as name variants.
      • Finally, Rights Management societies almost always treat pseudonyms as separate identities.

      ...

      Authority data have characteristics that are significantly different from other data types, and these differences make it difficult to apply models of sharing and distribution that are already
      applied to bibliographic records and documents. For example, authority data raise the following issues:

      • Name and identity ambiguity
      • Pseudonyms and hidden identities
      • Mixed identities, or single entities that describe multiple, unique entities
      • Frequent updates
        • for individuals, such as changing affiliations and life-event dates
        • for organizations, such as changing organizational structures
      • Extensive "sameAs” links, accurate or otherwise
      • Privacy requirements

      source:  National Strategy for Shareable Local Name Authorities National Forum : White Paper 2018-03-29, page 14.

      Eli tässävoi periaatteessa tehdä miten päin vaan. Kunhan valitaan yhteinen koko KAM-sektorille sopiva malli!?  Nuo mixed ja kompleksit identiteetit pitäisi myös hanskata!

  3. Jarmo Saarikko

    Katso myös LC/PCC  practice for creating NARs for persons who use pseudonyms.   https://www.loc.gov/catdir/cpso/pseud.pdf

  4. Jarmo Saarikko

    user-99b6a  kommentoi:

    Tietomallin rakenne ei ole tässä kriittisin asia. Kriittisempää on se, että malli sisältää tarvittavat tiedot/kentät ja että nämä ovat mapattavissa arkistojen käyttämiin kenttiin.  Hyvä lähtökohta on se, mikä oli aiemmassa tietomallipohjassa ja ymmärtääkseni myös nyt esillä olevassa kuvassa, että eri kuvailukohteet (toimija/identiteetti, nimi, aika, paikka jne.) kuvaillaaan omina kuvailukohteinaan ja näiden kohteiden välille voidaan lisätä erilaisia suhteita.

    AHAAssa toimija ja identiteetti voidaan kuvailla identtisellä tavalla – eli molemmissa tapauksissa on käytettävissä samat attribuutit.

    • Yhtenä lähtökohtana tässä on ollut se, että kuvailija ei välttämättä kuvaillessaan tiedä kuvaileeko hän ”henkilöä/todellista identiteettiä” vai ”toista identiteettiä”. Näin ollen ohjeena on, että kaikkia kuvailtavia toimijoita/identiteettejä käsitellään ”todellisina identiteetteinä”, kunnes  tiedossa on, että kyse on ”toisesta identiteetistä”. Tätä puoltaa myös se, että joissakin tapauksissa aineisto on syytä liittää ”toiseen identiteettiin” ja tälle toisellle identiteetille on myös tarve luoda ”todellisesta indentiteetistä” poikkeavaa kuvailua.

    • Itse näen kuitenkin tärkeänä, että edellä mainitun kaltaisissa tilanteissa voimme tuoda näkyville sen, että ”toisen identiteetin” kuvailu voi olla esim. osittain fiktiivinen ja kertoa taustalla olevan todellisen identiteetin tai todelliset identiteetit. Mielestäni identiteetti voi siis olla muutakin kuin pelkkä nimi – nomen.

    Voiko Nomen olla samalla ”toinen identiteetti” ja esim. varianttinimi on vastaus mielestäni ”kyllä”.

    • Itse asiassa mielestäni ”todellisen identiteetin varianttinimissä” tulisi esittää myös ”todelliseen identiteettiin” liitettyjen ”toisten identiteettien” kaikki nimimuodot. Toki näiden näkymisessä pitää, sitten huomioida mahdolliset näyttörajoitukset. Periaatteessa jokainen varianttinimi voi olla ”toinen identiteetti”, mutta meillä ei varmaankaan ole tarvetta kuvailla kaikkia varianttinimiä erillisinä identiteetteinä. Tarve tälle tulee silloin, kun aineisto on kyettävä liittämään johonkin ”toiseen identiteettiin”.

    Muutenkin pidän tärkeänä sitä, että olemme mappautuneet noihin standardeihin, mutta rakenteemme ei välttämättä tarvitse olla yhteneväinen standardien kanssa, kunhan voimme esittää asiat riittävän hyvin myös standardien mukaisessa muodossa.

    • Tämä tarkoittaa yksinkertaisimmillaan sitä, että nimellä voi tarvittaessa olla useita eri rooleja, joita ei standardeissa ei tunneta, mutta ne kaikki mappautuvat esim. ”varianttinimiksi”. Toimijan syntymäaika voidaan esittää täysin erillisen aikaelementin ja suhteen avulla, kunhan se voidaan kostaa näistä tiedoista standardien mukaiseen esitystapaan.

    Vastaavasti vierastan erillistä attribuuttia ”auktorisoituhakutieto”. Sen sijaan meidän tulisi muodostaa selkeä kaava siitä, minkä kenttien yhdistelmästä tuo auktorisoituhakutieto koostuu

    1. Jarmo Saarikko

      • Jarmo Saarikko vastaa: 
        • Alustava näkemykseni tähän on ollut se, että tällainen property ja sen viittaama merkkijono (Nomen) voitaisiin muodostaa automaattisesti juuri noin eli muiden kenttien pohjalta silloin, kun järjestelmä löytää kaksi identtistä identiteettiä/henkilön ensisijaista nimeä. Tämä on olennainen kenttä kirjastopuolella. Sama tilanne, jos tällainen property oli jo olemassa ja löytyy uusi identtinen auktorisoitu hakutieto toisen auktorisoidun hakutiedon kanssa. 
        • Tämä propertyn voisi luoda esimerkiksi Wikibaseen sijoitettu Botti joka täydentäisi tietoja henkilön/identiteetin eri propertyistä ennalta määriteltyjen toimijakuvailun sääntöjen perusteella, kunnes nimet ovat erilaisia. Tällöin kuvailussa luodut käytettävät nimet eivät muuttuisi, mutta syntyisi uusi yksilöllinen tälle henkilölle/identiteetille kuuluva merkkijono.
        • Jokaisella identiteetillä olisi vähintään ensisijainen nimi.  Kaikkia nimiä ei auktorisoida.  Marja Liisan mukaan henkilöllä voi olla vain yksi auktorisoitu hakutieto. Toisaalta, jos identiteetit kuvataan samaan luokan kohteina, niin silloin kullakin identiteetillä olisi myös auktorisoitu hakutieto.
        • Ensisijainen nimi ei välttämättä ole sama kuin auktorisoitu hakutieto. Vasta tämä jälkimmäinen olisi se, joka erottaa identiteetit muista identiteeteistä.    
        • Tulkintani edellisestä: Voitaisiin ajatella, että nimen ”auktorisointi” tapahtuu silloin, kun siitä muodostetaan järjestelmään oma identiteetti.
      • Jarmo Saarikko Kysymys kokoukselle oli, pitääkö kaikki nimet liittää johonkin henkilön identiteettiin?  
        • Luodaanko tällöin henkilölle kuitenkin aina myös "todellinen identiteetti", vaikka sitä ei näytettäisi (esim. koska kirjoittaja ei ole käyttänyt sitä julkaisuissa tai ei halua sen näkyvän)?  Joskus auktorisoidaan vain pseudonyymi (toinen identiteetti) ja henkilön todellinen nimi jää sen varianttinimeksi.

      1. Jarmo Saarikko

        user-99b6a vastaus:

        • pitää. Tässä on ehkä yksi ydinkysymys ainakin koko palvelun nimenkin suhteen. Itse olen mieltänyt ja alkuperäistä tietomallipohjaa tehdessä lähtenyt siitä, että kuvailemme toimijoita ja myöhemmin tarkentuneena heidän identiteettejään. Näin ollen nimet liittyvät aina johonkin toimijaan. Ne voivat liittyä toimijaan joko suoraan tai toimijan jonkin identiteetin kautta. Mikäli järjestelmässä on nimiä, jotka eivät liity mihinkään toimijaan tai identiteettiin, eivät ne silloin kuvaile tomijaa tai identiteettiä. Sinänsä en tämä mielestäni ratkeaa sillä tavalla, että nuo nimet tulkitaan ja kuvaillaan joko toimijana tai identiteettinä ja kaikki tulkitaan toimijoiksi, jos ei ole tiedossa, että ne ovat ”toisia identiteettejä”.

        • Itse loisin noissa pseudonyymitilanteissa myös todellisen identiteetin ja tarvittaessa rajoittaisin näiden suhteen näkymistä. Aineisto liitetään siihen identiteettiin, johon sen liittäminen on mielekkäintä tehdä.

  5. Jarmo Saarikko

    Tässä vielä user-ad065 kommentit, jotka ehdin lukea vasta kokouksen jälkeen:

    • Että näen (ehkä vajavaisesti..) itse sen nomenin käytännössä vain merkkijonona joka tässä tapauksessa viittaa henkilöön. Siten en toisi noita identiteettejä mukaan personin ja nomenin välisiin suhteisiin vaan käyttäisin mahdollisuutta käyttää sitä ylempää suhdetta "henkilöön liittyvä nomen", "related nomen of person" jolloin nimet olisivat vai nimiä ja se onko personilla given identity vai acquired identity (tai että sitä ei olisi kuvailussa määritetty) määrittäisi toimijan identiteetin luonteen.  Ja edelleen se mihin aineistoon tmv. toimija on liitetty puolestaan sen mitä identiettiä milloinkin käytetään liitettynä kuvailuun
    • Ensisijainen nimimuoto saa RDA:n mukaan olla myös application-kohtainen ja kannatan myös tuota auktorisoidun hakutiedon luomista automaattisesti joidenkin sääntöjen perusteella- ehkä vielä siten että toimijan eri identiteetit olisivat auktorisoituja.. sitten taas jos vain yksi identiteetti valitaan auktorisoinnin kohteeksi niin silloinhan muut identiettetit tulisi olla mahdollista saada esiin myös tästä .. jolloin niiden paikka kai periaatteessa olisi varianttinimissä- tosin eri identiteeteillä voisi olla toisistaan poikkeavia käyttöajankohtia yms. Ongelma avarmaan kuitenkin muodostuu silloin kun auktorisoitu hakutieto on käytännössä julkinen identiteetti, mille ei sinänsä voida antaa esim. elinvuosia.

    1. Jarmo Saarikko

      tässä vielä kommenttejani vielä kokouksen jälkeen:

      Kohtaan 1. 

      • Oletko smaaa mieltä, että siis tuo "aquired identity" viittaa siis Person-luokan kohteesta toiseen Person-kohteeseen?  Siis kuten GND:n  :pseudonym? 
      • Mikäli henkilöllä on käytössä vain pseudonyymi (identieetti) ja se kuvaillaan, niin tämä tieto pitäisi jossakin propertyssä kertoa.  Henkilön todellinen nimi (jos on tiedossa) on kuvaillun henkilön identiteetin varianttinimi.  Tämä vaatisi henkilölle erillisen propertyn, joka kertoo, että tämä identiteetti ei ole henkilön todellinen identiteetti.

      Kohtaan 2. 

      • Kullakin henkilöllä (tai identiteetillä) tulisi olla uniikin URI-tunnisteen lisäksi myös yksi uniikki merkkijono (Nomen) eli tuo <auktorisoitu hakutieto>.
      • Henkilön (tai identiteetin) <käytettävä nimi> ja <auktorisoitu hakutieto> propertyt voivat viitata samaan merkkijonoon, jos se on uniikki. 


  6. Marja-Liisa Seppälä

    Tässä vielä kokouksen jälkeinen kommentti (en pystynyt osallistumaan kokoukseen 13.3.2020):

    Tässä kokouksessa tehty ratkaisu tarkoittaa uuden RDA:n kannalta, että henkilön toinen identiteetti on toinen henkilö, sillä uudessa RDA:ssa on vain vaihtoehdot henkilö-entiteetti tai nomen-entiteetti. Henkilöiden välille ei ole RDA:ssa suhdetta, joka kertoisi niiden olevan sama henkilö, mutta tämä varmaan saadaan hoidettua tietomallin omilla suhteilla.

    RDA:n kannalta on hyvä, että toinen identiteetti on melko harvinainen kuvailun kohteena. Suurin osa kuvailtavista henkilöistä on todellisia henkilöitä ja näin yhtenä entiteettinä tietomallissa.