Page MenuHomePhabricator

Evighetsrunor / “Everlasting Runes”
Open, LowPublic

Assigned To
None
Authored By
Salgo60
Nov 21 2020, 12:48 PM
Referenced Files
F33945930: image.png
Dec 15 2020, 1:47 AM
F33944794: image.png
Dec 13 2020, 12:11 PM
F33942638: image.png
Dec 11 2020, 8:29 AM
F33941274: image.png
Dec 9 2020, 10:43 PM
F33941217: image.png
Dec 9 2020, 9:52 PM
F33940821: image.png
Dec 9 2020, 1:36 PM
F33940820: image.png
Dec 9 2020, 1:36 PM
F33940822: image.png
Dec 9 2020, 1:36 PM
Subscribers

Description

Task: get better data to Wikidata about Runes see Wikidata:Property_proposal/Evighetsrunor

  1. approach 1 link a new app Evighetsrunor - challenge not all data available easy
  2. approach 2 use Rundata all data available in Excel but also rather messy data and no semantic interoperability with Evighetsrunor or Wikidata

Status: stalled... see
Wikidata project WikiProject_Sweden/Runic_inscription
Discussion sv:Wikipedia Bybrunnen

Open issues:

  • do we need a new WD property for “Everlasting Runes”
  • K-samsök has some data but to add value to Wikidata we need an API to Evighetsrunor as K-Samsök has less data and looks like bad quality (they send strings Evighetsrunor -> K-samsök)
  • can we use RUNDATA all data available in Excel but rather messy data and also no semantic interoperability with Wikidata or Evighetsrunor

The goal I guess for step 1

image.png (1×2 px, 1 MB)

image.png (1×2 px, 163 KB)

image.png (1×2 px, 216 KB)

image.png (630×2 px, 114 KB)

  • easy create links from an article in sv:WIkipedia about a Rune using a template -> Evighetsrunor swedish
  • easy create links from an article in en:WIkipedia about a Rune using a template -> Evighetsrunor english

Event Timeline

Try to explain why we dont want to use ksamsök

Tackar för svar..... lite synpunkter. Vi vill ha något som löser behovet att peka på en runa hos Evighetsrunor och undvika alla dom problem vi har med ksamsök

Som jag skriver ned så känns det att ni inte ens internt pushar för ksamsök exempel nedan med nya fornsök vilket gör det ännu mer udda att vi som externa som inte har tillgång era interna databaser, helpdesk skall gå omvägen via ett lager som inte tillför något för oss i detta användarfallet.....

a) Signum ej unika
Om nu inte era Runsignum är persistenta och unika kan ni inte bara ha en redirect om ni byter namn? annars är min erfarenhet att det är enklare att köra igenom alla kopplingar till runstenar och se om sidan finns och sedan korrigera det manuellt.... Ksamsök fungerar inte i praktiken se nedan...

Den form vi vill ha är formatterings-url se hur Alvin ser ut
ex. http://www.alvin-portal.org/alvin/view.jsf?pid=$1

där $1 är det unika persistenta

exempel alvin-record:370850 --> http://www.alvin-portal.org/alvin/view.jsf?pid=alvin-record:370850

Exempel lista med länkröta Wikipedia har med ksamsök > 4800 filer

b) K-samsök URI Property 1260 problem vi ser
Swedish Open Cultural Heritage URI - Wikidata
Swedish Open Cultural Heritage URI - Wikidata ... identifier
www.wikidata.org

Tyvärr har jag dåligt förtroende för K-samsök jag har lagt den i påsen av bra tanke från början men ruttnar för mycket och vidareutvecklas inte och saknar helpdesk

b-1 saknar helpdesk och unika helpdeskid
upphör en länk i K-samsök att fungera så vet man inte vart man skall vända sig

lyckas man frågar någon på Ksamsök så är svaret det är inte vårt ansvar se b-3

b-1-1 det är så galet att personer på museerna frågar mig om varför det är problem med K-samsök se K-samsök används det

b-2 länkröta extremt mycket jag testade 160 000 länkar som vi har i WIkipedia 5 % har ruttnat. Ksamsök är så primitivt att den förklarar inte varför utan skickar http-koder som feedback....

vi vill veta om en länk med länkröta skall tas bort och kunna följa status på dessa. Idag är min känsla att vi sitter med > 5000 länkar som inte funkar och inte går att felanmäla och inget händer....
se GIST test 2020 06 30
Ok: 156539 Not ok 7604
körde om detta idag --> 2020-11-20
OK: 154158 not ok 6390

