Property talk:P972

Documentation

catalog
catalog for the item, or, as a qualifier of P528 – catalog for which the 'catalog code' is valid

Description

Either a) catalog where the item appears (used as qualifier for catalog code (P528)), or b) catalog of an exhibition (Q464980)

Represents

catalogue (Q2352616)

Data type

Item

Domain

exhibition (Q464980), or individual items potentially appearing in catalogs (note: this should be moved to the property statements)

Allowed values

catalogues - catalogue (Q2352616), often exhibition catalogue (Q780605) (note: this should be moved to the property statements)

Usage notes

Brukes som elementets katalog eller som kvalifikator for P528 katalogkode

Example

According to this template:

a) as qualifier:

NGC 42 (Q49648) => catalog code (P528): PGC 867, qualifier: catalog (P972): Principal Galaxies Catalogue (Q1479861)

b) as main property:

Mona Lisa Exhibition (Q15087813) => Mona Riza ten / Exposition la Joconde (Q15088275)
~~Hans Holbein the Elder (Q49987) => catalog (P972): Web Gallery of Art (Q1464063) + qualifier catalog code (P528): HOLBEIN, Hans the Elder~~

c) for encyclopaedia articles use:

Hans Holbein the Elder (Q49987) => described by source (P1343): Brockhaus Enzyklopädie (19 ed.) (Q17377889) + qualifiers volume (P478): 10, page(s) (P304): 183, section, verse, paragraph, or clause (P958): Holbein, Hans, d.Ä.

According to statements in the property:
The Night Watch (Q219831) → Catalog of the paintings on show at the Rijksmuseum in 1956 (Q16986324)
Cubism and Abstract Art (Q60332815) → Cubism and Abstract Art (Q55379663)

When possible, data should only be stored as statements

Robot and gadget jobs

DeltaBot does the following jobs:

Move source to qualifier

Question on usage[edit]

I have seen this property used for an encyclopaedia, and wanted to know whether that is an expected use. I have not considered an encyclopaedia to be a catalogue, though understand that an encyclopaedia has a syntax and a function that involves cataloguing. Please {{Ping}} me with a response so I don't miss it. Thanks. — billinghurst sDrewth 05:48, 21 October 2014 (UTC)[reply]

@Zolo: are you able to offer any clarity. The archive link to its proposal isn't helpful. — billinghurst sDrewth 23:02, 21 October 2014 (UTC)[reply]

@billinghurst: The use for an encyclopaedia sounds like an error. Can you link your example? --Kolja21 (talk) 23:25, 21 October 2014 (UTC)[reply]

@Kolja21: Ephraim George Squier (Q721839) — billinghurst sDrewth 03:46, 22 October 2014 (UTC)[reply]

Noting that adding RIGHT and WRONG examples would be useful, plus a little plumping of the explanatory text. Plus for WRONG, then a pointer to what should have been used (if existing) would be helpful. — billinghurst sDrewth 03:52, 22 October 2014 (UTC)[reply]

@billinghurst, Magnus Manske: +1. A better documentation is needed. I've added four examples. Imho this property should not be used for citing encyclopaedia articles. In the above case I would use described by source (P1343): Appletons' Cyclopædia of American Biography (Q12912667) + the qualifiers vol., page, and section, verse, paragraph, or clause (P958): "Squier, Ephraim George". Let's see what Magnus thinks about it. ("Reinheitsgebot", who did this edit, is his bot.) --Kolja21 (talk) 05:19, 22 October 2014 (UTC)[reply]

@Kolja21, billinghurst: My bot did these edits on behalf of manual matches between Wikidata items and "external identifiers" (to use a general term) using my mix-n-match tool. Several "catalogs" (my generalization; some are encyclopedias, others like YourPaintings are not) have their own property by now. I thought catalog (P972) to be a generic enough "anchor", but apparently we have a better one now. I can switch to described by source (P1343) and section, verse, paragraph, or clause (P958) easily enough; vol. and page however would not be set through my method, mainly because I do not have the information int the first place, at least not in machine-readable form. OTOH, work and article title should be a good enough start IMHO. Would that be sufficient? --Magnus Manske (talk) 08:07, 22 October 2014 (UTC)[reply]

@Magnus Manske: Sure, sounds good! Thanks for the fast reply. --Kolja21 (talk) 21:26, 22 October 2014 (UTC)[reply]

@Kolja21: Changed in the tool. Will probably just remove the "catalog" statements from the respective items, then add the new ones instead. I can do that with existing tools, no need to write new code! --Magnus Manske (talk) 22:04, 22 October 2014 (UTC)[reply]

