Property talk:P396

Add topic
Active discussions

Documentation

SBN author ID
identifier issued by National Library Service (SBN) of Italy
RepresentsOPAC SBN (Q105086090)
Associated itemIstituto Centrale per il Catalogo Unico (Q3803707)
Applicable "stated in" valueOPAC SBN (Q105086090)
Has qualityVIAF component (Q26921380)
Data typeExternal identifier
Domainhuman (Q5), organization (Q43229), pseudonym (Q61002), group of humans (Q16334295) or fictional character (Q95074)
Allowed values\D{2}[A-Z0-3]V\d{6}
ExamplePetrarch (Q1401)CFIV017574
Galileo Galilei (Q307)CFIV004372
Sourcehttps://opac.sbn.it/voci-controllate-nomi
Formatter URLhttps://opac.sbn.it/nome/$1
Tracking: usageCategory:Articles with ICCU identifiers (Q18174792)
Related to country  Italy (Q38) (See 274 others)
See alsoSBN books ID (P5485), SBN work ID (P10396), SBN place ID (P10397)
Lists
Proposal discussionProposal discussion
Current uses
Total90,010
Main statement66,963 out of 328,460 (20% complete)74.4% of uses
Qualifier2<0.1% of uses
Reference23,04525.6% of uses
Search for values
[create Create a translatable help page (preferably in English) for this property to be included here]
 
Format “\D{2}[A-Z0-3]V\d{6}: value must be formatted using this pattern (PCRE syntax). (Help)
Exceptions are possible as rare values may exist.
List of this constraint violations: Database reports/Constraint violations/P396#Format, SPARQL
 
Distinct values: this property likely contains a value that is different from all other items. (Help)
List of this constraint violations: Database reports/Constraint violations/P396#Unique value, hourly updated report, SPARQL (every item), SPARQL (by value)
 
Single value: this property generally contains a single value. (Help)
Exceptions are possible as rare values may exist.
List of this constraint violations: Database reports/Constraint violations/P396#Single value, SPARQL
 
Allowed entity types are Wikibase item (Q29934200): the property may only be used on a certain entity type (Help)
Exceptions are possible as rare values may exist.
List of this constraint violations: Database reports/Constraint violations/P396#allowed entity types
 
Scope is as main value (Q54828448), as reference (Q54828450): the property must be used by specified way only (Help)
Exceptions are possible as rare values may exist.
List of this constraint violations: Database reports/Constraint violations/P396#scope, SPARQL
  Pattern ^IT\\ICCU\\(\D{2}[\D\d]V)\\(\d{6})$ will be automatically replaced to \1\2.
Testing: TODO list

  Pattern ^(\D{2}[\D\d]V)\\(\d{6})$ will be automatically replaced to \1\2.
Testing: TODO list

 

Please notify projects that use this property before big changes (renaming, deletion, merge with another property, etc.)

4 formatsEdit

What is the format for this?

I just changed the sample at Wikidata:List_of_properties#Authority_control from "002049" to "CFIV\002049".

Re-reading the above sample from the initial proposal, it seems it should be "IT\ICCU\CFIV\002049". However, the "IT\ICCU\" part seems to define the property that follows.

The only use on an item I had found doesn't include the slash (Q3108024: "CFIV067552") --  Docu  at 07:10, 25 April 2013 (UTC), edited 07:38, 25 April 2013 (UTC), edited 11:31, 25 April 2013 (UTC)

It should be IT\ICCU\CFIV\000000. This is the original form. I don't think there are so many usage of this property, so it should be easy to correct all of them to this form. (see below) --Sannita - not just another it.wiki sysop 12:57, 26 April 2013 (UTC)

Link somewhere?Edit

It would be nice if this could link somewhere, e.g. http://www.sbn.it/opacsbn/opac/iccu/free.jsp ?

The corresponding addition could be requested at MediaWiki talk:Gadget-AuthorityControl.js. --  Docu  at 07:14, 25 April 2013 (UTC)

Yes, it would be lovely, but there's a problem: the original link at http://opac.sbn.it/ is huge - and by huge I mean at least five or six rows, no kidding. I'm trying to work a solution about that, but I've got literally no time until May 2. --Sannita - not just another it.wiki sysop 12:57, 26 April 2013 (UTC)

As far as I know, there is no useful link. What makes it even worse, there are two IDs. Take for example Michelangelo:

  • Identificativo SBN: IT\ICCU\CFIV\017291
  • Identificativo internazionale: IT\ICCU\0000077060

