Property talk:P3035
Documentation
part of an ISBN(-13) specific to a publisher
List of violations of this constraint: Database reports/Constraint violations/P3035#Type Q2085381, Q5, SPARQL
97(8-([0-57]-\d{1,7}|(65|8\d|9[0-4])-\d{1,6}|(6[0-4]|9[5-8])\d-\d{1,5}|99[0-8]\d-\d{1,4}|999\d\d-\d{1,3})|9-(8-\d{1,7}|(1[0-2]|6\d)-\d{1,6}))”: value must be formatted using this pattern (PCRE syntax). (Help)List of violations of this constraint: Database reports/Constraint violations/P3035#Format, SPARQL
List of violations of this constraint: Database reports/Constraint violations/P3035#Entity types
List of violations of this constraint: Database reports/Constraint violations/P3035#Scope, SPARQL
|
This property is being used by: Please notify projects that use this property before big changes (renaming, deletion, merge with another property, etc.) |
Constraints edit
@Zorglub27, JakobVoss, Thryduulf, John Vandenberg, Skim, VIGNERON:
WikiProject Books has more than 50 participants and couldn't be pinged. Please post on the WikiProject's talk page instead.
Hi, I'm not sure about the two first constraints : « unique value » and « single value » and I'd like you point of view. At least for the first, I guess there will be too much violations as it's not unusual for two publishers to share the same prefix.
For example :
- 978-2-01
- Deux coqs d'or (Q3024920)
- Gautier-Languereau
- Hachette
- Hachette Carrère
- Hachette collections
- Hachette Education
- Hachette Français langue étrangère
- Hachette Jeunesse
- Hachette jeunesse - Disney
- Hachette Littératures
- Hachette Pratique
- Hachette Supérieur
- Hachette Technique
- Hachette Tourisme
- Hachette-CIL
- Hachette-Informatique
- Hachette-Pluriel
- Istra
- Le Livre de poche jeunesse
- Octopus
- Pluriel
- SCOP
- 978-2-10 is used by :
- Dunod Editeur
- Ediscience
- Elsevier Masson
- ETSF
- Microsoft Press
(all these sub-publishers being more or less possessed by the same publishing company/group)
I've looked at the ANFIL publisher search engine, I can't find a single prefix own only by one publisher... I found some but most publishers share a prefix, only small publisher have a unique single prefix. Is it specific to France ? (and Belgium and french-speaking Africa which the AFNIL manage too)
On the other way around, should/could we be more specific on the format constraints ? For example, 978-1-21 is not possible as in France (and maybe elsewhere but I'm not sure) only these codes are attributed : 01 to 19, 200 to 349, 400 to 699, and so on (which is kind of logical and allow to automatically find the publisher prefix inside a random ISBN or add the three or four dashes).
Cdlt, VIGNERON (talk) 10:46, 7 August 2016 (UTC)
- 'single value' is for sure not right as small publishers are attributed new blocks/prefixes when exceeding the space given in their previous block (example: Hesperian Health Guides (Q5745871)). 'unique value' is more problematic but if sharing a prefix is indeed a usual practice, having several entities attributed the same prefix should be possible, it would only mean that one can't infer the publisher from this prefix. Zorglub27 (talk) 13:26, 7 August 2016 (UTC)
- I added some Czech publishers with multiple ISBN publisher prefixes. Examples are simple. When publisher was a small company, has a small block. If the block exceeds, has a new block, which conforms a size of company. Skim (talk) 20:59, 7 August 2016 (UTC)
- As for using a more specific format constraint, that seems rather unrealistic given the amount of data you would have to put and maintain, see for instance how much data that extra validation represents for the lib isbn3: those ranges are then periodically updated based on isbn-international.org data. -- Maxlath (talk) 12:19, 26 April 2021 (UTC)
ISBN(-10) prefixes edit
WikiProject Books has more than 50 participants and couldn't be pinged. Please post on the WikiProject's talk page instead.
Hi, what about ISBN(-10) prefixes? This prefixes are there, but this property doesn't handle it. Skim (talk) 05:22, 22 March 2019 (UTC)
- As far as I know, the ISBN-13 prefixes from the 978 block are equivalent to the ISBN-10 prefixes, so it wouldn't make sense to have a separate property to store the same data (less the 978 prefix). -- Maxlath (talk) 12:09, 26 April 2021 (UTC)
- @Maxlath: Yes, prefixes from ISBN-10 are compatible with 978- version without this prefix. But what about adding to publishing houses? We have source in National Library of the Czech Republic (Q1967876) e.g. this, where are "978-80-7292" and "80-85788". When i add to Wikidata, there is format constraint issue Axióma (Q111728553)). I believe that we need another property to ISBN(-10) version to comply with ISBN-10 (P957) and ISBN-13 (P212). It's better to have exact version of number to check on book and sources. Skim (talk) 09:04, 26 April 2022 (UTC)
- @Skim: If I get it right, a publisher that had an ISBN-10 prefix like "80-85788", but didn't use it all by the time they switched to ISBN-13, would also have publications that use the "978-80-85788" prefix, meaning that we would need to store both forms. Consequently, working with those prefixes would get sensibly harder: we would need to query both forms when looking up that prefix, and would need to handle the different forms when trying to regroup items by prefixes (which can be especially useful to find duplicated items). While if we just store "80-85788" in its ISBN-13 form as "978-80-85788", querying and deduplicating becomes much easier. What about keeping the ISBN-13 form as the canonical form, but use a reference property such as subject named as (P1810) to keep the information of how it was formatted in the source? -- Maxlath (talk) 09:54, 26 April 2022 (UTC)
- @Maxlath: Ok. Usage of subject named as (P1810) is interesting point. For me is ok, still i don't know if it's enough. I will ping librarians about this question. Skim (talk) 09:53, 28 April 2022 (UTC)
- @Maxlath: That's true that range e.g. 80-7320 and 978-80-7320 is same and could contain both versions of ISBNs. Skim (talk) 10:42, 28 April 2022 (UTC)
- @Maxlath: I have discussion with National library of the Czech Republic and we are trying define this concept. Will be some communication. Seems that we want describe 80-7320 and 978-80-7320 as items in NAK database (if are really used in books). This is not about Wikidata, still it's practical to check real ISBNs. Skim (talk) 12:29, 28 April 2022 (UTC)
- @Skim: If I get it right, a publisher that had an ISBN-10 prefix like "80-85788", but didn't use it all by the time they switched to ISBN-13, would also have publications that use the "978-80-85788" prefix, meaning that we would need to store both forms. Consequently, working with those prefixes would get sensibly harder: we would need to query both forms when looking up that prefix, and would need to handle the different forms when trying to regroup items by prefixes (which can be especially useful to find duplicated items). While if we just store "80-85788" in its ISBN-13 form as "978-80-85788", querying and deduplicating becomes much easier. What about keeping the ISBN-13 form as the canonical form, but use a reference property such as subject named as (P1810) to keep the information of how it was formatted in the source? -- Maxlath (talk) 09:54, 26 April 2022 (UTC)
- @Maxlath: Yes, prefixes from ISBN-10 are compatible with 978- version without this prefix. But what about adding to publishing houses? We have source in National Library of the Czech Republic (Q1967876) e.g. this, where are "978-80-7292" and "80-85788". When i add to Wikidata, there is format constraint issue Axióma (Q111728553)). I believe that we need another property to ISBN(-10) version to comply with ISBN-10 (P957) and ISBN-13 (P212). It's better to have exact version of number to check on book and sources. Skim (talk) 09:04, 26 April 2022 (UTC)
Wrong values edit
https://www.wikidata.org/w/index.php?title=Q16368652&oldid=1167270311#identifiers MrProperLawAndOrder (talk) 01:20, 8 June 2020 (UTC)
Done by those changes -- Maxlath (talk) 12:12, 26 April 2021 (UTC)