Classes of items[edit]

Is it appropriate to use this as a property on classes of items ?

eg:

Thanks, Jheald (talk) 10:39, 8 November 2015 (UTC)[reply]

As a property[edit]

I do not see why this property should be a qualifier-only property, - and not a property-property. Many editors use it together with catalog code (P528) where catalog code (P528) is the property and catalog (P972) is the qualifier, but I use it (also) the other way round with catalog (P972) as the property and catalog code (P528). I see no reason to restrict catalog (P972) to be a qualifier only. Indeed there are a number of reason to allow both versions:

Redundancy can in some instances enable tools to better detect wrong information.
Having both version may make certain queries easier to formulate in SPARQL.
Magnus Manske's Listeria tools is a very nice system. It allows unambiguous identification of of catalogue codes in the case of catalog (P972)-as-a-property, see Talk:Q28466355 for an examples of a Listeria query. I do not see how to unambiguously identify the correct catalogue code when there are multiple catalogue codes.

I suggest we allow the use of catalog (P972) as a property. Indeed we get unfortunate problems when a user remove the instances. You can see that I use it for the works of Hans Christian Andersen (Q5673), Talk:Q28466355, and it harms noone. — Finn Årup Nielsen (fnielsen) (talk) 19:43, 24 May 2017 (UTC)[reply]

This is interesting. What should be done when some item is included in a catalog but the identifier in that catalog is a standard ID? Example: Directory of Open Access Journals (Q1227538) (DOAJ). It's cool querying every journal indexed in DOAJ but it's not useful storing the ID in Wikidata, since DOAJ uses ISSN (P236). Example Dynamis (Q4302890) -> 0211-9536/2340-7948 (they are both valid, printed and online). Wrt these situations I find using catalog (P972) as a "direct" property fine too. Strakhov (talk) 20:00, 24 May 2017 (UTC)[reply]

Catalog is used for the management of projects like "Black Lunch Table" and "Colección Patricia Phelps de Cisneros" among others. Thanks, GerardM (talk) 22:08, 12 June 2017 (UTC)[reply]

I removed the ridiculous constraint. The description and usage of this property has always been to use it as a property and as a qualifier. Multichill (talk) 12:20, 16 December 2017 (UTC)[reply]

I disagree. We should stick to one version. Inconsistent use of properties makes querying a lot more difficult and it's absurd to expect both ways stated for each item as done on Q42770530. I don't oppose redundancy where it is maintainable, I don't see that it's here. The use for the Black Lunch Table is a bad use as pointed out elsewhere. Ping @Jane023 as a heavy user of the property. --Marsupium (talk) 13:20, 16 December 2017 (UTC)[reply]

There seems to be confusion about the use of this property as a main property, and I'm concerned that the current definition above is not consistent between qualifier and property use.

As a qualifier, it is clear that P972 means an item is a "member of" a catalog, qualifying P528:catalog-code.
As a main-property however, from the example above Mona Lisa Exhibition (Q15087813) it means the item is the "owner of" a catlog. The exhibition has a catalog, it is not on the catalog.

I interpreted this talk section as being about, and consensus on, using P972 as a main property to denote membership of a catalog, but this conflicts with the current definition. "catalog for the item" is poorly worded and I think could be (and is) interpreted either way without further context, but combined with the example, means only the owner of/has a sense. This SPARQL query searching for non-constraint violating uses of P972 as a main property shows the majority are intended to mean "member of" a catalog. A small handful mean "has a" catalog. I don't know how to tell the two uses apart unambiguously. This seems like a clear double use for the same property, with completely different meanings, which cannot be correct.

Does it even make sense for this property to mean "member of" as a qualifier, but "owner of/has a" as a main property? It seems wrong to me, but perhaps there is a logical way to think of it? The original proposal only deals with qualifier clearly. As a main property appears to have been tacked on afterwards without the same consideration. Possibly with the wrong sense.
There is a reasonable desire to denote membership of a catalog without catalog code. According to the current definition of this property, I don't think that can be done correctly, with this, or any other property. It only works as a qualifier to catalog-code. There is nothing about catalogue (Q2352616) that states cataloged items must have codes AFAIK, yet the restriction is in place because of the qualifier usage of this property.

Hopefully I have been clear enough, I feel this is a major problem with P972 that has gone unnoticed, and the confusing definition has contributed to a lot of innocent misuse. Salpynx (talk) 04:46, 9 January 2018 (UTC)[reply]

