Wikidata:Property proposal/Wikidata focus list

From Wikidata
Jump to navigation Jump to search

Wikimedia project focus list

[edit]

Originally proposed at Wikidata:Property proposal/Generic

DescriptionProperty to indicate that an item is part of a group of items of particular interest for maintenance, management, or development. Please note: This property does not add notability to items and items should not be created with this property if not otherwise notable for Wikidata. Don't use it when querying another property will give a comparable list.
Data typeItem
Domainany
Allowed valuesitems representing Wiki projects
Example
Planned usetake over existing uses from catalog (P972)
See alsocatalog (P972), P4570 (P4570)
Motivation

Property catalog (P972) has been used with great practical effectiveness since spring last year to indicate groups of items of particular interest for maintenance, management, or development, that can then be queried as a group using SPARQL to produce progress reports, Listeria pages, summaries of recent changes, etc.

However there is now a desire to re-focus P972 to its original role of indicating concrete external real-world verifiable listings, rather than groups of items that may be related by more Wiki-orientated management and development purposes.

So this property is proposed as a drop-in replacement for P972, to use for such groupings.

An alternative would be to use the existing P4570 (P4570) property. However, there may be advantages (i) in having a property that is item-valued, allowing queryable statements to be added to the focus-list item to indicate eg the purpose, domain of interest, parent sponsor groups, etc of the item grouping; and (ii) in distinguishing a property for groupings of active interest that may be more tightly focussed than the broad interests of a whole WikiProject. Jheald (talk) 12:21, 6 January 2018 (UTC)[reply]