b-3 K-samsök är inte persistent saker bara upphör och vi vet inte varför och inte vart vi skall vända oss och hittar man någon på K-samsök så blir svaret det är inte vårt problem se SamlaLibris/issues/5

image.png (314×1 px, 119 KB)

hur skall vi veta vart det är ? dvs. K-samsök bara inför ett lager som gör att vi inte kan ens hitta sakerna och det är fel designat som skickar http errors istället för att berätta vart vi skall fråga, och vad problemet är och helst ha en länk till er task som jobbar med detta eller att vi kan skapa en helpdesktask med ett klick

b-4 nyutveckling känns som det saknas och vi kan inte se er backlog

det pratades om att content negotiation kring 2019 finns som en change request hos er se talksida P 1260 Wikidata men vi kan inte prenumerera på det eller kolla status....

Det är content negotiation vi vill ha istället för att vi skall mixtra med massa script och ha kunskap om hur ni skapar era URL-ar.... mig veterligen så är ni en av få av våra 4000 externa egenskaper som krånglar till det så extremt.... och ovanpå detta inte har en helpdesk som fungerar med helpdesk id ....

Kollar man på talksidan så verkar detta strulandet funnits sedan 2015 men ingen ser till att göra kopplingen mer användarvänlig.....

Content negotiation - HTTP | MDN
In HTTP, content negotiation is the mechanism that is used for serving different representations of a resource at the same URI, so that the user agent can specify which is best suited for the user (for example, which language of a document, which image format, or which content encoding).
developer.mozilla.org

b-5 tittar vi på nya Fornsök får jag en känsla av att ni inte ens internt på RAÄ pushar K-samsök dom visar bara upp sina egna GUID nummer och hoppar över "omvägen"

Hälsningar mer kommentarer nedan
Magnus Sälgö
0705937579

Tackar fick något liknande av Abbe min bild av det hela

  1. Enkelt sätt att länka Wikipedia till Evighsterunor för en runa
  2. Att styra till en sida med engelska eller svenska
    1. Enklast vore att skicka med en språk parameter beroende på i vilken Wiki språkversion länken skapas men gissar att det Inte fungerar om man går via kulturarvsdata
      1. För SKBL har vi gjort det på svenska och engelska Wikipedia

Jenny Lind

    1. en https://skbl.se/en/article/JennyLind
      1. mall en:SKBL
    2. sv https://skbl.se/sv/artikel/JennyLind
      1. mall sv:SKBL
  1. Artikeln om Rökstenen finns på 28 språk med > 100 000 läsare i år
    1. Workaround 1
      1. Runor kollar läsarens Accept-Language och väljer språk med hopp att det är fallback engelska
    2. Workaround 2
      1. Användaren själv får hitta Meny och byta språk

Öppna frågor / Tankar

  1. I Wikipedia finns listor med Runor ex. Lista över Östergötlands runinskrifter
    1. då skulle vi vilja på en sida som denna hoppa direkt till sidan motsvarande

https://app.raa.se/open/runor/search_results?key=county&id=f35eeac1-f212-4e94-9cc0-3e0d081fa330 jag gissar att Östergötland exponeras som f35eeac1-f212-4e94-9cc0-3e0d081fa330 --> att då länkar man direkt Runor utan kulturarvsdata?

  • Idag har vi Structured data in commons video där vi kan i bilden peka på Wikidata Qnummer finns tankar vad ni vill se som markeras i bilder eller hur ni vill söka fram det... så dela gärna...
  • ett scenario some vore lite kul vore att i bilden markera den runrad som vi ser och ange ert inskriptionsid vilket inte stöds idag i Wikicommons, Idag stöds bara att ha "depict" Wikidata Qnummer --> gissar att vi måste skapa Wikidata objekt för runinskriptionerna som sedan peka på ert id för inskriptioner ?!?!? eller är det alltid hela stenen man pekar på?
  • Vore trevligt med en objekt modell för oss oskolade... och om ni har tänkt på detta scenario....
  • Q472975 = Rökstenen
    • P180=Q472875 --> bilder som avbilder Rökstenen men borde kunna vara frågor för att hitta ännu mera intelligent alla bilder med vissa runor etc... gissar jag
  1. Skall vi ha en ny Wikidata egenskap för evighetsrunor?
    1. Lista med det vi har idag som karta som har med Runor att göra....
    2. Vi har väldigt få externa egenskaper på dessa poster lista externa / alla egenskaper

