Property talk:P528

Documentation

catalog code
catalog name of an object, use with qualifier P972

Description

the catalogue code of an object. This property need qualifier catalog (P972) to specify the catalog.

Represents

catalog code (Q45026116)

Data type

String

Domain

all (note: this should be moved to the property statements)

Allowed values

every catalogue has a specific and rigorous syntax established by the compilers (note: this should be moved to the property statements)

Usage notes

Use with qualifier P972

Example

According to this template:

Alcina (Q275627) => catalog code <HWW34> with qualifier catalog (P972) => Händel-Werke-Verzeichnis (Q847730) // or:
Alcina (Q275627) => catalog (P972): Händel-Werke-Verzeichnis (Q847730) with qualifier catalog code <HWW34>
Liberty Leading the People (Q29530) => exhibition history <La Galerie du temps (Q3094671)> with qualifier catalog code <203>
See also: inventory number (P217)

According to statements in the property:
The Night Watch (Q219831) → 2016
The Starry Night (Q45585) → JH1731
Irish Red Cross (Q11282482) → CHY3950
Symphony No. 40 (Q231390) → K. 550
FOSSGIS (Q1389424) → 90 VR 3594

When possible, data should only be stored as statements

Source

any catalog (note: this information should be moved to a property statement; use property source website for the property (P1896))

Tracking: usage

Category:Pages using Wikidata property P528 (Q37296153)

Structure

I do not know anything about astronomical catalogues, but as far as I understand, the same object can have several numbers depending on the catalogue. If so, I think we should have have the catalogue as a qualifier, not just as a source (If something changes the meaning of the statement, it should usually be a qualifier).

Also, is there any need to restrict it to astronomy ? We also have catalogues in other domains, see Wikidata:Property_proposal/Creative_work#Catalog number / Numero di catalogo. --Zolo (talk) 15:52, 10 June 2013 (UTC)[reply]

Interesting question. When I proposed this property, I also proposed here a qualifier property for the same reason of you. But someone suggested me to use catalogues as sources (also for other values), and it seemed to me a good idea. For me it is the same, even if using qualifiers it could be possible check the "orthography" of codes. So:

I haven't anything against a generalization of this property: it is a good idea;
For the reason explained above, it could be better using one (or more?) qualifier(s) instead of "source properties".

Only a question: as do we manage with qualifiers the huge number of catalogues of different domains? --Paperoastro (talk) 18:20, 10 June 2013 (UTC)[reply]

Actually I am afraid that we need to repeat things twice. We need the qualifier name of the catalogue as a qualifier (because it changes the meaning), and once as a source, to state that we found the number in the real catalogue (and not that is has been copied from a very bad tertiary source, as sometimes happen in Wikipedia), and possibly to add some details about URL, the date when the information was retrieved, or the book page. That is a bit redundant, but I think it make sense, and after all, bot will take care of it.

I do not think there is any problem with having various catalogues using the same property: we just should have something like

Catalogue number: XX
<small>catalogue name (item type qualifier): The funny catalogue of funny things</small>

There is no limit in the number of catalogues that can be accomodated this way.

Alternatively we could do things other way around, using the catalogue name as the main property and the number as the qualifier (I do not think it matters much). --Zolo (talk) 19:29, 10 June 2013 (UTC) --Zolo (talk) 19:29, 10 June 2013 (UTC)[reply]

Thank for your explanation and patience :) If it can be useful, we can reopen my qualifier proposal. ;) --Paperoastro (talk) 21:08, 10 June 2013 (UTC)[reply]

I think Wikidata:Property_proposal/Creative_work#Catalog number / Numero di catalogo is enough, I have added a link from Wikidata:Property_proposal/Generic. --Zolo (talk) 21:31, 10 June 2013 (UTC)[reply]

Extension of the property

Can we extend the application field of the property to ID's of database/catalog which have no specific property ? This will be used in source section with "stated by" for the name of the database. Snipre (talk) 17:59, 18 August 2013 (UTC)[reply]