Discussion
  •  Support Proposed. Jheald (talk) 12:48, 6 January 2018 (UTC)[reply]
  •  Support - Based on the discussion I saw on the mailinglist, this solves one problem of the issues with the current approach. Mbch331 (talk) 12:55, 6 January 2018 (UTC)[reply]
  •  Weak support if nothing else, at the very least least it's better than the current misuse of P972.  Comment what is the intended domain and allowed values? Cdlt, VIGNERON (talk) 13:15, 6 January 2018 (UTC)[reply]
  • Support with provisos:
    1. Use of this property should be temporary.
    2. For each project, a project page in the Wikidata: space should be created, indicating the project's purpose, key contact(s) and its expected and-point.
    3. Once the project is ended (or activity ceases, or the project organiser is no longer contactable), values should be removed from items.
    4. A list of values used by this property shall be maintained, by a bot, on a dedicated sub-page of the property page.
    5. The community may decide, through consensus at project chat (or a talk page identified at project chat) that a value used by this property is not bona fide and such values may then be removed from items.
    6. Use of this property does not convey notability, and items using it may be deleted in the normal manner if they do not meet our notability criteria.
  • If any of these are not applied, then I object to creation. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:23, 6 January 2018 (UTC)[reply]
    • I have an additional concern - do Black Lunch Table (Q28781198) & PlantsAndPeople (Q31805038) meet our notability policy? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:27, 6 January 2018 (UTC)[reply]
      • If we approve this property, they would fulfil a structural need. Actually, they fulfill a structural need anyway -- as evidenced by the usefulness they already bring as objects of P972. Jheald (talk) 13:29, 6 January 2018 (UTC)[reply]
      • @Pigsonthewing: Can you explain why (1) ? Why might one not eg want to see recent changes to a particular group on an ongoing basis, that may be hard to otherwise define by SPARQL ? Jheald (talk) 13:32, 6 January 2018 (UTC)[reply]
        • In such cases the project is ongoing. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:44, 6 January 2018 (UTC)[reply]
          • @Pigsonthewing: So it would be okay with you, to use this proposed new property in such a case, so long as the timespan was marked as 'ongoing' ? BTW, I agree that it totally makes sense that many/most uses should have a 'sunset' date; and that tagging should be removed once it is no longer useful, to avoid item clutter (it can always later be reinstated easily enough, if one has generated a list of uses eg via Listeria). But it does seem to me that there might be some uses that could usefully be ongoing. Jheald (talk) 14:55, 6 January 2018 (UTC)[reply]
            • The concern I have with this sunset date is that these task lists are being used for editathons, and that information needs to be preserved. They serve a functional and administrative purpose. This metadata of event location and time is not intrusive or disruptive to Wikidata. I am also sort of laughing at the idea of clutter on Wikidata. I think that is sort of an absurd concern when there are tons of uploads to Wikidata that are generating a lot more clutter than these small, highly curated and manually created outreach initiatives generate. So I vote against a sunset date, feel very strongly this is not productive or helpful as a qualifier. -- BrillLyle (talk) 18:22, 6 January 2018 (UTC)[reply]
              • @BrillLyle: This issue of items becoming cluttered up, making them harder to read and harder to edit, is not a small concern -- particularly if the statements were obsolete and/or of little relevance beyond Wiki. But you make a fair point, that if somebody's item or wiki coverage has been the target of an editathon, that may be information that it is useful to preserve; for example, for selecting subjects to prioritise or not for a future editathon; or simply as a record of work done. I would be interested to hear User:Pigsonthewing's thoughts. He's run enough editathons himself to have a fairly sharp notion of information he thinks is worth preserving. Jheald (talk) 18:55, 6 January 2018 (UTC)[reply]
              • A core problem with the existing links is that they often don't contain enough information about the people in question to allow for disambigutation and thus a decision whether two items should be merged or not that can be made another Wikidata user. Requiring an editathons to enter enough information about a person they want to research to provide the ability of disambigutation is some effort but it's effort that should also be useful for the purpose of the editathons. ChristianKl ❪✉❫ 12:40, 7 January 2018 (UTC)[reply]
                • If you look on the RfD link, the Black Lunch Table understands this concern, takes it seriously, and has asked for and has received a six-month timeframe to address this issue from those involved in the discussion, I believe in a productive way.
                • The idea that this solution is temporary is insane. We need a workable solution that can be implemented in current and future outreach. To flip around from one property to another is unhelpful. Yes, I know there can be a bulk change made but this issue should not be solutionless. There has to be something that will solve this problem. -- Erika aka BrillLyle (talk) 09:10, 8 January 2018 (UTC)[reply]
  •  Support as a simple query access handle for projects, as long as three conditions are met: (1) this property does not establish Wikidata notability (2) the property does not imply editorial priviledges for the WikiProject, and (3) there is a project page at Wikidata (complex constraint?) that has a /Participants subpage with a number of active project members (to {{Ping project}} the project in case). —MisterSynergy (talk) 14:35, 6 January 2018 (UTC)[reply]
  •  Support, and agree with the requirements about establishing a regular, contactable WikiProject, and normal rules of notability applying.--Pharos (talk) 15:10, 6 January 2018 (UTC)[reply]
  •  Oppose when this property has as its requirement that items on this list are non notable and can be deleted, it no longer functions in the way this property is meant to function. Only when items are protected from arbitrary deletion, this will work. Thanks, GerardM (talk) 18:10, 6 January 2018 (UTC)[reply]
    • @GerardM: This property doesn't have 'as a requirement' that items it is placed on are non-notable. It can be placed on any item, that is part of a group of particular focus. But it doesn't give an end-run around notability either. An item does not become notable just because it has this tag on it. Notability has to be established by verifiable sources. However if a project is in good standing, and has a good reputation, I would hope that people seeing this tag would be disposed as a courtesy to allow the item a grace period of, say, a couple of months from creation, by which time sufficient biographical details and references to establish that notability and disambiguate against anyone else of the name ought to be put in place. Jheald (talk) 18:42, 6 January 2018 (UTC)[reply]
    • @Jheald: When items with few statements are deleted it destroys the integrity of the data. The objective is to find subjects for future events. Either an organisation, a group of individuals are trusted and nothing is deleted, or this proposal has little merit. This is about trust and diversity. It is not about whoever finds something non-notable is excused to delete.  – The preceding unsigned comment was added by GerardM (talk • contribs) at 09:42, 7 January 2018‎ (UTC).[reply]
      • It was a major problem of the month-long dispute around the BLT items that the independent issues of notability and accessibility were not discussed separately. Meanwhile we have figured that out, and this proposal is a promising approach to at least solve the accessibility problem. However, if this proposed property became a carte blanche to put anything to Wikidata, I’d have to strongly oppose it; this is not a BLT-specific property, so while lack of trust is not at all a problem with BLT, other (future) projects would quickly exploit this method of establishing notability of all kinds of weird things Wikidata is not made for. —MisterSynergy (talk) 09:01, 7 January 2018 (UTC)[reply]
        • The unintended consequence of deleting items of a collection like this is that it makes this approach impossible. When items are deleted, the collection is no longer complete and valid. This is however not a carte blanche. When a project becomes stagnant. When nothing happens, there comes a time to remove this property for all the items involved and consider the items individually. This discussion exists because the BLT is the first and most prominent project involved, it is not a Smithsonian. When you talk about weird, well weird is in the eye of the beholder; it is about notability. Future projects can have a listeria list like the BLT to show it is evolving. Thanks, GerardM (talk) 10:49, 7 January 2018 (UTC)[reply]
          • Also for Smithsonian or for PlantsAndPeople I have finded a lot of item in the same state of BLT items, but in this case I have finded easily external reference and I have added them, the same isn't for BLT items --ValterVB (talk) 11:14, 7 January 2018 (UTC)[reply]
          • The approach would not at all be impossible, but the workflow during initial setup of fresh items may be different. It would be very beneficial to have identifiers or external references from the very first moment on. But even if this was not the case, I am convinced that we would handle this appropriately while looking for items to be deleted—even if the new property does not establish notability and references/identifiers were missing. For instance, I would exclude items with this property while looking for problematic items; at the same time, use of this property could be monitored, and actions can be taken on a per-WikiProject level which is practically impossible with the P972 misuse. However, if an editor contests notability of an item with this property which does not have any other indication of notability, someone would have to add proper references or identifiers in order to avoid deletion. —MisterSynergy (talk) 06:18, 8 January 2018 (UTC)[reply]
        • To support original research, a staging area for topics that may be notable, but still need references could help. Maybe a toolserver instance of Wikibase .. It could still use properties and statement values from Wikidata.
          --- Jura 11:21, 7 January 2018 (UTC)[reply]
  •  Oppose I oppose on a couple of levels, mostly the sunrise issue, but I have to say I think the name of this property is not ideal. I am not sure what "focus" has to do with anything. Is this property name supposed to be a Wikidata project-connected tag, so that's why it says Wikidata in the name? Are there Wikidata project specific properties created that can be used as examples? Yes, this property will be actively used for Wikipedia task lists, but it can be used for other types of lists as well, like publication list, taxonomy lists, etc. that are connected to various diverse Wikipedia and GLAM outreach efforts. I think we need a better name, and a better understanding of the scope and context of this property. And I want assurance that we can run SPARQL queries like we have been with catalog to query location, gender, publication date, language of work, etc. -- Erika aka BrillLyle (talk) 00:35, 8 January 2018 (UTC)[reply]
  • Another question is about constraint violations. Current usage of the catalog property is generating a ton of constraint violations (see here), which is why MultiChill deleted the over 2,000 tags in the first place. Will this property generate constraint violations? It would be great to see the property not generate these errors so an editor doesn't make this same mistake going forward. -- Erika aka BrillLyle (talk) 03:22, 8 January 2018 (UTC)[reply]