Both numbers are not in VIAF. The SBN uses the link:

  • opac.sbn.it/opacsbn/opaclib?db=solr_iccu&resultForward=opac/iccu/brief.jsp&from=1&nentries=10&searchForm=opac/iccu/error.jsp&do_cmd=search_show_cmd&item:5032:BID=IT\ICCU\CFIV\xxx

xxx = Identificativo SBN ("017291"). --Kolja21 (talk) 18:42, 26 April 2013 (UTC)

A slightly shorter version could be:
opac.sbn.it/opacsbn/opaclib?db=solr_iccu&resultForward=opac/iccu/brief.jsp&do_cmd=search_show_cmd&item:5032:BID=IT\ICCU\CFIV\017291
We would still need to resolve the format question. --  Docu  at 10:45, 27 April 2013 (UTC)
Hi, the shorter version I've found is
http://opac.sbn.it/opacsbn/opaclib?db=solr_auth&resultForward=opac%2Ficcu%2Ffull_auth.jsp&item:1032:Codice_Auth=IT\ICCU\CFIV\017291&searchForm=opac%2Ficcu%2Fauthority.jsp&do_cmd=search_show_cmd&nentries=1&fname=none&from=1
where the identifier appear after Codice_Auth=. Previous versions of the URL you provided were search inside title's catalog, not authority. --Borgopio (talk) 13:26, 29 April 2013 (UTC)
Actually RicordiSamoa bought http://iccu.tk/ which can be used to shorten the link. I already asked him for a minor fix (since the link works only with the numbers, while the right code is "IT\ICCU\xxxV\123456"), but it's ready and can be used in the .js, I think. Sannita - not just another it.wiki sysop 10:57, 10 May 2013 (UTC)
Actually Ricordisamoa didn't buy anything (.tk domains are free); and yes, the fix will arrive soon. --Ricordisamoa 11:12, 10 May 2013 (UTC)
However, the hosting plan is free too, and I'm concerned about the traffic limits...   --Ricordisamoa 11:15, 10 May 2013 (UTC)
Sannita asked me on my talk page to help implement this. As stated above, it would just need to be requested on the talk page of MediaWiki talk:Gadget-AuthorityControl.js.
Personally, I don't think the length of the URL is a problem. We just need to be sure about the format of the string we will use.
Using a third party redirect may be an issue as it might not comply with WikiMedia's privacy policy or at least with similar ones, e.g. on toolserver. --  Docu  at 05:19, 11 May 2013 (UTC)

URLEdit

I've changed the target URL.[1] It was reported that some items are not reachable via the previous URL, but they are with this. Example: [2]. --Nemo 07:31, 6 March 2015 (UTC)

@Nemo_bis: Non concordo sulla proposta di modificare la URL connessa all'identificativo del record di autorità facendola puntare a una lista di record bibliografici dell'autore X anziché, come adesso, al record di autorità dell'autore X. Nelle diverse Wikipedia, i vari identificativi dei record di autorità che appaiono all'interno del box Controllo di autorità puntano sempre al record di autorità a cui fa riferimento l'identificativo. Cioè puntano alla sezione di un opac che contiene i records di autorità e non a una lista di opere di X. È anche una questione di coerenza: 1) con l'etichetta di quel box: si chiama Controllo di autorità e non Lista di libri di; 2) l'identificativo in chiaro se è, come è sempre, un hyperlink, ha senso che se cliccato porti alla pagina che mostra ciò a cui si riferisce il codice dell'identificativo e non a una pagina che ha un contenuto completamente diverso. Il fatto di far collegare l'identificativo del record di autorità alla pagina web del record e non a una lista di opere, è una decisione presa tra 2012 e 2013 e ormai consolidata tra tutte le Wikipedia. Qualora la sola Wikipedia italiana adottasse la tua proposta, sarebbe l'unico caso. Infine l'obiettivo che ti poni, offrire al lettore della voce di Wikipedia un link immediato a una lista di opere "di" in un opac è già realizzato nella Wikipedia inglese con la soluzione di John Ockerbloom adottata dalla Wikipedia inglese: un template che consente di aggiungere alle voci biografiche di Wikipedia un box con dei link per fare ricerche negli opac di biblioteca e ottenere 2 tipi diversi di liste: opere "di" e opere "su" (vedi il post sul suo blog: John Ockerbloom, “From Wikipedia to our libraries”, in Everybody’s Libraries, 4 marzo 2013 http://everybodyslibraries.com/2013/03/04/from-wikipedia-to-our-libraries/). Per un esempio vedi la voce di Jane Austen: https://en.wikipedia.org/wiki/Jane_Austen che verso il fondo, vicino al margine destro, contiene il box: “Library resources box”. Considerati anche i tre vantaggi che ha l'uso di quel box: 1) la sua maggiore visibilità rispetto al link nel box Controllo di autorità; 2) il fatto che contiene una etichetta esplicativa chiara; 3) il fatto che consente ai lettori di selezionare in una schermata intermedia quale catalogo interrogare, io propenderei per l'adozione di quella soluzione. Volendo, potrebbe anche essere adattata in maniera semplificata al contesto italiano: basterebbe che contenga il link alla lista delle opere "di" con l'uso della URL che hai proposto tu e che punta al catalogo SBN.--Pierfranco Minsenti 12:08, 6 March 2015 (UTC)
RB to the AC code SBN redirecting service. URL used by Nemo links to the bibliographical records, NOT to the AC record.
Sorry for my boldness, but I have rollbacked the change according to Piefranco findings. The link shall be relevant to the Authority control record, and not to the related bibliographical record. --Accurimbono (talk) 15:12, 20 March 2015 (UTC)

