Moduldiskusjon:Authority control

IDer fra Wikidata er et komplett rot

En av de tingene som Wikidata ikke har fått til er bruk av id'er. Dette er et eneste rot fra ene enden til den andre, og jeg er særdeles betenkt på å ta ibruk denne delen av Wikidata. Dette er forsøkt "fikset" via ymse mer eller mindre smarte (les idiotiske) løsninger, deriblant bruk av Lua-script for å forsøke å redde kaoset.

Jeg mener vi burde kreve at dette ble fikset på Wikidata, vi bør ikke forsøke å fikse dataene lokalt.

Problemet består i at det ikke er laget en skikkelig implementasjon av en URI, og derfor har nettsamfunnet forsøkt å gå rundt problemet ved å lage "strenger" som kan puttes inn i lenker slik at en kan gjenskape URIene (som er de reelle identifikatorene). Problemet er antakelig forsterket av manglende type og range på egenskapene. — Jeblad 17. aug. 2014 kl. 17:16 (CEST)

Liten korreksjon: Det finnes nå en URL som delvis kan brukes som en URI, men det ser ikke ut som om denne er i bruk som identifikator. Korrekt bruk av en URI (eller egentlig en rdf:resource) er litt mer omfattende enn kun å følge en URL til en webside. — Jeblad 17. aug. 2014 kl. 17:37 (CEST)

Oops. Det høres ut til at jeg bør ta en aldri så liten kjapp rollback på {{Autoritetsdata}} inntil videre. Men akkurat dette burde wikidata vært ganske velegnet til. --Chameleon (diskusjon) 17. aug. 2014 kl. 17:59 (CEST)

Rollback burde ikke være nødvendig. Jeg forstår Jeblads savn etter en URI-datatype (eller noe sånt), men det må da være mye bedre å gjøre det beste ut av situasjonen vi er i, enn å vente på en drømmesituasjon som kanskje aldri kommer. Og når det gjelder hva som er «de reelle identifikatorene» kommer det nok an på om man spør noen i RDF/linked data-miljøet eller utenfor :) Det finnes også URIer som ikke gir tilbake noe som er forståelig for mennesker (eks. Bibsys), og da er det faktisk bedre i å kunne lage URLer fra identifikatorene selv, slik denne modulen gjør, hvis målet er å skape pekere til mer informasjon for leseren av artikkelen. – Danmichaelo (δ) 17. aug. 2014 kl. 18:27 (CEST)

Jeg har allerede rullet tilbake malen (dvs den som er live nå er den gode gamle). Mulig jeg var litt for kjapp der, men jeg vil helst ikke stå bak et «komplett rot», ihvertfall ikke uten å tenke/diskutere litt igjennom det først. Malen som fungerer med modulen ligger i malsandkassen. Modulen bruker de id-ene som evt er parametre til malen, og supplerer med andre fra Wikidata. Id-ene som brukes i modulen er tilsvarende de som brukes i dagens mal. Så vidt jeg forstår Jeblad så ønsker han at man fra Wikidata skal kunne hente ut URI-ene for å slippe og mekke dem til selv i forskjellige scripts/maler (pluss at valideringen av id-ene bør skje i Wikidata). Det høres ut som en god idé, men som Danmichaelo heller jeg i retning av at det er bedre å prøve og utnytte informasjonen som er tilgjengelig nå enn å vente på at det blir endret. --Chameleon (diskusjon) 17. aug. 2014 kl. 19:10 (CEST)

Det er to ting her. Det ene er at Wikidata er fullstendig kaos på dette punktet og hva vi skal mene om dette, og det andre er om vi skal prøve å avhjelpe situasjonen lokalt slik at vi får noe som kanskje fungerer (eller om ikke annet ikke er helt crap). Situasjonen er at Wikidata er semantiske data, men Wikidata publiserer bare delvis lenkede data. En URI brukes i lenkede semantiske data for å følge kilden til dataene, for at en derved skal kunne si mer om dataene. Når URI-er ikke finnes (det er kun lokale id-er som lagres) så er dataflyten amputert. Slik det skal fungere er at en URI i lenkede data følges til et nettsted, og når nettstedet oppdager at det er en nettleser (dvs en person) som ankommer, så vil nettleseren redirigeres til en ordinær webside. Hvis den som ankommer sier den vil ha maskinlesbare data så sendes den besøkende typisk til en RDF-representasjon av siden. Dette er en grunnleggende oppførsel på nettet og har vært kjent svært lenge. Hvi skal ikke ta kontrollen over hva brukeren vises, det er nettstedene selv som skal håndtere dette. Det kalles «content negotiation». Det folka på Wikidata gjør er å klippe ut hva de tror erinternidentifikatoren til nettsteder og så publiserer de den som en eksternt gyldig identifikator. Identifikatoren som brukes av nettsteder som publiserer lenkede semantiske data er URI-en.