Now I have just noticed that P972 is is a subclass of part of (P361) 'Part of', which goes against my interpretation of the current definition and example a meaning "has a", and that perhaps the majority usage intending "member of" from the query above is ok, and in fact the only correct use. Which is it? Both property meanings can't be valid, surely? This catalog (P972) seems broken. Salpynx (talk) 05:42, 9 January 2018 (UTC)[reply]

I'm using catalog (P972) as property in the new Wikidata:Wikiproject_Lieder which I started to make the scheme and collect all Lieder, Lieder cycles and their poems. I believe it makes much more sense to have catalog (P972) as property and catalog code (P528) as its qualifier as this is the way it is written in the works: D911, K104, etc. As per the items already in WD, I will add catalog (P972) as property for the ones that have catalog code (P528) as property, but I'm not intending to apply this redundancy with the new entries I will add. Please, let me know if there is any problem with this. --Robertgarrigos (talk) 08:22, 14 January 2022 (UTC)[reply]
I believe this property was incorrectly defined, although I understand the reason mentioned above. It is currently possible to set the qualifier as mandatory and generate a warning/error when someone misplaces it. However, we must accept that some of current uses are oriented to something similar to "member of" and maybe should be moved to on focus list of Wikimedia project (P5008). See:https://w.wiki/4gGe

I think the logical order is catalog >> number/id within the catalog, and it's a good initiative to start "migrating" to thematic blocks, like this case from Wikidata: Wikiproject_Lieder.

Salut ! Amadalvarez (talk) 13:14, 14 January 2022 (UTC)[reply]

@Robertgarrigos: please stick to the practice documented at Wikidata:WikiProject Visual arts/Item structure instead of invention something different yourself. Multichill (talk) 17:20, 14 January 2022 (UTC)[reply]

@Multichill I'm not inventing anything: it is already being done by other users, it is also permitted in the description of the property and Lieder have nothing to do with visual arts and might work differently. Robertgarrigos (talk) 17:25, 14 January 2022 (UTC)[reply]

@Robertgarrigos: you are. As you can see for the property statistics of this property:

Total 23,822,376

Main statement 68,888 0.3% of uses

Qualifier 23,753,372 99.7% of uses

Reference 116 <0.1% of uses

And the property statistics for catalog code (P528)

Total 28,737,373

Main statement 28,715,642 >99.9% of uses

Qualifier 17,221 <0.1% of uses

Reference 4,510 <0.1% of uses

So it's clear the established practice is to use catalog code (P528) as the property and catalog (P972) as the qualifier. Consistency of the data model across different domains is important for the usability of our data so please stick to the established model. See also Violin Concerto No. 1 (Q163689) and Piano Sonata No. 14 (Q12008) for examples closer to your domain. Multichill (talk) 17:36, 14 January 2022 (UTC)[reply]

@Multichill: No, I'm not inventing anything. It is already happening for music items: https://w.wiki/4ga5

Also, I read the whole thread here, and it is clearly and option as catalog (P972) has actually been changed to allow this.

Besides, it is a lot more logical for the classical music items, where the catalogue is normally included for the work in the form as, per example, D. 911, D. for the catalog (P972) and 911 for the catalog code (P528) Robertgarrigos (talk) 17:49, 14 January 2022 (UTC)[reply]

@Robertgarrigos: Let's focus on musical work/composition (Q105543609):

Using catalog code (P528) as the property and catalog (P972) as the qualifier: 5195 hits
Other way around: 689 hits

The fact that it's happening doesn't make it correct. Both was around are correct, we just made a modeling choice to do it in one way. The other way around might look more correct, but is it worth the inconsistency with millions of other items? I ask you to please stick to this to make Wikidata as a whole better. Would you be willing to do that? Multichill (talk) 18:38, 14 January 2022 (UTC)[reply]

Hi, @Multichill, how are you?

I understand your arguments and the figures support them. However, the inconsistency already exists and no one seems to be working to correct the misuses towards the original defined ontology. I mean, if some other editor like @Robertgarrigos decide to use the catalog-code format, the music figures may change in a few months, and then, the argument won't work.

I know the immense use of this property in Wikidata:WikiProject sum of all paintings where I participated. But, if we have assumed - in fact - the double structure, why don't we try to fix the current situation?

Obviously, one way is to reverse the entire catalog-code structure (not done so far). The other is to try to put things in order working with both of them. For example, allow this structure for specific domains, such as ... lieder. Or, why not, music, ...

If we do not move in either direction, the next time an editor makes growth the "wrong solution" cases, we will repeat this talk.

By the way. We are talking thanks to the goodwill of Robertgarrigos, who could have applied his point of view without saying anything here, as I suppose others have done before.

How do you see it? Amadalvarez (talk) 20:42, 14 January 2022 (UTC)[reply]