Replies to all your concerns:
  • I am a bit irritated about the “Wikidata” in the proposed property name as well, but this is in fact just cosmetics. Maybe WikiProject focus list fits better?
  • With the proposed property you can run exactly the same queries as you do right now, as they are technically identical; you’d only need to replace P972 by the new P-ID.
  • This effort with a new property is being done to tailor a property that really fits your needs, i.e. that does not need to bulk-violate constraints of a another property and that allows you to access the items in scope of your project. Until now it seems that there would be a few constraints (maybe 2 or 3) on the new property, but none that are a problem for your project.
—MisterSynergy (talk) 06:07, 8 January 2018 (UTC)[reply]
@BrillLyle:: The name isn't set in stone yet, If you have a suggestion for a better name, mention it here and it can be discussed. Mbch331 (talk) 06:43, 8 January 2018 (UTC)[reply]
  • Oh good. I'm glad I am not the only one!
  • WikiProject refers to specific outreach initiatives. The outreach initiatives currently using catalog are both in the Wikipedia:Meetup space as well as the Wikipedia:GLAM space. The outreach could definitely come from WikiProject too, so to be too specific and have WikiProject as part of the name would be non-ideal, I think.
  • Why is there a constraint for the catalog property then? What about us using it is triggering it. I don't get that.
  • As far as ideas, I ran across this unused Q number Wikipedia:Wiki-ID, which I like the idea of because it incorporates the idea of a unique identifier and is tied to identifiers, which is how I envision this property
  • property:Wiki-ID
  • property:WikiOutreachID
  • property:W-ID