Joda, vi kan bruke et Lua-script for å få orden i galskapen, men da prøver vi å lage ku av kjøttdeig. Jeg mener det riktige er å be Wikidata fikse rotet. — Jeblad 17. aug. 2014 kl. 19:53 (CEST)

(←) Kjenner du til hva slags vurderinger som ligger bak valg av type for AC i WD? Og om det er diskusjoner om denne bør lagres på en annen måte (URI/rdf:resource)? Jeg søkte litt etter AC i WD igår, uten å finne noe veldig konkret (dvs jeg fant hauger og lass av WD- og AC-diskusjoner, den samtalen er ganske så spredd). Dersom jeg skal gjette så er typen arvet (uten noen god vurdering) fra den tyske malen (og der er det sikkert fornuftig at parametrene bruker denne korte «representasjonen»). Jeg ser at det å få en lenke til AC fra WD nevnes som et ønske i en tysk diskusjon. Tyskerne har (såvidt jeg kan se) ikke begynt å hente ut AC fra WD. Men de diskuterer det, og det ser ut til at de ikke er veldig langt unna å starte. Slik jeg leser diskusjonen deres går bekymringene til dem ut på hvordan man skal håndtere evt. data som er ulike WP og WD, hvordan man skal velge korrekt id (f.eks. kan en person ha flere VIAF-er) og om man skal kunne overstyre lokalt eller hente id-ene fra WD.

Jeg synes idéen din om å få ut id-ene som URI fra WD høres fornuftig ut, men jeg har begrenset tro på at et slikt forslag vil få gjennomslag. Dersom man ikke skal lagre id-ene dobbelt (dagens versjon + URI) vil vel en slik endring fort være lite kompatibel? Et alternativ kunne vært en utvidelse av mw:Extension:Wikibase Client, f.eks. la mw.wikibase.entity:formatPropertyValues returnere ulike representasjoner (formatere verdier på ulik måte) styrt av et argument (lokal/global/lang/kort/elns). For en AC entitet kunne denne funksjonen returnert id-en enten som en URI eller i kortformen (kanskje også på en formatert kortform). Funksjonaliteten kan kanskje også brukes for f.eks. datoer eller enkelte andre felt. Om man internt i WD lagrer infoen i dagens format eller som en URI ville da spille noe mindre rolle. Ihvertfall for bruk i WP.

Inntil noen evt. får endret dette mener jeg vi bør jenke dette til lokalt. Egentlig sliter jeg litt med å forstå hvorfor du er skeptisk til det. En ulempe med å bytte ut dagens mal med den lua-baserte er at den nye bruker flere typer id-er (det er flere lenker som må holdes oppdatert, og særlig de mest obskure id-ene kan det ta tid før vi registrerer om de feiler). Men samme problem (om enn i mindre skala) har vi i dagens mal. En fordel med den nye malen/sciptet er at vi får brukt (tilbudt/tilgjengeliggjort til lesere) mer av informasjon fra WD. Når/hvis lagringen i WD endres er det sannsynligvis enkelt å oppdatere scriptet.

Jeg foreslår ikke å bytte ut id-ene som er angitt i WP med data fra WD nå (men det er en ting vi må/bør ta stilling til på ettellerannet tidspunkt). Dvs. vi beholder dagens informasjon, men får noe informasjon i tillegg. Det betyr også at vi kan gå tilbake til dagens mal dersom den nye løsningen blir bedømt som crap. Ihvertfall inntil det blir lagt til endel {{Autoritetsdata}} uten argumenter i artiklene.

