Beauciup de "tag" réunissant tous les articles.  – The preceding unsigned comment was added by Legonin (talk • contribs) at 06:00, September 17, 2024‎ (UTC).

  Notified participants of WikiProject France  – The preceding unsigned comment was added by Legonin (talk • contribs) at 08:09, 21 September 2024 (UTC).[reply]

  Notified participants of WikiProject France - re-pinging, since the previous one was unsigned (and therefore didn't work). --Lewis Hulbert (talk) 09:53, 7 October 2024 (UTC)[reply]

•   Support, riche idée ! Maxime 10:05, 7 October 2024 (UTC)[reply]
•   Support — Baidax ^💬 11:04, 7 October 2024 (UTC)[reply]
•   Comment pas totalement convaincu, est-ce vraiment un identifiant pérenne ? (combien y en a-t-il ? depuis combien de temps ? etc.) En plus, je vois que pour chaque mot-clef, il n'y a qu'un petit nombre d'articles les plus récents (et une ligne d'information dans le cas du PCF). Au final, je m'interroge un peu sur l'utilité de cette propriété, qu'apporte-t-elle ? Une propriété générale comme hashtag (P2572) me semble suffisant, non ? Cdlt, VIGNERON (talk) 14:07, 7 October 2024 (UTC)[reply]

  @Legonin, could you please clarify the comment? Regards, ZI Jony ^(Talk) 08:52, 10 October 2024 (UTC)[reply]

  Pas mal d'articles (ex. 1, 2, 3, 4, ..), pas mal de sujet couverts (regarder les tags en bas des articles). Permet de savoir l'actu de l'époque sur ces sujets et d'en savoir plus. Legonin (talk) 17:22, 10 October 2024 (UTC)[reply]

  @VIGNERON, would you like to give your opinion? Regards, ZI Jony ^(Talk) 06:56, 18 October 2024 (UTC)[reply]

  Still not full convinced that this property is useful or needed, I guess I'm   Weak oppose. Cheers, VIGNERON (talk) 07:42, 18 October 2024 (UTC)[reply]

  The same properties exist for other newspapers, such as Le Monde ID (P5558), Libération topic ID (P13113), Le Figaro tag ID (P6621) and so on. I can't figure why L'Humanité, one of the oldest daily newspaper in France can't have its own. Rémi sim (talk) 17:34, 15 December 2024 (UTC)[reply]

•   Support — Rémi sim (talk) 22:21, 14 October 2024 (UTC)[reply]

Beer style is a key classification for differentiating beers by their characteristics, complementing existing properties like beer color and bitterness.  – The preceding unsigned comment was added by Mitsjol (talk • contribs) at 10:43, September 30, 2024‎ (UTC).

•   Comment This seems related to the proposal here: Wikidata:Requests for comment/object vs design class vs functional class for manufactured objects - it sounds like your intent is to replace overspecifity of subclass of (P279)/instance of (P31) in this domain? ArthurPSmith (talk) 20:02, 30 September 2024 (UTC)[reply]

  Yes, that's correct, the intent is to reduce the overspecificity of subclass of (P279) and instance of (P31) by introducing a clear "beer style" property, similar to cuisine (P2012) for food or genre (P136) for media. Mitsjol (talk) 07:52, 1 October 2024 (UTC)[reply]

    Oppose on those grounds, instance of (P31) and subclass of (P279) are sufficient, we don't need special subclass items for types of object. Vicarage (talk) 17:56, 7 October 2024 (UTC)[reply]

•   Comment Why do we need this property for beer specifically? Why not "alcohol style" or "beverage style"? The other beer properties in "See Also" have quantity values for a specific standard, so it would make sense for them to exist. -wd-Ryan (Talk/Edits) 21:39, 30 September 2024 (UTC)[reply]

  You raise good points about beverage classification. My proposal for a "beer style" property stems from the wide variety of distinct beer styles. However, I recognize the value in exploring broader categories like "alcohol style" or "beverage style." That said, using "alcohol style" for instances of vodka, for example, may not be beneficial due to its limited recognized styles. Mitsjol (talk) 09:18, 1 October 2024 (UTC)[reply]

• Grolsch 0.0% is indeed a low-alcohol beer; but that is not its style, which is Pilsner. Guinness 0.0% is a stout. The two beers are not of the same style. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:42, 7 October 2024 (UTC)[reply]
• I think a shared property with food would be more useful, since we have quite a few of type of food or dish (Q19861951): type of pizza (Q116392487), type of cheese (Q3546121), type of cooked meat (Q129175686). There's also type of drink (Q116861721) for drinks, but no specific classes have been created for this yet, and the metaclass itself doesn't have much use as well yet. Although I can find lots of items with description "type of cocktail" and the like, so there is a great potential to extend both branches. And I think we can distinguish basic types for all of them - sort of genres or broad groups. Well, we can use "genre" for this purpose, but I'm not sure if it's really appropriate for food. Solidest (talk) 07:16, 8 October 2024 (UTC)[reply]

  subclass of (P279) could be used with all of those. No need for a property tree Vicarage (talk) 09:09, 8 October 2024 (UTC)[reply]

  Sorry, I didn't word what I meant precisely. That the new shared property could be used to specify food types for branded food\beverages and such. Something that is not a specific type, but rather an implementation of a specific sort. For example, Mukuzani (Q4306822) -> sort/type -> red dry wine; Bavaria Pilsener (Q13436879) -> sort/type -> pilsner (Q152281); César Régalis (Q23211927) -> sort/type -> sheep milk cheese (Q1411808); Coca-Cola Zero (Q937783) -> sort/type -> diet cola (Q50425277). At the moment the link between brands and meal/beverage types is specified via p31 or p279 and I'm not sure if this is correct for branded reproduction of a particular type. For example, here you can see how often p31/p279 of "beer style" are used in p31: https://w.wiki/BThF . These are mostly sorts of beer used by the brands. It would be much more orderly to mark all of them with the class "beverage brand" or something like that. Using multiple types in p31 is not really database friendly, and continuing the type hierarchy through p279 with brands is definitely clogging it up. You may have hundreds of varieties of one product, for example cheese. And you may have 2-3 varieties each placed in p31 for a particular cheese product under its own name, whereas it's just a branded reproduction of a particular type of cheese. If we have hundreds of types filled randomly in p31 or p279 - it's definitely less usable than if it was just p31 = "branded food" or "branded dairy product" or "branded cheese". And at this point, the hierarchy of types and sorts is already heavily cluttered with commercial branded reproductions. Compared to other realms, it's like if you use music genres in p31/p279 for individual songs - something the Music project dealt with by creating a single metaclass. And, as I said, we can use "genre" to refer to types of branded food, but that seems like a stretch for the realm of food. Solidest (talk) 15:07, 8 October 2024 (UTC)[reply]

  See the RFC mentioned at the top which explains how product_model is currently used. It works for brands without the need for extra properties. Your approach goes against that. Vicarage (talk) 20:13, 8 October 2024 (UTC)[reply]