Doing fine. I hope the same fore you.

The inconsistency is currently less than 0.1% of all cases or less than 1 in 1000 cases. That's pretty consistent and small chance of running into it by accident.

This discussion is a bit like driving on the right or on the left: Both are correct, but if you mix the two, it gets really messy. What you're proposing is a bit like proposing a different side of the road to drive on. You should stick to the current side and if you get consensus to change to the other side, change everything in one go. Already changing some items to the other side now is a mistake and should be corrected. The fact that someone hasn't done so yet doesn't make it correct. Usually we set up constraints when we encounter these kind of cases. I added one to see how much it will catch.

Wikidata is a Wiki. We work by trying, making mistakes and having conversations to improve things. I'm sure we'll get consensus at some point. Multichill (talk) 21:27, 14 January 2022 (UTC)[reply]

Hello all, can you just, I don’t know, make a vote before make this kind of change ? Put the both way allows for multiple ways to find information. I think it’s important to note add a big constraint on this property. Lyokoï (talk) 22:20, 14 January 2022 (UTC)[reply]

And why that changment while next to it we have collection (P195) and inventory number (P217) which in exactly the same situation? (With this example : Codex Sinaiticus (Q152962)) Lyokoï (talk) 23:16, 14 January 2022 (UTC)[reply]

Hi Lyokoï, thanks. It's not exactly the same. P195+P217 is oriented to objects owned by a collection (like museum, or similar). However, P972+P528 (or P528+P972) define an inventory, list, etc. with the id given by the catalog editor. For instance, paintings have P195+P217 given by the museum criteria and one or more P972+P528 given by the catalogue raisonné (Q1050259) scholar criteria. Amadalvarez (talk) 07:32, 15 January 2022 (UTC)[reply]

The inconsistency is much larger when you work on musical work/composition (Q105543609): there are some 5000 items with catalog code (P528) as property, some hundred of them already have a double entry of catalog (P972) as property as well. This is 20 in 1000 cases. And I run into it.

I tried to have conversations on wiki projects to improve things many times, but I have to say that 100% of them end up saying: "things have been working like this since ...., don't change it". As if this make things right.

@Salpynx put it right, and the inconsistency is much larger everywhere. But your wishes will be heard. I don't have enough energy for everything. Robertgarrigos (talk) 00:01, 15 January 2022 (UTC)[reply]

It's quite difficult for me to follow the logic of this conversation because people seem to be talking about items I can't find. Certainly catalog code (P528) is oddly named. I would have preferred catalog number, which is what art catalogs use when they refer to artist or museum catalogs. As far as catalog (P972) goes, this has always supposed to be a publication, but some stubborn wikidatans have used it for online catalogs which are not published. An online catalog is at least a thing you can point to with a list of numbers or codes though. That said, opus number (Q385271) is definitely not a catalog. It's more of a P528 so maybe P528 should just get an alias for "opus number" and the qualifier could be applies to part (P518) pointing to opus number for clarification. The question then becomes "Is it alright to use P528 without a catalog?" and my feeling is no - someone needs to decide what the opus list is for the artist and make an opus item for use as a catalog for that artist (which could then be used in listeria lists the same way we do for art catalogs). Jane023 (talk) 09:12, 15 January 2022 (UTC)[reply]

I was talking with user:Moebeus the other day. He is quite active in the music field. He added a lot of statements the other way around (catalog/catalog code instead of catalog code/catalog), probably several thousands. He is willing to change the statements he worked on, he just needs some time for it.

Now that we have the constraint, we have an overview at Wikidata:Database_reports/Constraint_violations/P972#"Allowed_qualifiers"_violations. Multichill (talk) 19:05, 18 January 2022 (UTC)[reply]

Abuse of this property for original research[edit]

It appears that some people are abusing this property to store original research for their Wikiproject:

SELECT ?item WHERE { ?item wdt:P972 ?catalog . ?catalog wdt:P31 wd:Q21025364 }

Try it!

I'll probably start cleaning it up soon. permalink to the constrain violations in case people want to retrieve the list later. Multichill (talk) 20:02, 2 January 2018 (UTC)[reply]

@Multichill: Am I right in remembering some general discussion last month, I think on the wikidata mailing list, though it might have been on the facebook group, or even project chat, that P972 was quite an appropriate property for this purpose, analogous to its previous use for the Black Lunch Table? Jheald (talk) 16:46, 3 January 2018 (UTC)[reply]

I don't recall such a discussion. The Black Lunch Table is the offender with the highest number of violations right now. Using this property is not appropriate. Multichill (talk) 19:56, 3 January 2018 (UTC)[reply]