Dvs. jeg sier jatakk til hamburgere inntil vi får tilgang på ytrefilet :) --Chameleon (diskusjon) 18. aug. 2014 kl. 11:23 (CEST)

Det her går på at autoritetsidentiteter skal peke til poster i autoritetslister, og at «peke til» i denne sammenhengen betyr at id-en må være en URI og at posten det pekes til bør være maskinlesbar (typisk RDF) og eventuelt med en 303-dans for å presentere menneskelesbare data. For at alt skal bli transparent så må WD gjøre materialisering av dataene hos seg (automatisk caching), det vil si at de implementerer rdf:resource og gjør materialisering slik at klientene kan hente ut dataene. Det er nokså mye arbeid som gjenstår for å få til dette, å endre på mw.wikibase.entity:formatPropertyValues er ikke rett fremgangsmåte. Jeg spurte om status på dette for over ett år siden og det er fortsatt ukjent om, og eventuelt når, det blir implementert. Kanskje det er like greit å bruke løsningen (rotet) slik det er nå og håpe det blir fikset en gang i fremtiden. Jeg tviler på WD vil bli fikset med det første, men en kan jo håpe. — Jeblad 19. aug. 2014 kl. 01:28 (CEST)

Dette har du åpenbart tenkt bedre igjennom enn det jeg har. Men jeg re-enabler malen basert på Lua, og gjør regning med at jeg får høre det om det blir helt crap. Så får vi prøve å følge med på hva som skjer med dette på WD og oppdatere scriptet/malen når virkeligheten er tilpasset kartet. --Chameleon (diskusjon) 19. aug. 2014 kl. 09:24 (CEST)

Jeg har fulgt med på diskusjonene på dewp, og kjenner innvendingene som er kommet fram der, men synes Lua-malen gir en klar forbedring. Og det burde holde inntil det perfekte dukker opp. --Kaitil (diskusjon) 19. aug. 2014 kl. 11:52 (CEST)

Jeg tror ikke dette blir fikset med det første, så bruk det som finnes. — Jeblad 19. aug. 2014 kl. 18:54 (CEST)

ORCID

Excuse me for writing in English, but please can somebody help at Maldiskusjon:Autoritetsdata#ORCID? Pigsonthewing (diskusjon) 15. sep. 2014 kl. 16:22 (CEST)

Ah, yes. Sorry I forgot, but at least I've answered your request there now. --Chameleon (diskusjon) 15. sep. 2014 kl. 16:35 (CEST)

Kategorisering

Foreslår at vi legger til kategorisering i de tilfellene hvor «elements» har innhold. Det vil si at vi får en katagori ala «Autoritetsdata eksisterer». Denne kategorien bør være en skjult vedlikeholdskategori. Den kan deretter brukes som grunnlag for å si at artikkelen har en kilde på at den eksisterer om ikke annet. — Jeblad 11. okt. 2015 kl. 15:02 (CEST)

Noen mangler

De viktigste som står igjen. Disse krever en del arbeid for å sikre at riktige poster kobles. — Jeblad 15. des. 2015 kl. 02:48 (CET)

• Forfatterkatalogen [1], bruk de publiserte oversiktene og lag oppføringer for alle blålenka. Det er rundt 2000 oppføringer. Dette er nok en katalog og ikke en autoritetsfil.
• Sentralt stedsnavnregister, må skrives script for å hente ut de dataene som er aktuelle for oss. Veldig mye av våre artikler som har stedsangivelse finnes her. Dette er en autoritetsfil.
• Norsk kunstnerleksikon, Nasjonalmuseets tjeneste har karakter av autoritetsfil, SNL sin utgave er katalog/leksikon. 5-6000 oppføringer.
• Nasjonalmuseet/Preus fotomuseum/NLI, Nasjonalmuseets fotografregister har karakter av autoritetsfil, de andre er kataloger/leksikon. Kan kobles via KulturNav. Over 5000 oppføringer.[2]
• BRreg, autoritetsfil, må hentes ut og kontrolleres. Søk med tittel som i Bokhylla-søket. Forvent mye feil. Alle norske firmaer bør få arg.nr.