To respond to some of the above. This property is not intended to be just for outreach. It is intended to be usable for any group of Wikidata items that are the focus of some process of improvement or management, that would otherwise be hard to identify and analyse as a group in SPARQL. So, for a completely different example, it might be a group of items that have categories on Commons that are inter-related in some way in the Commons category tree, which we can see using SQL on Commons, but not via SPARQL here. The property is intended to make it possible to tag any group of items that are going to be the focus of work. That work might be part of an outreach drive, but it is useful for the possible focus areas not to be limited to only those that may be the target of an outreach drive. Any focus area should be within scope for this property.
As for "identifier", with respect to Wikidata properties the word 'identifier' has a strong connotation of a property which it is expected will have a different unique value for each item. That is not the case here, where the intention is for the property to have the same value for all items in the group, to make them easy to extract and analyse as a group. IMO it would therefore be better to avoid the term "identifier" or "ID" in naming this property. (Also 'identifier' suggests the value will be a code, whereas for this property the value will be an item).
I think "Wikidata focus list" is a reasonable name for the property, because the intention is to group together a set of items as a list that can be given a name; items that are Wikidata items, that are going to be the focus of some work or ongoing management or ongoing tracking. I think "Wikidata" is appropriate in the name, because it is for a list of items on Wikidata as a list of items on Wikidata -- as to whether in turn that group of items has or has not a real-world significance beyond Wikidata, that is a function of the list itself and its nature, not a function of the use of this property. Jheald (talk) 14:52, 8 January 2018 (UTC
I wanted to point out re. applicability, some of the current uses of catalog that this property intends to replace are not by Wiki Projects, e.g. Colección Patricia Phelps de Cisneros = philanthropy and Smithsonian Institution = institution, so Allowed values: items representing Wiki projects, in the proposal above, needs an update, or clarification. The constraint violations in the catalog case were caused by BLT not being an 'instance of' a catalog. Adding a new P31:instance of value to BLT of Q2352616:catalog will silence the constraint violations. I'm NOT suggesting that as a solution (edit: 2 hours later after more digging, turns out I am... see below), but it is important to get the Allowed Values of this new property correct, and stated clearly to avoid confusion. Salpynx (talk) 03:47, 9 January 2018 (UTC)[reply]
Thank you for this work. I for one really appreciate it. To clarify: Colección Patricia Phelps de Cisneros is NOT a philanthropy. It is a large private art collection that is unique in that it generates scholarly and art history-intensive publications of an under-represented pan-regional Latin American sector of art and art history. -- Erika aka BrillLyle (talk) 21:05, 9 January 2018 (UTC)[reply]


  •  Support we need some way to store metadata about the items themselves, including its relevance to a particular project. However, as a technical feature, I am not exactly convinced their our two current domains for properties (general and authority control), actually encompasses how these are used. We almost need a third set of properties called "meta-properties" which describe whether or not an item is a featured item, its WikiProjects, and other similar relational context that are structurally useful for Wikidata as a socially-organized group, but have little or no "meaning" about the item (nor require referencing, etc). Sadads (talk) 23:54, 8 January 2018 (UTC)[reply]
Interesting viewpoint and I get this. We do have properties for the core articles lists and so on, so I think I understand what you mean. The problem of course is how to deal with the items on the edge of inclusion that do not meet Wikidata notability on any level and yet the Wikimedia project wants to track them. This property will at least be able to zero in on those so that broken links on a project-related workflow page can be retraced to item deletions, mergers, or whatever. Jane023 (talk) 15:17, 11 January 2018 (UTC)[reply]
  •  Oppose with counter-proposal to salvage current catalog (P972) usage with minimum disruption:
BENEFITS: 1) BLT and others only have to modify one item, their root item, and have no disruption to their current workflows to remove constraint violations. 2) catalog (P972) will have a consistent unambiguous definition, which needs addressing independently of this issue anyway. 3) Is practical, and I'm not aware of any further violations of constraints or concepts, and it seems inline with the original advice given and already acted upon.
OTHER CONSEQUENCES: a small number of items currently using P972 as a property to denote an exhibition having a catalog will need to be altered to represent that meaning correctly. I now contend that those items are currently incorrect anyway, given catalog (P972) inherits from part of (P361). Salpynx (talk) 07:12, 9 January 2018 (UTC)[reply]
I disagree. What you are describing is a different property. There is also a problem referring to people as "catalogued items". That is something that many people object to, especially in Europe. Jane023 (talk) 15:21, 11 January 2018 (UTC)[reply]
One of the key things the usage of the catalog property allows for is the ability to generate task lists for editathons under the initiative's catalog "tag." Having a task list that is often full of BLPs is a key thing, especially with GLAM initiatives where the Creator is the starting point from which all information follows. I assume that Europe allows for BLPs, for the establishment of a Creator's notability? This "Europe finds this problematic" seems like a pretty extreme argument to base an objection of this very functional and usable "tool" (for lack of a better word) upon. Aren't people listed in cataloged records in various ways, like as entities in Authority control identifiers? Is that objectionable? We are talking about metadata about a variety of topics and subjects. To exclude people as items is both disingenuous and misses the point pretty fully. I find this very odd. -- BrillLyle (talk) 13:08, 18 January 2018 (UTC)[reply]
A property is not a "tag". We do not use catalog (P972) for VIAF ids. We actually have the specific property VIAF ID (P214) for that. If you want your own property, go ahead and propose one. Whether a human is represented by a BLP doesn't matter for the metadata about the person. Properties for place of birth (P19), date of birth (P569), country of citizenship (P27) and so on are used on people both alive and dead. Our goal is to properly describe people using properties, and proposing such properties is done here. Jane023 (talk) 13:30, 19 January 2018 (UTC)[reply]
Andy: 1 makes little sense; a project may always need to monitor a specific set of items. 2 makes sense, but why can't the project page be on some other Wikimedia site? I have no objections to 3 through 6.
MisterSynergy: I have no objections to 1 and 2, but the same concern for Andy's 2 applies to 3 here.
Jura: No objections to the additional requirement. Mahir256 (talk) 00:01, 12 January 2018 (UTC)[reply]
  • A participants list at Wikidata can be pinged, which is not the case for outsite-of-Wikidata participants lists. I would not expect to see a fully developed WikiProject; so apart from the Participants list, it would be sufficient if the WikiProject main page briefly outlines the project scope and then links to the actual work page in another Wikimedia project. Sounds complicated, but my experience from the BLT case is that it is difficult to actually get an overview about the participating editors of the project, and to get in touch with them if anything with the items in their scope is wrong (e.g. someone contests notability). —MisterSynergy (talk) 06:03, 12 January 2018 (UTC)[reply]