@Multichill: Please revert your edits and participate first in the discussion at Wikidata:Requests_for_deletions#Artist_of_Black_Lunch_Table --Pasleim (talk) 20:43, 3 January 2018 (UTC)[reply]

@Multichill: Because YOU didn't see the multiple discussions then you take this far-reaching and negatively impactful action?!? There's actually a discussion over on https://www.wikidata.org/wiki/Wikidata:Requests_for_deletions#Artist_of_Black_Lunch_Table right now. Where there was a six month plan for the initiative to address any issues of notability. This is (and I guess was) an outreach initiative on En Wikipedia that was addressing gender gap and diversity on the projects. It was one of the few that was successfully using Wikidata for its task lists, and was integrating Wikidata into its initiative. In one single swoop you have destroyed HOURS of work, and have deleted the utilization of Wikidata as a way to support outreach efforts. What give any of you this right. There has been discussion, but you haven't seen it. I'm really upset here. I was trying to evangelize Wikidata to Wikipedians at editathons. Take a minute to think now, why on earth I should continue to do this. I am beyond flabbergasted that this action was anything but a petty nasty attempt to shut down diversity on Wikidata. It's unacceptable. -- Erika aka BrillLyle (talk) 20:43, 3 January 2018 (UTC)[reply]

Also, it's NOT an abuse of original research. At all. The fact that this is the characterization means you have not done due diligence and taken the time to actually understand what this property is being used for. This is about outreach and creating notability scaffolding on Wikidata to onboard the articles onto Wikipedia. And to encourage its use in multi-lingual approaches in other outreach projects. You are impacting multiple initiatives here. Very negatively. -- Erika aka BrillLyle (talk) 20:46, 3 January 2018 (UTC)[reply]

This seems to be merely about deleting imaginary catalogues. The other discussion is about the deletion of items consisting entirely of unreferenced statements and without sitelinks. Maybe the word "catalogue" has a different meaning in some languages. At least, I failed to grasp how it could mean "WikiProject".
--- Jura 20:47, 3 January 2018 (UTC)[reply]

Yet another person who is not listening to what is going on here. If you researched what is being one here you would understand. Just because you do not understand this usage doesn't mean that it is incorrectly utilized here. I have a master's in library science. I understand this usage. I am not sure why this is something that a few people can destroy or support destroying. Beyond the fact that consensus has been made elsewhere in support of this usage. I continue to be amazed by this. It makes me want to abandon all the good work being done on Wikidata -- and recommend others abandon it too. -- Erika aka BrillLyle (talk) 20:51, 3 January 2018 (UTC)[reply]
- I notice you complained about being "lectured" by Wikidata administrators, but I don't quite understand why you attempt to do what appears to be the same instead of just providing us with the reference that supports your meaning of "catalogue".
  --- Jura 20:56, 3 January 2018 (UTC)[reply]

@Multichill: I was under the impression that we reached a consensus on this issue via the discussion. I second the request to please kindly revert your edits and participate first in the discussion at Wikidata:Requests_for_deletions#Artist_of_Black_Lunch_Table Thank you@Pasleim:. Black Lunch Table was using the Catalog property in good faith and had spoken with many Wikipedians before doing so. @GerardM: I was told the only thing missing was references to notability, which is being fixed as quickly as humanly possible. I look forward to your contributing to our discussion.--Heathart (talk) 22:12, 3 January 2018 (UTC)[reply]

No problem as such. We just can't leave in an imaginary catalogue. To avoid such problems in the future, did anyone other than GerardM suggest to you to use this property?
--- Jura 22:18, 3 January 2018 (UTC)[reply]

@Jura1: This was discussed very widely, multiple times, on project chat and on the mailing list and elsewhere. Nobody in those discussions raised any problems.