SBNV035264Edit

I added that https://www.wikidata.org/w/index.php?title=Q16007669&diff=prev&oldid=567375648, based on http://opac.sbn.it/opacsbn/opaclib?db=solr_iccu&resultForward=opac/iccu/brief.jsp&from=1&nentries=10&searchForm=opac/iccu/error.jsp&do_cmd=search_show_cmd&item:5032:Nomi::@frase@=SBNV035264

Ricerca: Nomi = SBNV035264 

but link http://id.sbn.it/af/SBNV035264 does not work. 85.182.83.61 21:11, 27 September 2017 (UTC)

It means that that particular code has been removed, probably because it was merged with another code. --Sannita - not just another it.wiki sysop 17:48, 7 October 2017 (UTC)

Property for SBN edition IDEdit

@Sannita: Qui urge una nuova proprietà dedicata alle edizioni, ci sono decine di item nel report... Che ne pensi? --Accurimbono (talk) 12:35, 20 June 2018 (UTC)

@Accurimbono: Non capisco perché non mi ha segnalato questa discussione Sì, ci ho già pensato pure io. Me ne occupo con l'utenza di lavoro più tardi. --Sannita - not just another it.wiki sysop 18:50, 1 July 2018 (UTC)
@Sannita: Ottimo!
PS: In che senso "non mi hai segnalato"? Pensavo che il ping fosse sufficiente. --Accurimbono (talk) 08:52, 2 July 2018 (UTC)
@Sannita (ICCU):, forse intendevi che ti avrei dovuto pingare a quest'altro account? Vabbè, cmq non era una cosa urgentissima. Ciao e grazie di nuovo, --Accurimbono (talk) 08:56, 2 July 2018 (UTC)

Format question on frwikiEdit

