Versions Compared

Old Version 42

changes.mady.by.user Unknown User ([email protected])

Saved on

compared with

New Version 43

changes.mady.by.user Unknown User ([email protected])

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

DC-kenttäSelite
 

Pohdittava: dc.type-kentän tarkenteiden lisääminen omiksi sivuikseen vai lisätietona yläsivulle? Esim. dc.type.coar.

  • Type-kentästä käytetyistä aineistotyypeistä tehtävä listaus ja koottava julkaisuarkistojen kanssa yhdessä lista suositeltavista termeistä, koska nyt kentän käyttö on melko kirjavaa.
dc.contributor.groupauthor

Yhteisötekijä tai ryhmä julkaisun tekijänä

Yhteisötekijän nimen voi tallentaa tähän kenttään, jos halutaan erotella yhteisötekijät (organisaatiot, työryhmät) ihmistekijöistä tilastoinnin tai jonkin muun syyn vuoksi. Muussa tapauksessa kaikki tekijät voidaan tallentaa dc.contributor.author-kenttään. Toistettava kenttä.

Huomioita: Esimerkiksi julkaisuarkiston etusivun selailulistaukset voivat näyttää erikoisilta, jos tekijäselauksessa on mukana paljon organisaatioita tai työryhmiä.

dc.coverage.spatial

Kattavuus (paikka)

  • YSO-paikat, jotta konteksti löytyy helposti (mahdollisimman tarkka paikka olisi hyvä)
  • Historialliset paikat (SAPO? Suomalainen Ajallinen PaikkaOntologia)
  • Kansainvälisiä suosituksia?
  • Koordinaatit
  • Ohjeistus tehtävä, jossa suositellaan ontologioiden tai yhteisesti sovittujen muotoilujen käyttöä
  • Pystyykö DSpace tekemään näistä klikattavia linkkejä esim. Fintoon?
  • Finnalla saattaa olla käyttöä näille tiedoille
dc.coverage.temporal

Kattavuus (aika)

Julkaisun ajallinen kattavuus, kuten vuosikymmen, vuosisata tai ajanjakso, jota julkaisu käsittelee. Suosituksena on tallentaa ajanjaksot numeroin, esim. 500-1400; ei 1980-luku, vaan 1980-1989. Ajanjaksojen nimitykset tulee tallentaa dc.subject-kenttään, esim. renessanssi, keskiaika, antiikki. Jos ajallista kattavuutta ei tiedetä tarkasti, voi tallentaa arvion aikavälistä. Älä käytä katkaisumerkkejä.

  • Ohjeistus tehtävä, jossa suositellaan ontologioiden tai yhteisesti sovittujen muotoilujen käyttöä
  • Kysy Juhalta lisätietoa kuinka ajanjaksot pitäisi merkitä standardin mukaan!
  • Pystyykö DSpace tekemään näistä klikattavia linkkejä esim. FintoonTarkista suositus DCMI:ltä?
  • Finnalla saattaa olla käyttöä näille tiedoille
dc.description.editionPainosmerkintä, jos sellainen on tarpeen merkitä, esim. 2. painos, erikoispainos, juhlapainos. Painostieto tulee tallentaa metadataan niin kuin se on merkitty julkaisuun.
dc.description.provenance

(Kentän nimi: provenienssi-/alkuperätieto?) Tieto tallentuu DSpacessa, mutta on piilotettu tietosuojan(?) vuoksi. Kirjautuneille käyttäjille näkyvissä.

  • Kentän voi lisätä suositukseen, mutta selitteeseen on täsmennettävä käyttöä
  • Yksinkertaisuuden vuoksi jätetään pois suosituksesta toistaiseksi
dc.identifier.doi

DOI-tunnus

Julkaisuarkistoon tallennetun teoksen pysyvä DOI-tunniste. HUOM: Muualle kuin omaan julkaisuarkistoon viittaava DOI-tunniste tallennetaan dc.relation.doi-kenttään.

Huomioita: Pääosa kotimaisista julkaisuarkistoista käyttää URN-tunnuksia, DOI-tunnukset viittaavat useimmiten muualle tallennettuun julkaisuun.

dc.relation.funder

Rahoittaja

  • Suosituksena esim. Finton yhteisönimet
  • Entä kielivaihtoehdot ja kansainväliset rahoittajat?
dc.relation.url?

Muu verkko-osoite

Kustantajan tai muun organisaation tietokantaan tallennetun (alkuperäis)julkaisun verkko-osoite. Toistettava kenttä.

  • tarkenteeksi tässä käyttötarkoituksessa .url voi olla harhaanjohtava, olisi hyvä keksiä kuvaavampi vaihtoehto.
  • pitääkö kaikilla erilaisilla tunnisteilla/verkko-osoitteilla olla oma relation-kenttänsä vai voisiko käyttää samaa?
dc.relation.urn?

Muu URN-tunnus / Muu pysyvä tunnus?

Toisen organisaation julkaisuarkistossa käytössä oleva julkaisun URN-tunnus. HUOM: Pidettävä huolta, ettei tunnus resolvoidu oman julkaisuarkiston URN-tunnukseksi ja näin "kaapata" julkaisua toiselta organisaatiolta. Toistettava kenttä.

  • tarkenteeksi tässä käyttötarkoituksessa .urn voi olla harhaanjohtava, olisi hyvä keksiä paremmin tilannetta kuvaava vaihtoehto
  • pitääkö kaikilla erilaisilla tunnisteilla/verkko-osoitteilla olla oma relation-kenttänsä vai voisiko käyttää samaa?
dc.rights.copyright