Plein d'IDs et articles très intéressant. Pas mal de sujet/tags de journaux proposé et déjà sur Wikidata.  – The preceding unsigned comment was added by Legonin (talk • contribs) at 07:15, 16 October 2024 (UTC).[reply]

  Notified participants of WikiProject France  – The preceding unsigned comment was added by Legonin (talk • contribs) at 07:15, 16 October 2024 (UTC).[reply]

• VIGNERON
  Ayack
  Ash Crow
  Tubezlob
  PAC2
  Thierry Caro
  Pymouss
  Alphos
  GAllegre
  Jean-Frédéric
  Manu1400
  Marianne Casamance
  Nattes à chat
  Pierre André
  Bouzinac
  Jsamwrites
  Baidax
  LearnKnowGive1
  Mathieu Kappler
  Daieuxetdailleurs
  Archives nationales DJI
  Jmax
  LearnKnowGive1
  Koxinga
  Maxime
  Framawiki
  Legonin
  Rémi sim
    Notified participants of WikiProject France - repinging, signing is required to send pings. --Lewis Hulbert (talk) 00:06, 17 October 2024 (UTC)[reply]
•   Support. Maxime 05:47, 17 October 2024 (UTC)[reply]
•   Oppose not convinced, this is a tag more than an identifier (which probably means it won't be perennial). I'm not really sure what value it brings. Cheers, VIGNERON (talk) 06:18, 17 October 2024 (UTC)[reply]
•   Support Rémi sim (talk) 07:20, 17 October 2024 (UTC)[reply]
•   Oppose I agree with VIGNERON. -Ash Crow (talk) 09:23, 17 October 2024 (UTC)[reply]
•   Support. This proposal aligns with a series of other identifiers of the same kind, giving the articles of a sufficiently important periodical on a given theme. As the theme itself is stable enough, the identifier will, in practice, be perennial, even though it is not numerical, and it is assumed to be unique for each theme. — Baidax ^💬 12:50, 18 October 2024 (UTC)[reply]

Cette propriété est importante pour recenser les dangers pour la santé et l'environnement associés aux activités économiques. Une propriété dédiée permettra d'ajouter les qualificatifs pertinents (dates, références, etc.) pour chaque risque. Arpyia (talk) 08:53, 19 October 2024 (UTC)[reply]

  Notified participants of WikiProject France

  Notified participants of WikiProject France. Ping needs a signature to work. Samoasambia ✎ 14:07, 22 October 2024 (UTC)*[reply]

•   Support — Baidax ^💬 14:19, 22 October 2024 (UTC)[reply]
•   Comment Arpyia is there no other property that could be used? this proposal seems too specific without reason. If not, why not create a more general property? Something like "industrial classification" would make more sense. Also, about ICPE, 2. we should model the "régime" before the "rubrique", this is way more important ; the SEVESO status would be also more useful. Cheers, VIGNERON (talk) 15:20, 22 October 2024 (UTC)[reply]
•   Oppose en l'état, car trop spécifique. Maxime 15:31, 22 October 2024 (UTC)[reply]
•   Comment C'est pas plutôt une classe qu'une propriété ? Alphos (talk) 23:18, 22 October 2024 (UTC)[reply]

capital cost (P2130) already captures the initial capital cost of an object (building, vehicle, etc) but there is no equivalent property for capturing the recurring ongoing costs of maintaining and operating an object.

Qualifiers such as determination method or standard (P459) and valid in period (P1264) would be very important to use with this property as there are many ways to calculate an operating cost for equipment or a building. In the Tesla Model 3 example provided (USD$623/year) this was only an estimate valid at a point in time, for the first five years of ownership of a car, and excluding a number of other operating costs such as electricity and insurance.

--Dhx1 (talk) 03:22, 25 October 2024 (UTC)[reply]

•   Weak support A week support from me, because I think it needs a qualifier of sort. I think the cost of annual ownership can benefit from qualifier of a country, region, city, where it's owned. For example, cost of ownership of Tesla car in Norway and US differ tremendously. Also, I think it would benefit from more time periods like 5 year and so on, but I'm not certain about it. --David Osipov (talk) 12:11, 26 October 2024 (UTC)[reply]
•   Comment The time span should be specified using duration (P2047) qualifier; otherwise you need to create items for every combination of currencies with day/week/month/year, which would be a nightmare for editors and data consumers. Dexxor (talk) 17:57, 27 October 2024 (UTC)[reply]

There is no property existing for the expected useful lifespan of an artificial object (such as a machine, tool, vehicle or building) after which it is expected the object needs replacing due to wear and tear, obsolescence, lack of support and lack of maintainability.

This concept is useful in finance for determining the current value of a purchased asset for taxation and financial reporting reasons. It is also useful for consumer items such as toothbrushes, phones, computers which are replaced regularly for reasons of wear and tear and obsolescence of technology.

--Dhx1 (talk) 03:23, 25 October 2024 (UTC)[reply]

•   Oppose This varies per product and also the lifespan of a laptop obviously is not just 2 years. --Prototyperspective (talk) 09:46, 25 October 2024 (UTC)[reply]

  My thought with this property proposal is that qualifiers such as determination method or standard (P459) and the references are critical. This property could be used 10 times on laptop (Q3962) all with different sources such as standards for asset management and taxation depreciation schedules of different governments. Thus the users of this property have to pick and choose whichever of these 10 statements is most useful to them. For example, the life of a laptop (Q3962) could be 5 years after first product release until it is typically expected to be obsolete and would be scrapped, could by 3 years as determined by continuous use causing battery degradation and wear and tear typically requiring replacement, could differ in expectations between a government in country X versus country Y depending on affluence of the country and wiliness to adopt newer technologies and scrap older ones seen as obsolete, etc. Dhx1 (talk) 12:42, 25 October 2024 (UTC)[reply]

  I don't know of anybody who would replace a laptop after just 5 years. Moreover, the planned obsolescence of laptops, smartphones, several plastic products, and so on are a major problem and WD should not normalize or reinforce that by suggesting this is how long these products inherently last. They can last much longer, for example via standardized replacement parts + requirement to be somewhat modular and having parts (such as battery) offered individually. Prototyperspective (talk) 12:13, 26 October 2024 (UTC)[reply]

•   Weak support It's connected to depreciation of an item, which is a correct accounting notion. But weak support from me, because it needs to have qualifiers like Determination method, Usage frequency of some sort. I would suggest looking up various calculation methods of the effective life of a depreciating asset, writing them out and starting to propose these qualifiers along with this property. Without these qualifiers, the property alone is deceiving. --David Osipov (talk) 12:18, 26 October 2024 (UTC)[reply]
•   Weak support I agree that it needs to be way more precise. It represents depreciation (Q114403).

  For me the property name that would better fit the source indicated would be "legally-based usual depreciation period". The definition would be "usual depreciation period of an asset legally fixed by a fiscal administration and used for accounting purposes"

  Qualifer could be end time (P582), start time (P580) and valid in place (P3005).

  The value could be a range, for example 5-10 years, I don't know how this would translate in terms of allowed units.

  The property should not imply this is the desirable lifetime of an object (question related to sustainability issues such as eco-design and other calculations methods such as life cycle analysis), nor imply this is the actual lifetime of an object (question related to the analysis of real life practices). Jeanne Noiraud (talk) 20:37, 5 November 2024 (UTC)[reply]

•   Oppose something like "depreciation period" would be a better way to store information on the legal depreciation period than a more generally named property. ChristianKl ❪✉❫ 09:01, 31 October 2024 (UTC)[reply]

First of all, no, I don't know why there's an item about me, but I might as well use it as an example! So, in Toki Pona, names only ever serve as adjectives. So even though my name is Tansin, one can't refer to me as just that. Instead, a name must modify a common noun, which essentially serves as Toki Pona's own "instance of" statement. So it's not Mewika, but rather ma Mewika 'country called Mewika'. The ma there, is not however semantically part of the name of the country, and contextually could be replaced with some other word (for instance, a critic of the U.S. could say ike Mewika, 'bad thing called Mewika').

This common noun is called a headnoun. Some people refer to themselves with a headnoun other than jan 'person', which thereby functions as something between a courtesy title and preferred pronoun. For instance, I usually use wan 'union' to refer to myself, and that's the name I'm credited under in the acknowledgments to Toki Pona Dictionary (Q108617357). My item thus gives a name (P2561) of wan Tansin, but that's akin to saying my name in English is "person named Tamzin". One solution would be to simply remove wan, but that word is required information to understand how to refer to me in Toki Pona.

My understanding is that language-specific properties have been approved in the past, e.g. Vietnamese middle name (P8500) and second family name in Spanish name (P1950). -- Tamzin^{[cetacean needed]} (they|xe) 23:18, 27 October 2024 (UTC)[reply]

•   Comment Hmm, this seems like it should be attached to the "class", not the instances. Especially if several different ones could be used (as in your "ma"/"ike" example). ArthurPSmith (talk) 21:18, 29 October 2024 (UTC)[reply]

  That would work for something like a country, but wouldn't work for entities that state a preferred headnoun. Both Sonja Lang and I are instance of (P31)human (Q5), and there's no other statements in our respective items from which one could infer that I primarily use the headnoun wan (L220805) while she uses the more standard (but by no means universal) jan (L220656). This is true of organizations too. I co-own an LLC that uses the word kulupu (L220679) 'community', but another might use esun (L220644) 'business' or something else entirely. And for creative works: Common headnouns for typefaces include sitelen (L220771) 'writing', nasin (L220725) 'way', and linja (L220690) 'lines'. Again, all not inferable from any other statement. -- Tamzin^{[cetacean needed]} (they|xe) 20:23, 1 November 2024 (UTC)[reply]

• Vietnamese middle name (P8500) and second family name in Spanish name (P1950) exist because there's semantic content that's expressed. second family name in Spanish name (P1950) is about expressing that a name is inherited from the mother. Can you explain why you think name (P2561) doesn't work here and what you think the property would add? ChristianKl ❪✉❫ 08:41, 31 October 2024 (UTC)[reply]

  @ChristianKl: Including the headnoun in the name would be incorrect because a headnoun is not part of someone's name. A headnoun just establishes some common noun that applies to the entity, before stating what that name is. If it were standard in English to always call you "the Wikidatan Christian"—and indeed, this is roughly how some newspapers write—that wouldn't make "the Wikidatan" part of your name. So, that leaves two options: omit headnouns entirely from Wikidata, or create a property. If we did the former, it would not be possible to use Wikidata to figure out how to refer to or address someone in Toki Pona. You could guess with decent reliability based on P31 and some map of values to lexemes, but for the reasons explained above to ArthurPSmith, that will carry a significant error rate. In short: a headnoun is a required aspect of how people are addressed and referred to in Toki Pona, but is not semantically part of the name and cannot be fully predicted from other data. -- Tamzin^{[cetacean needed]} (they|xe) 20:32, 1 November 2024 (UTC)[reply]

I was asked by @Kirilloparma: to save certain references not with reference URL (P854) but instead (for instance) ‎Playdate Catalog ID (P12125) in Wikidata:Tools/Wikidata for Web.

My concerns regarding this was that, I cannot automatically distinguish between data provided by the database item behind ‎Playdate Catalog ID (P12125) and information that just happens to be found under the same url.

Let's say the footer of a page might contain an email address, that is not related to the person reviewed in the page.

Or isbnsearch.org would tell me the title of a book but I wouldn't use ISBN-13 (P212) as the reference.

Now if I had an indication that a url that resolves to (for instance) an IMDb ID (P345) usually holds the information that applies to title (P1476), then I could make the assumption that it would make for a fitting reference statement when extracting this property from the url.

This information could be useful for other tools like:

• A tool that tells you that an item should have a title and that you could find it on the IMDB
• A tool that highlights a reference that might be faulty because it occours in an unusual context. Let's say Deku Deals ID (P8364) is used on a date of birth (P569) statement.

If an ID points to a wiki, that could hold all kinds of statements, it should be set to unknown.

@Addshore: –Shisma (talk) 10:00, 28 October 2024 (UTC)[reply]

  Support I quite like the idea, and it falls in line with what I am trying to do with more visual cues on items for the viability of references / sources and notability ·addshore· ^{talk to me!} 10:23, 28 October 2024 (UTC)[reply]

  Question Same as supported metadata (P8203)? Midleading (talk) 15:06, 28 October 2024 (UTC)[reply]

I'm not sure what this is meant for but the datatype is different. So it's definitely not the same. – Shisma (talk) 15:14, 28 October 2024 (UTC)[reply]

supported metadata (P8203) can be used to tell what kind of data a database stores, and not being limited to data that Wikidata has a property for. The example PubMed ID (Q2082879)supported metadata (P8203)digital object identifier (Q25670) is no different from the examples given here except that it accepts items which can be created by anyone. Midleading (talk) 04:03, 29 October 2024 (UTC)[reply]

  Support -wd-Ryan (Talk/Edits) 16:56, 28 October 2024 (UTC)[reply]

  Support Knowing the data a property may hold would be helpful for sourcing statements on items. --Lewis Hulbert (talk) 01:03, 29 October 2024 (UTC)[reply]

  Support Useful. --Prototyperspective (talk) 12:14, 29 October 2024 (UTC)[reply]

•   Wait this property mixes three things together (1) Some entries in the database have data on this property. (2) All entries in the database have data on this property. (3) All entries have reliable data that's worthy of being imported on this property.

If we aren't clear about the meaning, different people are likely going to use it differently leading to bad conclusions. ChristianKl ❪✉❫ 19:09, 1 November 2024 (UTC)[reply]

I read the proposal and all comments again and I'm left with the impression the only assumed meaning of this property is (1). (2) can be expressed with a qualifier nature of statement (P5102) → sometimes (Q110143752). (3) if there is a property for it, I'd assume that the is a consensus that it is worthy of importing 🤷

I have an instance were data is there, but it it's format is always faulty. I would just   deprecate the statement in such cases. We could do the same for when the source is known to be factually faulty reason for deprecated rank (P2241) → source known to be unreliable (Q22979588) –Shisma (talk) 08:34, 2 November 2024 (UTC)[reply]

"A tool that tells you that an item should have a title and that you could find it on the IMDB" is only true for (3). ChristianKl ❪✉❫ 09:38, 2 November 2024 (UTC)[reply]

A tool that tells you that an item should have a title and that you could find it on the IMDB does not mean you shouldn't review it first. Did I imply we should do automatic imports based on this property alone? – Shisma (talk) 11:48, 2 November 2024 (UTC)[reply]

@Shisma the general meaning of "should" is "there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course".

It's not clear whether MyWaifuList character ID (P13031)Provides data for propertyblood type (P1853) is how the property is supposed to be used. A tool complaining that everything with MyWaifuList character ID (P13031) should have blood type (P1853) would be wrong.

While you didn't explicitely suggested automatic imports, the wording that you did use encourages people to read it as a justification of automatic imports. If you propose a property you not just have to think about how you want to use the property about also about how other people might misuse it and think about how to design the property to prevent misuse. ChristianKl ❪✉❫ 09:31, 7 November 2024 (UTC)[reply]

If the data provided is faulty, wrongly formatted, or unreliable we can surely express it with ranks and qualifiers. Don’t you think? — Shisma (talk) 08:49, 12 November 2024 (UTC)[reply]

Previous proposals: Wikidata:Property proposal/provides data and more refined ones: Wikidata:Property proposal/provides HTML microdata, Wikidata:Property proposal/provides JSON-LD data.--GZWDer (talk) 11:21, 5 November 2024 (UTC)[reply]

Resistance in Belgium is a platform that makes it possible to do research on the resistance in Belgium during the Second World War.
  Comment: This database contains mostly persons, but most of them are only known in this database (Wikidata:Notability). That's why I said in the 'planned use' section that I will only use the ID for already created Wikidata QIDs.  – The preceding unsigned comment was added by RVA2869 (talk • contribs) at 10:51, 28 October 2024 (UTC).[reply]

  Notified participants of WikiProject Military History &

  Notified participants of WikiProject Victims of National Socialism. Samoasambia ✎ 17:05, 2 November 2024 (UTC)Lihavointi[reply]

  Support the website seems well organised and official, I see it uses wikibase software. Vicarage (talk) 17:18, 2 November 2024 (UTC)[reply]

  Support Nortix08 (talk) 19:00, 2 November 2024 (UTC)[reply]

  Comment Interesting to see wikbase deployed there! Is this property proposal part of Wikidata:WikiProject WWII? Here's a list of Dutch resistance members Wikidata:Netwerk Oorlogsbronnen/Nederlandse verzetsstrijders. I assume there is overlap between Belgian and Dutch resistance members. Looking at the example items I noticed that the wikibase deployment seems to be simply a way to have a unique starting point for external links in en/nl/fr langauges. It seems to me it would be more beneficial to link those language links directly to the Wikidata items with specific properties per language, especially because it would be nice to provide such links as references to the WWII parts of people's lives. Obviously that 5 year period had a huge impact, but many people were notable for other reasons. I think the various resistance groups need items so I would start there, and not with the individuals, but a more generic property would enable that. As a wikidatan I feel comfortable navigating another wikibase item, but I doubt that's the case for many Wikipedians who could use those links for articles in their language of choice. Jane023 (talk) 09:15, 3 November 2024 (UTC)[reply]

  Support --Kdkeller (talk) 16:21, 12 November 2024 (UTC)[reply]

  Support Karmakolle (talk) 16:38, 14 November 2024 (UTC)[reply]

I did not find the right property to describe the method used in an academic work. This could be useful in the long run to make queries about scientific items and evaluate their quality for example.

(Maybe "uses data analysis method" is a better phrasing for the property name).

Jeanne Noiraud (talk) 21:25, 4 November 2024 (UTC)[reply]

Edit : I have listed existing properties on methods and my other property proposals here Wikidata:WikiProject_Wikidata_for_research/Data_models/Social_science_results#Properties_for_methods

Jeanne Noiraud (talk) 22:48, 5 November 2024 (UTC)[reply]

•   Comment I believe main subject (P921) could be used for this now (although the label maybe doesn't quite fit). Would it make sense to have a more general "method" property though? ArthurPSmith (talk) 20:58, 5 November 2024 (UTC)[reply]

  Hi, thank you for your comment.

  Some scientific work are discussing methodologies themselves, those papers can have data analysis method as their main subject (P921). But the other would be simply be using these methods, while their subject are behaviours, organisations, diseases...

  I think it would be better to have something more specific than "method". We usually make the distinction between the research design (experiment, case study...), the data collection method (questionnaire, observation, physical measures...) and the data analysis methods (qualitative analysis, statistic, comparative analysis...). I plan to make other proposals for these.

  Having details about this for each research item would be useful to fit open science best practices about metadata. Jeanne Noiraud (talk) 22:15, 5 November 2024 (UTC)[reply]

  There are already more than 31 million statements in wikidata using main subject (P921), so it would unlikely be able to support use cases involving SPARQL queries. On the other hand, having a property that is too specific or narrow in scope may end up being rarely used, as in heat treating (P6212). A compromise is to have a new property such as "analysis method", with study type (P8363) as Qualifier if needed. --Zhenqinli (talk) 23:13, 5 November 2024 (UTC)[reply]

  Hi, thanks, I missed study type (P8363), it would be a good fit for what I call "research design" in my jargon. Actually I would rather put "analysis method" as a qualifier for study type (P8363) rather than the other way around. But I still think it can be useful on its own as well. Jeanne Noiraud (talk) 16:06, 6 November 2024 (UTC)[reply]

  Sounds good. By the way, I see that you have another proposal Wikidata:Property proposal/Use data collection instrument. Just wonder if it could be served instead by the existing property uses (P2283)? In fact, you may browse the instances and subclasses of Wikidata property related to method, methodology or mode of actions (Q119301849) for other existing/available Wikidata properties related to methods. --Zhenqinli (talk) 15:27, 7 November 2024 (UTC)[reply]

•   Comment I think that uses (P2283) could be used instead of creating a new property. PAC2 (talk) 21:02, 10 November 2024 (UTC)[reply]
• @Jeanne Noiraud: please refer to actual items in your examples instead of "Scientific article XXX". When properties get created, we set the properties examples of a new property based on what's written in the proposal and that's not possible without concrete items. Concrete items make it also generally easier to reason about how well the property serves the specific role in which it's used instead of only thinking about it generally. ChristianKl ❪✉❫ 12:40, 13 November 2024 (UTC)[reply]

  Thanks, I updated the examples.

  Jeanne Noiraud (talk) 22:52, 13 November 2024 (UTC)[reply]

• While both main subject (P921) and uses (P2283) could theoretically contain this information, both of those are overly broad. I think it can be useful to have more specific properties in cases like this. ChristianKl ❪✉❫ 12:50, 13 November 2024 (UTC)[reply]

    Support I agree So9q (talk) 08:34, 4 December 2024 (UTC)[reply]

•   Support with the label "analysis method" ArthurPSmith (talk) 15:28, 19 November 2024 (UTC)[reply]

I am trying to create relevant properties for scientific research items metadata and I find there are many properties missing. This property is inspired by existing controlled social science vocabulary, but can be used for many science related items.

The closest property for now is probably uses (P2283), but it seems too generic. I have listed existing properties on methods and my other property proposals here Wikidata:WikiProject_Wikidata_for_research/Data_models/Social_science_results#Properties_for_methods

Jeanne Noiraud (talk) 22:41, 5 November 2024 (UTC)[reply]

•   Not done, no support for creation! Regards, ZI Jony ^(Talk) 11:32, 14 December 2024 (UTC)[reply]

In Germany, for example, the measuring point uuid is used as a unique identifier for water level measuring points (Stream gauge). At these points, the current level of the water of rivers, channels, lakes or the sea will be collected. These Measuring points have a coordinate. This will belong to the Project Germany, WikiProject Rivers and WikiProject Geology. These Measurement points indicates the difference between standard sea level and actual water level. As alternativ a general uuid value can be implemented. There are already uuid properties, but they are to specific, either people World Rowing UUID or books BHCL UUID. If a universal uuid is implemented, it would be fine for my project. I like to add all wate level measurement point in Germany. They are used at rivers, Canals, at North- and Baltic Sea. In Germany there are more than 650 measurement points. See also extern: [1] GodeNehler (talk) 16:13, 7 November 2024 (UTC)[reply]

• Take a look at how property descriptions are usually written, and write one for this property in the same form. Currently, it's not clear to me whether this is supposed to be a property about a certain German identifer (so a standard external ID property) or supposed to be something more general.

Is there some regulation that codifies these measuring points? ChristianKl ❪✉❫ 21:38, 7 November 2024 (UTC)[reply]

Die Aufnahme dieser ID hat auch für die Datenpflege hier einen expliziten Nutzen, z. B. in der Vermeidung von Dubletten oder der eindeutigen Zuweisung, falls kein Label verwendet wird/kein sinnvolles Label verwendet werden kann.  – The preceding unsigned comment was added by P170 (talk • contribs).

•   Comment Enorme Fülle an Detailinformationen zum deutschen Energiesystem, daher definitiv ein nützlicher Vorschlag. Ich würde aber nicht für jeden Prefix der Nummer eine eigene Eigenschaft erstellen, sondern alle Typen von Einheiten, Betreibern usw. unter einer zusammenfassen. (Daher würde ich auch die beiden Wikidata Einträge zusammenlegen, weil es eigentlich der selbe Identifikator ist.) Weißt du darüber hinaus, ob das Online-Portal eine Möglichkeit bietet anhand der MaStR-Nummer auf den jeweiligen öffentlichen Registereintrag zu verlinken? (sowas wie marktstammdatenregister.de/{MaStR-Nummer} leitet dann auf die entsprechende Seite im Register weiter) Aus formellen Gründen wären außerdem zwei weitere Beispiele noch gut. Printstream (talk) 00:00, 9 November 2024 (UTC)[reply]

  Hi!

  • Zwei weitere Beispiele habe ich ergänzt.
  • Mir wäre es (leider) nicht bekannt, dass aus der MaStR-Nummer auf den Eintrag verlinkt werden kann
  • Dein Vorschlag die IDs für Einheiten, Betreiber usw. unter einer Eigenschaft zusammenzufassen klingt sinnvoll. Ich ändere das und gehe davon aus, dass das kein Problem ist und kein neuer Vorschlag nötig ist.

  P170 (talk) 08:50, 9 November 2024 (UTC)[reply]

  Ergänzung: Zusammenfassen bedeutet allerdings, dass eine Einheit bei Wikidata mehrere MaStR-Nummern erhält: Für die Einheit an sich, dann gibt es bspw. noch eine MaStR-Nummer für die EEG-Anlage und teilweise eine MaStR-Nummer für die Genehmigung. Diese beiden letztgenannten Beispiele fallen ja auch unter das eine Wikidata-Objekt. Siehst Du da ein Problem oder hattest Du das schon einkalkuliert? P170 (talk) 08:59, 9 November 2024 (UTC)[reply]

  Mehrere MaStR-Nummern pro Objekt sind kein Problem, können dann per Qualifier einfach spezifiziert werden. Da müsste man sich dann auf eine einheitliche Methode einigen. Vielleicht mit instance of (P31) und dann jeweils eigenen Wikidata-Objekten für die 23 verschiedenen Prefixe/Typen von Einträgen. Wegen der Weiterleitung habe bei der BNetzA mal angefragt. Printstream (talk) 10:46, 9 November 2024 (UTC)[reply]

    Support @P170: @SuPich: Endlich nach viel hin und her: https://www.marktstammdatenregister.de/MaStR/suche/$1 ist der Endpunkt. Habe den Vorschlag dementsprechend angepasst. Printstream (talk) 00:05, 13 December 2024 (UTC)[reply]

  Bzgl. der Verlinkung: In der URL ist eine eindeutige ID erkennbar, z. B. 3046180: https://www.marktstammdatenregister.de/MaStR/Einheit/Detail/IndexOeffentlich/3046180

  Diese verändert sich auch nicht, könnte also auch als Referenz-ID verwendet werden, um auf das MaStR zu verlinken. Evtl. könnte man sich dann auch die übrigen IDs sparen.

  Ansonsten würde ich dieses Proposal auf jeden Fall unterstützen, da im MaStR viele relevante Informationen drinstecken!

  -- SuPich (talk) 22:36, 25 November 2024 (UTC)[reply]

  Ein bisschen Reverse Engineering hat mich auf folgende API gebracht: https://www.marktstammdatenregister.de/MaStR/Schnellsuche/Schnellsuche?praefix=SEE&mastrNummerOrId=930503783721

  Die Response ist {"url":"/MaStR/Einheit/Detail/IndexOeffentlich/3046180"}, liefert also die gewünschte URL.

  Das gleiche funktioniert dann z.B. auch mit der EEG-Nummer, die auf (fast) dieselbe URL führt, nur mit dem passendem Abschnitts-Anker: https://www.marktstammdatenregister.de/MaStR/Schnellsuche/Schnellsuche?praefix=EEG&mastrNummerOrId=910547427461

  {"url":"/MaStR/Einheit/Detail/IndexOeffentlich/3046180#eeg"}

  Falls es also möglich ist, diese API anzubinden, könnten wir auch direkt diese Nummern verwenden. SuPich (talk) 22:42, 25 November 2024 (UTC)[reply]

• Bigbossfarin Galaktos Labant M2k~dewiki Mathieu Kappler PantherStrix Wiljes jobu0101 cookroach Looniverse LockaPicker Printstream
    Notified participants of WikiProject Germany Printstream (talk) 13:47, 11 November 2024 (UTC)[reply]
•   Comment Are the entities described by this ID actually notable? Individual wind turbines for example? That seems a stretch to plan to include them all. ArthurPSmith (talk) 15:10, 19 November 2024 (UTC)[reply]

  I wouldn't focus solely on wind turbines, as the ID also captures a wide range of other entities. The register contains almost all entities that are in some way connected to the German energy infrastructure. This includes larger power plants of all kinds, thousands of companies (e.g., grid operators or all German municipal utilities, for which, to my knowledge, there is no other identifier in Germany), as well as authorities, energy trading platforms, business associations, and more. Printstream (talk) 17:38, 20 November 2024 (UTC)[reply]

Note there is no single resolver for this ID.--GZWDer (talk) 14:50, 12 November 2024 (UTC)[reply]

•   Support I wasn't aware this was so complicated, it sounds useful to have this property then. ArthurPSmith (talk) 15:00, 19 November 2024 (UTC)[reply]
•   Support A very useful proposal, I think, that smoothens programmatic data access via OAI. Awinkler3 (talk) 12:36, 26 November 2024 (UTC)[reply]
•   Support Sounds great. --Kdkeller (talk) 20:52, 26 November 2024 (UTC)[reply]
• How is this going to be tied to a specific OAI-PMH feed? With a required qualifier of some description? Stuartyeates (talk) 01:15, 1 December 2024 (UTC)[reply]

Bessere Verlinkung der DAten in der OpenLibrary.  – The preceding unsigned comment was added by Ogmios (talk • contribs) at 11:09, 13 November 2024 (UTC).[reply]

The Best Practices Badge is an initiative of the Linux Foundation (Q858851) and the Open Source Security Foundation (Q104245202) to improve and document many aspects of Free and Open Source Software. Registered projects expose structured information including governance, quality control, and vulnerability reporting.  – The preceding unsigned comment was added by FSImonis2 (talk • contribs) at 11:26, November 27, 2024 (UTC).

  Note This replaces the proposal Open Source Security Foundation Best Practices Identifier --FSImonis2 (talk) 11:53, 27 November 2024 (UTC)[reply]

•   Support Dexxor (talk) 13:00, 27 November 2024 (UTC)[reply]

An analogy to category populated by (P4329) is needed for extensions. Taylor 49 (talk) 20:58, 27 November 2024 (UTC)[reply]

•   Weak oppose Why not rename category populated by (P4329) to "template, module, or extension that populates category" or even "MediaWiki category populated by"? Dexxor (talk) 09:01, 28 November 2024 (UTC)[reply]
•   Oppose The property being proposed here would never have many uses, because there aren't many categories which are populated by extensions (I found 62 while searching the source code for them) and it would still not cover all cases (there are also 18 categories which are populated by MediaWiki directly). The relation between the items would be the same (just used for a different set of instance of (P31) values) and the constraint violations can easily be solved by modifying the constraint (which I've now done). - Nikki (talk) 07:20, 3 December 2024 (UTC)[reply]
•   Support changing category populated by (P4329) to something like "MediaWiki category populated by component" accepting templates, modules, extensions, and the MediaWiki core.   Oppose new property. Taylor 49 (talk) 22:47, 3 December 2024 (UTC)[reply]
•   Not done, lack of support! Regards, ZI Jony ^(Talk) 11:57, 14 December 2024 (UTC)[reply]

There is a popular trend in the United States to make "land acknowledgements" at public meetings. Universities do this especially, because they are sensitive to remembering history. Other organizations which may do this include cultural centers, museums, and inaugurations of buildings. A typical land acknowledgement occurs at the beginning of a meeting. After people have convened, the host of the meeting will make a statement acknowledging the colonial nature of cities, and how colonists displaced the native people. The host will state the names of the tribes or indigenous people who lived in the place before colonists arrived. Then there is some statement of well wishing for the descendants of those people, and for recognizing the history of the native people.

As examples I listed some universities, because universities document their land acknowledgements more frequently than other kinds of organizations. Land acknowledgements could apply to any place, like an entire city or region, but here in Wikidata, I propose that we track any organization which makes a land acknowledgement for itself, and that the target be the people to whom their acknowledgement is directed. I think there will clear data here when our model for land acknowledgement requires a citation from the organization making the claim. Bluerasberry (talk) 19:25, 2 December 2024 (UTC)[reply]

• Amqui Arlo Barnes Bibliojo Daniel Mietchen Fjjulien GaryMan1968 Infopetal morinjam PKM Smallison Yupik Skybristol
    Notified participants of WikiProject Indigenous peoples of North America Bluerasberry (talk) 19:33, 2 December 2024 (UTC)[reply]

  I love this proposal!
  I was actually just thinking today about how we could use the <ancestral home> property to connect traditional Indigenous territories like Mi'kma'ki to their associated Indigenous peoples (Mi'kmaq). We could potentially make items for traditional territories based on the territories listed in Native-Land.ca, and then use those territory items for land acknowledgements in some way? Just a thought. GaryMan1968 (talk) 19:57, 2 December 2024 (UTC)[reply]

@GaryMan1968: ancestral home (P66) is for self-identification (with third party citation, of course) of individuals and people to their ancestors. The land acknowledgement concept is a statement that organizations choose to make. In the case of land acknowledgements, it could be the case that the indigenous people do not want the acknowledgement, and that the statement benefits the current occupants more than the previous native occupants. The native-land.ca website would be what a contemporary organization used to determine the ancestral owners of the land which they now occupy. But the "land acknowledgement" concept is a voluntary declaration which communicates the politics of the organization making it, rather than giving information about native people who formerly lived there. The default is that organizations make no land acknowledgement, and have no stated opinion about previous land occupants. In the absence of an organization's acknowledgement, there can be no "land acknowledgement", as these have to be cited to an organizational statement. Perhaps there also should be a Wikidata property for what you are describing, like "indigenous people of this location", which could be applied to cities and regions. Bluerasberry (talk) 21:57, 2 December 2024 (UTC)[reply]

•   Support Not just in the USA - I've definitely seen this for Canadian institutions and I think I've seen this for Australia/New Zealand too. ArthurPSmith (talk) 19:06, 3 December 2024 (UTC)[reply]
• I'm really not sure about this path and urge caution. There is a difference between a land acknowledgement and traditional territories. There are mistakes with the native land website, and yes, most land acknowledgements are not "approved" by the Nations or peoples it is meant to acknowledge. These statements often change. I do wish we had a way to cite traditional territories, although this is a very, very complex topic. I would be supportive if it was clear that these land acknowledgements are official statements frequently coming from corporations or organization and are not to be conflated with traditional territories. There are massive issues with the modelling of Indigenous lands, peoples, and cultures in Wikidata.Smallison (talk) 16:15, 5 December 2024 (UTC)[reply]
• I support the caution mentioned by Smallison above. Amqui (talk) 03:42, 12 December 2024 (UTC)[reply]
• It seems the current proposal is to use the item datatype to link to the item for a polity or a people. What if instead it links to an item with instance-of land acknowledgement (Q96200400), being a particular document issued by the acknowledging organisation? Then full work available at URL (P953)/URL (P2699) and other such properties can be more prominent than they would be as a qualifier to this proposed property. Arlo Barnes (talk) 21:53, 13 December 2024 (UTC)[reply]

  Notified participants of WikiProject Authority control: I propose to create a new property for the tags on the website of the Algerian French-language newspaper El Watan (Q2529832). --Soufiyouns (talk) 07:29, 4 December 2024 (UTC)[reply]

To accompany Three Decks people ID (P7389), Three Decks ship ID (P11085) and Wikidata:Property_proposal/Three Decks class ID, but for conflicts (they call them variously battles or actions, a naval history term, but they map to WD conflicts) from the Age of Sail, held by the Three Decks online database. Like ships and people and classes, this adds conflicts, with a different url format. I've been adding the information using described by source (P1343), this property would replace those records. Vicarage (talk) 06:34, 9 December 2024 (UTC)[reply]

  Support Decent resource. Infrastruktur (talk) 19:01, 11 December 2024 (UTC)[reply]

  Notified participants of WikiProject Authority control: I propose to create a new property for the tags on the French-language website of the Algerian news agency Algeria Press Service (Q1162323). --Soufiyouns (talk) 08:55, 9 December 2024 (UTC)[reply]

  Comment: See also Wikidata:Property proposal/Algeria Press Service tag ID (English). --Soufiyouns (talk) 09:17, 9 December 2024 (UTC)[reply]

  Comment: See also Wikidata:Property proposal/Algeria Press Service tag ID (Arabic). --Soufiyouns (talk) 09:35, 9 December 2024 (UTC)[reply]

  Notified participants of WikiProject Authority control: I propose to create a new property for the tags on the English-language website of the Algerian news agency Algeria Press Service (Q1162323). --Soufiyouns (talk) 09:18, 9 December 2024 (UTC)[reply]

  Comment: See also Wikidata:Property proposal/Algeria Press Service tag ID (French). --Soufiyouns (talk) 09:16, 9 December 2024 (UTC)[reply]

  Comment: See also Wikidata:Property proposal/Algeria Press Service tag ID (Arabic). --Soufiyouns (talk) 09:36, 9 December 2024 (UTC)[reply]

  Notified participants of WikiProject Authority control: I propose to create a new property for the tags on the Arabic-language website of the Algerian news agency Algeria Press Service (Q1162323). --Soufiyouns (talk) 09:31, 9 December 2024 (UTC)[reply]

  Comment: See also Wikidata:Property proposal/Algeria Press Service tag ID (English). --Soufiyouns (talk) 09:31, 9 December 2024 (UTC)[reply]

  Comment: See also Wikidata:Property proposal/Algeria Press Service tag ID (French). --Soufiyouns (talk) 09:31, 9 December 2024 (UTC)[reply]

ON HOLD currently creating a schema for this property  – The preceding unsigned comment was added by Brechtd (talk • contribs) at 14:00, 26 November 2024 (UTC).[reply]

•   Comment I think a unified "tour URL" property would be better, with a qualifier object of statement has role (P3831) audio tour (Q758877). Your proposal also seems incomplete! And I don't think you meant for the data type to be EntitySchema, but rather URL. -wd-Ryan (Talk/Edits) 19:35, 29 November 2024 (UTC)[reply]

  Yes its correct that the proposal is still under construction, URL alone is not enough to cover everything. You have audio tours that you can use through URL, but also audio tours you only can listen to for example in an museum itself, beside that you have apps for audio tours (Android, F droid, iOS), thats why I'm bussy creating Wikidata:Schema proposals/virtual tour to use with audio tour. Beside that I'm new to Wikidata so still searching my way how everything works... Brechtd (talk) 21:53, 29 November 2024 (UTC)[reply]

ON HOLD currently creating a schema for this property  – The preceding unsigned comment was added by Brechtd (talk • contribs) at 14:56, 26 November 2024 (UTC).[reply]

ON HOLD currently creating a schema for this property  – The preceding unsigned comment was added by Brechtd (talk • contribs) at 14:57, 26 November 2024 (UTC).[reply]

Plein de description/biographies. Aussi Compagnie de télévision et de radio biélorusse, Garde républicaine, 4th Armored Division, Peter Cherif, Ministère de la Défense et de la Logistique des forces armées, ministère de la Défense nationale, Al-Qaïda, Forces armées de la fédération de Russie, Armée de résistance du Seigneur, Jaish al-Muhajireen wal-Ansar, VGTRK, Al-Qaida en Irak, Jaych Aden Al Islami-Abyane … Legonin (talk) 18:07, 15 December 2024 (UTC)[reply]

  Notified participants of WikiProject France