Jihaim on frwiki (fr:Wikipédia:Le_Bistro/2_novembre_2018#ICCU) is trying to put the ICCN number of someone ( Adelaide Orsola Appignani (Q4681752) ) and failing because of a constraint format (he tries « RMLV045206 »). What’s wrong with this ? @Aubrey: who proposed the constraint for the format initially. author  TomT0m / talk page 18:47, 2 November 2018 (UTC)

Answer on Le Bistro de frwiki --Eihel (talk) 21:56, 5 November 2018 (UTC)

Mail per segnalare errori SBNEdit

Per segnalare errori:

  • in voci di autorità: ic-cu.AFnomi@beniculturali.it
  • in record bibliografici o altro: ic-cu.infobib@beniculturali.it

--Bgelosia (talk) 11:05, 30 November 2021 (UTC)

Nuovo OPAC SBN e formato degli IDEdit

Airon90 ValterVB Alexmar983 Epìdosis Pietro Jura Beta16 Yiyi Sannita Camelia Sentruper Pierpao Marcok CristianNX Daniele Pugliesi (WMIT) AttoRenato Parma1983 Aborruso Sabas88 Lalupa DnaX Fausta Samaritani Patafisik Malore Jtorquy Nicholas Gemini Civvì Devbug Afnecors Susanna Giaccai FabC FeltriaUrbsPicta Horcrux Uomovariabile Luckyz Francians Carlobia Ferdi2005 Luca.favorido Lemure Saltante Giacomo Alessandroni divudì Federica Gaspari   Notified participants of WikiProject Italy Buon pomeriggio. Come sapete, recentemente l'Istituto Centrale per il Catalogo Unico (Q3803707) (ICCU) ha operato un’importante reingegnerizzazione delle proprie basi dati, specificamente OPAC SBN (Q105086090), Censimento nazionale delle edizioni italiane del XVI secolo (Q1053428) (EDIT16) e Manus Online (Q104174535) (MOL) e ha creato il nuovo portale Alphabetica (https://alphabetica.it/web/alphabetica/informazioni), che è stato presentato recentemente (qui la registrazione dell’evento).

Per quanto riguarda specificamente l’OPAC SBN, è stato creato un nuovo sito (https://nuovo-opac.sbn.it/), in cui sono state rese visibili anche le voci di autorità per opere e luoghi (oltre alle voci di autorità per gli autori), ed è stato annunciato che entro pochi mesi il vecchio sito (https://opac.sbn.it/opacsbn/opac/iccu/free.jsp) sarà dismesso, o meglio che il nuovo sito verrà spostato al posto del vecchio sito (come è già stato fatto in dicembre per EDIT16 e per MOL); ICCU mi ha confermato oggi che (cito): "Entro febbraio rimarrà online un solo sito dell'OPAC SBN, con il seguente URL: https://opac.sbn.it/".

Questo significa che sarà per noi necessario aggiornare gli URL di formattazione di SBN author ID (P396) e SBN books ID (P5485), che fanno entrambe capo all’OPAC SBN in corso di dismissione. Si pone dunque il seguente problema: il formato attuale degli ID, es. IT\ICCU\CFIV\017574 (autori) e IT\ICCU\MOD\0578992 (record bibliografici), non è compatibile cogli URL di formattazione offerti dalla nuova interfaccia. Dopo le dovute verifiche, oggi ICCU mi ha confermato precisamente l'incompatibilità dichiarando che (cito):

Nota: i link qui sopra attualmente non funzionano perché cominceranno a funzionare solo a spostamento avvenuto; attualmente funzionano soltanto sostituendo id.sbn.it e opac.sbn.it con nuovo-opac.sbn.it.

Per evitare un link rot imminente, risulta evidente dalla risposta di ICCU la necessità di modificare il formato dei nostri ID, rimuovendo le barre "\" e il prefisso "IT\ICCU", così da mantenere di fatto soltanto gli ID veri e propri, i cosiddetti VID (voci di autorità) e i BID (record bibliografici); l’esito sarebbe quindi CFIV017574 (autori) e MOD0578992 (record bibliografici). Questi ID, oltre a evitare il link rot, avranno il vantaggio di avere una triplice compatibilità:

Inoltre, considerato che i due nuovo ID per opere e luoghi (appena proposti) avranno la forma breve, i VID appunto, non avrebbe senso cercare di mantenere in modo difforme questi ID in forma estesa.

In assenza di obiezioni, avvierò all'inizio della prossima settimana il procedimento di modifica del formato degli ID secondo i seguenti passaggi:

  1. disattivazione del catalogo Mix’n’match degli autori SBN -   To do
  2. modifica da parte di un bot di tutte le occorrenze dei due ID sia come valori principali sia come riferimenti -   To do contattato Ladsgroup
  3. aggiornamento degli URL di formattazione, dei regex, degli autofix, degli esempi e delle descrizioni dei due ID -   To do
  4. aggiornamento dei gadget che estraggono SBN dal VIAF -   To do
  5. ricaricamento del catalogo Mix’n’match degli autori SBN cogli ID nel nuovo formato -   To do
  6. (al momento della dismissione definitiva del vecchio OPAC) avviso del cambiamento avvenuto ai vari progetti Wikimedia che utilizzano i due ID -   To do

--Epìdosis 15:12, 3 February 2022 (UTC)

ok. Che mattonata leggersi tutto, figurarsi scriverlo.--Alexmar983 (talk) 15:26, 3 February 2022 (UTC)
Un grande progresso per ICCU e per tutti :clap  Bargioni 🗣 16:03, 3 February 2022 (UTC)
Grazie mille @Epìdosis, molto interessante. Buon lavoro Patafisik (talk) 16:39, 3 February 2022 (UTC)
Grande novità e grandissimo lavoro! Grazie @Epìdosis!! Carlobia (talk) 07:36, 4 February 2022 (UTC)
Can you summarize in English what's being done to the id values? --- Jura 11:04, 4 February 2022 (UTC)
@Jura1: Format change, removing the initial "IT\ICCU\" and the remaining "\" from both P396 and P5485: e.g. P396 from IT\ICCU\CFIV\017574 to CFIV017574, P5485 from IT\ICCU\MOD\0578992 to MOD0578992 (practically, these lists of edits). --Epìdosis 13:58, 4 February 2022 (UTC)
I'd copy that to a new property. --- Jura 14:15, 4 February 2022 (UTC)
The values will effectively remain the same; changes of format which don't fundamentally change ID values have already happened due to changes in website URLs (e.g. zero-padding in HDS ID (P902), which is a very similar case). In general, while in cases where the IDs fundamentally change a new property is created (which is a practice I perfectly support), the same property is kept when the format conversion can be made through a simple regular expression, as in the case of DSS. And above there seems to be consensus for keeping the same property. --Epìdosis 15:46, 4 February 2022 (UTC)
Not sure. While minor corrections shorter or longer before creation shouldn't matter, P396 was created years ago. Changing its definition just complicates it for anybody using the property (it would save you the steps you listed above). This even if eventually P396 would be discontinued.
A proposal to versionize property definitions didn't find any support.
It's clear that occasionally, users sometimes change values to another identifier or scheme (possibly without even seeking input before), but I don't think that is good practice. It makes Wikidata content unpredictable. One property is currently even listed for deletion as its scheme changes are seen as erratic.
OTH, recently people even created additional properties for more or less identical identifiers (Property:P10297, Property:P10283). --- Jura 16:15, 4 February 2022 (UTC)
So, I understand your motivations. Keeping the old P396 and P5485 and creating new properties with new formats would have one advantage: allowing reusers of Wikidata's data to keep using the old format of the IDs without changing to the new one (so the content would remain predictable). However, I see more disadvantages, which make me still think that changing the formats of these properties is a better solution: if a reuser keeps using P396, they will end up with link rot before the end of this month - so a change, both of property and of formatter URL (if stored locally), will be necessary anyway, and keeping the old data would give in my opinion the false impression that both the old and the new format are still usable; if a reuser, anyway, wants the old format for historical purposes, another risk is that P396 will end up being kept just for historical purposes and so cases of mismatches will be corrected not in P396 but only in the new property (unless through an autofix, which would mean further edits to sync the old and the new IDs); if a reuser wants to have the effective SBN IDs, they would have to switch to a new property, while if the old property is re-formatted the reuser could in fact do nothing (if they don't store the formatter URL locally) and still have up-to-date data. In conclusion, I tend to think that probably no reuser would be interested in retrieving the old format (or, if they want, they could just derive the old format from the new format using a regular expression) and that substantial duplication of the same IDs is not desirable for Wikidata, both in terms of storage capacity and of edits require to keep in sync the two groups of IDs. Regarding additional properties for more or less identical identifiers, consequently, I think it is a questionable practice; unfortunately I missed those property discussions.
I reflected upon "it would save you the steps you listed above" and I tend to exclude this possibility: we would still need 1) to deactivate old MnM (due to link rot), 5) to create a new MnM (to have effective links), 4) to update gadgets extracting SBN from VIAF in order to have them use the new property, 6) to have Wikimedia projects switch to the new property and new formatter URL (instead of just changing the formatter URL), 3) to update old properties to mark them as obsolete (instead of changing their format); point 2) (re-formatting values) would be avoided, but I would have to propose the new properties instead - so, in fact, the same to-do-list with just some different points.
Finally, ICCU expressed itself in favor of keeping the same properties, as I said. So, I think there are more reasons for re-formatting than for creating new properties. --Epìdosis 16:51, 4 February 2022 (UTC)
I think we heard similar arguments for some other properties. We learned later that the "old" format was still in use a year later or that the other format was used in a different context. Possibly this was due to some overly optimistic views on change implementation (possibly, mandated by their "corporate communication") or a misunderstanding of the impact on our side by the websites.
BTW, there is no linkrot if one de-activates the formatter url and users aren't forced to a changeover. --- Jura 17:34, 4 February 2022 (UTC)
I think that re-formatting the properties we are talking about is better than create new ones.
Grazie per il tuo lavoro @Epìdosis e per la chiara spiegazione. Spero sarà possibile procedere alla modifica del formato degli ID per evitare un link rot imminente e inevitabile! Taniamaio (talk) 17:40, 4 February 2022 (UTC)
That's a great news and thank you for all the work! I can understand the motivation for the creation of new properties, in general, but in this particular case the maintenance of the old properties is very important for all the users that are used to using P396 and P5485 (I also think about tutorials, guides, videos ect.. that report those properties). Moreover it could sound a bit strange but the current format is really "strange" for all italian librarians (that are the most active community that add bibliographical metadata from SBN catalogue) because all the local catalogue (that derive data from SBN) both in front end and back end already adopt the short ID format (the one that is finally about to become the only one), so this change of format is largely welcome and expected and this will take a great simplification of our work (and this also make realistic that ICCU will mantain its promise of dismissing the old format). On the contrary, IMHO the adoption of new properties risks to create uncertainty and errors moz (talk) 18:28, 4 February 2022 (UTC)
This discussion is a terrible case of TL;DR, LOL all in all I'm in favor of changing the formatter url and it seems that IF problems would ensue (which could not, but my vision is library centric) couldn't they be easily fixed the other way around? anyway... as a librarian I can add that multiple ILS software (like Sebina) are shedding the prefix in the fields in their new releases, aligning themselves with the format of the new national opac. If other "actors" are using the property won't they also inevitably modifiy their products since the national opac is changing? divudì 17:53, 4 February 2022 (UTC)
Da quello che mi sembra di capire dalla spiegazione di @Epìdosis, l'ICCU non garantirà la persistenza dei vecchi identificativi di SBN. Sono dunque anche io favorevole al cambio di formato degli attuali ID, in ragione del fatto che i vecchi ID non sarebbero utilizzabili in alcuna maniera.
If I've understand @Epìdosis's explanation, the ICCD will not guarantee the persistence of "old" SBN IDs. So I'm in favor to change the IDs' format, because the old IDs couldn’t be usable in any way. Alessandra.Moi (talk) 18:36, 4 February 2022 (UTC)
I am in favor of changing the format of SBN ID, removing the initial "IT \ ICCU \" and the remaining "\"; idea also supported by compatibility with VIAF, OPAC SBN and Alphabetica. The maintenance of the old properties is very important. Thanks for your work @Epìdosis Alessandra Boccone (talk) 20:30, 4 February 2022 (UTC)
  • From the comments, I gather that there is an additional problem I hadn't seen before: the proposed change seems to create a user expectation that identifiers at Wikidata somehow keep getting updated. This seems contrary to the stability that Wikidata aims to achieve and the same reasoning can lead to problems when attempting to use Wikidata in general.
    BTW, I'm not really convinced that the outlined approach for MxM is sufficient (it doesn't seem unlikely that there is more than one catalogue using P396).
    Obviously, I share other users praise for Epidosis excellent work with Wikidata in general. --- Jura 11:10, 5 February 2022 (UTC)
    Fortunately only https://mix-n-match.toolforge.org/#/catalog/4629 is using P396, I’m pretty sure. --Epìdosis 20:03, 6 February 2022 (UTC)

