Page History

...

• Tarkenteet eri lehdelle taulukkoon? Voidaan siirtää omalle välilehdelle
• Propertyjen tasot
  • 0 core (kaikille yhteiset pakolliset)
  • 1 (kaikille yhteiset)
  • 2 (avoimet sektorikohtaiset elementit)
  • 3 (vain yhden sektorin elementit)
• Pakollisuus tähän verrattuna?
• tietomallissa pakollisuus nimi ja tunniste, ydintason eli 0-tason pakollisuus on toinen
• Tasoja tulee yksi lisää ydintason yläpuolelle
• ToiKu-verkosto käsittelee pakollisuudet tammikuussa
  • suurin osa jo määritetty ydinpakollisuuksiksi, muutama perustason pakollisuus
  • kesään mennessä tasot varmistuvat lopullisesti
  • Jos Nimitietopalvelu ei jatka, niin ToiKussa voidaan taulukon ydinelementit käsitellä loppuun
• RDA-ydinelementit pakollisia?
• Onko pakollisuus kaikille pakollista (0 taso) vai sektorikohtaista?
• pakollisia elementtejä?
  • nimi, tunniste (vai tunnus?), ajanjaksot
• Toistettavuus
  • käytiin läpi toistettavuudet
    
    • yhteisön tyyppi
    • yhteisön toiminta-aika
    • toistettavuudet ToiKun listauksen mukaan
    • mallissa ominaisuus voi olla toistettava vaikka kuvailusäännöissä ei
      • ei-toistettava elementti yksittäisessä järjestelmässä voidaan merkitä lähdeviitteellä: jos yhteisessä järjestelmässä elementtiä toistetaan, tieto voidaan palauttaa samaan elementtiin
  • esim. yhteisön tyyppi
    • tavoitteena karkeampi jaottelu, jota tarkennetaan toimialatiedolla?
• Nimet
  • varianttinimet
    • puretaanko osiin (MARC-datassa voi olla kaksi identtistä a-osakenttää)?
    • Voiko sisältää muuta tietoa, kuten vuosilukuja ja arvonimiä (onko kyseessä varianttihakutieto)?
    • Arkistoissa ensisijainen nimi ja varianttinimi kahteen kentään jaettu, siirtotiedostoissa vaihtoehtona yhdessä tai kahdessa osassa
    • Museoissa varianttinimi yhdessä kentässä eikä säännönmukaisessa järjestyksessä etu- ja sukunimen osalta
  • henkilön etu- ja sukunimi erillisinä propertyinä vai nimien tarkenteina?
    • yritetäänkö myös varianttinimet jakaa etu- ja sukunimiin?
    • Etu- ja sukunimet tarkenteina, jos tietoa ei ole, tarkenteita ei voi käyttää
  • yhteisön ensijaisen nimen ja varianttinimen ilmaiseminen
    • puretaanko osiin ja miten, jos hierarkian tasoja nimessä (esim. yliopisto-tiedekunta-laitos)?
      • Kattoyhteisön nimi toistettava (järjestysnumero property määrää hierarkian), jos alayhteisön nimi on kuvailta kohde?
        • näistä yhdessä muodostuu ensisijainen nimi vai alayhteisön nimi on ensisijainen nimi?
      • onko museoilla ja arkistoilla yhteisöjä, joissa on kolme tai enemmän hierarkian osaa?
  • PäätösetPäätökset:
    • ensisijaiseen nimeen tarkenteeksi museon osasto, kirjaston osalta eri nimenosat auktorisoituun hakutietoon
    • varianttihakutieto uudelleen käyttöön tämän ratkaisuksi, vaikka tämä ajatus hylättiin projektin alussa
• museoiden ”tyyli” + kirjastojen ”toimiala” ohjautuvat nyt samaan ominaisuuteen?
• 372-kentissä muutaman kerran tyylisuuntaus, kuten barokki, mutta 
• tyylin ja toimialan sekoittaminen olisi varmaan todella ongelmallista
• ehdotus: erilliset property
  • ehdotus hyväksyttiin
• relaatiot
  • merkitäänkö Metatietosanaston/Agrelonin relaatiot omina propertyinä mappaustaulukkoon?
    • voidaan lisätä malliin, kun otettu Metatietosanastoon
• auktorisoinnin taso, tarkkuus ja tila - tarvitaanko näitä?
  • RDA-elementti tunnistamistaso on tällä hetkellä pakollinen perustason kuvailussa
  • liittyy uudessa RDA:ssa nomenin määrittelyyn, ei tarvitse merkitä tässä vaiheessa
• Voidaanko luokkien ja propertyjen tila ilmaista seuraavasti:
  • esim. http://metadataregistry.org/concept/list/vocabulary_id/31.html ”RegStatus”: Proposed, Under Review, Approved, Published, Deprecated
    • merkintätapa hyväksyttiin

...