Publicerat

Under hösten 2011 utvecklades K-samsök i en version 1.1. Fokus låg på att vidareutveckla protokollet så att det på ett smartare sätt stödjer webbsemantik och bredda K-samsök för att kunna hatera flera typer av information, bl a kring personer och händelser. Den nya protokollet är framtaget av Riksantikvarieämbetet i nära samverkan med de institutioner som hittills levererar data till K-samsök. Nedan följer de ändringar som gjorts.

Än så länge återstår uppdatering av dokumentationen samt de engelska sidorna.

Läs mer om ändringar i K-samsök 1.0 till 1.1 (pdf)

Objekttyper (itemType)

För att gruppera objekttyperna har en övergripande typ införts (itemSuperType) som är obligatorisk. Den är en URI som itemType och måste ha något av värdena (prefixat av http://kulturarvsdata.se/resurser/EntitySuperType#):

Nya superobjektstyper (itemSuperType)

  • Agent (agent)
  • Fysiskt ting (object)
  • Händelse (event)
  • Koncept (concept)

Alla pre-1.1-objekttyper hamnar i strukturen under Fysiskt ting.

Nya objektstyper (itemType)

  • Karta (map)
  • Kulturlämning (monument)
  • Byggnad (building)
  • Person (person)
  • Organisation (organization)
  • Grupp (group)
  • Historisk händelse (event)
  • Utställning (display)
  • Koncept (concept)

Förändrade objektstyper

  • Objekttypen Objektavbildning (objectImage) har utgått
  • ”Miljö” (site) har delats upp i tre delar: Byggnad (building), Kulturlämning (monument) och Kulturmiljö (culturalLandscape). Miljö finns kvar till vidare för bakåtkompatibilitet.

De nya objekttyperna har som tidigare prefixet http://kulturarvsdata.se/resurser/EntityType#. K-samsök kräver i o m version 1.1 att itemType verkligen är någon av de definierade typerna för att en post ska godkännas vid skördnig till K-samsök.

RDF-resurser för itemType och itemSuperType kommer finnas att läsa här.

Agenter

Eftersom Agenter är aktörer (omfattar både personer, organisationer och grupper) finns behov av kontexter som hanterar liv, verksamhet och död. Kontexterna har ändrats till att bli mer allmängiltiga create-interaction-destroy (med underkategorier), för att underlätta detta. Det finns också behov av flera olika nya relationer med anledning av de nya objektstyperna t.ex. för att beskriva släktskap. Dessa listas nedan.

För agenter har nya fält tillkommit på toppnivån. Det handlar om:

  • name
  • gender
  • title
  • nameAuth
  • nameId
  • firstName
  • surname
  • organization.
  • fullName

Samtliga tillägg är från foaf som har använts i tidigare protokollversioner (ex http://xmlns.com/foaf/0.1/#name).

Event

Event är händelser av makro-karaktär, som historiska händelser, bröllop, slag, utställningar etc som är avgränsningsbara i tid och rum. De ska inte blandas ihop med kontexterna som är händelser i ett enskilt objekts livscykel.

Koncept

Koncept (SKOS Concept) är företeelser som inte är avgränsningsbara i tid och rum. T ex Vikingatid, Stormaktstid, Sjöfart etc. Dessa objektstyper används huvudsakligen för att göra mappningar från museer med ett visst ansvarsområde (t ex Historiska museet=Medeltid/förhistorisk tid). Koncept kopplas med fördel direkt mot Wikipedia.

 

Kontexttyper (contextType)

I o m version 1.1 har kontexttyperna förändrats. Precis som för objekttyperna så har en obligatorisk supertyp (contextSuperType) införts för de generella (prefixat av http://kulturarvsdata.se/resurser/ContextSuperType#):

  • Skapa (create)
  • Interagera (interact)
  • Upphöra (cease)

Kontexttyperna som tillkommit och avskaffats är:

Tillkommit

  • Starta (start)
  • Designa (design)
  • Producera (produce)
  • Visa (display)
  • Verka (act)
  • Avföra (dismiss)
  • Avsluta (stop)

Andra förändringar

  • Belägen (exists) har avskaffats.
  • Fotograferad (reproduced) har blivit Reproducerad (reproduce)
  • Tillverkad (create) har flyttat till att bli en supertyp.
  • Förstörd (destroyed) har övergått till supertypen Upphöra (cease)

ContextLabel har förändrats, iom 1.1 indexeras alltid en inskickad contextLabel om den finns istället för rdf-resursen. Värden för contextType (och contextSuperType) måste vara enligt standardiserad värdemängd för att poster ska indexeras.

RDF-resurser för contextType och contextSuperType finns här.

Relationer

Några nya relationer har tillkommit på toppnivå, dvs mellan objekt. De flesta har att göra med de nya objekttyperna.

Nya relationer

  • isMentionedBy /nämns av (k-samsöks NS)
  • mentions/nämner (k-samsöks NS)
  • child/förälder till (BIO, prefix http://purl.org/vocab/bio/0.1/)
  • parent/barn till (BIO)
  • mother/har mor (BIO)
  • father/har far (BIO)
  • P12F.occurred_in_the_presence_of/händelsen skedde i närvaro av (CIDOC-CRM, prefix http://www.cidoc-crm.org/rdfs/cidoc-crm#)
  • P12B.was_present_at/var närvarande vid händelse (CIDOC-CRM)
  • P11F.had_participant/händelsen hade deltagare (CIDOC-CRM)
  • P11B.participated_in/deltog i händelse (CIDOC-CRM)
  • P107B.is_current_or_former_member_of/är eller var tidigare medlem i (CIDOC-CRM)
  • P107F.has_current_or_former_member/har eller hade medlem (CIDOC-CRM)

Notera att CIDOC-CRM-relationernas index/värden inte har med P-prefixet, utan bara namnet, t ex was_present_at.

Roll-relationer

Ett antal nya relationer som utgår från kontexten och som pekar på agenter har också tillkommit i k-samsöks NS och från CIDOC-CRM. Nya kontext-/roll-relationer är (i k-samsöks NS om inget annat anges) :

  • Beställare (client)
  • Kompositör (composer)
  • Författare (author)
  • Arkitekt (architect)
  • Uppfinnare (inventor)
  • Scenograf (scenographer)
  • Designer (designer)
  • Producent (producer)
  • Arrangör (organizer)
  • Regissör (director)
  • Fotograf (photographer)
  • Målare (painter)
  • Byggare (builder)
  • Byggmästare (masterBuilder)
  • Byggherre (constructionClient)
  • Gravör (engraver)
  • Myntmästare (mintmaster)
  • Konstnär (artist)
  • Konstruktör (designEngineer)
  • Snickare (carpenter)
  • Murare (mason)
  • Tekniker (technician)
  • Förläggare (publisher)
  • Publicist (publicist)
  • Musiker (musician)
  • Skådespelare (actorActress)
  • ryckare (printer)
  • Påskrift av (signer)
  • Upphittare (finder)
  • Förvärvare (abandonee)
  • Förmedlare (intermediary)
  • Köpare (buyer)
  • Säljare (seller)
  • Generalagent (generalAgent)
  • Givare (donor)
  • Deponent (depositor)
  • Återförsäljare (reseller)
  • Inventerare (inventoryTaker)
  • Grävare (excavator)
  • Undersökare (examinator)
  • Konservator (conservator)
  • Arkivbildare (archiveContributor)
  • Intervjuare (interviewer)
  • Informant (informant)
  • Patentinnehavare (patentHolder)
  • Brukare (user)
  • Skanneroperatör (scannerOperator)
  • Bildredaktör (pictureEditor)
  • Arbets- eller uppdragsgivare (employer)
  • Har nuvarande eller tidigare förvaltare (P49F.has_former_or_current_keeper CIDOC-CRM)
  • Har nuvarande eller tidigare ägare (P51F.has_former_or_current_owner CIDOC-CRM)
  • Skapades av (P94B.was_created_by CIDOC-CRM)
  • Rättigheter ägs av (P105F.right_held_by CIDOC-CRM)

Notera att CIDOC-CRM-relationernas index/värden inte har med P-prefixet, utan bara namnet, tex was_created_by. Notera också att fn kan man bara ange dessa relationer utgående från kontextet, och inte från ”andra hållet” från den utpekade agenten.

”Kontextindex” med typ och supertyp

Nytt är också i o m införandet av kontextsupertyper att ”kontextindex”, dvs tex use_fromTime även bildas med supertypen. Om ett fromTime-värde finns i ett kontext där kontexsupertypen är ”create” och kontexttypen är ”start” så kommer värdet indexeras i både create_fromTime och start_fromTime.

10 kommentarer

  1. När kontexttypen exists är borttagen, hur representerar man då en fornlämnings belägenhet?

  2. Bra fråga! För att lägesbestämma en fornlämning eller byggnad använder du superContextType ”create” och contextType ”produce” och använder placeLabel som tidigare.

    /Johan Carlström

  3. Hej,

    1.1 ser väldigt intressant ut för oss applikationsutvecklare! Jag har en fråga: Om jag i min applikation visar data från K-samsök, t.ex. en person och dennes relation till en händelse, plats eller annan person, och de användare (t.ex. en släktforskare eller historieforskare) som brukar min tjänst påstår att något av en relation/entitet från K-samsök är felaktig – hur tar K-samsök emot ett sådan korrigering? Finns det en sådan möjlighet överhuvudtaget? Om så, vad gör ni med en sådan korrigering? Sprids denna korrigering till andra K-samsök tjänster och/eller till era innehållsleverantörer?

    mvh,

    /per

  4. Hej Per

    Vi har idag inget bra sätt att hantera fel-rapporter. De relationer som sätts är de som finns i respektive käll-databas och/eller anges i mappningen mot K-samsök. Det finns dock en möjlighet att komma åt kontaktuppgifter till institutionen som levererat informationen via api-metoden http://www.ksamsok.se/api/metoder/#getServiceOrganization (den är i behov av uppdatering ser jag nu).

    Säg till om du/ni vill ha en API-nyckel att labba med.

    /Johan Carlström

  5. Johan,

    1. Men jag har hört att ni jobbar på sk UGC-hubbar (User Generated Content) eller snarare UCC-hubbar (User Corrected Content) till vilka användaren till en applikation kan korrigera data som sedan görs tillgänglig till andra användare av K-samsök (även om detta kanske inte går ända fram till käll-databasen). Stämmer detta?

    2. Om inte, antar jag att jag som applikationsansvarig själv får spara korrigerat/nyskapat data/relation i min tjänst, eller hur? Frågan är bara hur jag på bästa sätt delar ut detta data till andra historie-intresserade (jag skulle vilja optimera öppenheten av mitt data)? Skulle K-samsök överväga att ta in en sådan tjänst som en av sina datakällor (och på så sätt tillgängliggöra korrigerat/nyskapat data till användare av K-samsök)?

    mvh, Per

  6. Det stämmer, den UGC som skapas i Kringla idag sparas i en separat databas via ett API som kan både läsa och skriva. Än så länge är den väldigt alpha. Syftet är att möjliggöra samlandet av all UGC (taggar, länkar, geotaggar, kommentarer) som har K-samsökskoppling på ett ställe. Denna data går idag dock inte tillbaka till respektive institution.

    Vi kommer att jobba mer med UGC-hubben i höst och är såklart öppna för önskemål och krav.

    >>Johan Carlström – systemansvarig

  7. Pingback: Anonym 768769
  8. Jag är gärna med i kravarbetet för UGC-hubbarna i höst! Kommer UGC-hubbarna att tillåta skapandet inte bara av kopplingar, taggar av existerande poster, utan även att man kan skapa nya poster, t.ex. nya agenter och event?

  9. Kul att du är intresserad. Tanken är att UGC ska utgå ifrån de objekt som finns i K-samsök, i alla fall i dagsläget.

    /Johan

  10. Pingback: Anonym 768772

Lämna ett svar

Din e-postadress kommer inte publiceras. Obligatoriska fält är märkta *