So, after 3 days of discussion (the thread has also been linked from Wikidata:Bar), it seems that we have reached a deadlock. As I recognised, no solution is 100% good or 100% bad, so it is probable that positions will not change a lot. As it could be useful also for future similar discussions, I try to summarize in a table the main argumentations for reformatting (so against new properties) and against reformatting (so for new properties):

For reformatting Against reformatting
1 Reformatting changes the ID in a way that reusers could, through a simple regex, easily reconstrunct also the previous format of the ID Reformatting introduces a major change in the format of the ID
2 Reformatting makes it evident that a relevant change has been made in the website and that IDs and URLs need to be updated accordingly Reformatting introduces umpredictability for reusers of Wikidata’s content
3 Reformatting obliges the reusers to change only their formatter URLs (or to change nothing, if formatter URLs are dinamically taken from Wikidata) in order to keep effective links (while new properties oblige the reusers to change the Wikidata properties they read: in any case, a change is needed) Reformatting is a complication for reusers
4 Reformatting keeps the existing property’s IDs updated (while new properties would mean that errors made in the older properties may be corrected only in the new properties and remain unnoticed in the older ones; the same could be said for updates to subject named as (P1810) qualifiers) New properties allow reusers to continue using old IDs, if they want
5 Having two properties for two formats of the same ID may confound Wikidata users and reusers, e.g. associating one format to the wrong property Wikidata users may continue using the property with the old format instead of with the new one
6 New properties implies a substantial duplication of the IDs, which is detrimental for the easy consultation of the items and for storage capacity