This property should not be a roadblock for the A+F project on Wikidata at all. We already created a working page for A+F and we can create lots of worklists for use by contributors and organizers without any need for a special property. See Wikidata:WikiProject_Women/ArtAndFeminism_2018. Jane023 (talk) 21:42, 25 January 2018 (UTC)[reply]
@Jane023:, you have mentioned this page here: Wikidata:WikiProject_Women/ArtAndFeminism_2018 We are very happy that you have welcomed us into the effort. The reasons why we seek a specific metadata marker is to trace the work we have done, so we can build on the work, but also trace its impact. And also to improve the wikidata items. For example: we want to add profession data to the items that are missing this (about 50%). We really need a metadata marker so we can access the full set of items via queries, rather than from one giant long unstable list. So our efforts will include using queries to identify articles to work on and improve (which we can do at present from the extant P21 values) our initial goal is to improve the set of items that correspond to the Wikipedia pages that have been created or improved at our many events of the past 5 years. Please correct me if I have misunderstood you, or your proposed use of that WikiProject page. Thanks. --Theredproject (talk) 18:55, 4 March 2018 (UTC)[reply]
  •  Oppose Wikipedia/Wikidata internal stuff like that does not belong to the entities itself. Wikipedia projects are using templates on talkpages, Wikidata projects should use item talkpage (and query it using petscan+SPARQL combination).--Jklamo (talk) 17:41, 28 January 2018 (UTC)[reply]
    • @Jklamo: That would make it impossible to access the information from a pure SPARQL query, and therefore an auto-updating Listeria page couldn't be created either. You presume the desired output can be generated by Petscan, but that's very limiting. For maintenance queries, one generally wants to see a number of other fields, sometimes the results of a subquery run for each of the items. And it's hugely useful then to be able to patch the results into Listeria to be able to see the results in an always recently-updated automatically-generated view. The natural place to store information about items on Wikidata is in Wikidata. And it's not as if there's something new here -- Wikidata items already contain lots of information that is "internal stuff" and Wiki-specific. Jheald (talk) 14:53, 8 February 2018 (UTC)[reply]
      • It is not a good idea to create highly problematic property just because of imperfection of technology. WikiProjects are important (I am participant of 5+ WikiProjects here on Wikidata), but I insist that internal stuff like WikiProject does not belong to the entity workspace.
      • I am also afraid of that lot of support votes here are more likely "we do not want this in catalog (P972)" than "this is the best solution". Let's find some better solution.--Jklamo (talk) 22:19, 10 February 2018 (UTC)[reply]
  •  Comment This proposal has been marked as ready, but at a quick glance it is not clear to me that consensus has been reached. I can see 8 support votes, 2 weak or conditional support votes, and 5 oppose votes. Is that good enough? − Pintoch (talk) 12:48, 8 February 2018 (UTC)[reply]