The usefulness of tagging items with Wikidata statements to enable WDQS queries on a group of interest, that can then be used to drive projects, is now well proven, and should not be sacrificed. If people object to the mild extension of P972 to facilitate that, then the only question is whether we are going to use some other property to do the job (eg P4570 (P4570), or if a new property needs to be created. Jheald (talk) 23:27, 3 January 2018 (UTC)[reply]

The imaginary nature of this catalogue and the problem with original research was mentioned in the deletion discussion. Obviously discussions at Wikipedia are important to them, but I'm really interested if someone here at Wikidata suggested this. Can you provide a link to any onsite discussions about this?
--- Jura 23:32, 3 January 2018 (UTC)[reply]

Here's a set of wikidata-l mailing list posts mentioning Black Lunch Table: [1], starting in February last year.
After various mechanisms were considered and rejected in the initial mailing list discussion, a specific property was then proposed.
The property proposal was ultimately rejected; but in the process User:Pigsonthewing suggested using catalog (P972). (21:03, 24 February 2017).
This was then raised further at Wikidata:Project_chat/Archive/2017/03#Catalog_and_Catalog_code (26 February onwards).
By March 22, according to a mailing list post, use of P972 for the purpose was in full swing and working well. It has since been mentioned many times on that list, as can be seen in the set of posts linked above; and also at project chat: [2]. Jheald (talk) 00:01, 4 January 2018 (UTC)[reply]
Here's also Gerard presenting the mechanism to the "Wikidata + GLAM" facebook group, to a number of positive comments [3]. (9 March 2017). Dan Brickley explicitly clarifies "So it's items catalogued into https://www.wikidata.org/wiki/Q28781198 ?" Jheald (talk) 00:13, 4 January 2018 (UTC)[reply]

Looking at the one on project chat, it seems that it was dropped it as it didn't get any support and P972 remained unchanged. Some posts at least have the merit of not amalgamating it with third party identifiers. I'm not aware the Facebook is a suitable forum to develop this. I think at some WMF sites, users are rather hostile if you tell them it was coordinated on Facebook rather than onwiki.
--- Jura 00:22, 4 January 2018 (UTC)[reply]

I don't know how you get that interpretation. On 7 March Gerard clearly states he's now using P972, and no-one objects. Gerard thinks it may nevertheless be suboptimal (12 March), but nobody asks him to stop, or suggests anything else. And by 21 May, on the property proposal page, he's writing that 'The current solution of using "catalog" with "Black Lunch Table" works really well', pinging a slew of people including Multichill. That's in addition to all of the off-wiki forums where he flagged up what he was doing.

FB is indeed no place to make policy. But it's not a bad place to let people know what you're doing. Gerard's not always the easiest person, but this time you can't fault him. He went out of his way to let people know what he was doing, on multiple forums; and all through this period there was nobody that raised a single note of dissent. Jheald (talk) 01:03, 4 January 2018 (UTC)[reply]

Given the constraint violations, it's not being used correctly. So I'm doubtful how one could write that it "works really well". People might have trusted this and it's probably only once someone dumped 600 mostly empty and otherwise unreferenced items into Wikidata that we noticed that this was original research. The amalgamation with third party catalogues might have obscured it too. Other WikiProjects/editathons are much more thorough with the basis they use for lists. Clearly we need to develop better guidance to avoid this in the future.
--- Jura 01:40, 4 January 2018 (UTC)[reply]

On what planet is this original research. And the action Multichill took -- WITHOUT good faith -- means that no alternative can be used, even if an alternative would be possible. And please, name the other WikiProjects and editathons that are using Wikidata so effectively. Please, elucidate. Because as far as I know, the Black Lunch Table was the first and only one for months. To great effect. The reasoning to justify this very aggressive and destructive behavior is so far not logical. It is unfortunate that there seems to be this late-breaking problem, as there has been consensus given that what we were doing was okay -- and a real understanding on the part of other Wikidatans on the effectiveness of this catalog property to connect Wikipedia and Wikidata. Just because you all don't get this shouldn't mean you can destroy so much work and outreach. Which was done in good faith. Unbelievable. -- Erika aka BrillLyle (talk) 06:09, 4 January 2018 (UTC)[reply]

It was not apparent from the proposal on which I commented, that the list was original research, rather than a bona fide external catalogue. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:17, 4 January 2018 (UTC)[reply]

Also, I did not "suggest using catalog (P972)", I suggested "Use QID, or use catalog code (P528)/ catalog (P972).", The examples I have seen recently do not include any BLT code, or identifier. Without a code (let alone a meaningful code), the property serves as no more than a tag; and is no more useful than keeping a list of QIDs on a talk page. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:27, 4 January 2018 (UTC)[reply]

Actually, Andy it is hugely more useful than keeping a list of QIDs on a talk page, because WDQS can read it. The appropriate analogy is tagging a group of pages on Commons with an ad-hoc category, that one can then use to run database queries for that group of files. That is an entirely uncontroversial maintenance and management strategy, and very very useful. P972 may not be the right property to use (or rather: pretty much certainly isn't). But to have some property that can be used to do this kind of job is very very valuable. One possibility would be the new P4570 (P4570) property; another possibility would be a new property for the purpose. But it should be possible to move the now objected-to uses of P972 to their new property with minimum fuss or drama. In contrast, outright deleting them is entirely unhelpful. Jheald (talk) 13:59, 4 January 2018 (UTC)[reply]

@Pigsonthewing: I agree, the WDQS functionality is useful and key here. By all means, we can find another use of property that may be more appropriate long-term, but it is important not to break existing functionality. The current system was set up on what appeared to be consensus at the time, and should only be changed when we have a viable solution that doesn't break an important project.--Pharos (talk) 14:19, 4 January 2018 (UTC)[reply]

Maybe after consensus somthing has been lost: I read: instance of (P31)=Wikidata qualifier (Q15720608) and instance of (P31)=Wikidata property related to creative works (Q18618644) not for human (Q5) --ValterVB (talk) 20:16, 4 January 2018 (UTC)[reply]

The discussion if P972 can also be used as property and not only as qualifier is going on in the section above (#As_a_property). If P972 can also be used for humans seems okay when looking at the result of this query. --Pasleim (talk) 20:37, 4 January 2018 (UTC)[reply]

I meant: if there is consensus, why don't change claim of the property so we avoid problem with constraint and make the use clearer? --ValterVB (talk) 20:50, 4 January 2018 (UTC)[reply]

The constraint which restricted it to be used as qualifier is already removed [4] and a constraint restricting it to works never existed. --Pasleim (talk) 20:53, 4 January 2018 (UTC)[reply]

You are right, I read otherwise, it's Black Lunch Table (Q28781198) that don't respect the constraint, sorry, it's necessary change instance of (P31) of it. --ValterVB (talk) 21:01, 4 January 2018 (UTC)[reply]

Done. Making Black Lunch Table (Q28781198) an instance of both WikiProject (Q21025364) and catalogue (Q2352616) solves the problem. If someone requires to split both aspects just create an item "Black Lunch Table catalog". -- JakobVoss (talk) 10:09, 10 January 2018 (UTC)[reply]

I was about to thank you for making this edit, as I had made the same solution proposal on Wikidata:Property_proposal/Wikidata_focus_list a few days ago, but unfortunately I see user Jura1 has immediately reverted the edit. Rather than getting into a revert war, I don't think the statement needs a reference. If we can reach an agreement that it is the correct solution to fixing the constraint violations for an already implemented use that is valid in principle, then it will fix the many violations. I am prepared to argue these points further with evidence, but to put this ridiculous storm in a teacup into perspective, 2 of the three examples in the Documentation above also violate the same constraint, and have done so for YEARS without being noticed or challenged. One since a user edit in 2014, the other I can't see has ever not violated the constraint. I have tried to raise some issues with inconsistencies with this property in the Property section above, but the whole argument about protecting the perfect sanctity of P972:catalog seems like a joke. Given the poor nature of the definition, examples and conflicting definitions, BLT deserves to be cut some slack on this, and is probably due an apology. I contend that BLTs interpretation of this property is correct, and opponents can't even agree how their usage is incorrect, because the whole P972 property is so damn confused. Wikidata property related to creative works (Q18618644) instance seems also wrong because the original proposal states it is for "Creative works, celestial objects, probably other things.", and since an early and demonstrably good sophisticated use of the property is for astronomical catalogs, restriction to works is also wrong. Happy to keep trying to argue points with evidence, but I'm beginning to wonder if that is really what this is about. Having constraint violations does not somehow magnify these nebulous oppositions that are being surfaced and make them automatically indefensible. The constraint violations are what needs to be addressed, all BLT are guilty of is being active editors doing work that the mainstream opinion agrees is valuable, and have popped up on someones radar for something that can be resolved by a single property edit. Salpynx (talk) 21:54, 10 January 2018 (UTC)[reply]

@Salpynx: Constraint violations are like smoke alarms. You can always take the battery out of the alarm to stop it going off -- that's easy enough to do -- but it's not always such a good idea.

The fundamental here is that there are users who want to be able to distinguish whether a grouping of items has an external independent verifiable retrievable source, or whether it's a grouping that's been created in a more ad-hoc way as something of practical usefulness. It's simple enough to satisfy that desire, by having different properties for the two use-cases. So let's just do it. Jheald (talk) 22:50, 10 January 2018 (UTC)[reply]

@Jheald: I agree that Constraint violations are like smoke alarms, but what you refer to further up "On 7 March Gerard clearly states he's now using P972, and no-one objects.", I believe Gerard was in good faith following advice that implicitly (and reasonably) expected him to use a catalogue (Q2352616) as a value. Gerard made a small mistake (no offence meant by this!) and accidentally set the off the smoke alarm. If he happened to use a catalogue (Q2352616), everything would have unfolded the same, except we would not be having this discussion about constraint violations. Not wanting to drop anyone else in hot-water, but here is a potentially comparable 'catalog' list of things, Wikipedia:List of articles all languages should have (Q5460604) that has gone under the radar with dual instance of (P31), so does not violate any constraints. It has no statement references, but links to wikimedia in talk page. I am finding it hard to stay focused on the one or many issues here. Constraint violations, or conditions for making P31 claims. Are there any instance of (P31) catalogue (Q2352616) that are backed up by references? Jheald, I really appreciate you are trying to be constructive, and I was going to support your new property proposal given that P972 has definition issues, but now I think the original intent of P972 supports the current use, and catalogue (Q2352616) is a suitably vague class that is already being used as a list, while more specific things are subclasses of it. The proposal is for a new 'list', not a 'catalog', I'm not sure what the practical difference is, any criticism of BLT could equally be levelled at the new property use without clear guidelines that should be just as applicable to the current P972 use. I don't believe anyone has shown a valid reason why P972 or Q2352616 are inappropriate, rather they have demonstrated they have not looked closely at the definitions themselves. I would like to see the burden of proof placed on those who think there is a fundamental problem. (Excluding issues that have already been dealt with, and taking into account that this use has been ongoing for sometime by a range of editors). I am trying be helpful, but feel BLT is being targeted unfairly by easy to point out inconsistencies that are in fact all over wikidata, and are being selectively applied. It is hard to counter everything with evidence, and I am getting tired already. BLT have other work to do and probably can't take the time to do it, the obvious outcome is to get exhausted and drop it. Salpynx (talk) 00:19, 11 January 2018 (UTC)[reply]

@Jheald: In this case, the fire is that P972 has confusing and inconsistent property use descriptions. It surfaced the fact that a previously accepted definition of "or b) catalog of an exhibition (Q464980)" is technically incorrect (someone please check my argument), and BLT in fact uses the correct sense. Hooray for working smoke alarms! Salpynx (talk) 01:14, 11 January 2018 (UTC)[reply]

"Yet another person who is not listening to..." - please do not attempt to dismiss people who legitimately disagree with you in such a manner. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:03, 4 January 2018 (UTC)[reply]

There appears to be some off-wiki canvassing; see https://lists.wikimedia.org/pipermail/wikidata/2018-January/011663.html. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:43, 4 January 2018 (UTC)[reply]

Wikidata:Property_proposal/Wikidata_focus_list now proposed, to take over some existing uses of this property. Jheald (talk) 12:55, 6 January 2018 (UTC)[reply]
- It's interesting to note who were the first two people to oppose that proposal. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:28, 11 January 2018 (UTC)[reply]
Comment It seems that participants of this Wikipedia project deliberately use Wikidata for original research. Possibly their articles keep getting deleted from English Wikipedia and someone led them to believe that Wikidata is a host for original research. If a catalogue isn't published, it's not a suitable value for this property.
--- Jura 10:44, 11 January 2018 (UTC)[reply]
I agree that this property is being misused and agree that the list of items should be preserved (history of the constraints page is fine as long as the list can be easily reused for another property. Strange that the alternative property "Wikidata_focus_list" is being contested by the same people abusing this property. Weird. Maybe we should set up best practises for temporary Wikimedia projects that take the items listed on a page (say a subpage of Wikidata:GLAM) and create a listeria list from it, using "Wikidata_focus_list". Nothing more is needed, as far as I know. Jane023 (talk) 15:08, 11 January 2018 (UTC)[reply]

Wikipedia:List of articles all languages should have (Q5460604)[edit]

Now that there is on focus list of Wikimedia project (P5008), I think the above value should use that property.
--- Jura 10:39, 11 April 2018 (UTC)[reply]

Agreed, and I see that has been done already e.g. here. Jane023 (talk) 11:05, 15 April 2018 (UTC)[reply]

Value type constraint[edit]

I have broadened the value type constraint from "instance of" to "instance and subclass of", because some catalogs seem to consider the (abstract) collection a "subclass" of a type of catalog, and reserve "instance" to refer to a specific physical copy of the catalog. Deryck Chan (talk) 14:35, 19 January 2019 (UTC)[reply]

Property talk:P972

Contents

Documentation

Question on usage[edit]

Classes of items[edit]

As a property[edit]

Abuse of this property for original research[edit]

Wikipedia:List of articles all languages should have (Q5460604)[edit]

Value type constraint[edit]

Navigation menu

Property talk:P972

Documentation

Question on usage[edit]

Classes of items[edit]

As a property[edit]

Abuse of this property for original research[edit]

Wikipedia:List of articles all languages should have (Q5460604)[edit]

Value type constraint[edit]

Navigation menu

Search