Muu tekijänoikeustieto

Muu selite pääsyoikeudesta, esimerkiksi kustantajan vaatima tekijänoikeustieto: © [kustantajan nimi]. Toistettava kenttä.

  • erillinen kenttä koska dc.rights.accessrights on varattu DSpacen sisäiseen pääsyoikeustehtävään. Lisätietoja Samulta
dc.subject.communityname (cn)

Yhteisönimet (Samu taitaa tietää tästä enemmän). Liittyy järjestelmään, ei oteta yleiseen suositukseen.

  • Suosituksena esim. Finton yhteisönimet
    • Entä kielivaihtoehdot ja esim. kansainväliset yhteisönimet?

     

     

     

     

     

    [LISÄTTY SUOSITUKSEEN] Tiedekunta, laitos, oppiaine ym. kentät – ehdotuksia mahdolliselle käytölle, yhtenäisyyden vuoksi kenttä voi olla kaikissa vaihtoehdoissa contributor- tai subject-alkuinen.

    ...

    DC-kenttäSyy korjaukseen
    dc.contributor.organization

    Muuta otsikko: Opinnäytteen tai julkaisun tekopaikka

    dc.identifier.[tunnisteen lyhenne]

    Selitteen korjausehdotus:

    Julkaisuarkistoon tallennetun teoksen pysyvä tunniste, kuten DOI, Handle tai URN. Jos pysyvää tunnistetta ei ole, teoksen URI tallennetaan dc.identifier.other -kenttään. Tunnisteet voidaan tallentaa dc.identifier.other -kenttään myös, jos ei ole tarvetta tarkentaa mistä tunnisteesta on kyse.

    Huomioita: Kokonaisten verkko-osoitteiden tallentaminen DOI:n tapauksessa aiheuttaa teknisiä ongelmia DSpace-julkaisuarkistoissa, pelkän numero-osan tallentaminen toimii paremmin.

    • Verkko-osoitetta ei saisi sotkea tunnisteisiin. Mutta tunnisteet tulisi tallentaa kokonaisina verkko-osoitteina (uusi suositus, Jyrki Ilva tietää tarkemmin). Uuden suosituksen mukaan DOI-tunnisteet pitäisi ORCID:ien tapaan ilmoittaa kokonaisina verkko-osoitteina.
    • Kokonaisten verkko-osoitteiden tallentaminen DOI:n tapauksessa aiheuttaa teknisiä ongelmia DSpace-julkaisuarkistoissa, pelkän numero-osan tallentaminen on parempi (viesti Samulta myöhemmin)

    dc.identifier.isbn,

    dc.relation.isbn,

    dc.relation.isversionof

    Kirjaa kenttään pelkkä tunnus ilman lyhennettä "ISBN". Numerotunnus mahdollisuuksien mukaan väliviivoineen, muussa tapauksessa yhtenä numerojonona, ilman välilyöntejä tai väliviivoja.

    • Tunnuksen perään voi relation-kentissä tallentaa aineistomuodon sulkeissa, jos niin haluaa. Esim. (epub), (painettu) jne.
    dc.identifier.uri

    Kentän korjausehdotus:

    Uniform resource identifier
    Julkaisuarkistoon tallennetun teoksen URI. URI:lla ei tässä metadatasuosituksessa ole tunnisteroolia, vaan se toimii vain osoitteena.

    Huomioita: Liittyy DSpace-järjestelmään, tarkennetta ei pysty vaihtamaan.

    • Koska URI on W3C:n katsannossa sekä tunniste, että verkko-osoite, molemmat tiedot pitäisi mainita selitteessä.
    • Mietitään vielä riittääkö yllä oleva lisäys uri-tarkenteen käyttöön (tarkenne näyttää olevan laajasti käytössä julkaisuarkistoissa)
    •  
    dc.rights.accessrights

    Ehdotus ohjetekstiksi:

    Pääsyoikeustieto, jos kuvailun kohteena olevaan tiedostoon pääsyä on rajoitettu. Rajoitus voi perustua esimerkiksi autentikointiin, käytetyn koneen IP-osoitteeseen, maksullisuuteen tai muuhun vastaavaan. Esimerkki arvosta: ”Pääsy aineistoon rajattu, käyttö vain [nimi] kirjaston tiloissa.”

    • Suositukseen tehty laajennus pois, perusteena kenttään tallennetun tiedon käyttö Finna-rajapinnassa käyttörajoituksen ilmaisemiseen
    • Kysyttävä lisätietoa Samulta ja finnalaisilta, onko suositeltavia arvoja kentän sisällöksi? Ei ole olemassa virallisia ohjeita, jokainen organisaatio määrittelee pääsyrajoituslauseen itse
    • Riittää että kenttä on käytössä, tekniikka hoitaa DSpacessa/Finnassa loput
    dc.rights.uriurl

    Kentän korjausehdotus:

    Tekijänoikeus-/käyttöoikeussivun URIverkko-osoite
    Tallennetun teoksen käyttöoikeuden/lisenssin mahdollinen URI. URI:lla ei tässä metadatasuosituksessa ole tunnisteroolia, vaan se toimii verkko-osoitteena.

    Koska URI on W3C:n katsannossa sekä tunniste, että verkko-

    osoite

    , molemmat tiedot pitäisi mainita selitteessä

    .

    Mietitään vielä riittääkö yllä oleva lisäys uri-tarkenteen käyttöön (näyttää olevan laajasti käytössä julkaisuarkistoissa)

    • Suositellaan tulevaisuuden varalle verkko-osoitteen tallentamista tähän kenttään

    ...