Like this as an example. It's ok for me! -- Lavallen^talk(block) 18:15, 18 August 2013 (UTC)[reply]

Ok also for me. Do we need to modify some constraints? --Paperoastro (talk) 07:43, 19 August 2013 (UTC)[reply]

{{Constraint:Item|property=P60}} would not make sense anymore. "Unique value" will have several false positive, but I think we can live with that. P107 will be deleted sooner or later... -- Lavallen^talk(block) 07:52, 19 August 2013 (UTC)[reply]

Ok to remove {{Constraint:Item|property=P60}} and P107, of course. Unfortunately "unique value" is very useful for astronomical objects, because indicates items that should be merged. --Paperoastro (talk) 08:11, 19 August 2013 (UTC)[reply]

I think we can keep it (the unique value), but be prepared to some false positive. -- Lavallen^talk(block) 08:18, 19 August 2013 (UTC)[reply]

I have requested to have a "type of catalogue" property to be used as qualifier of this one.--Micru (talk) 14:01, 19 August 2013 (UTC)[reply]

It will not work inside sources. -- Lavallen^talk(block) 14:11, 19 August 2013 (UTC)[reply]

but it can be used as qualifier when this property is not used inside sources (as for astronomical objects, for example). --Paperoastro (talk) 14:29, 19 August 2013 (UTC)[reply]

It will work inside sources if it replaces 'stated in'. Filceolaire (talk) 21:23, 19 August 2013 (UTC)[reply]

Modify my example above to show how! -- Lavallen^talk(block) 06:30, 20 August 2013 (UTC)[reply]

I can't find your example but here is mine:

- - Source: 'Catalog' 'astronomical catalog (Q605175)'
  - Source add 'catalog code (P528)' 'M31'
  - Source add 'catalog code (P528)' 'NGC 224'

I used 'Catalog' as the property name instead of 'type of Catalog' because I think that name is better. Filceolaire (talk) 23:44, 20 August 2013 (UTC)[reply]

Oppose, it is better to create separate property with different constraints, "wikification", then mix different catalogs in one property. Separate properties are better controlled (for example situation with missed catalog-type qualifier is impossible). — Ivan A. Krestinin (talk) 18:25, 20 August 2013 (UTC)[reply]

Are you aware of that there is ~1,500,000 databases of this kind (from my example) only in Sweden? Every single priest made such database every year during 500 years. -- Lavallen^talk(block) 19:17, 20 August 2013 (UTC)[reply]

Is it really no database where all these databases are merged? I do not find original document using reference in your sample. Could you please give direct link to the document or to some record about the document if this is possible? — Ivan A. Krestinin (talk) 19:54, 20 August 2013 (UTC)[reply]

In this case there is a merged database since it is from 1990, but it is not online since it contains private information and the examples from 19th century and earlier cannot be linked. They are still only handwritten. -- Lavallen^talk(block) 05:30, 21 August 2013 (UTC)[reply]

Ok, thank you for explaining the situation. For merged database is better to refer using this database identifiers as I think. This make data more verifiable both by humans and bots. For handwritten documents: is where some global catalog of these documents? — Ivan A. Krestinin (talk) 19:36, 21 August 2013 (UTC)[reply]

In some cases yes, this information is public but the digitization has been made by private organisations who wants us to subscribe to reach the information. In this specific case, I do not think bots should crawl in the database since you have to interpret the information you get manually. The 19th century and earlier documents are as I said handwritten and you have to be more or less expert to interpret the information. It is not necessarily hard to read them, but they contains a lot of more or less coded information. -- Lavallen^talk(block) 08:35, 22 August 2013 (UTC)[reply]

Hello, I would propose to make it even more general. Something like "identification number". Sometimes we need to provide an id that is not really in a catalogue, but there does not seem to be much point in having a separate property. For instance, as mentionned on my talk page user:Pyb needs something to add the number of the box where someone's ashes lies.

I would also prpose to modify the format when this property is used on a standalone basis (that is not in a reference). For instance in Messier 86 (Q2577), I would replace:

Catalog code: PGC 40653 
source: stated in: Simbad

with

Catalog: Lyon-Meudon Extragalactic Database
qualifier: identification number: PGC 40653 
source: stated in: Simbad

Within their fields of expertise, people may think that the catalogue name is obvious, but I think we need to make things explicit here. . --Zolo (talk) 13:47, 4 September 2013 (UTC)[reply]

Looks like it would work with the example I talked about in PP/Generec earlier today:

Catalog:  Rundata (Q492230)
qualifier: identification number: U 11
qualifier: url: http://www.nordiska.uu.se/forskn/samnord.htm (a link to the database, even if it's not to the content of the database for exactly this signum)
source: whatever

-- Lavallen^talk(block) 19:44, 4 September 2013 (UTC)[reply]

In general for me is not important how we use this property (as "main" property or qualifier), and I like your proposals, but in this discussion Ivan pointed our attention on the difficulty to use Constraints with qualifiers. At now the Unique value constraint is very useful for the intricate items of the objects listed in the New General Catalogue (Q14534), so, at now, I prefer to use this property as "main" property for the astronomical objects. --Paperoastro (talk) 20:49, 4 September 2013 (UTC)[reply]

I think we need to have the same format in all topics, otherwise it will be a bit complicated to use. We can also make the catalogue number the main property, and the name of the catalogue the qualifier. That would make the transition simpler, but that feels a bit strange. And I do not think the "unique value" constraint car really work without qualifiers. That may work for astronomy catalogues (actually I do not understand exactly how they work...), but take artworks: they are usually listed in a catalogue of the artist's work, and have very simple identification number like "12" or "122". In this case the identification number alone cannot guarantee uniqueness, we need catalogue name + catalogue number.

Yes, it seems to be essentially the same proposal as Wikidata:Project_chat/Archive/2013/08#Database_property, I had missed that. I have left a message at User talk:Ivan A. Krestinin --Zolo (talk) 05:54, 5 September 2013 (UTC)[reply]

The constraints are a problem, but users like Byrial can maybe do a more detailed analys from dumps of the database than the toolserver can? -- Lavallen^talk(block) 06:59, 5 September 2013 (UTC)[reply]