om jag förstod en tanke med K-samsök URI Property 1260 så var det att minska antalet egenskaper i Wikidata min känsla är att vi får en renare lösning om vi skapar en egen egenskap i Wikidata för Evighetsrunor

Ex. hur det blir idag där det blir flera K-samsök kopplingar som inte alltid är enkla att tolka dvs. känns nästan som egna egenskaper för Fornsök, Evighetsrunor gör saker enklare för Wikidata att administrera och underhålla.... sär

  • Spontant känns det som vi skulle behöva fråga K-samsök med egenskaper dvs.
    • ge mig Runa XX där den kom från --> blir Fornsök
    • ge mig var Runa XX finns idag -> blir Evighetsrunor

...

Exempel med Runa som finns på Skansen som blir säkert struligare än "normal runan"

image.png (830×2 px, 118 KB)

  • Södermanlands runinskrifter 352 = wd:Q7666330
    • K-samsök Property 1260
      • raa/fmi/1001280054000 --> Kulturlämning bb26f7cc-1547-45bc-9866-abeeca03b21d
        • är väl inte samma som runan utan där runan hittades
      • nomu/object/NM0082552 --> Nordiska museets föremål NM0082552
        • är den runa med skansens inventeringsnummer NM.0082552

skall om jag förstår rätt vara tidigare identifikationsnummer som Nordiska museet haft och kanske skall städas bort?

sk/object/SKANM0082552 -> Nordiska museets samling på Skansen -> SKANM0082552

Frågor Synpunkter på ny egenskap för er som hänger på Wikidata

Häslningar
Magnus Sälgö
0705937579

Salgo60 updated the task description. (Show Details)
Salgo60 updated the task description. (Show Details)
Salgo60 updated the task description. (Show Details)

Svar Marcus

Hej Magnus, ursäkta sent svar.

  1. Enkelt sätt att länka WIkipedia till Evighsterunor för en runa

löses med er nya funktion för content negotiation

Fint. Denna är nu driftsatt på vår sida.

  1. Att styra till en sida med engelska eller svenska

2-1 Workaround 1
Runor kollar läsarens Accept-Language

Jag tror det är det som redan händer, men får dubbelkolla.

A I Wikipedia finns listor med Runor ex. Lista över Östergötlands runinskrifter
<https://sv.wikipedia.org/wiki/Lista_%C3%B6ver_%C3%96sterg%C3%B6tlands_
runinskrifter>

A-1 då skulle vi vilja på en sida som denna hoppa direkt till sidan motsvarande
https://app.raa.se/open/runor/search_results?key=county&id=f35eeac1-f212-
4e94-9cc0-3e0d081fa330 jag gissar att Östergötland exponeras som f35eeac1-
f212-4e94-9cc0-3e0d081fa330
<https://app.raa.se/open/runor/search_results?key=county&id=f35eeac1-f212-
4e94-9cc0-3e0d081fa330> --> att då länkar man direkt Runor utan
kulturarvsdata?

Ja, det skulle man behöva göra i så fall.

ett scenario some vore lite kul vore att i bilden markera den runrad som vi ser
och ange ert inskriptionsid vilket inte stöds idag i Wikicommons, Idag stöds bara
att ha "depict" Wikidata Qnummer --> gissar att vi måste skapa Wikidata objekt
för runinskriptionerna som sedan peka på ert id för inskriptioner ?!?!? eller är
det alltid hela stenen man pekar på?

VI skiljer i datan mellan inskrifterna som informationsobjekt och sina bärare som fysiska objekt, men idag länkas enbart det fysiska objektet, som är överordnade.

C Skall vi ha en ny Wikidata egenskap för evighetsrunor?

om jag förstod en tanke med K-samsök URI P1260 så var det att minska antalet
egenskaper i Wikidata min känsla är att vi får en renare lösning om vi skapar en
egen egenskap i Wikidata för Evighetsrunor

WD får göra det som funkar bäst för WD. Jag har dock uttryckt min åsikt om detta sen tidigare, nämligen att det känns inte lönt att ha olika WD-properties för varje datamängd i K-samsök, särskilt när de beskriver likadana saker.

Ex. hur det blir idag där det blir flera K-samsök kopplingar som inte alltid är enkla
att tolka dvs. känns nästan som egna egenskaper för Fornsök, Evighetsrunor gör
saker enklare för Wikidata att administrera och underhålla.... sär