@GerardM, BrillLyle, Salpynx, Liuxinyu970226, Jklamo: If you could review your opposes, it would be good to know whether you still stand by them. Jheald (talk) 14:57, 8 February 2018 (UTC)[reply]
  • Apologies for the delayed response. The name is problematic for me -- so much so that I don't think this new property is helpful. I still don't see anything wrong with using catalog. It's a better indicator of a unique identifier than this somewhat jive "focus list" thing. This property is neither a focus nor a list really. It's just so dang imprecise and non-functional. Catalog connotes a body of work, a collection, a curation that has been carefully collected and supplied. So I still oppose. Also I don't see this property addressing the initial concerns. I don't have hope the property is sufficient to address Wikidatan objections to notability, and other issues that Gerard will hopefully chime in on. But basically, why shift from one semi-ideal/non-ideal (depending on your perspective) property to another one, which is in my opinion much worse? Thoughts? -- Erika aka BrillLyle (talk) 14:58, 10 February 2018 (UTC)[reply]
  • While I appreciate the intent behind this proposal to resolve an issue, in the meantime my counter proposal above has basically been put into effect, so the BLT {P972} constraint violations no longer exist. The clearest complaint issue is already resolved. I still  Oppose because I do not consider this new property adds any more clarity. If there are issues with the current use, they simply will be transferred to (or more likely split between) this new property, with a more restrictive name. I strongly echo Jklamo's 'also afraid of that lot of support votes here are more likely "we do not want this in catalog (P972)" than "this is the best solution".' Additionally I am not yet convinced {P972} is inappropriate, so outstanding concerns (if any) could just as well be addressed there. Thanks Salpynx (talk) 21:08, 11 February 2018 (UTC)[reply]
  •  Support per Jheald. strakhov (talk) 02:20, 9 February 2018 (UTC)[reply]
  •  Comment I'm abstaining from voting right now mostly because I'm torn. I'd vote to support with some modifications. I really just want this resolved. I am the co-founder of BLT, the initiative that needs this list. We are not just a WikiProject, we are an archive and the names that we have in our catalog statement are artists in our catalog for our archive. They are all notable, whether there is a url or a hard-copy book, but we would also like to potentially keep track of artists who are just becoming notable (may be they will have the cred by next year etc). I would support this solution because the people on our list now do have references and are notable, and understand that any creation of an item should follow the rules of Wikidata... even if I personally find flaw in those rules (that is a different issue and seems to not be tied to the creation of this anyway). A new name would be nice, Wikifocus list? WikiProject focus list is too narrow and so is Wikidata focus list. I also oppose to sunset issue- even though this does not apply to our project because we are ongoing... It is useful to see what other projects focused on in prior years in case a new group wants to use that list for some reason... anniversary editathon or something. Anyway, it seems like this property is passing, so I hope we can all work together to help grow a healthy, equitable Wiki. Thanks --Heathart (talk) 19:27, 11 February 2018 (UTC)[reply]