Besides, there are some further characteristics of the specific case of SBN IDs:

  1. a relevant part of Italian library systems has only been using the short (“new”) format instead of the long (“present”) format
  2. VIAF has always been using the short (“new”) format (e.g. https://viaf.org/processed/ICCU%7CCFIV023920) in the ICCU processed pages
  3. reformatting is supported by ICCU (which manages the IDs) itself

Finally, in the discussion above, reformatting has been supported by 10 users (including me) and opposed by 1 user. Since a decision has to be taken (possibly before the dismissal of the old OPAC, which according to ICCU will happen during February causing link rot) and no decision on this matter could be unanimous, as the discussion shows, IMHO there is a sufficient, although not unanimous, consensus for the solution of reformatting; and, anyway, the other possible solution (new properties) has a narrower support. If @Ladsgroup: agrees, we can go on with the editing of the IDs; otherwise, we can wait another week for more opinions. --Epìdosis 20:03, 6 February 2022 (UTC)

@Epìdosis Yes. It doesn't have to be unanimous. I consider this consensus reached. Amir (talk) 12:53, 7 February 2022 (UTC)

Reformatting to-do listEdit

  1. old MnM deactivated https://mix-n-match.toolforge.org/#/catalog/4629 --Epìdosis 13:02, 7 February 2022 (UTC)
  2. SBN author ID (P396) adapted to new format --Epìdosis 13:08, 7 February 2022 (UTC)
  3. Wikidata:Requests for permissions/Bot/Dexbot 15 approved --Epìdosis 20:17, 13 February 2022 (UTC)
  4. SBN books ID (P5485) adapted to new format --Epìdosis 20:22, 13 February 2022 (UTC)
  5. autofix set for SBN books ID (P5485) --Epìdosis 20:25, 13 February 2022 (UTC)
  6. User:Bargioni/moreIdentifiers adapted to new P396 format --Epìdosis 21:16, 13 February 2022 (UTC)
  7. all values of P5485 reformatted by autofix --Epìdosis 11:47, 14 February 2022 (UTC)
  8. User:Magnus Manske/authority control.js adapted to new P396 format --Epìdosis 13:05, 15 February 2022 (UTC)
  9. User:Tpt/viaf.js adapted to new P396 format --Epìdosis 19:08, 16 February 2022 (UTC)
  10. all values of P396 reformatted by Dexbot and autofix --Epìdosis 19:19, 19 February 2022 (UTC)
  11. old OPAC SBN went offline at about 17 CET --Epìdosis 16:47, 28 February 2022 (UTC)
  12. formatter URLs updated, both in these properties and in the proposed ones --Epìdosis 16:57, 28 February 2022 (UTC)
  13. for P396, all templates adding articles to categories in Category:Articles with ICCU identifiers (Q18174792) have had the formatter URL updated, or a correction has been asked --Epìdosis 17:19, 28 February 2022 (UTC)
  14. new MnM uploaded https://mix-n-match.toolforge.org/#/catalog/5076 --Epìdosis 17:53, 6 March 2022 (UTC)

  transition completed --Epìdosis 17:53, 6 March 2022 (UTC)

Useful maintenance queriesEdit

Queries for divergent dates

--Epìdosis

Queries for qualifiers

--Epìdosis

Queries for homonyms

--Epìdosis

Discussion about replacing values with a new format or schemeEdit

Maybe we can continue the discussion here. Afterall, this was only advertized on Friday on project chat.

The question is if we should replace the values like "IT\ICCU\CFIV\017574" with "CFIV017574" or rather copy them to a new property and then eventually phase out. --- Jura 13:08, 7 February 2022 (UTC)

OK for continuing the discussion. I would suggest going on in Wikidata:Requests for permissions/Bot/Dexbot 15 just opened, in order not to disperse comments. I tried to summarize there what's been said until now. --Epìdosis 15:51, 7 February 2022 (UTC)
  • Let's not restart the discussion elsewhere. Bot permission requests are mainly to determine if the operator would correctly do it. --- Jura 15:53, 7 February 2022 (UTC)
Return to "P396" page.