URI:er ska helst inte innehålla uppgifter om posten i fråga, de ska inte gå att "tolka" utan att man först löst upp dem. Precis som WD gör med P- och Q-nr.

Spontant känns det som vi skulle behöva fråga K-samsök med egenskaper dvs.
ge mig

  • Runa XX där den kom från --> blir Fornsöj
  • Ge mig var Runa XX finns idag -> blir Evighetsrunor

Nu har du tappat mig helt med den gränsdragingen. Både Fornsök och Runor kan ha uppgifter både om äldsta kända och nuvarande position i koordinatform.

  • Exempel med Runa som finns på skansen som blir säkert

struligare än "normal runan"

Dessa är poster från olika datamängder och datapartners som alla beskriver samma fysiska objekt; detta framgår av att de alla är owl:sameAs varandra (eller, när det gäller den gamla FMIS-posten och den nya KMR, dcterms:replaces). I detta fall har då runstenen fyra URI:er hos K-samsök (fem om man även räkna den utgångna) som från olika databaser beskriver samma sak.

hälsningar,
Marcus

Riksantikvarieämbetet RAÄ Evighetsrunor.ipynb

image.png (802×1 px, 347 KB)

  • socknar etc,. verkar vara textsträngar plus inte alltid vara socknar i Evighetsrunor verkar det användas sockenkoderna vilket borde finnas i K-samsök.....
Salgo60 updated the task description. (Show Details)

Status: stalled

Jag lutar till att en egen Evighetsrunor egenskap behövs. Att blanda in olika owl:sameAs och datapartners fungerar inte när man skall länka från Wikipedia utan då måste vi kunna lösa upp och peka på en specifik URL....

Skriver på Bybrunnen om att Evighetsrunor finns och om någon vill dra detta vidare..... ser att Fornsök inte länkar Evighetsrunor gissar dom har samma problem med att dom själva finns i K-samsök men vill till Evighetsrunor för samma post....

  • borde finnas i K-samsök möjlighet med en URL ha
    • parameter så man kan "tvinga" att se rdf, html oberiende av "accept-header"....
    • parameter så man kan styra till ex. Evighetsrunor och inte hamna på fornsök...
    • känns fel att Fornsök som är platsen där en runa finns är samma objekt som för Evighetsruna som är Runan oberoende av den plats den finns på (ex. Skansen har en runa som funnits på flera platser...)
  • Textsträngar en hel del som måste matchas mot Wikidata objekt lite synd att dom inte har same as Wikidata.... eller RAÄ sockenkoder...

Sockenkoder hämtade från Ksamsök som blir massa textsträngar och verkar inte ta höjd för skillnad på olika Hovs socken se test skott med Jupyter Notebook RAÄ Evighetsrunor.ipynb

image.png (802×1 px, 347 KB)

image.png (192×1 px, 43 KB)

image.png (218×1 px, 53 KB)

image.png (530×2 px, 232 KB)

Salgo60 updated the task description. (Show Details)
Salgo60 updated the task description. (Show Details)
Salgo60 changed the task status from Open to Stalled.Dec 9 2020, 1:39 PM
Salgo60 updated the task description. (Show Details)
Salgo60 renamed this task from Evighetsrunor to Evighetsrunor / “Everlasting Runes”.Dec 13 2020, 12:17 PM
Salgo60 updated the task description. (Show Details)
Salgo60 updated the task description. (Show Details)
Salgo60 updated the task description. (Show Details)
Aklapper changed the task status from Stalled to Open.Apr 6 2024, 7:40 AM
Aklapper subscribed.

@Salgo60: The previous comments don't explain who or what (task?) exactly this task is stalled on ("If a report is waiting for further input (e.g. from its reporter or a third party) and can currently not be acted on"). Hence resetting task status, as tasks should not be stalled (and then potentially forgotten) for years for unclear reasons.

(Smallprint, as general orientation for task management:
If you wanted to express that nobody is currently working on this task, then the assignee should be removed and/or priority could be lowered instead.
If work on this task is blocked by another task, then that other task should be added via Edit Related Tasks...Edit Subtasks.
If this task is stalled on an upstream project, then the Upstream tag should be added.
If this task requires info from the task reporter, then there should be instructions which info is needed.
If this task needs retesting, then the TestMe tag should be added.
If this task is out of scope and nobody should ever work on this, or nobody else managed to reproduce the situation described here, then it should have the "Declined" status.
If the task is valid but should not appear on some team's workboard, then the team project tag should be removed while the task has another active project tag.)