"but we would also like to potentially keep track of artists who are just becoming notable" Wikidata is in no hurry we can wait for them to become notable. If you are looking for just a tool to store data you can do a personal installation of Wikibase --ValterVB (talk) 14:06, 12 February 2018 (UTC)[reply]
Thanks for the tip, ValterVB. Sounds good, and I'll investigate Wikibase for our idea of tracking pre-notable folks. All the artists we entered into Wikidata are notable, so no worries there. But, just to be clear, we are definitely not "looking for just a tool to store data" for a personal installation. Wikimedia Foundation mission is to make Wiki more equitable, which is what we are trying to do both with our project in its current form and with our ideas for potential. Thanks again for your help! --Heathart (talk) 15:52, 15 February 2018 (UTC)[reply]
  •  Comment I want to add on to my earlier comment about the plans by Art+Feminism (Q24909800) to bring some of our work to Wikidata. Our first goal is to try to track the ~10,000 articles created or improved (with another ~10,000 to come next month), so as to be able to sort them for further analysis and improvement (by medium, discipline, region, age etc). Our second goal is to improve these Wikidata items themselves. Either way, we need a means of tracking the set of items. It should not be temporary. It is worth noting: we are not an external archive, as BLT does function; we are not a Wikiproject on en wiki; we are a User Group. We would like to engage Wikidata, but we will hold off until there is a stable meta property that will allow us to collect and track our related items. In solidarity. --Theredproject (talk) 02:08, 17 February 2018 (UTC)[reply]
  •  Strong oppose Had some time to think about this. The constraint violation of "catalog" is gone, if I am understanding things correctly. So this new property is not providing any different functionality, is in no way solving the fundamental issue that was discussed previously when Gerard was trying to assist in making these queries possible. Therefore this new property is not a better option. So I strongly oppose the new property. Beyond these obvious points, the name and options for a different name continue to be inadequate and imprecise. It provides no improvement. Strong oppose.
  • I want to say that I recognize that the use of the catalog property should be used selectively. And responsibly. The editors working on the outreach projects should have a clear understanding of the usage and they need to be proactive and diligent in curating the use of the catalog property. If an outreach partner without a clear scope and proven track record of hard work integrating Wikipedia into their project -- like let's say Art+Feminism -- if the organizers are lazy and have not established proficiency which includes content creation, they should not use this property. And they should not jump on the bandwagon here because they see a way to manipulate and use this property for their own muddy agendas. To be blunt, A+F is anti-Wikipedia. They don't want to do the hard work that needs to be done to utilize this property responsibly. I don't endorse their usage of the property, which I realize is not something that can be controlled. But I am unhappy with their joining in this project work, as they have proven they will abuse situations for their own agenda. Which is not really about the projects themselves. I just want to be clear in my skepticism of them joining this discussion. I don't want people to see their input as overly weighted or more highly valued than other less funded and smaller but even more effective efforts. They can do what they want but their initiative has a proven track record of ineffectiveness and a hostility to on Wiki project work unless it benefits them directly. I just wanted this said here. -- Erika aka BrillLyle (talk) 18:12, 20 February 2018 (UTC)[reply]
  • Comment Hi All, for more context on @BrillLyle:’s ad hominem attacks on Art+Feminism and myself you can see this deletion discussion on commons. This is part of a pattern that has stretched out over 2 years on and off wiki and led to BrillLyle’s event ban. I note that BrillLyle continues not to ping us directly when making these attacks on wiki. And I also note that the chilling effect of this attack caused discussion to cease for two weeks.
  • In this case BrillLyle is quite transparent in motive: to find whatever solution will best prevent the participation of Art+Feminism in using this potential property, and to simultaneously discourage and/or prevent us from being able to do our work on Wikidata. This is quite astonishing. I want to underscore that our goal here isn’t to win, or lose, or prevent anyone from doing anything that isn’t part of the group consensus. Our goal is to support our wiki-ally @Heathart: and Black Lunch Table’s effort on Wikidata and ensure that A+F has a route forward to work on Wikidata with some kind of data/metadata that allows us to unify a set of items. A rising tide lifts all boats.
  • Question: Is @Salpynx: correct that the constraint violations on Catalog property are no longer extant?
  • Question: Am I correct in understanding the logic presented that Art+Feminism would not be able to use the existing Catalog property in order to establish a way to track and query the items that correspond to the Wikipedia pages that have been created or improved at our many events of the past 5 years? Or will Art+Feminism be able to use the existing (and now modified) Catalog property as well? --Theredproject (talk) 19:01, 4 March 2018 (UTC)[reply]


  • Outreach initiatives by cultural institutions that are either part of the Galleries Libraries Archives and Museums (GLAM) universe or outreach that is curated and is coming from very specific communities and projects (like Black Lunch Table and others I support) have a very clear need to have a way to create task lists that are based on Wikidata. The catalog property is providing a solution to do task lists efficiently -- and also creates a strong pathway between Wikidata and Wikipedia. One that is not present in typical outreach. It is a very positive and constructive thing.
  • That functional need to create task lists and language-neutral scaffolding to base new articles in various language Wikipedias is what the catalog property is being used for.
  • This usage is not meant to be an automated method and/or substitution for tracking Art+Feminism events. That is an outrageous thing to expect Wikidata to do. A+F clearly states they don't want event pages on Wikipedia, they don't want a presence on Eng Wikipedia because it is too much work. So what, they expect Wikidata to provide a workflow tool of some kind? I am laughing here as this seems to be a constant thing with A+F, that they don't want to do the hard work that involves editing of any kind, of managing their own metadata. They want their metadata automated, but they aren't part of the community and reject basic concepts like event pages, transparency, and you know, Wikipedia editing (but I digress).
  • I am in no way preventing A+F from doing anything. I am only one editor who has been thoroughly maligned by WM NYC and Art+Feminism. I face these people alone. I have no power here. Am I critical of A+F? Yes. I have been since I donated free digital labor for over a year and had such a bad experience with them, while being ridiculed for doing a ton of work for them. Do I contribute and support and help others when I see they are possibly in need of administrative skill-sharing with outreach activities? Yes. I am an active contributing editor and have worked really hard with GerardM's kind help in embracing Wikidata for this task list purpose. It's an obvious need that the Wikidata community does not really support in general, from this discussion and others.
  • I am no longer helping the Black Lunch Table but there are other outreach projects that are using catalog to organize their metadata. It's a critical functionality. And there is room on Wikidata for this. So Michael can say he wants but my work is solid and stands for itself. I am using Wikidata responsibly and muscularly, especially as it connect to Wikipedia. I am proud of that hard work. I refuse to let his comments go unresponded to, but I am so tired of the underlying agendas, which are not very community based in fact. This is exhausting. This new property solves no problems. Catalog is working fine. And neither property is meant to be A+F's solution to their ongoing management problems like this. It's a misunderstanding of Wikidata in the extremis. But if you all want to support this, then go ahead. I will stay in my dusty corner of Wikipedia and hope to be left alone there to molt. -- Erika aka BrillLyle (talk) 08:06, 5 March 2018 (UTC)[reply]
Proposal review

In my view this proposal is ready for creation, as all the concerns have been addressed, and the fears of misuse shouldn't be enough reason to block the creation of this property. I have changed the label to "Wikimedia project focus list" because it seems that it represents better that it can be used for any Wikimedia project. It makes much sense to reserve catalog (P972) for external catalogues, and use this one for internal use catalogs, not only because of the constraints, but because it is misleading to use the same property for both. I will wait a couple of days just in case if there are additional comments before proceeding to create this property. Micru (talk) 13:10, 28 March 2018 (UTC)[reply]

@Jheald, Mbch331, VIGNERON, Pigsonthewing, BrillLyle: @ChristianKl, MisterSynergy, Pharos, GerardM, ValterVB: @Jura1, Salpynx, Sadads, Jane023, Mahir256: @Liuxinyu970226, Theredproject, Jklamo, Pintoch, Strakhov: @Heathart: ✓ Done Micru (talk) 07:27, 4 April 2018 (UTC)[reply]

Retrieved from "https://www.wikidata.org/w/index.php?title=Wikidata:Property_proposal/Wikidata_focus_list&oldid=661040667"