Wikidata talk:WikiProject Properties
Moving the declaration of exceptions to constraints to the items
edit
WikiProject Properties has more than 50 participants and couldn't be pinged. Please post on the WikiProject's talk page instead.
Notified participants of WikiProject property constraints @Lucas Werkmeister (WMDE):
Currently, we list expection to our constraint inside the constraint section of the property. One alternative would be to list them inside the actual item either as qualifier or in the reference. Listing them in the item would have the advantage that we can better deal with cases where there are 100 expections. Having the information that the constraint is declared for the item visible when browser the item could also be valuable. What do you think? Does the status quo make sense? ChristianKl (✉) 19:02, 5 December 2017 (UTC)
- I agree with User:ChristianKl. While working with programming languages, softwares, I came across several instances where I found that because of missing constraints, we were not able to detect problems. Sometimes properties are being used in a way they were not supposed to have been used. John Samuel 19:12, 5 December 2017 (UTC)
- @Jsamwrites: It surprises me that this happens in that area. Do you have examples? ChristianKl (✉) 19:15, 5 December 2017 (UTC)
- @ChristianKl: Try this SPARQL query. I created it sometime back to see different properties used by various programming languages, you can see properties like publisher (P123), country of origin (P495), game mode (P404) etc. being used.
- That being I would still keep some constraints on the properties side. But it would be great to have them on the items too. John Samuel 19:45, 5 December 2017 (UTC)
- What I'm proposing here is to move the information about the expections to the constraints. I'm not proposing to move the actual declaration of the constraint elsewhere, as I think that declaration belongs to the property. ChristianKl (✉) 20:02, 5 December 2017 (UTC)
- I’m not sure how this would work. Would you disable all constraint checks on a certain statement, or all constraint checks of a certain type (e. g. all value-type constraint (Q21510865))? The best thing would be to disable only a single constraint, just as with the current exception system, but I don’t see how that’s possible, since we don’t have a property type to link to a specific statement (in this case, a constraint statement). --Lucas Werkmeister (WMDE) (talk) 17:33, 6 December 2017 (UTC)
- We would add exception to constraint (P2303) subject type constraint (Q21503250) as qualifier to an item when it's a violation on a type constraint. ChristianKl (✉) 17:37, 7 December 2017 (UTC)
- Well, that means you could only add an exception for all constraints of the same type. For instance, properties with item-requires-statement constraint (Q21503247) have, on average, about two and half constraints of that type (full query), and you could only add an exception for all or none of them. I’m not sure if that’s an acceptable limitation… --Lucas Werkmeister (WMDE) (talk) 19:00, 7 December 2017 (UTC)
- We would add exception to constraint (P2303) subject type constraint (Q21503250) as qualifier to an item when it's a violation on a type constraint. ChristianKl (✉) 17:37, 7 December 2017 (UTC)
External identifiers
editHi All,
I wrote a proposal about expanding the statements regarding external identifiers, please have a look and add your opinions: https://www.wikidata.org/wiki/Wikidata:Project_chat#External_Identifiers_-_expanding_statements,_best_practice --Adam Harangozó (talk) 19:54, 2 November 2019 (UTC)
Changing the format of existing external identifiers
edit WikiProject Properties has more than 50 participants and couldn't be pinged. Please post on the WikiProject's talk page instead. Is there any precedent for the scenario found at Wikidata:Property_proposal/TripAdvisor_ID_2 where an improved form is possible for an existing external identifier? Should a new property be created so that existing statements aren't suddenly changed which could be disruptive for anyone using the data, or should the existing property be converted to the new form to avoid unnecessary property creation? --SilentSpike (talk) 22:01, 9 April 2020 (UTC)
Community Wishlist Survey proposal to make property creation easier
edit WikiProject Properties has more than 50 participants and couldn't be pinged. Please post on the WikiProject's talk page instead. I have created a proposal for a dedicated Property proposal entity namespace that should allow for properties to be effortlessly created at the click of a button without requiring you to copy anything from the proposal! I would appreciate if you vote on it so that it can possibly be implemented!
The proposal: meta:Community Wishlist Survey 2022/Wikidata/Entity Draft Namespace Lectrician1 (talk) 19:57, 29 January 2022 (UTC)
New RFC: Create items for property proposals
edit WikiProject Properties has more than 50 participants and couldn't be pinged. Please post on the WikiProject's talk page instead.
Wikidata:Requests for comment/Create items for property proposals Lectrician1 (talk) 20:45, 5 November 2022 (UTC)
Discussion re. Wikidata:List of properties
editSee Wikidata:Project chat#Request for input on Wikidata:List of properties’s poor condition. Please comment there. Thanks, MisterSynergy (talk) 20:14, 7 October 2023 (UTC)
Using number of records (P4876) as qualifier
editPlease comment: Property_talk:P4876#Use_as_qualifier_for_Stack_Exchange_tag_(P1482)? -- Vladimir Alexiev (talk) 16:11, 9 October 2023 (UTC)
Wikidata:Property proposal/Creative work exceeds template include size
editHi everybody! The page Wikidata:Property proposal/Creative work currently exceeds the transclusion limit, which means that six sections and seven proposals are currently broken. Could somebody please take a look? Thanks! ViktorQT (talk) 08:59, 12 December 2023 (UTC)
Dedicated page for describing the property proposal process
editWikidata_talk:Property_proposal#Dedicated_page_for_describing_the_property_proposal_process Lectrician1 (talk) 00:33, 13 January 2024 (UTC)
Category:Properties ready for creation contains 60 entries
editHello, the Category:Properties ready for creation currently contains 60 entries M2k~dewiki (talk) 22:59, 20 January 2024 (UTC)
Discussion
editHeads up
editWikidata:Property proposal/object of action & object class of action. Swpb (talk) 20:13, 16 July 2024 (UTC)
Instances of numeric identifier
editHi all, we have over 3.600 properties that are instances of numeric identifier (Q93868746). It is not a subclass of Wikidata internal entity (Q21281405) which leads to Wikidata properties leaking into the main knowledge tree, and I propose that we should move those from P31 into has characteristic (P1552) to solve this issue. Any comments or other suggestions? Samoasambia ✎ 00:07, 29 November 2024 (UTC)
Support makes sense to me. ArthurPSmith (talk) 17:01, 4 December 2024 (UTC)- Support ChristianKl ❪✉❫ 17:58, 4 December 2024 (UTC)
- Support Good catch. Numeric identifier might not have been optimal to begin with as you said, it's intended for the entity namespace. The other option would be to introduce a new property class like "Wikidata property for a numeric identifier". But from my basic understanding the class hierarchy is intended to reflect the fundamental nature of things and not its characteristics - for that reason I think your suggested solution is better. Infrastruktur (talk) 11:02, 5 December 2024 (UTC)
- Support could it be done through
{{Autofix}}; I hope it works also with properties but I'm not sure honestly. --Epìdosis 20:48, 5 December 2024 (UTC)- I was considering that but then I realized that Autofix would also edit regular items that are instances of numeric identifier. Samoasambia ✎ 01:43, 6 December 2024 (UTC)
- I set two batches to do the change: [1] [2]. I checked that the P31 statements were in normal rank and didn't have any references nor qualifiers to avoid any collateral damage. Samoasambia ✎ 22:40, 8 December 2024 (UTC)