yes and... no! :-( Yes: there are many items with the same label and using Byrial toolserver will be very useful. No: there is an intrinsic problem into the NGC catalogue: for historical reasons (e.g., position errors, duplicate observations...) many real objects have two or more NGC identification number, but more recent catalogues (e.g., Uppsala General Catalogue (Q615925), 2MASS (Q1454942)...) use only one identification number. A "good" case is Q31264 (NGC 6/NGC 20): some Wikipedias use the name NGC 6, others NGC 20, but the object is one and also the item. A "bad" case is Q631985 (NGC 577/NGC 580): some Wikipedias have articles for both of them! So we have two items for one real object (in this case Q631985 and Q860921)! Use the "unique value" constraint with other catalogues, we can find the "duplicate items", remove the duplicate statements, and (my idea) add said to be the same as (P460). In this table there is some other examples. I'm sorry, I know, it is a very boring and specialistic thing, but if there is another manner to do this, I will be very happy to abandon unique constraint. --Paperoastro (talk) 20:36, 6 September 2013 (UTC)[reply]

Note that catalog (P972) has been created, it can be used as a qualifier for this property. --Zolo (talk) 05:54, 21 October 2013 (UTC)[reply]

Two ways of using this property, which one is right?

Zolo, Paperoastro, Lavallen: I have seen 2 different uses of this property, either sourced with the catalog name or qualified with catalog (P972). What is the correct option?--Micru (talk) 01:34, 25 November 2013 (UTC)[reply]

The proposal about catalog (P972) was to use it as a qualifier of "catalogue name" as a qualifier for the catalogue number. That said, if we get the catalogue number directly from the original, it may make sense, to use that as a source as well (that would indicate that we checked the original catalogue and did not just import the id from a database, and we could add so info like the page number in the source). --Zolo (talk) 08:10, 25 November 2013 (UTC)[reply]

In the case of astronomical objects (my prevalent use), the catalogue name is recovered by some databases (as SIMBAD (Q654724)) that are the source of the information. So, it make sense for me to specify the catalogue using P972 as qualifier. If there is no technical prescription, we will continue to use both of ways. --Paperoastro (talk) 20:52, 25 November 2013 (UTC)[reply]

Domain

Zolo, Paperoastro, Lavallen, Snipre, Filceolaire: some time ago the description of this property was changed to reflect that it could be used for everything, but thanks to Pigsonthewing I just realized that the documentation of the property still says that the domain is astronomy. Is that still wanted or can we change it? It would be great to be able to use it for music catalogues or for accession numbers. Another possibility would be to use inventory number (P217) instead.--Micru (talk) 10:45, 20 March 2014 (UTC)[reply]

As far as I understand, I think we agreed to use it in more places, but maybe failed to agree exactly how. -- Lavallen (talk) 16:07, 20 March 2014 (UTC)[reply]

This property was proposed for astronomical objects, but in general I was agree to expand its domain (see discussion above). The only (technical) problem to generalize it is the constraints "Unique value", useful for astronomical objects. Perhaps is better another property? --Paperoastro (talk) 20:59, 20 March 2014 (UTC)[reply]

The "unique value" constraint is still valid for other catalogues, it wouldn't be a problem.--Micru (talk) 11:58, 21 March 2014 (UTC)[reply]

The "unique value" would be valid for other catalogue number + catalogue name couple., not for catalogue number along. Most catalogues raisonnées have entries like like "23" or "47". So numbers like "23" would not be unique.

I do not know about merging this property with inventory number (P217). In a way that could make things simpler, but all databases that I know clearly separate catalogue number (associated with a particular reference book), and accession numbers (associated with an instition, but conceptually more or less indenpendent from catalogues).

Notified participants of WikiProject Visual arts. --Zolo (talk) 14:09, 21 March 2014 (UTC)[reply]

Not sure what to say - in the case of the Amsterdam museum and the Rijksmuseum, for many paintings there are accession numbers maintained by both institutions for the same paintings. I think we need a coupled set of properties such as "is in institution x with accession number y" and "is in catalog x with catalog number y". Jane023 (talk) 19:03, 21 March 2014 (UTC)[reply]

inventory number (P217) and catalog code (P528) could be different in the case of astronomical catalogues. @Jane023: in astronomy the "catalogue number" is always prefixed by an acronym of the name of the catalogue (e.g. NGC for New General Catalogue (Q14534)). If the nomenclature of painting (or others) catalogues are similar, P528 and P972 can cover all cases without new properties. --Paperoastro (talk) 19:24, 24 March 2014 (UTC)[reply]

For artworks numbers, the catalogue number usually refers to a number in the catalogue raisonné of the artist's work. They are numbered from 1 to X (X usually between 100 and 1000). There are common abbreviations for well known catalogues. For instance, if you want to say that a painting is number X painting in Faille's van Gogh catalogue you can put it this way : F X. But the number provided in the book is X, not F X and if you want to write out the full reference, it should be : Faille, Van Gogh Catalogue, n°X, not Faille, Van Gogh Catalogue, n°F X). And anyway there are certainly many other catalogues that are abbreviated at X, so that adding the prefix would not make the number unique. -Zolo (talk) 08:09, 25 March 2014 (UTC)[reply]

Unfortunately, they are not - and it's not just galleries, but museums, libraries and archives that need to be considered. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:16, 24 March 2014 (UTC)[reply]

How to use the property?

Hello, is there any sample how to use this property in Wikipedia templates? How to extract identifier for concrete catalog? — Ivan A. Krestinin (talk) 20:54, 8 August 2014 (UTC)[reply]

Include catalog prefix in value?

