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]

•   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]

This is an important identifier for EU legislation.--So9q (talk) 10:43, 18 October 2024 (UTC)[reply]

•   Support Arpyia (talk) 08:36, 19 October 2024 (UTC)[reply]
• What makes you think that this is the identifer for the document and not 32013L0036? Does the European Union have a documentation that says that "dir" is part of the name of the identifer? ChristianKl ❪✉❫ 20:26, 21 October 2024 (UTC)[reply]

  It is the document type in the implementation by EU institutions. See https://op.europa.eu/en/publication-detail/-/publication/8159b75d-5efc-11e8-ab9c-01aa75ed71a1. French ELI ids look like this: http://legifrance.gouv.fr/eli/loi/2014/10/13/2014-1170/jo/texte and the general prefix seems to be: {typedoc}/{year}/{natural_number}/ followed by implementation specific endings e.g. "http://data.europa.eu/eli/{typedoc}/{year}/{natural_number}/oj <- canonical ELI to identify a directive or regulation in EU" So9q (talk) 09:14, 22 October 2024 (UTC)[reply]

Samoasambia Julius Schwarz User:So9q

  Notified participants of WikiProject European Union, @Ainali, Belteshassar: Redoing the ping because it requires a signature after it. Samoasambia ✎ 14:33, 22 October 2024 (UTC)[reply]

  Weak oppose I'm not really sure why would we need this property because we already have CELEX number (P476) (it's the "32013L0036" ChristianKl mentioned) and full work available at URL (P953) where we could add the ELI URL. P953 is useful because it is used e.g. by Template:Cite Q (Q22321052). Samoasambia ✎ 14:33, 22 October 2024 (UTC)[reply]

European Legislation Identifier is basically a common URL and metadata format for laws in EU member states and the EU itself. Here's a few examples: http://data.finlex.fi/eli/sd/1734/4, http://data.europa.eu/eli/dir/2013/36/oj, https://www.legifrance.gouv.fr/eli/loi/2023/4/14/2023-270/jo/texte, https://www.retsinformation.dk/eli/lta/2014/1603. Some of the URLs are actual pages and some of them just redirects. Unfortunately there does not seem to be any central domain from which you could be redirected to the right national database, so ELI properties would have to be done separately for each country (and the EU itself). Samoasambia ✎ 15:09, 22 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]

A Wikidata property to identify news website topics (Q105946994) for ITV News (Q4189762), one of the most significant news sources in the United Kingdom.

The IDs seem stable, going back to at least 2012. --Lewis Hulbert (talk) 12:44, 25 October 2024 (UTC)[reply]

• Jheald (talk) 09:48, 11 January 2015 (UTC) PKM (talk) 19:09, 11 January 2015 (UTC) Fabian Tompsett (WMUK) (talk) 08:51, 12 January 2015 (UTC) Charles Matthews (talk) 09:27, 15 January 2015 (UTC) Filceolaire (talk) 16:27, 4 February 2015 (UTC) Danrok (talk) 13:01, 19 October 2015 (UTC) Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits JJBullet (talk) 10:55, 27 June 2019 (UTC) Yirba (talk) 09:53, 10 August 2023 (UTC) Lewis Hulbert (talk) 12:58, 25 October 2024 (UTC)[reply]
    Notified participants of WikiProject UK and Ireland. --Lewis Hulbert (talk) 12:57, 25 October 2024 (UTC)[reply]
•   Support Seems reasonable to me, we have several similar ids and having one that's stable is good. ArthurPSmith (talk) 21:28, 4 November 2024 (UTC)[reply]

@Lewis Hulbert, ArthurPSmith:   Done as ITV News topic ID (P13135). Samoasambia ✎ 12:21, 13 November 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]

Pas mal de personnalités écrivent dans Mediapart (ça permetrrait d'enlever de official website (P856) et de official blog URL (P1581) les blogs Mediapart, voir ici)

Aussi concernés : [1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11] (?) Legonin (talk) 16:25, 31 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. --Lewis Hulbert (talk) 21:52, 13 November 2024 (UTC)[reply]
•   Support — Baidax ^💬 21:58, 13 November 2024 (UTC)[reply]
•   Support. Maxime 22:03, 13 November 2024 (UTC)[reply]
•   Support Rémi sim (talk) 22:05, 13 November 2024 (UTC)[reply]

   Under discussion

Description	International Standard Content Code. Hash code that identifies a media object based on fuzzy hashing.
Represents	International Standard Content Code (Q129857134)
Data type	String
Allowed values	ISCC:[A-Z2-7]{10,73}
Example 1	→ ISCC:KECV7KS6BOJ35WEUX7SMMG3BY4LGBACQ2PJPVVGGHVEZ4DZISC7CXLI
Example 2	→ ISCC:KMCU72IF2EHZH5PKFS2UODT2EGOTGY5CIBRMRYSQR6HGLFBHAAUANVY
Example 3	→ ISCC:KECV7NLW5ME7CEN2XZHDHAODEGDT66ZOQVNDPKM4AKWU6L32BHKVXMQ

As of May 2024, the International Standard Content Code (Q129857134) has been an ISO standard (ISO 24138:2024) to identify digital assets in a robust way by applying fuzzy hashing technology to objects. Awinkler3 (talk) 14:50, 1 November 2024 (UTC)[reply]

  Notified participants of WikiProject Commons

•   Comment This would be more useful if the Commons servers could automatically generate the hash on file upload, see phab:T121797. Dexxor (talk) 18:42, 1 November 2024 (UTC)[reply]

  definitely. I'd also love to see automatic embeddings on Commons to make (third-party?) similiarity/semantic search easier ... that's another topic, though. Awinkler3 (talk) 13:30, 2 November 2024 (UTC)[reply]

•   Support I guess the scope is only Commons files, right? Multichill (talk) 13:09, 2 November 2024 (UTC)[reply]

  mostly, I guess. I am thinking of structured data on Commons Awinkler3 (talk) 13:27, 2 November 2024 (UTC)[reply]

•   Comment The "ISCC" prefix should not be stored in the values. It's redundant information. Dexxor (talk) 19:11, 3 November 2024 (UTC)[reply]

  not sure how to handle this. It's part of the ID (albeit redundant) Awinkler3 (talk) 18:40, 4 November 2024 (UTC)[reply]

•   Comment presumably ISRC (P1243) and ISWC (P1827) are related (those are for musical works)? Note also International Standard Text Code which briefly had a property here but was removed (deletion discussion). ArthurPSmith (talk) 21:23, 4 November 2024 (UTC)[reply]
• Ping Zache who has previously worked with image hashes on Commons. Samoasambia ✎ 18:26, 11 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]

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]

  Notified participants of WikiProject Authority control: I propose to create a new property for the tags on the website of the Algerian newspaper El Moudjahid (Q28055931). --Soufiyouns (talk) 09:43, 6 November 2024 (UTC)[reply]

•   Support Train songs (talk) 16:38, 6 November 2024 (UTC)[reply]
•   Support Kolja21 (talk) 22:16, 6 November 2024 (UTC)[reply]
•   Support Back ache (talk) 19:25, 9 November 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: [12] 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]

• 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]

Note there is no single resolver for this ID.--GZWDer (talk) 14:50, 12 November 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]