Should the prefix of the catalog (Bach-Werke-Verzeichnis (Q214203) BWV, Guide Star Catalog (Q143003) GSC, etc.) be included in the value? In my opinion, it’s completely redundant information (since the catalog is already specified by the qualifier catalog (P972)), so when adding catalog codes to musical items, I’ve omitted it. On the other hand, Betelgeuse (Q12124) for example includes the prefix in all the catalog code statements, and I’ve seen lots of edits by Hardwigg and Xmlizer that added Köchel catalogue (Q162478) catalog codes to Mozart’s compositions, all following the pattern “K. 123”, so obviously some would disagree with me. Can we decide on the correct usage now? WikiProject Music has more than 50 participants and couldn't be pinged. Please post on the WikiProject's talk page instead. —DSGalaktos (talk) 09:58, 28 March 2015 (UTC)[reply]

Note: the property is used in ru:Шаблон:Звезда as is, without qualifiers processing. Removing prefixes will make template output unstructured numbers sequence. So please change the template logic before removing prefixes. — Ivan A. Krestinin (talk) 10:37, 28 March 2015 (UTC)[reply]

For template usage we’d then need to record the template prefix on catalog items. Probably even as monolingual text – for example, Köchel catalogue (Q162478) is abbreviated “K.” in English, but „KV“ in German. —DSGalaktos (talk) 11:07, 28 March 2015 (UTC)[reply]

This property was used for astronomical objects only originally. Astronomical catalogs have stable interlingual prefixes. For example NGC is used for New General Catalogue (Q14534) in all languages. — Ivan A. Krestinin (talk) 11:33, 28 March 2015 (UTC)[reply]

I recently added catalog codes to Mozart's Symphonies. The only reason I used the prefix was because before I began, 11 Mozart compositions had P528, and 10 of these used the prefix, so I used what appeared to be more popular. However I agree that it makes more sense not to, and that the prefix data should be stored with the catalog item (somehow). Should I fix my edits now, or wait for a consensus on this post? —Hardwigg (talk) 22:04, 29 March 2015 (UTC)[reply]

Given the above note, I’d wait with the edits, but I’ve now created Wikidata:Property proposal/Authority control#catalog prefix, so hopefully we can fix the situation soon. —DSGalaktos (talk) 08:51, 30 March 2015 (UTC)[reply]

Sounds good. I'll keep an eye on that page for any updates. –Hardwigg (talk) 23:47, 31 March 2015 (UTC)[reply]

@Ivan A. Krestinin, Hardwigg: could you perhaps give some feedback on the proposal? It’s been quiet over there… —DSGalaktos (talk) 14:25, 12 April 2015 (UTC)[reply]

I see this hasn't been discussed much here in a long while. Structured data in Wikidata should be language agnostic. Because abbreviations for certain catalog numbers (such as the Köchel catalog) are different depending on the language (German: KV, English: K), I would argue that the prefix should be omitted from P528. As others have stated, it is also redundant if the qualifier P972 (catalog) is used. Fuchsiaflute (talk) 17:46, 15 May 2024 (UTC)[reply]

Can we get rid of the unique value constraint?

With over 2000 violations and counting, this constraint is pretty useless. I have also started to notice that when I add catalogs through quick statements, the catalog number isn't added when the constraint kicks in, which is very annoying! Jane023 (talk) 07:25, 26 September 2016 (UTC)[reply]

Done. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:49, 3 October 2016 (UTC)[reply]

Thanks Andy! Jane023 (talk) 15:12, 3 October 2016 (UTC)[reply]

in identifiers

must be in identifiers not statements section, like in d:Q62703 Albedo (talk) 17:11, 4 January 2024 (UTC)[reply]

Property talk:P528

Contents

Documentation

Structure

Extension of the property

Two ways of using this property, which one is right?

Domain

How to use the property?

Include catalog prefix in value?

Can we get rid of the unique value constraint?

in identifiers

Navigation menu

Property talk:P528

Documentation

Structure

Extension of the property

Two ways of using this property, which one is right?

Domain

How to use the property?

Include catalog prefix in value?

Can we get rid of the unique value constraint?

in identifiers

Navigation menu

Search