Wikidata:Property proposal/Generic


Property proposal: Generic Authority control Person Organization
Creative work Place Sports Sister projects
Transportation Natural science Lexeme Wikimedia Commons

See alsoEdit

This page is for the proposal of new properties.

Before proposing a property

  1. Check if the property already exists by looking at Wikidata:List of properties (research on manual list) and Special:ListProperties.
  2. Check if the property was previously proposed or is on the pending list.
  3. Check if you can give a similar label and definition as an existing Wikipedia infobox parameter, or if it can be matched to an infobox, to or from which data can be transferred automatically.
  4. Select the right datatype for the property.
  5. Start writing the documentation based on the preload form below and add it in the appropriate section.

Creating the property

  1. Once consensus is reached, change status=ready on the template, to attract the attention of a property creator.
  2. Creation can be done 1 week after the proposal, by a property creator or an administrator.
  3. See steps when creating properties.

  On this page, old discussions are archived. An overview of all archives can be found at this page's archive index. The current archive is located at 2020/12.

GeneralEdit

arcade system motherboardEdit

   Under discussion
DescriptionArcade system hardware board the system motherboard used by a hardware device
Representscomputer hardware (Q3966)
Data typeItem
Template parameter|placa base= and |sistema arcade= in Ficha de hardware and Ficha de videojuego
Domainproperty
Example 1Tempest (Q1340846) Atari Vector (Q63109245)
Example 2Killer Instinct (Q973459) Killer Instinct arcade motherboard (Q63109134)
Example 3F-Zero GX (Q1940315) Triforce (Q1324477)
Example 4Open Desktop Workstation (Q838593) Pegasos (Q2067286)
Planned useAlmost inmediately, to be used in (Arcade) videogames infobox

MotivationEdit

I want to create this as a series of properties to be used in Videogames infoboxes. This would be an alias for "Motherboard" instead. Namely, this is intended for the motherboard codename, specially in arcade machines, wich several ones uses the same motherboard. Amitie 10g (talk) 22:01, 1 April 2019 (UTC)

ΛΧΣ21 Vacation9 John F. Lewis (talk) Bene* talk #Reaper (talk) Josve05a (talk) Chris Mason (talk) FunPika Arthena (talk) Wangxuan8331800 (talk) Sjoerd de Bruin (talk) Nicereddy (talk) Syum90 (talk) DrakeCaiman (talk) --George (Talk · Contribs · CentralAuth · Log) Andreasburmeister (talk) Danrok (talk) 18:20, 30 October 2015 (UTC) Macrike (talk) Dispenser (talk) 16:56, 7 July 2017 (UTC) --Zache (talk) 13:34, 12 July 2017 (UTC) SharkD  Talk  06:41, 9 November 2017 (UTC) ZebaX2010 (talk) 00:49, 21 November 2017 (UTC) Sight Contamination (talk) Lewis Hulbert (talk) 20:26, 13 December 2017 (UTC) Jean-Fred (talk) 10:48, 28 February 2018 (UTC) Santer (talk) Cloaker416 (talk) 22:18, 12 June 2018 (UTC) Rampagingcarrot (talk) 19:57, 28 June 2018 (UTC) Diggr (talk) 08:07, 3 July 2018 (UTC) Harsh Rathod Poke me! 09:42, 7 July 2018 (UTC) Kirilloparma (talk) 00:30, 5 August 2018 (UTC) Sir Lothar (talk) 10:10, 10 August 2018 (UTC) Cwf97 (talk) 14:33, 22 October 2018 (UTC) Esteban16 (talk) 00:08, 27 October 2018 (UTC) Peterchanws Brasig Le Yota de Mars YotaMoteuchi (talk) 08:09, 22 May 2019 (UTC) Coloradohusky CptViraj BugWarp ʂɤɲ User:Nw520 Cynde Moya Dexxor Floyd-out CadetPatrick AntisocialRyan   Notified participants of WikiProject Video games --Jean-Fred (talk) 17:04, 8 April 2019 (UTC)

DiscussionEdit

  Comment Can you fix the examples? NMaia (talk) 01:12, 2 April 2019 (UTC)

I've added the proposed value. Is this a right value for items already existing in Wikidata (ej. the motherboard used in an arcade system)?
If I understand correctly, you would like to express Star Wars (Q54317) Atari Star Wars Vector (Q17462637)?
If so, I have been wondering − shouldn’t we just use Star Wars (Q54317) platform (P400) Atari Star Wars Vector (Q17462637)? This is already used in the wild:
SELECT ?item ?itemLabel ?platform ?platformLabel WHERE {
  SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en". }
  ?item wdt:P31 wd:Q7889.       # All video games...
  ?item wdt:P400 ?platform.     # ...whose platform...
  ?platform wdt:P31 wd:Q631229. # is an arcade system board.
}

Try it!

Jean-Fred (talk) 17:15, 8 April 2019 (UTC)

  Oppose Agree that platform (P400) could be used instead. Thadguidry (talk) 22:33, 8 April 2019 (UTC)

  • platform (P400) refers to the platform in general (Arcade, Nintendo 64, etc, wich is used already), while "Arcade system" refers to the details of the hardware (generic or codename of the motherboard). arcade system board (Q631229) is a statement, not a property, what we need for the infobox. "Hardware" could be also a name for this property. --Amitie 10g (talk) 15:44, 9 April 2019 (UTC)
    Well, at some level we get to decide what platform (P400) means :). You could argue the same way for console and PC games, that we should do something like:

Metal Gear Solid (Q6582527) platform (P400) video game console (Q8076)
Metal Gear Solid (Q6582527) <Hardware> PlayStation (Q10677) or
Star Wars: The Old Republic (Q737308) platform (P400) personal computer (Q16338)
Star Wars: The Old Republic (Q737308) operating system (P306) Microsoft Windows (Q1406)

  • The layout of the downstream infobox which will use the data is somewhat irrelevant: as far as I know, there is no need for 1-1 mapping between infobox fields and Wikidata statements − I think the infobox could be coded either way in the Lua.
    (Not entirely sure what you mean by « arcade system board (Q631229) is a statement, not a property » − based on the definitions used here, it’s neither ;-))
    Jean-Fred (talk) 08:51, 12 April 2019 (UTC)
Thanks for fixing the example ; however one question: we can’t model free-text like « Proprietary MIPS based hardware system ». In this case, would it make sense to create an item for that particular hardware? Jean-Fred (talk) 08:52, 12 April 2019 (UTC)
Well, as no way to create free text, I'll take care to create new elements for missing ones, as you mentioned (see the examples above, I fixed them). --Amitie 10g (talk) 12:12, 12 April 2019 (UTC)

Tobias1984
Emw
Zuphilip
Danrok
Bene*
콩가루
TomT0m
DrSauron
Ruud Koot
Andreasburmeister
Ilya
Toto256
MichaelSchoenitzer
Metamorforme42
Pixeldomain
User:YULdigitalpreservation
Dipsode87
Daniel Mietchen
Jsamwrites
Tinker Bell
FabC
Jasc PL
putnik
Dhx1
Tris T7
Peb Aryan
lore.mazza004
Rc1959
Premeditated
Iwan.Aucamp
LiberatorG
Primhill.Computers
FWVH (passionné d'informatique et d'électronique)
94rain
So9q
Adrijaned
Sylvain Leroux
SM5POR
Haansn08
  Notified participants of WikiProject Informatics

Before claiming «then it does not have a “hardware” per se − after all», please keep in mind those games has been launched as Arcade machine first, and a browser is just an emulator for the hardware (arcade) the machine ran, so, this property is relevant for videogames first launched as arcade. See the examples I given, specially the Killer Instinct, having its own dedicated hardware, as most of the arcades. --Amitie 10g (talk) 20:32, 22 November 2019 (UTC)
I think we misunderstandood each other here. I don’t disagree that arcade games have specific hardware. What I mean is that the Q7889-items are about games as creative works: Killer Instinct (Q973459) is about both the arcade and the SNES versions − so the statements on that item should (mostly) be applicable to both (although we can use qualifiers to clarify that). For me it would be like using number of pages (P1104) on Les Misérables (Q180736) - sure, there was a first edition of Les Misérables which had a given number of pages, but that does not apply to all reeditions of the text.
I see that the new proposal is about “the system motherboard used by a hardware device” − that sounds good, but right now video games are defined as not being hardware.
My take-away is that arcade games/machines/cabinets are clearly very complex objects (both culturally and technically). I would like us to come up with a comprehensive modeling concept, because I really think that stuffing more data on Q7889 items is breaking left and right and won’t fly much longer (and not only for arcade) (I started writing some thoughts about that). For example, next, we might decide we need a property to model that cabinets are upright or cocktail (a valid data point to record, and an actual field in some Wikipedia infoboxes) − yet I understand that some games (like Space Invaders) were published on both cabinet types.
For example, maybe we need to create items about the machines themselves then (the 'package' cabinet+motherboard+display+audio system) − or maybe not if go down the road of splitting items per platform-realisation (or some yet other solution).
Jean-Fred (talk) 16:58, 23 November 2019 (UTC)
  •   Support Germartin1 (talk) 08:00, 24 May 2020 (UTC)
  •   Comment I'm not familiar with nonfree arcade games: are games compatible with specific mainboards? I've looked a bit at the nonfree software history, like the DOS era through the LGR youtube channel (which according to the LGR (Q3820312) wikipedia disambiguation page is "an American YouTuber focusing on retro technology") and as I understand, in DOS, the userspace programs could take over the control of the computer, and also patch the software that is running if they wanted to, for instance by hooking interrupt handlers and so on. While they appear to have been drivers in DOS, many nonfree games didn't use them and instead directly implemented support for specific hardware like adlib or Sound Blaster 16 (Q7564654) compatible sound cards. In such case, the operating system (P306) and/or platform (P400) could be DOS (disk operating system (Q600659)), specific Microsoft Windows (Q1406) versions, etc, but would also be compatible with specific hardware chip (like the Yamaha chip that is in the AdLib Music Synthesizer Card (Q26883996) sound card or other compatibles sound cards with the same chip (Yamaha YM3812 (Q1684767))). Some games are also be compatible with a specific controller (3D gloves, 3D glasses, etc) while the game already runs on a operating system (P306) and/or an platform (P400). In the cases documented by LGR, the games had to be specially modified to support that kind of hardware, so it might apply to a specific version of that game. I'm also not very familiar with nonfree console games, Are there any situations where some games are made for a platform (Gameboy) but somehow only run on the Gameboy color? I'm interested in that as I proposed a Compatible property: Wikidata:Property_proposal/Compatible_with, so it might be interesting to find ways to precisely describe things regarding the compatibility with specific hardware or API, which is different from platform (P400) or operating system (P306). GNUtoo (talk) 00:37, 28 May 2020 (UTC)
  •   Oppose It's probably super useful to document which motherboard a system has (that can be done through has part) but that's not what this is about. It's rather "compatible with a specific mainboard" or "platform -> [specific mainboard]" and as-is I think that other qualifiers like platform (P400) could be used instead, unless someone find information that would show otherwise as requested in my previous comment. It looks like platform (P400) is sufficient here, but if it's not, I've also proposed a "Compatible with" property that could work too if the platform is not a specific mainboard and that it's only compatible with specific mainboards, though I can't think of examples about that as I'm not familiar with that part of arcade games hardware. Maybe "compatible with" could be used if a video game is known to work on a specific mainboard but that people don't know why, or that the mainboard is listed as officially compatible. GNUtoo (talk) 20:12, 20 June 2020 (UTC)
  • I've done more research on that, and it seems that we have several kind of systems:
    • Neo Geo had mainboards where you could plug cartridges inside, so it acts like a game console.
    • According to an LGR review of a "mainboard", the game and the mainboard seem to be really tied together in people's mind. To me it looks like the game is on some memory chip and could somehow be swapped, but people generally expect the game and the mainboard to be the same thing. Could platform (P400) still make sense here as the game is software that is made for a platform (a given mainboard here), or is platform expected to be something more generic? What about Game & Watch series (Q215034) ? Is that a Platform?. In that case do we need some Compatible property or would a mainboard property still make sense? GNUtoo (talk) 05:28, 8 July 2020 (UTC)

number of pins, number of pin positionsEdit

   Under discussion
Description2 related properties:
  • number of pins: number of contacts that an electrical connector has (excluding any grounding shroud not used for communication)
  • number of pin positions: number of positions in an electrical connector, including empty or keyed positions
Representselectrical contact (Q394001)
Data typeQuantity
Template parameter"num_pins" in en:template:Infobox connector; "contacts" in w:en:Template:Infobox CPU socket
Domainitem: Subclasses of electrical connector (Q2119531). optical fiber connector (Q2296938) could be added later, pending discussion of how to handle optical module (Q48740842)s (which have electrical contacts on one end and optical connections on the other).
Allowed valuespositive integers
Allowed unitsnone
Example 1USB-C connector (Q58051489)
→ "number of pins" → 24
→ "number of pin positions" → 24
Example 2NEMA 5-15 (Q24288456)
→ "number of pins" → 3
→ "number of pin positions" → 3
Example 36P2C modular connector (Q64831598)
→ "number of pins" → 2
→ "number of pin positions" → 6
Example 4Intel HD Audio connector (Q64764371)
→ "number of pins" → 9
→ "number of pin positions" → 10
citation: https://www.intel.com/content/www/us/en/support/articles/000005512/boards-and-kits/desktop-boards.html
Example 5Socket F (Q1475023)
→ "number of pins" → 1207
→ "number of pin positions" → 1225
Planned useAnnotating items for electrical connectors. They could also be generalized to optical fiber connectors, since it's fundamentally the same concept.
Expected completenesseventually complete (Q21873974)
Robot and gadget jobsWhen only "number of pins" is specified, "number of pin positions" can be populated with the same value.
See alsoWikidata:Property proposal/contact area count
Type constraint - subclass ofelectrical connector (Q2119531)

MotivationEdit

For annotating items for electrical connectors (see connector (P2935)).

Why are 2 properties needed? Some connectors have additional positions which are not filled. For example, the RJ11 w:en:Modular connector has 6 physical positions, but only 2 of them are populated. Similarly, the Parallel ATA (Q230360) data connector has 40 positions but only 39 pins, since one position is keyed. The unfilled positions should be counted when the connector's conventional numbering includes them.

Aliases: replace "pin" with "contact" or "conductor"; same without the initial "number of" 2620:0:1000:3216:5413:4AF0:7532:8655 23:59, 21 June 2019 (UTC)

Tobias1984
Emw
Zuphilip
Danrok
Bene*
콩가루
TomT0m
DrSauron
Ruud Koot
Andreasburmeister
Ilya
Toto256
MichaelSchoenitzer
Metamorforme42
Pixeldomain
User:YULdigitalpreservation
Dipsode87
Daniel Mietchen
Jsamwrites
Tinker Bell
FabC
Jasc PL
putnik
Dhx1
Tris T7
Peb Aryan
lore.mazza004
Rc1959
Premeditated
Iwan.Aucamp
LiberatorG
Primhill.Computers
FWVH (passionné d'informatique et d'électronique)
94rain
So9q
Adrijaned
Sylvain Leroux
SM5POR
Haansn08
  Notified participants of WikiProject Informatics 169.234.25.175 20:28, 5 July 2019 (UTC)

DiscussionEdit

  • In principle, we could do it by combining qualifiers with an entity for a pin; there are just some practical issues:
  • It's not totally obvious for an editor which combination to use, and I don't see a way to hint recommended values. For example, quantity (P1114) with applies to part (P518) looks just as plausible (even if you're not supposed to use it that way). Also, people might use other elements besides the intended "pins" and "pin positions", e.g. pogo pin (Q1400617), wire (Q551997), or lead (Q947546). This will make querying more difficult.
  • It's easier to express a constraint that the "pins" and "pin positions" should be specified together when they are expressed as a property.
  • We might want to generalize this to support w:en:optical connectors; we would then have to add some items for pretty abstract concepts that encompass "electrical contact", "termination of a single optical fiber" (is there even a term for that?), and positions thereof. These would be hard to find.
In any case, there are lots of existing "number of X" properties, where X is a domain-specific part that an item contains. 2620:0:1000:3216:5413:4AF0:7532:8655 20:39, 25 June 2019 (UTC)
  •   Support Seems like a fine idea. —Scs (talk) 11:18, 30 June 2019 (UTC)
  •   Split support and oppose   Oppose For the given examples, RJ11 is only valid for countries that only host 2 wires. You can find RJ11 with 4 wires in 6 positions. RJ45 can also be used to replace RJ11, so RJ11 and RJ45 will have several possibilities. In addition, you write "electrical connector" which is quite broad: you give an example of an IC, which enters the electronic domain. With an electronics training, you can find a multitude of cases (so number of pins variable) for a single component (therefore for a single manufacturer and a single function and sometimes with a single denomination). The differences are according to the use of the component: assembly, power, disposition, etc. For the multilingual side of WD and the complexity of the domain (electricity), I fear that this future property brings errors. Of course, in obvious cases, this property will work, but contributors will not stop there. —Eihel (talk) 17:15, 11 July 2019 (UTC)
  • Thanks for the feedback!
  • Regarding RJ11, the Wikipedia article explicitly says RJ11 requires a 2-wire connector (without citation); if you have better information please update that. I switched the example to 6P2C modular connector (Q64831598) for precision, which I forgot to do earlier.
  • I'm not sure what IC you're referring to, but assume you're talking about the CPU socket. I'm aware that a given IC can be packaged in multiple ways, but as far as I've seen, a given CPU socket necessarily has a well-defined number and arrangement of pins, so I don't see the issue.
  • Regarding the risk of misuse, would a property type constraint (should be used on connectors only and not ICs or other components) address this? I'll update the proposal.
73.202.12.249 23:22, 17 July 2019 (UTC)
  1. w:fr:RJ11#Belgique. Indeed, 6P2C is normalized in the sense of the use of pins.
  2. Yes, CPU sockets remain the same as far back as I can remember. But I suggest you look for the term 7805 on your search engine (only browse images to make your life easier). It is a simple CI used in voltage regulation and there is a multitude of form, manufacturer, etc. , so several possibilities. And it's the same for a multitude of CIs, from the simplest to the most complex. Sorry. There is conflicts-with constraint (Q21502838)
    relation (P2309)instance or subclass of (Q30208840)
    class (P2308)electronic component (Q11653)
    constraint status (P2316)mandatory constraint (Q21502408)
    but this restriction will overshadow many items (In addition I do not know if it works!)
  3. In the content of pages linked to the infobox on enwiki, it seems to be appropriate. 78xx does not contain a number of pins and the page does not contain this infobox. —Eihel (talk) 03:26, 28 July 2019 (UTC)
  •   Support I had pretty much the same ideabut called it "contact area count. The reason is that eg. an LGA CPU has no pins. So I searched for a more general name that can be used for multiple things. number of pin positions is an interesting idea, however I'm not sure if this is really the way to go.
An example: A CPU socket has 1000 pin positions. CPU a) has 900 pins, because it's missing some workstation ECC RAM functions. CPU b) has also 900 pins, but not the pins for ECC RAM, but for the ones for CPU interconnects (so a single socket setup). CPU 3) has only 800 pins. It supports CPU interconnect and ECC RAM. He 200 missing pins are because it's a low end version that does not use as much power. How would you include that for the socket (and is the socket the right place to collect that information or should this rather be collected in the CPU item)
A second example: The Type 2 connector that is used to charge electric cars has 7 pins. The maximum output is ~43 kW with 7 pins. For slow charging out of eg. Schuko plugs it is about 3 kW and here only 5 pins are used. It is the same connector and the same layout. One charging type just misses 2 metal connectors. --D-Kuru (talk) 11:58, 2 August 2019 (UTC)
  Comment It sounds like maybe the item for the interconnection standard should list in some way the meaning of all the pins? Though that might require an item for each pin position that further describes it? Like, pin 3 carries this signal with this voltage, etc.?? And then items that conform to that standard would specify that conformance, and which specific pins they actually use? ArthurPSmith (talk) 18:08, 2 August 2019 (UTC)
If it's not an open standard you will never now why one pin is used and the other isn't. A description for every pin is just not usefull in my opinion. In my opinion a "number of used pins" is not really ncecessary since a configuration can change over time and with the used device. If eg. a CPU socket hast 4000 pins and a CPU that fits the socket has 3000 pins, the number of pins for the socket is still 4000 (even some are not used - for now - but could be used at some point) and the CPU also still has only 3000 pins. For me, this applies also for eg. USB or SATA where one pin isn't in use. If USB version 2.0 uses 10 out of 20 pins, the number of pins would be tagged as 10 on the USB connector side. If USB 3.0 uses 20 pins, the pin information could be tagged for version 2.0 and 3.0. But you would not have to set any information about how many pins are not used in the USB connector. What if the USB connector is used anywhere else for some other connection that actually uses all 20 pins right from the start. It's an open standard, so this could happen quite easily. --D-Kuru (talk) 22:07, 6 August 2019 (UTC)
  •   Support Interesting idea. I'm curious to see how it goes. --- Jura 09:05, 4 August 2019 (UTC)
  •   Comment So if 2 properties are actually needed here, could somebody split the template into 2 separate proposal templates with the appropriate examples etc, to make it a little easier on the property creator(s)? ArthurPSmith (talk) 17:09, 7 August 2019 (UTC)
  •   Comment How many pins and number of pin positions do Mini-USB (Q16578670) or Micro-USB (Q1931429) have? Do they always have 5 pins and 5 pin positions? Or are there case where they have 4 pin or pin positions? What the number of pins / pin positions can apply to? Only connectors and similar things? In any case it's very useful to be able to represent the number of pins. It would also be even more useful to enable to have more in depth proprieties about each of the pins such as the voltage levels, the pin name, if it's connected or not, if it's analog or digital, and similar things. You could then potentially reuse that information in CAD software like KiCad (Q942363) if it's mentioned in components. It might be ultra useful for standard connectors or standards like USB connectors, as people often need just the pinout of such connectors for a given standard like USB 2.0. It could even be used to describe the peculiarities of some connector used on some computers or other hardware for instance. GNUtoo (talk) 15:24, 22 May 2020 (UTC)

value group numberEdit

   Under discussion
Description(qualifier only) an higher level of series ordinal used to separate various lists already with series ordinal (P1545)
Data typeString
Domainany
Example 1(Q3595028) fanqie (P5523) (Q2391630) (series ordinal (P1545)=1, value group number=1), (Q55806623) (series ordinal (P1545)=2, value group number=1)
Example 2(Q3595028) fanqie (P5523) (Q2391630) (series ordinal (P1545)=1, value group number=2), (Q55806688) (series ordinal (P1545)=2, value group number=2)
Example 3MISSING
Planned useUse as a qualifier of fanqie (P5523) and ideographic description sequences (P5753)

MotivationEdit

See User_talk:Ivan_A._Krestinin#Bot_edits_on_P5523 as the background of the proposal. GZWDer (talk) 16:24, 18 July 2019 (UTC)

DiscussionEdit

Item Equivalence Fanqie (initial) Fanqie (final) References
A Guangyun (Q2189818)
A Jiyun (Q35792)
A Hongwu Zhengyun (Q10958946)
B Guangyun (Q2189818)
B Jiyun (Q35792), Hongwu Zhengyun (Q10958946)
C Guangyun (Q2189818)
C Jiyun (Q35792), Hongwu Zhengyun (Q10958946)
D Guangyun (Q2189818)
D Jiyun (Q35792)

There are 9 pairs of data, each consisting of an initial and final character, and these 9 pairs can be further grouped into four equivalent pairs of data (A,B,C,D). Are there any existing properties that can be used to handle this situation? KevinUp (talk) 21:00, 18 July 2019 (UTC)

Perhaps the value group number can be modified to "A1, A2, A3, B1, B2, C1, C2, D1, D2" or "1a, 1b, 1c, 2a, 2b, 3a, 3b, 4a, 4b" to mark the equivalence of certain data sets? KevinUp (talk) 21:12, 18 July 2019 (UTC)

Opensofias
Tobias1984
Arthur Rubin
Cuvwb
TomT0m
Physikerwelt
Lymantria
Bigbossfarin
Infovarius
Helder
PhilMINT
Malore
Nomen ad hoc
Lore.mazza51
Wikisaurus
The Anome
The-erinaceous-one
Daniel Mietchen   Notified participants of WikiProject Mathematics for suggestions on how to handle this situation. The proposed property may also have other applications. KevinUp (talk) 19:35, 20 July 2019 (UTC)

  •   Comment @KevinUp: is the suggestion here to have a general mechanism to handle two-dimensional indexing, not just something specific to these characters? That sounds like a reasonable thing to do in principle, but in practice the items would still show up as a one-dimensional list within the Wikidata UI. "Series ordinal" doesn't have to be just a number, you could for example combine letters and numbers, or have two numbers separated by a comma or other special character. Is this really needed? ArthurPSmith (talk) 18:49, 22 July 2019 (UTC)
    @ArthurPSmith: Yes, the idea is to have a general mechanism to handle two-dimensional indexing that can be applied not just to these characters. In the examples given above, "value group number" is used to indicate that group 1, which is represented by (Q2391630) and (Q55806623) and group 2, which is represented by (Q2391630) and (Q55806688) are distinct groups that are not the same. The "value group number" does not indicate any rank but is used to indicate distinction. KevinUp (talk) 20:40, 22 July 2019 (UTC)
    To add another layer of complexity, in the table I have prepared for the item "笈", there are four different groups (A,B,C,D) and each group can be described by more than one method, e.g. in group D, (Q55414074) (series ordinal 1) + (Q54873157) (series ordinal 2) and (Q54879270) (series ordinal 1) + (Q54873157) (series ordinal 2) are equivalent, so we could perhaps use a second character in the value group number, e.g. "4a", "4b" to indicate equivalence of the subgroups a and b within group 4. KevinUp (talk) 20:40, 22 July 2019 (UTC)
  • If you are using series ordinal like 3a or 3.4, they are not much machine readable or queryable. Although this proposal (with only one property) does not work well in more than two dimensions.--GZWDer (talk) 20:58, 22 July 2019 (UTC)
    @GZWDer: To solve the issues of [1] series ordinal such as 3a or 3.4 not machines readable [2] the property in this proposal not working well in more than two dimensions, I suggest the following: KevinUp (talk) 17:45, 25 July 2019 (UTC)
    1. Replace fanqie (P5523) with two new properties: initial fanqie character and final fanqie character (as originally suggested by you) - This is because initial and final fanqie have different properties, i.e. the initial character shares the same initial consonant while the final character shares the same vowel, consonant ending and tone with that of the queried item.
    2. Use series ordinal (P1545) for groups A,B,C,D in the example above (this would indicate that the fanqie readings are distinct).
    3. Apply the proposed property (value group number/group ordinal) to values that have the same series ordinal. This is analogous to A1, A2, A3 in the example above.
    For fanqie, values with the same series ordinal but different value group number/group ordinal are similar in a way, e.g. 其,極,忌 (initial fanqie from A1, A2, A3) all share the same initial consonant in Middle Chinese. KevinUp (talk) 17:43, 25 July 2019 (UTC)
  • Thanks for the responses. So now I'm wondering, where did the proposed label "value group number" come from? Is that a common term used for these character representations, or is that something GZWDer came up with? If we are to do this I think I'd prefer a shorter name if possible. "group ordinal" perhaps? ArthurPSmith (talk) 19:19, 23 July 2019 (UTC)
    No, it's not a common term used for these character representations. I also prefer a shorter name such as "group ordinal" as long as it has the meaning "higher level of series ordinal". KevinUp (talk) 17:43, 25 July 2019 (UTC)
  • I remembered a similar situation at disjoint union of (P2738), where different sets are saved. A special value list values as qualifiers (Q23766486) is used as a dummy value and actual list is saved as qualifier. It might be applicable here. It will look like (Q77040173) fanqie (P5523) list values as qualifiers (Q23766486) / follows (P155) (Q55414074) / followed by (P156) (Q54873157).  – The preceding unsigned comment was added by Midleading (talk • contribs) at 10:16, December 2, 2019‎ (UTC).

part numberEdit

   Under discussion
Descriptionthe item's part number
Representsidentifier (Q853614)
Data typeExternal identifier
Domainproperty
Allowed unitsa string that contains numbers and/or letters
Example 1AMD Phenom II X6 1090T (Q66481199) → HDT90ZFBK6DGR (OEM number), HDT90ZFBGRBOX (boxed number)
Example 2AMD Ryzen Threadripper 2990WX (Q56062941) → YD299XAZUIHAF (OEM number), YD299XAZAFWOF (boxed number)
Example 3Core i5-760 (Q15223620) → BV80605001908AN (OEM number), BX80605I5760 (boxed number, english version), BXC80605I5760 (boxed number, english version)
Sourceen:Part number
Planned useAdd to every item for which a part number can be found

MotivationEdit

While working on CPUs, I noticed that this property does not seem to exist. I had primarly CPUs in mind, but I'm sure there are a lot more items that have a part number in real life.
However, as shown in the example, there can be more than one part number for the same productname. So you have to be able to add some sort of referece to the information (eg. "OEM" or "boxed" or something like that) --D-Kuru (talk) 17:22, 16 August 2019 (UTC)

DiscussionEdit

ChristianKl
ArthurPSmith
d1g
JakobVoss
Jura
Jsamwrites
MisterSynergy
Salgo60
Harshrathod50
Wildly boy
ZI Jony
Ederporto
99of9
Danrok
Eihel
Emw
Fralambert
GZWDer
Ivan A. Krestinin
Jonathan Groß
Joshbaumgartner
Kolja21
Kristbaum
MSGJ
Mattflaschen
MichaelSchoenitzer
Nightwish62
Pablo Busatto
Paperoastro
PinkAmpersand
Srittau
Thierry Caro
Tobias1984
Vennor
Yellowcard
Ivanhercaz
DannyS712
Tinker Bell
Bodhisattwa
Iwan.Aucamp
Cunme
NAH
Gnoeee
The-erinaceous-one


  Notified participants of WikiProject Properties Tobias1984
Emw
Zuphilip
Danrok
Bene*
콩가루
TomT0m
DrSauron
Ruud Koot
Andreasburmeister
Ilya
Toto256
MichaelSchoenitzer
Metamorforme42
Pixeldomain
User:YULdigitalpreservation
Dipsode87
Daniel Mietchen
Jsamwrites
Tinker Bell
FabC
Jasc PL
putnik
Dhx1
Tris T7
Peb Aryan
lore.mazza004
Rc1959
Premeditated
Iwan.Aucamp
LiberatorG
Primhill.Computers
FWVH (passionné d'informatique et d'électronique)
94rain
So9q
Adrijaned
Sylvain Leroux
SM5POR
Haansn08
  Notified participants of WikiProject Informatics Visite fortuitement prolongée (talk) 19:06, 18 August 2019 (UTC)

  •   Question It’s unclear to me if this is really workable. It seems reading the enwiki article that the consumer of the product may use a different number than the producer itself for example. Your difference in the part number type may come either of this, for example if the processor is used on, say, a samsung laptop and samsung gave its own part number something like
    ⟨ Samsung laptop model XYZ ⟩ has part (P527)   ⟨ processor I42 ⟩
    part number search ⟨ ABCDEF ⟩
(in such a case we don’t have to discriminate between the user part number to the manufacturer one because it’s used by a user in a design)
Or … there is several numbers because there is subdesigns by the manufacturer of the same processor, in which case it may be possible to subclass the processor model item with fresh new items to reflect that, with their own properties and values to reflect the differences. author  TomT0m / talk page 19:25, 18 August 2019 (UTC)
As far as I know the CPU type has a unique ID that changes under some conditions. The manufacturer is not such a condition - at least as far as I know. Since the ID is unique to every processor type I switched the datatype to external-id. It seems that the different numbers are more to indicate which segment of the global market is targeted. If the CPUs ID is ABC1 in the boxed version you will not find an appropriate CPU when it is labled ABC2. Even they are actually the same die under the hood. I don't think that a new item is really the route to go if there is just a different ID, but all other values stay the same. You don't create a new item for every version of some program, do you? --D-Kuru (talk) 20:58, 20 August 2019 (UTC)
  Question Is this at all related to Global Trade Item Number (P3962)? See also the discussion on this old proposal. ArthurPSmith (talk) 17:50, 19 August 2019 (UTC)
Yes and now I would say. The part number is not the European Article Number. There is no bar code on the processor. But it's shares some properties since it's also a unique ID for every product. --D-Kuru (talk) 21:00, 20 August 2019 (UTC)
  •   Support given that it's distinct from the EAN. ChristianKl❫ 07:46, 30 August 2019 (UTC)
  •   Question for me it's unclear if it is different from the stock-keeping unit (Q399757) given by the manufacturer? Dom (talk) 09:39, 22 September 2019 (UTC)
stock keeping units are retailer codes that track price, manufacturer and product information of the product and are used to track sales. The part number is more like a barcode. An individual code for certain product types. Since it's not about tracking - at least not that I know - they are different in my opinion --D-Kuru (talk) 16:26, 25 November 2019 (UTC)
  Support. Thanks for the explanation. We probably need to add it in the property once it is created to disambiguate between both properties. GNUtoo (talk) 20:47, 20 June 2020 (UTC)
  Question Currently the linked CPU page use serial number (P2598) which is explicitly not for that purpose: "Not a product code or model number". To me it seems a property that can be used together with existing stock-keeping unit (Q399757), part number (Q3879409) and item number (Q57446692) is needed.  – The preceding unsigned comment was added by F-ludwig (talk • contribs).
Good point. I added corresponding property constraints at Property:P2598#P2302. --- Jura 11:31, 19 July 2020 (UTC)
  •   Strong oppose not an "external-id" type ; subject item is in source field: part number (Q3879409) ; not "property" domain ; RegEx field empty ; etc. I give this opinion to avoid that a new property is created in this way, sorry. —Eihel (talk) 00:25, 23 August 2020 (UTC)

religion or world viewEdit

   Ready Create
Descriptionreligious or world view affiliation of a person, organization or religious building
Representsreligion or world view (Q71966963)
Data typeItem
Domainitem (persons, corporate bodies), e.g. Hans Modrow (Q57241)
Allowed valuesitem (persons, corporate bodies
Example 1Bertrand Russell (Q33760)atheism (Q7066)
Example 2David Malet Armstrong (Q1173590)naturalism (Q56000)
Example 3William Stewart Ross (Q2580659)agnosticism (Q288928)
Example 4Leo von Caprivi (Q10873)Catholicism (Q1841)
Example 5Rudolf Steiner (Q78484)anthroposophy (Q184719)
Planned useI would like to use this property in a to-be-built linked-data contemporary-history dataset held by a German research centre.
See alsopolitical ideology (P1142), religion (P140)

MotivationEdit

Properties religion (P140) and political ideology (P1142) do not intersect nor overlap. Yet I suggest to create the property "religion or world view" that would incorporate both of them in a consistent way. This property would like to describe the religious or ideological affiliation in a more comprehensive way than the afore-mentioned properties do. The to-be-created property wishes first of all to express the German fixed expression "Religionszugehörigkeit oder Weltanschauung", which has a broad use and a high frequence in German-speaking countries, and for which the property religion (P140) is not equivalent. Yet the use of the property "religion or world view" would be helpful for every linguistico-cultural context in order to describe the affiliation of an individual, may he be catholic, atheist, agnostic or polytheist.  – The preceding unsigned comment was added by F.Gelati (talk • contribs).

DiscussionEdit

  •   Support if P140 and P1142, became redundant, are then deleted.   Oppose otherwise. Nomen ad hoc (talk) 20:13, 23 October 2019 (UTC).
  • Deleting Property:P140 and Property:P1142 is in my understanding premature. P140 is more appropriate e.g. when describing places of worship, because a marginal number of them are agnostic or atheist. P1142 is based on the clearly-defined same-name class Q12909644 and I would not consider it redundant. In my view, all three of them can coexist. User:F.Gelati
  • I'd like to see some more examples (perhaps you have some from German-speaking countries?) where this property would be required and the existing properties would not be sufficient. Your examples so far don't, I think, meet that standard. ArthurPSmith (talk) 16:44, 24 October 2019 (UTC)
  • As an example, The German Biography displays personalities' confession: for atheists, e.g. E.Krenz or E.Honecker, the field bears a "/", which is not exhaustive. This database displays religious confessions only but no world view. Creating the property "religion or world view" would allow to solve this disparity. Alternatively, a property from World view could be created, for the relation between religion and world view is debated: see World view. --F.Gelati (talk) 09:36, 25 October 2019 (UTC)
  • Antroposophy is described in English Wikipedia as philosophy, and Nazism as ideology, whereas both of them may be defined as world views too, as their German-written pages do. This proofs in my understanding that the property "religion or world view" would offer an exhaustive alternative to such fragmented solutions. --F.Gelati (talk) 10:16, 25 October 2019 (UTC)
  •   Support I'm inclined to view all of these as one or another kind of religion, but if the people accustomed to using religion (P140) don't want to broaden it in this fashion, then a new property makes sense to me. ArthurPSmith (talk) 17:50, 29 October 2019 (UTC)
  •   Oppose. Seems redundant with the existing properties. --Yair rand (talk) 00:51, 31 October 2019 (UTC)
  •   Oppose per Yair rand. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:32, 21 November 2019 (UTC)
  •   Support A natural parent of political ideology (P1142) and religion (P140) that supports values for which neither of those are appropriate. Suggest alias "philosophical position". Swpb (talk) 15:02, 27 December 2019 (UTC)
  •   Support per Swpb as a parent to existing categories but not to replace them. Some world views can be clearly attributed to political or religious and others may not which is the reason for this proposal. --Hannes Röst (talk) 02:35, 6 June 2020 (UTC)
  •   Support, but I think we should just call it "worldview." That way, if either "political ideology" or "religion" apply to an item , then they should be used. In cases, when they don't, then "worldview" can be used. The-erinaceous-one (talk) 07:14, 13 September 2020 (UTC)
  •   Comment Actually, I suggest we use something more general than "worldview." What if we instead called it something like "philosophical view" or "philosophical stance"? My objection to merely using "worldview" is that it is unnecessarily restricting---a person could have any number of notable philosophical beliefs that aren't "worldviews." For instance, philosophical beliefs about epistemology, ethics, aesthetics, or logic are not "worldviews" but might still merit inclusion in Wikidata. The-erinaceous-one (talk) 07:26, 13 September 2020 (UTC)
    • "philosophical view/stand" for me sounds like a thing that should be one of Empiricism/Naturalism/Pragmatism/Rationalism/Relativism/Skepticism or subclass. Orthogonal to religion, in other words. Also there are religion-centric stands, like Islamic philosophy (Q193104). --Lockal (talk) 12:10, 30 October 2020 (UTC)
Template:Commen Whats gonna happen to political ideology (P1142) and religion (P140)?--Trade (talk) 12:08, 7 November 2020 (UTC)

verifiability of propertyEdit

   Under discussion
DescriptionVerifiability of this property, one of "Verified", "Human verifiable", "no value"
Data typeItem
Domainproperty
Allowed values"Verified", "Human verifiable", "no value"
Example 1stated in (P248) → "Verified"
Example 2imported from Wikimedia project (P143) → "Human verifiable"
Example 3retrieved (P813) → no value
Example 4reference URL (P854) → "Verified"
Planned useSourcing SPARQL query
Robot and gadget jobsno

MotivationEdit

We need a way to enforce that results from Wikidata query service are reliably sourced. Currently there is no simple way to require higher reliability standard in Wikidata query service than "wdt". And this means unsourced statements or statements imported by bots from Wikipedia will appear in query result. Simply requiring a source be provided doesn't work, because it can be imported from Wikimedia project (P143) Wikipedia (Q52). Requiring any sources other than imported from Wikimedia project (P143) doesn't work either, because imported from Wikimedia project (P143) can be accompanied by retrieved (P813), and retrieved (P813) triple will be matched by SPARQL software as a valid source. Not to mention we are starting to have new identicals of imported from Wikimedia project (P143), such as Wikimedia import URL (P4656) and inferred from (P3452).

Using this new property, we can write SPARQL query that require the data be properly sourced. Example:

SELECT ?item ?value ?reliablesource ?reference WHERE {
  ?item p:P31 [ps:P31 ?value;
               a wikibase:BestRank;
               prov:wasDerivedFrom [?reliablereference ?reference]].
  ?reliablesource <http://example.com/verifiability> <http://example.com/Verified>;
                  wikibase:reference ?reliablereference.
}

Alternatively, we can link the new items "Verified" or "Human verifiable" to properties using existing properties, for example instance of (P31) or has quality (P1552). But using a new property we can even define a hierarchy of reliability. For example if statement "Verified" next lower rank (P3729) "Human verifiable" exists, we can write the following SPARQL query to require the result having at least one source even if it is linked to Wikipedia (Q52), but do not include unsourced statements or bogus sources, for example a reference with only retrieved (P813):

SELECT ?item ?value ?reliablesource ?reference WHERE {
  ?item p:P31 [ps:P31 ?value;
               a wikibase:BestRank;
               prov:wasDerivedFrom [?reliablereference ?reference]].
  ?reliablesource <http://example.com/verifiability>/wdt:P3729* <http://example.com/HumanVerifiable>;
                  wikibase:reference ?reliablereference.
}

Midleading (talk) 12:28, 10 December 2019 (UTC)

Data Model: There are multiple ways to model source reliability. We should decide which one we want to use.

  1. "Generic reliable source" > "Unreliable source", as proposed above.
  2. "Reliable source from trusted organizations and governments" > "Generic reliable source" > "Unreliable source". Defines a multi-level reliability hierarchy. More levels can be added if necessary.
  3. "Reliable source of science", "Reliable source of law", "Reliable source of medicine", "Reliable source of biblography", "Generic reliable source", "Unreliable source". Defines reliability by area.
  4. "Primary source", "Secondary source", "Tertiary source", "Generic reliable source", "Unreliable source".

Also we need to discuss the criterion used to define this property, is it about verifiability or is it about reliability? Midleading (talk) 08:06, 11 December 2019 (UTC)

DiscussionEdit

  •   Support, seems interesting. Nomen ad hoc (talk) 18:29, 10 December 2019 (UTC).
  •   Support I think it would be very useful. --Tinker Bell 20:28, 10 December 2019 (UTC)
  •   Support David (talk) 07:01, 11 December 2019 (UTC)
  •   Comment doesn't reliability/verifiability attach to the source, not the way in which it is referenced (i.e. why is this a property to be attached to reference properties?) I can link just about anything I want with reference URL (P854), that doesn't mean it's either reliable or verifiable! (for example if the website domain has disappeared it can probably no longer be verified...) This doesn't feel like the right approach to modeling this. To identify types of reference properties it would probably be better to just subclass Wikidata property to indicate a source (Q18608359), no? ArthurPSmith (talk) 20:03, 11 December 2019 (UTC)
Using a subclass technically works, but the new items used to specify property verifiability are subclass of Wikimedia internal item (Q17442446), as they are specific to Wikidata. The properties themselves are subclass Wikidata property to indicate a source (Q18608359) but not indirect subclass of Wikimedia internal item (Q17442446). Also, this new property uses parent relationship next higher rank (P3730)next lower rank (P3729) which is different from subclass of (P279). This property doesn't indicate the results are indeed reliable, the statement can still be incorrect or vandalized, but the reference is listed in query result which you can verify by consulting sources. Without this property, you will be overwhelmed by huge list of values without means to verify.--Midleading (talk) 02:25, 12 December 2019 (UTC)
Properties are specific to Wikidata too, I'm not sure what your point is there. Here's specifically what I'm suggesting: create new items like "Wikidata property to indicate a verified source", "Wikidata property to indicate a human-verifiable source" as subclasses of Wikidata property to indicate a source (Q18608359), and make stated in (P248) an instance of the first, imported from Wikimedia project (P143) an instance of the second, and leave retrieved (P813) as it is. You can relate the new items with next lower rank (P3729) etc. relationships if you like, and a modified version of your SPARQL will work the same way, but using the subclass relation instead of a new property. ArthurPSmith (talk) 18:25, 12 December 2019 (UTC)
I don't think properties are specific to Wikidata because many of Wikidata property to indicate a source (Q18608359) have an external equivalent property, for example publication date (P577) = schema:datePublished . Making them an instance of Wikimedia internal item (Q17442446) is just like saying universe (Q1) is instance of "Wikipedia article". I'm fine with using subclass instead of a new property, provided we maintain the ontology stable so that we aren't forced to use ugly/slow "?reliablesource wdt:P31/(wdt:P279|wdt:P3729)* wd:Q123456789" and/or VALUES statement in next years, and the new subclass can't be used to infer the properties are Wikimedia-only.--Midleading (talk) 05:29, 13 December 2019 (UTC)
They're already listed as instances of Wikidata property to indicate a source (Q18608359) so whether or not you consider them Wikimedia-only, making them instances of subclasses of that won't change anything in that respect. Also have many existing items that were created for purposes like this and should remain stable - for example all the property constraint-related items. ArthurPSmith (talk) 18:47, 13 December 2019 (UTC)
@Midleading: That property exist to express a relationship that's defined by policy. This policy wants to say things about what sources are reliable in the absence of policy. A datamodel of how we think about source reliability should be codified in policy and RfC approved. ChristianKl❫ 11:23, 4 September 2020 (UTC)
Wikidata:Living_people exists because we protect the rights of living people. If an user violates that policy, he or she might be warned or blocked. But this one? I may violate this "reliable sources" policy, if defined, any time. Nobody would be blocked. I don't like such a useless policy being codified. If such a policy would be defined, it is the statement in the reference that matters, not the property itself. --Midleading (talk) 05:32, 5 September 2020 (UTC)
As explained from the start, this doesn't work because 1. there are references which combine imported from Wikimedia project (P143) and retrieved (P813) 2. there is other imported from Wikimedia project (P143) equivalent, for example, Wikimedia import URL (P4656). --Midleading (talk) 05:32, 5 September 2020 (UTC)
  Oppose I don't get the benefits from this proposal tbh. There should be no credibility differences between bot edits and human edits. If there are low quality bot edits, request the bot to be blocked. If you do not want to use information imported from Wikimedia projects, filter for imported from Wikimedia project (P143). -- Dr.üsenfieber (talk) 09:10, 12 September 2020 (UTC)

recipient (aliases: to, intended recipient, receiver, target, beneficiary, awardee)Edit

   Under discussion
Descriptionperson, group, or organization to which the given entity is directed, given, or sent
Represents
Data typeItem
Domainitems
Example 1pitch (Q1063937) recipient catcher (Q1050571)
Example 2Orteig Prize (Q1930819) recipient Charles Lindbergh (Q1618)
Example 3Zimmermann Telegram (Q154091) recipient Heinrich von Eckardt (Q1599502)
Example 4consumer complaint (Q1473099) recipient consumer organization (Q1329436)
Example 5Alaska Purchase (Q309029) instance of (P31) purchasing (Q1369832) / of (P642) Alaska (Q797) / recipient United States of America (Q30)
See alsoPossible parent properties:
  • participant (P710) or significant person (P3342) (these do not specify a role without adding a qualifier)
  • Possible sub-properties:

    Other similar properties:

    MotivationEdit

    To express a major thematic relation that is not well addressed by existing properties (as noted in the "See also" field). Swpb (talk) 19:48, 26 December 2019 (UTC)

    DiscussionEdit

    •   Support David (talk) 06:04, 27 December 2019 (UTC)
    •   CommentIs it the same as addressee (P1817)?--Midleading (talk) 09:13, 27 December 2019 (UTC)
      • addressee (P1817) at present only covers one of several use cases of the proposed property, but I would not be opposed to a radical expansion of its definition (really, turning it into the proposed property), rather than creating a new property, if folks like that idea. Swpb (talk) 14:31, 27 December 2019 (UTC)
    •   Oppose Widen winner (P1346) instead. Nomen ad hoc (talk) 17:30, 27 December 2019 (UTC).
      • That makes no sense. This is for items that are transferred between parties. Winning an event may involve the transfer of a prize to the winner, but often does not. If we were to turn that property into this one, someone would immediately propose a new "winner" property exactly like the old one, and with good reason – these are not at all the same concept. If any property were appropriate to expand into this role, it would be addressee (P1817), certainly not winner (P1346). I gather from Wikidata:Property proposal/general law that your preference is to shoehorn new uses into existing properties whether they fit there or not. In both these cases, not. Swpb (talk) 18:04, 27 December 2019 (UTC)
    •   Support but I would also support expanding the definition of addressee (P1817) if that's the consensus here. ArthurPSmith (talk) 21:28, 30 December 2019 (UTC)
    •   Oppose I think all usecases are already covered --- Jura 10:15, 20 January 2020 (UTC)
      • Please elaborate by expressing the example statements with existing properties. Without major expansion (e.g. of addressee (P1817) as discussed above), the existing properties simply do not work. Would you allow addressee (P1817) to be changed as described? Swpb (talk) 20:34, 21 January 2020 (UTC)
        • Notably by award received (P166), addressee (P1817) you apparently don't want to see in the "see also" section. I know it makes it more difficult to argue the added value of the property. BTW: first time a proposer deleted valid content from a proposal. --- Jura 20:36, 21 January 2020 (UTC)
          • addressee (P1817) is discussed above; please comment accordingly: would you allow it to be radically expanded for this role? In it's current form, it is explicitly limited to letters and notes. And award received (P166) takes a completely different class as values, namely awards, not people who receive them – its mention was a non-sequitur and presumably an accident. And no, you don't get to edit my proposal; the discussion section is good enough for everyone else, and it will be good enough for you. Swpb (talk) 20:40, 21 January 2020 (UTC)
            • Do you understand that you are proposing an inverse property for award received (P166)? --- Jura 20:48, 21 January 2020 (UTC)
              • 1) I am not, and 2) if I were, that wouldn't be an argument against. That's also a remarkably different argument from your initial one; I certainly hope your personal feelings towards me aren't the real factor here. Swpb (talk) 20:49, 21 January 2020 (UTC)
                • You might want to have a look at the item used as value in the second sample above, notably the statements at Q1618#P166. --- Jura 20:53, 21 January 2020 (UTC)
                  • And the four examples that have nothing to do with prizes? Covering a use case is not the same as being limited to that use case; which again, wouldn't be a problem anyway. Swpb (talk) 20:57, 21 January 2020 (UTC)
                    • 2 are covered by addressee (P1817). The first by "participant" with object has role. This has the advantage that the pitcher doesn't get omitted. The last one seems to be an error. --- Jura 21:01, 21 January 2020 (UTC)
                      • Ah, so 60% of the examples are not covered by addressee (P1817), unless we expand it! For the third time: are you for that? (Unsurprisingly, I don't find your takes on examples #1 and #5 compelling either, but at least they're valid opinions.) Swpb (talk) 21:05, 21 January 2020 (UTC)
                        • Given that we have 453,654 items with award received (P166), it's likely that 95% of actual Wikidata uses are covered.
    BTW, small correction: 1 is covered by P1817. It's unclear how "consumer complaint" recipient "consumer organization" is covered even by this proposal.
    Maybe you could explain how the seller and the pitcher is meant to be included. --- Jura 21:13, 21 January 2020 (UTC)

    author  TomT0m / talk page Mbch331 (talk) Jobu0101 (talk) Tubezlob (🙋) Flycatchr Koxinga (talk) Fuzheado (talk) Mfchris84 (talk) Manu1400 (talk) Daniel Mietchen (talk) Nomen ad hoc (talk) 07:53, 16 November 2019 (UTC)

      Notified participants of WikiProject Award @GerardM:

    There is no use case for it. It increases bloat in Wikidata. For years now we have found that a user interface like Reasonator shows perfectly well all known instances of recipients of an award. It is safe to say that the best remedy for this perceived need is a user interface Consider bloat, there are awards with over 500 recipients.. Additionally you gain a major pain; synchronising and error checking on duplicate entries (they are the same information). Thanks, GerardM (talk) 06:27, 22 January 2020 (UTC)
    I don't like to use the same property for diverse purposes (addressee, buyer, winner, target, ...). They will probably raise issues when the property is to be translated into every languages, and introduce unwanted items for property users. Can we discuss each of these usecases separately?--Midleading (talk) 13:42, 26 February 2020 (UTC)

      Support I like the idea of having more general relations to use as a fallback while we're waiting for more specific properties to be added. --Cdo256 (talk) 05:13, 9 September 2020 (UTC)

    external typeEdit

       Not done
    Description(qualifier only) main type of entry in external database (i.e. which separating those items into a limited number of broad categories, like P107 formerly did)
    Data typeItem
    Domainvarious
    Example 1Jehan Sadat (Q212190) GND ID (P227) 118604740 <external type> person (Q215627)
    Example 2Nature (Q180445) Microsoft Academic ID (P6366) 137773608 <external type> magazine (Q41298)
    Example 3(normal rank) Microsoft Academic ID (P6366) formatter URL (P1630) https://academic.microsoft.com/journal/$1 <external type> magazine (Q41298) (The current value will be perferred rank)
    Example 4Leonardo da Vinci (Q762) IMDb ID (P345) nm1827914 <external type> personal name (Q1071027)
    Robot and gadget jobsYes

    MotivationEdit

    For example Wikidata:Property_proposal/J-GLOBAL_ID contains multiple different types of entries using the same ID scheme. Microsoft Academic now uses a new URL scheme (though the old one still works currently); if the old scheme no longer work we will be able to migrate data to new properties easily using this qualifier.

    Questions: Should we create new items dedicated to the external types? GZWDer (talk) 10:23, 27 December 2019 (UTC)

    DiscussionEdit

    type of external pageEdit

       Under discussion
    Description(qualifier only) type (read: status) of external page
    Data typeItem
    Example 1Second Crusade (Q51654) Encyclopædia Britannica Online ID (P1417) event/Second-Crusade <type of external page> <Britannica directory page>
    Example 2MISSING
    Example 3MISSING

    MotivationEdit

    Wikidata:Requests for permissions/Bot/BsivkoBot proposed to deprecate all links to Britannica directory pages. I propose to tag them with a new qualifier. See also Wikidata:Project_chat/Archive/2016/11#Encyclopædia_Britannica's_'empty-ish'_concepts_in_Mix'n'Match. GZWDer (talk) 21:53, 29 December 2019 (UTC)

    DiscussionEdit

      Support This seems like a good solution to the problem at hand. ChristianKl❫ 11:16, 30 December 2019 (UTC)

      Support but I still have the feeling that they simply added them for ad revenue. --SCIdude (talk) 15:41, 30 December 2019 (UTC)

    • Actually having such entries is good in some perspective, as 1. this still refers to some clear distinguishable entries and 2. this prevents duplicate and naming conflict, and the "stub" may be expanded to a full article. This is somewhat like a solution similar to mw:Extension:ArticlePlaceholder/Smart red links (cf phab:T123021). --GZWDer (talk) 16:48, 30 December 2019 (UTC)

      Support I had thoughts about kind of parameters (like qualifier) to resolve the problem, but I'm not so expert in Wikidata to make such initiative. Thanks to starter for the proposal. Bsivko (talk) 20:55, 30 December 2019 (UTC)

    •   Support. Sounds OK. Nomen ad hoc (talk) 21:09, 30 December 2019 (UTC).
    •   Comment Why not use object has role (P3831) for this? Unless you have some other cases where this specific qualifier would be helpful, I think a more generic solution is better. ArthurPSmith (talk) 21:12, 30 December 2019 (UTC)
    • @ArthurPSmith: actually this example Britannica page also has an external type, which is "event".--GZWDer (talk) 07:30, 31 December 2019 (UTC)
    •   Comment why this new very specific property if you can just qualify it with object has role (P3831)? Multichill (talk) 13:08, 31 December 2019 (UTC)
      • Oh wait, Arthur already said the same :-) So   Oppose unless someone can come up with a good reason why it shouldn't be done that way. Multichill (talk) 13:11, 31 December 2019 (UTC)
      • I think you are right. I withdraw my support vote and also   Oppose. ChristianKl❫ 08:03, 2 January 2020 (UTC)
      • It could be there are two identifiers of one scheme on the same item, e.g. one for the real name and another for a stage name. These would probably be differentiated by object has role (P3831)
        BTW not really convinced by the usecase. I don't see why we should link empty-ish pages in the first place. --- Jura 11:33, 20 January 2020 (UTC)

    armament usedEdit

       Under discussion
    Descriptionarmament used to commit an act
    Representsweapon (Q728)
    Data typeItem
    Allowed valuesany P31/P279 of weapon (Q728)
    Example 1armament used → AGM-114 Hellfire (Q271930) as qualifier under manner of death (P1196) assassination (Q3882219)
    Example 2MISSING
    Example 3MISSING
    Planned useas qualifier for describing weapons used for assassinations and targeted killings see e.g. Qasem Soleimani (Q892014)
    See alsoarmament (P520), Wikidata:Property proposal/equipment used

    MotivationEdit

    Enables better modeling of targeted killings, equipment and weapon used.--So9q (talk) 15:12, 5 January 2020 (UTC)

    DiscussionEdit

    • It doesn't fit. "equippable weapon item for the subject" this is wrong when we are trying to model that this armament was used to kill someone, not that someone was equipped with the armament when killed. See the example. manner of death (P1196) assassination (Q3882219) + qualifiers ordered by=donald trump + armament=hellfire missile is not clear. Who is equipped with the armament? Donald Trump? Armament is used as a main value to e.g. describe the weaponry a military aircraft be equipped with, see https://www.wikidata.org/wiki/Q816695.--So9q (talk) 19:58, 6 January 2020 (UTC)
    • It seems clear enough to me. But maybe some others should weigh in on how this should be modeled... ArthurPSmith (talk) 16:34, 13 January 2020 (UTC)

    local to a language contextEdit

       Under discussion
    Descriptionproperty to identify the concepts related to the group of territories where a language is spoken
    Representslanguage territory (Q8561610)
    Data typeItem
    Domainlanguage territory (Q8561610), group of territories where a language is spoken. This is the language context. A concept of a language context is related to both the territorial entities (political territorial entity political territorial entity (Q1048835) and country country (Q6256)) and the culture culture (Q11042).
    Allowed valuesany language Qitem.
    Example 1Naples (Q2634)Italian (Q652), Neapolitan (Q33845)
    Example 2pesto (Q9896)Italian (Q652)
    Example 3Juventus F.C. (Q1422)Italian (Q652)
    Example 4Vasco Rossi (Q17171)Italian (Q652)
    Example 5Pep Guardiola (Q164038)Catalan (Q7026)
    Example 6Sagrada Família (Q48435)Catalan (Q7026)
    Example 7Andorra la Vella (Q1863)Catalan (Q7026)
    Example 8crema catalana (Q842566)Catalan (Q7026)
    Example 9Inca civilization (Q3404008)Quechua (Q5218)
    Example 10Huascarán (Q200935)Quechua (Q5218)
    Example 11Quechuas (Q134936)Quechua (Q5218)
    Example 12Chavin de Huantar (Q732554)Quechua (Q5218)
    Planned usefor creating selections of prioritized content to bridge the gaps and help language editions reach a higher cultural diversity in their contents.
    See also

    MotivationEdit

    This property is required to identify the most important items that relate to the context where a language is spoken, whether it is composed of one country or region or several. These items can be located in places, but also on traditions, language, politics, agriculture, biographies, events, etc. They are a collection local to a language context (e.g. Branbury cake is local to the English context, but also Time Square or the comedian David Mitchell).

    We suggested this property because in order to bridge the content gaps between language editions it is essential to identify which articles are “local” (see Cultural Context Content or related papers[1][2]), as they tend to be more developed because of their most direct knowledge and access to sources. By identifying which articles are local to every language context it is possible to create lists of essential or vital articles that can be considered to guarantee a minimum of content cultural diversity.

    As said, in a language context there are all kinds of topics. According to the most recent results from the method proposed by the project Wikipedia Cultural Diversity Observatory (WCDO), the extent of content that relates to a language context is around 25% of the articles in the largest 40 Wikipedias. In smaller languages, the percentage is much smaller as they have not devoted enough attention to represent their context. This is clearly a barrier to all the Wikipedia project achieve the sum of human knowledge.

    This property requires a language item. So, based on the data provided by the project WCDO we will create triplets to mark the articles (100 to 500) of that relate to the language context of the three hundred language editions. These are named Top CCC articles.

    ReferencesEdit

    1. Miquel-Ribé, M., & Laniado, D. (2018). Wikipedia Culture Gap: Quantifying Content Imbalances Across 40 Language Editions. Frontiers in Physics.
    2. Miquel-Ribé, M., & Laniado, D. (2019). Wikipedia Cultural Diversity Dataset: A Complete Cartography for 300 Language Editions. Proceedings of the 13th International AAAI Conference on Web and Social Media. ICWSM. ACM. 2334-0770

    --Marcmiquel (talk) 15:41, 13 January 2020 (UTC)

    DiscussionEdit

    @Marcmiquel: Isn't this use case taken care of now by the combination of location properties and language used (P2936) on the geographic items? For example Sagrada Família (Q48435) located in the administrative territorial entity (P131) ... Catalonia (Q5705) which has language used (P2936) Catalan (Q7026) (and others). Or are you trying to accomplish something else here? ArthurPSmith (talk) 20:38, 13 January 2020 (UTC)
    @ArthurPSmith, you are right that some are tackled with location and language properties. The creation of the dataset of articles that belong to a language context for each language edition uses these two properties (and many other aspects, as you can consult in the links/papers). The final selection of articles local to a language context is richer though - it includes items that range from traditions, people, places, language traits, etc. Having these collections is essential to later select the most relevant part of each language context, which should be prioritized in translation to other language editions. This is what the "Top CCC lists" is doing. They are algorithm-generated lists of 100-500 articles of the most essential articles of each language context that every other Wikipedia should have in order to ensure a minimum coverage of the existing Wikipedia cultural diversity. The purpose of this property is to be able to search the gaps using Wikidata queries. --Marcmiquel (talk) 11:02, 14 January 2020 (UTC)
    @Marcmiquel: So it's not just location + language, but also some notion of importance? How would you prevent this property from automatically being applied to, say, every village in Italy, or every type of pasta, to add "Italian" as the context? Or would that be ok? If there's a significance criterion involved then I don't think the label quite matches what you are trying to do here. ArthurPSmith (talk) 18:28, 14 January 2020 (UTC)
    It occurred to me that you are perhaps trying to duplicate this property: on focus list of Wikimedia project (P5008)? Would that existing property meet your needs? ArthurPSmith (talk) 18:30, 14 January 2020 (UTC)
    @ArthurPSmith: it is not just location + language, it's everything related to the context where the language is spoken. The notion of importance lies in just using the property for 100 or 500 items. However, the cultural context content of a language is more extense (in the Italian Wikipedia it is a 17.17% of its content, in the English a 44.91%, in the Catalan a 16.62%). With this property as presented, they could apply this property to the entire extent of cultural context content. I think it would be ok, but to mark the first 100 or 500 there should be another way. Or this property should have a criterion of importance in it. The on focus list of Wikimedia project (P5008) is good for specific projects, but here we are talking about a property with possible 300 values (languages). If we apply it to 100 items per language, then we have 30,000 items which are the "most relevant content for cultural diversity in Wikipedia". --Marcmiquel (talk) 08:53, 16 January 2020 (UTC)
    • Wikidata properties do not work like in your (current) examples. Please replace "is part of the x language context" by "=>". Visite fortuitement prolongée (talk) 21:48, 13 January 2020 (UTC)
    Thanks, I fixed it. --Marcmiquel (talk) 10:51, 14 January 2020 (UTC)
    @ChristianKl: Thanks for your answer. Yes, a cultural context is richer than location and language, it's what they create in it the speakers of that language. Could you explain how do you imagine this new property? Isn't it the one I am suggesting? --Marcmiquel (talk) 10:21, 16 January 2020 (UTC)
    I think that language used (P2936) should be used on Naples (Q2634) and that language used (P2936) might be subproperty of (P1647) of the newly created property. I don't think the newly created property should be used directly for Naples (Q2634). ChristianKl❫ 15:38, 16 January 2020 (UTC)
    Sorry @ChristianKl:, I'm not sure I understood what you propose as scheme. Could you explain it a bit more? Likewise, could you please guide me a bit on how we should proceed. I'm new at Wikidata property proposal. Thanks. --Marcmiquel (talk) 12:05, 19 January 2020 (UTC)
    Remove all the cases where the usecase is already covered by language used (P2936) or located in the administrative territorial entity (P131) from the list of examples. ChristianKl❫ 08:34, 20 January 2020 (UTC)
    If I remove these other cases covered by these properties, I might also need to remove many other properties. Isn't it possible to have a certain redundancy? --Marcmiquel (talk) 19:19, 28 January 2020 (UTC)
    In general, people doing gap analysis with Wikidata tend to get the completeness of Wikidata or the ground truth wrong. I haven't gone through your papers though.
    1. Can you explain the reasoning (ideally with references) that links "Pesto" to Italian language (second sample above)?
    2. Why has Naples (Q2634) Italian (Q652), but not Neapolitan (Q33845), Latin or Ancient Greek (Q35497)?
    3. Why does the "domain" above mention territory, but the samples use other (people, food, etc.)?
    4. Please fill in the "description" field.
    5. I added a few related properties as "see also" above.
    If it's merely an idiosyncratic approach, I think one would want to go with on focus list of Wikimedia project (P5008). --- Jura 09:10, 20 January 2020 (UTC)
    @Jura1:Presenting the idea here is part of the exploration of Wikidata's potential to bridge the gaps. I'm very open to check other possibilities. I'll try to answer your questions. 1. The reasoning behind linking Pesto to the Italian is that Pesto is a concept related to the Italian language territory (territories where Italian is spoken) since it was created there. I collect Cultural Context Content (CCC), which is usually called local content, and it contains all the concepts related to the territories where the language is spoken. This includes people, places, things, recipes, etc. I suggest you check the papers or the project Wikipedia Cultural Diversity Observatory I posted in this section. 2. Yes, indeed, it could be any of these languages (not Latin, as it is not in current use, just in the Vatican). 3. Just did it. 4. Thanks, they make sense. I appreciate your feedback. --Marcmiquel (talk) 19:13, 28 January 2020 (UTC)
    • (1) For "Pesto", that relationship is already indicated by "country of origin" = "Italy".
    (2) I added Neapolitan (Q33845) to the sample. If you exclude Latin, you'd also exclude Ancient Greek I suppose.
    (3) "domain" in the proposal would be the class of items that could hold it. Apparently it's any (populated) geographic location, not just "language territory (Q8561610)", + a few other classes of items.
    I tend to agree with ChristianKl that if the relationship is already covered by another property (or a combination as shown), there isn't much use of adding another one. It would be good to see use cases that aren't covered.
    BTW Another gap analysis done for itwiki: it:Progetto:Coordinamento/Wikidata/Italiani_senza_voce. --- Jura 14:28, 30 January 2020 (UTC)
    •   Comment maybe I dont quite understand this but to me it seems that it would make more sense to connect this to a culture (e.g. crema catalana (Q842566) would fit to an Catalan culture context which could then have language used (P2936) Catalan (Q7026)). To me it just seems unnatural to make attach crema catalana directly to the Catalan language / Pesto to the Italian language and not to a cultural context instead. I also agree that probably most of these properties can already be inferred as indicated above. --Hannes Röst (talk) 03:03, 6 June 2020 (UTC)

    next level in hierarchyEdit

       Under discussion
    Descriptionqualifier: indicates the value at the next hierarchy level which is true for this item, when more than one is possible at the next level
    Data typeItem
    Domainqualifier only in transitive property (Q18647515) with hierarchy (Q188619)
    Example 1111
    Example 2
    Example 3
    Planned usefor select only right values in cases like AB → (C and D) where C is right for A but D isn't
    See alsoterritory overlaps (P3179)

    MotivationEdit

    The question arose here. On the example of geographic hierarchical properties like located in the administrative territorial entity (P131), there are cases when at one level of the hierarchy there are two correct values but only one of them are correct for referencing item from lower hierarchy level. The proposed property will help to make the right choice in the case of such switches. We could do the opposite and indicate for each of the values a list of items corresponding to it from the lower level but in case of Atlanta (Q23556) it will be thousands of streets, non-profit organizations, monuments, schools, cafes etc. So best way to resolve it at the items of monuments or cafes.

    I am sure that this can be useful not only for territorial properties like part of (P361). Сидик из ПТУ (talk) 12:40, 28 January 2020 (UTC)3333333333

    DiscussionEdit

    •   Support Since geographic relationships are not always one-to-one (given the examples above), located in the administrative territorial entity (P131) needs to be able to be qualified with a specific "parent" administrative territory. For example, after a natural disaster, I need to be able to search for all museums in a specific county. Without having a qualifier like "hierarchy switch", many museums will show up as being in the wrong county. And as Сидик из ПТУ points out, this qualification may also apply to other hierarchical/transitive properties. -- Clifflandis (talk) 14:02, 5 February 2020 (UTC)
    •   Support. --Mitte27 (talk) 06:41, 14 February 2020 (UTC)
    •   Support certainly make sense Ghuron (talk) 06:16, 15 February 2020 (UTC)

    Tobias1984 (talk) TomT0m (talk) Genewiki123 (talk) Emw (talk) 03:09, 9 September 2014 (UTC) —Ruud 16:15, 9 December 2014 (UTC) Emitraka (talk) 14:32, 14 October 2015 (UTC) Bovlb (talk) 19:10, 21 October 2015 (UTC) Peter F. Patel-Schneider (talk) 22:21, 23 October 2015 (UTC) ArthurPSmith (talk) 15:51, 5 November 2015 (UTC) --Daniel Mietchen (talk) 20:53, 3 January 2016 (UTC) --Harmonia Amanda (talk) 22:00, 27 February 2016 (UTC) --Lechatpito (talk) --Andrawaag (talk) 14:42, 13 April 2016 (UTC) --ChristianKl (talk) 16:22, 6 July 2016 (UTC) --Cmungall Cmungall (talk) 13:49, 8 July 2016 (UTC) Cord Wiljes (talk) 16:53, 28 September 2016 (UTC) DavRosen (talk) 23:07, 15 February 2017 (UTC) Vladimir Alexiev (talk) 07:01, 24 February 2017 (UTC) Pintoch (talk) 22:42, 5 March 2017 (UTC) Fuzheado (talk) 14:43, 15 May 2017 (UTC) YULdigitalpreservation (talk) 14:37, 14 June 2017 (UTC) PKM (talk) 00:24, 17 June 2017 (UTC) Fractaler (talk) 14:42, 17 June 2017 (UTC) Andreasmperu Diana de la Iglesia Jsamwrites (talk) Finn Årup Nielsen (fnielsen) (talk) 12:39, 24 August 2017 (UTC) Alessandro Piscopo (talk) 17:02, 4 September 2017 (UTC) Ptolusque (.-- .. -.- ..) 01:47, 14 September 2017 (UTC) Gamaliel (talk) --Horcrux (talk) 11:19, 12 November 2017 (UTC) MartinPoulter (talk) Bamyers99 (talk) 16:47, 18 March 2018 (UTC) Malore (talk) Wurstbruch (talk) 22:59, 4 April 2018 (UTC) Dcflyer (talk) 07:50, 9 September 2018 (UTC) Ettorerizza (talk) 11:00, 26 September 2018 (UTC) Ninokeys (talk) 00:05, 5 October 2018 (UTC) Buccalon (talk) 14:08, 10 October 2018 (UTC) Jneubert (talk) 06:02, 21 October 2018 (UTC) Yair rand (talk) 00:16, 24 October 2018 (UTC) Tris T7 (talk) ElanHR (talk) 22:05, 26 December 2018 (UTC) linuxo Gq86 Gabrielaltay Liamjamesperritt (talk) 08:44, 21 June 2019 (UTC) ZI Jony Ivanhercaz (Talk) 11:07, 15 July 2019 (UTC) Gaurav (talk) 22:39, 24 August 2019 (UTC) Meejies (talk) 04:38, 29 August 2019 (UTC) Iwan.Aucamp SilentSpike (talk) Tfrancart (talk) Luis.ramos.pst.ag Sylvain Leroux TiagoLubiana (talk) 15:12, 2 December 2019 (UTC) Albert Villanova del Moral (talk) 15:43, 6 February 2020 (UTC) Clifflandis (talk) 15:10, 18 February 2020 (UTC) --Tinker Bell 16:48, 23 March 2020 (UTC) SM5POR Mkbergman (talk) 19:17, 10 July 2020 (UTC) Toni 001 (talk) 11:03, 11 July 2020 (UTC) The-erinaceous-one (talk) 22:02, 31 August 2020 (UTC) Cdo256 (talk) 06:26, 8 September 2020 (UTC) Antoine2711 (talk) 17:22, 25 September 2020 (UTC) Rehman 07:15, 12 October 2020 (UTC) Susanna Giaccai (talk) 07:22, 22 October 2020 (UTC)

    Nomen ad hoc

      Notified participants of WikiProject Ontology

    •   Oppose given the discussion on Wikidata:Project chat and the alternatives explained there. Essentially this qualifier would encourage users to add incorrect statements to the "parent" item. --- Jura 09:39, 15 February 2020 (UTC)
      • This qualifier will not require changing existing statements specified in accordance with the property documentation. Сидик из ПТУ (talk) 06:50, 16 February 2020 (UTC)
      •   Support - It seems that User:Сидик из ПТУ offers this evolutionary change that will help to correctly display geo-chains in wiki-cards. The User:Jura1 solution will break geo-chains in the wiki-cards, therefore it is harmful and not necessary. Carn (talk) 14:10, 20 February 2020 (UTC)
    •   Support This will allow to model the situation en e.g. Georgia, USA as viewed as almost everyone else does it. See also my summary of the discussion in Project chat in Special:Diff/1116318285. --Dipsacus fullonum (talk) 06:58, 16 February 2020 (UTC)
    •   Oppose This propoal assumes that administrative divisions are always organised as a linear hierarchy. Many countries however know branching hierarchies where two or more administrative divisions are subordinated to the same division. In such cases, one can add multiple located in the administrative territorial entity (P131) claims because there are multiple most local admin territories. --Pasleim (talk) 12:30, 16 February 2020 (UTC)
      • So, there will be several (two) administrative divisions for Atlanta (Fulton and DeKalb). Georgia will still not be the most local for Atlanta, nor will Fulton for Patch Works Art & History Center (Q76461608). Сидик из ПТУ (talk) 13:43, 16 February 2020 (UTC)
        • You might want to re-read the discussion on project. BTW territory overlaps (P3179) was made for that. --- Jura 13:51, 17 February 2020 (UTC)
          • As I read Wikidata:Property proposal/territory overlapse that isn't true. P3179 was made to: (quote) representing overlapse between territorial entities arising from distinct classifications. Administrative vs religious is one (as with administrative subdivisions of countries vs dioceses), administrative vs political (as is the case with american special districts), geographical vs administrative (landforms vs countries or cities). (end quote) I note the emphasis on different classification types. In the case Georgia, USA municipality and country belongs to different levels of the same type of classification. The municipalities is considered to be in one or more counties, where the counties isn't considered to be in municipalities. In such cases this proposed hierarchy switch will be best to describe the situation. In other cases like the examples in P:P3179 that property is better. So we need both. --Dipsacus fullonum (talk) 15:52, 17 February 2020 (UTC)
      • This makes sense, if you relax the requirement/assumption that only the "most local" value should go in P131. But it may be tempting for people to delete the "redundant" P131 value if they don't realise why it's there. Ghouston (talk) 08:38, 17 February 2020 (UTC)
    •   Oppose Jura points out above that this qualifier will encourage people to add incorrect assertions. I would go further and say that it is only useful in the case when people have added incorrect assertions. While Atlanta certainly overlaps two counties, it is false to say that it lies either "physically within" or "under the administrative control of" either of them. If we want to be able to identify the containing county of some specific landmark within Atlanta, we can simply assert it directly (without requiring a qualifier), or find some intermediate region such as a neighbourhood. Bovlb (talk) 21:54, 18 February 2020 (UTC)
    Not that P30 matters, but the English label for P30 has just "continent", not "located in continent". --- Jura 11:20, 19 February 2020 (UTC)
    The burden of proof (Q1535975) on those who deny the hierarchy (municipality of Georgia (Q76514543)county of Georgia (Q13410428)Georgia (Q1428)). Atlanta seat of Fulton county (but also partly in DeKalb county, how can we say that Atlanta on the same level with counties after this? Are you going to claim that articles County (United States) (Most counties have subdivisions which may include townships, municipalities and unincorporated areasSome municipalities are in multiple counties) and Local government in the United States (Most states and territories have at least two tiers of local government: counties and municipalities) are wrong? Сидик из ПТУ (talk) 12:35, 19 February 2020 (UTC)
    Oh, you know — there are many labels and aliases of P131 in many languages have not in but true. And counties perfectly match with Wikidata usage instructions (P2559) of located in the administrative territorial entity (P131) in Atlanta case. Сидик из ПТУ (talk) 12:35, 19 February 2020 (UTC)
    I suppose we will keep disagreeing on that. --- Jura 17:31, 19 February 2020 (UTC)
    WikiData is not a separate project, the data from it is used in different language sections of Wikipedia, so you should evaluate your proposal to see if the templates created in the language sections will break. Maybe for you this is another abstract question, for me everything looks different. It seems to me that you "disagree" without a proper level of argumentation at a practical level. Carn (talk) 14:19, 20 February 2020 (UTC)
    The question is you aren't doing the opposite as you are intending: by adding a complex additional element, you just to make sure that it works for a single outside projects that may not have implemented things correctly. --- Jura 20:19, 3 March 2020 (UTC)
    The approach in which some cities of Georgia have in P131 county while others have a state should be attributed to incorrect ones in the first place.
      Support --AleUst (talk) 14:55, 19 February 2020 (UTC)
      Support, administrative territories are quite well represented as an ascending hierarchy, and this correction would make it work even better. Wikisaurus (talk) 16:33, 19 February 2020 (UTC)

    ──────────────────────────────────────────────────────────────────────────────────────────────────── The good point of this debate is the highlights a problem: While I'm sympathetic to the problems faced by ruwiki infobox designers, it mainly illustrates that Wikidata should try to provide a basic infobox and breadcrum navigation as otherwise we keep getting requests from wikis that make use of our data in a somewhat sub-optimal way and attempt to tweak the data to their usecase. We already did that in other fields and should to it for that too. --- Jura 13:37, 21 February 2020 (UTC)

    At first, Wikivoyage doesn't use Wikidata for breadcrumb navigation. Secondly, I see Example: Europe > Russia > Southern Russia > North Caucasus > Dagestan where Europe, Southern Russia and North Caucasus are not administrative territorial entity (Q56061) at all. And Russia is not only in Europe too so Europe > Russia > Siberia > Krasnoyarsk Krai > Krasnoyarsk (region) > Krasnoyarsk is simply wrong. Сидик из ПТУ (talk) 13:48, 21 February 2020 (UTC)
    I think we understood that earlier in the discussion (please re-read the comment above by DerFussi if you haven't done so), but it's a feature that should be supported directly through Wikidata statements. I think it's useful even for projects/users other than Wikivoyage. --- Jura 13:52, 21 February 2020 (UTC)
    OK. In this case, if we somehow build a hierarchy through Russia then we definitely need a switch in order to choose Asia for Krasnoyarsk and Europe for St. Petersburg. Сидик из ПТУ (talk) 13:56, 21 February 2020 (UTC)
    •   Support The best way now. - Kareyac (talk) 11:16, 21 February 2020 (UTC)
    • @Сидик из ПТУ, Clifflandis, Mitte27, Ghuron, Carn, Pasleim: @Bovlb, Kareyac, Jura1, Dipsacus fullonum: @DerFussi, RolandUnger, Ghouston: I have altered the English proposed name per a discussion above; please comment below if that changes your view on this proposal. ArthurPSmith (talk) 18:42, 21 February 2020 (UTC)
      • It was one or more of several values and I suggest leaving this wording just in case. For example, when two of the three values are true. Сидик из ПТУ (talk) 19:17, 21 February 2020 (UTC)
      • My objection was structural, and about the misuse of P131, so I'm afraid your fix doesn't help me. Thanks for trying. Cheers, Bovlb (talk) 16:34, 25 February 2020 (UTC)
    •   Comment I have another suggestion, which would be to use another P131 statement as a qualifier on the P131 statement, instead of defining a new property. Maybe it would be easier to use that trying to remember the name of the obscure property that changes the hierarchy, and it would still be distinguishable from a redundant P131. Ghouston (talk) 22:21, 21 February 2020 (UTC)
      • Yes, I also proposed to do so from the very beginning, however, this requires special documentation so that users understand in which cases such a qualifier is needed and in which it is unwanted. I believe that a special property allows users to better understand what function it performs. Сидик из ПТУ (talk) 08:58, 22 February 2020 (UTC)
    •   Comment how to we determine what the next level of the hierarchy is? Wouldn't it rather be "alternate hierarchy"? --- Jura 09:30, 22 February 2020 (UTC)
      • It must be one or more of the values that are specified in a similar property at the item to which we add the qualifier. Сидик из ПТУ (talk) 10:39, 22 February 2020 (UTC)
        • Yeah, so "alternate hierarchy" fits it better. --- Jura 10:41, 22 February 2020 (UTC)
          • Maybe I do not understand the subtleties of the wording in English but, otherwise, there are no differences from a typical case, county of Georgia (Q13410428) are always the next level of hierarchy for municipality of Georgia (Q76514543). The qualifier allows us to make a choice of several alternative values. Сидик из ПТУ (talk) 10:46, 22 February 2020 (UTC)
            • From the discussion, I get the impression that you assume a pyramidal organization of different government entities and likely an infobox that can't handle alternatives. --- Jura 10:52, 22 February 2020 (UTC)
              • Yes, proposed property is for resolve this. Сидик из ПТУ (talk) 11:45, 22 February 2020 (UTC)
                • Sure, but it's better to fix the infobox than to try to change the underlying data. --- Jura 17:10, 22 February 2020 (UTC)
                  • The infobox algorithm just relies on the fact that Wikidata will follow the rule "You only need to add the most local admin territory". The most local admin territories for Atlanta are Fulton and DeKalb and this is in line with the main point of view of most serious sources. Сидик из ПТУ (talk) 17:58, 22 February 2020 (UTC)
    •   Comment If we are going to say (for example) that Atlanta is in both Fulton and DeKalb counties then, yes, we need something like this. But I think that's just bad modeling and a patch to get around it. When geographical entities overlap like this, the city is no more in the county than the county is in the city. I believe that Atlanta, Fulton County, and DeKalb County are each in Georgia; that Atlanta overlaps with Fulton County and DeKalb County; and that any given point in Atlanta is either in Atlanta and in Fulton County, or in Atlanta and in De Kalb County. The fact that a county is somehow "higher-level" than a city does not change this. Five counties of New York State each coincide with boroughs of New York City: this is the one case I know of in the U.S. where counties are proper subsets of cities. Are we really going to say that New York City is in Kings, Queens, New York, Richmond, and Bronx counties rather than vice versa? - Jmabel (talk) 16:20, 22 February 2020 (UTC)
    Сидик из ПТУ and I were just discussing New York City over at Property talk:P131#Possible change of usage. Although the two situations aren't legally analogous, I believe they might be ontologically similar enough that a solution that applies to one ought to apply to the other. —Scs (talk) 16:56, 22 February 2020 (UTC)
    Yes, we read articles about borough of New York City (Q408804) yesterday[3][4][5], it emphasizes that they are unique to the United States and are parts of the NYC now. Сидик из ПТУ (talk) 17:58, 22 February 2020 (UTC)
    @Jmabel:, how would you write the location linearly, e.g., in the infobox for c:Category:Baltimore Block on Commons? The question is whether to put the city or county first, or come up with some other way of writing it. Ghouston (talk) 22:35, 22 February 2020 (UTC)
    @Ghouston: By tradition, in the U.S. (with the exception of New York City) we list city before county regardless of containment, but that's a matter of tradition, not data modeling. I think it might make sense to have a query know that as a rule for U.S. places (should be possible to enforce based on "instance of"), rather than to have to say in doesn't really mean in.
    By the way, New York is a mess in this respect. Pretty much any New Yorker would say that Morningside Heights is in Manhattan, not that it is in New York County, or that Park Slope is in Brooklyn, not that it is in Kings County. As for Richmond County / Borough of Richmond: almost everyone calls it "Staten Island"; after more than 300 years, the effort to give it an English rather than a Dutch name never really stuck. - Jmabel (talk) 23:44, 22 February 2020 (UTC)
    If the query “all cities of the county Fulton” doesn’t return Atlanta then this is a bad base and it doesn’t matter how the data modeling was. If Britannica says in then we follow this as most users who expect that for all the cities of Georgia, a generally accepted order is kept in line with the real situation. As for the local names of the places in New York, I can say the same thing about Moscow, where the districts got their names from the villages, and then these villages ended up in other districts. But it all suggests that New York boroughs are seen as part of the city as a priority and they are named on the English Wikipedia as Manhattan, Brooklyn, Queens, The Bronx and Staten Island. There are not separate articles about Kings or Richmond. Everything is clear here. Сидик из ПТУ (talk) 07:14, 23 February 2020 (UTC)
    There's a broader question here, which is: who or what is (or are) the primary user(s) of Wikidata? If it's people browsing our database, as if it were a stylized and highly-structured Wikipedia, then it makes sense to worry about what Britannica says, or what a reasonable New Yorker would say, and to try to have the presented data match that somehow. But if our data is primarily being used by computers running SPARQL queries, or by Wikipedia as it renders infoboxes, then we should favor a data model that fosters clean, consistent, general-purpose SPARQL queries and Lua templates and the like. —Scs (talk) 12:20, 23 February 2020 (UTC)
    Dozens of Wikipedia language sections and a number of other Wikimedia projects need a supported hierarchy for a property. Q18008533 is a Lua module and it is popular, this switch will be useful to it, but, of course, it is required to return the correct sequences like Atlanta→Fulton→Georgia. Сидик из ПТУ (talk) 08:50, 24 February 2020 (UTC)
    • I think the point is that you can't write a single SPARQL query; in the general case you have to write a little program, with some loops and if statements, that issues a number of SPARQL queries and makes decisions based on any next level in hierarchy qualifiers it finds. (To be perfectly clear, suppose the question is not, "Show me everything in DeKalb County (Q486398)", but rather, "Show me everything in County X".)
    This isn't necessarily a fatal flaw, but it does need to be acknowledged.
    Overlaps are obviously a mess. I suspect we can have either a data model that's closer to the "real world" but requires more-complicated algorithms to query, or a "refactored" model that's easy to query because it interposes some extra, artificial, constructed entities (like "portion of Atlanta within DeKalb county"), but not both. —Scs (talk) 12:08, 23 February 2020 (UTC)
    Using of "portion of Atlanta within DeKalb county" will make it difficult to work with queries such as "select all Atlanta bus stops". In any case, it’s better to work with real data than to add unobvious database tricks to the imperfection of the world. Alternatives to switch are similar to Procrustean bed (Q10991776). Сидик из ПТУ (talk) 08:50, 24 February 2020 (UTC)
    @Сидик из ПТУ: How does an interposed subentity of Atlanta make it harder to find all Atlanta bus stops? —Scs (talk) 13:06, 24 February 2020 (UTC)
    At least we need to order unobvious where in Atlanta-DeKalb or Atlanta-Fulton. And queries may be to select all bus stops in the capitals of each state or to select all Gerogia bus stops with their cities or select count of bus stops by city, etc. And what P131 is correct for it? If counties then we lose Atlanta in our hierarchy and can’t easily select this city along with other state capitals. If Atlanta then we lose any effect of this. A completely different conversation that such administrative territorial entity (Q56061) do not actually exist so this may lead to misinformation of the users. Сидик из ПТУ (talk) 13:25, 24 February 2020 (UTC)
    This proposed qualifier is another such trick. I think we'd just stick to the initially suggested solution (add both Atlanta and DeKalb county statements to the bus stop item, but the most local entities) queries remain simple. --- Jura 10:26, 24 February 2020 (UTC)
    This will make it impossible to build a hierarchy without a strong knowledge base wired into the algorithm and this will be a false statement that destroys the general logic. By the way, the property can be used without minus and queries like "select all bus stops in county" may contain the requirement to display the most local units for this stops (expected only cities). Maybe somebody can add to my query all organisations where next level of P131 contains only one county. Сидик из ПТУ (talk) 10:57, 24 February 2020 (UTC)
    Actually, using this qualifier assumes that the qualifier is used in a given level of the hierarchy, thus requiring users to write a program to identify it as Scs mentions. --- Jura 11:02, 24 February 2020 (UTC)
    Using P131 assumes that the most local admin territory for the bus stops of Atlanta is Atlanta, not counties. Сидик из ПТУ (talk) 11:08, 24 February 2020 (UTC)
    You mean, you assume that. --- Jura 11:08, 24 February 2020 (UTC)
    The reverse situation will complicate both the algorithms on Lua and the operation of SPARQL-queries when they need to work with the hierarchy. Сидик из ПТУ (talk) 11:27, 24 February 2020 (UTC)
    I guess it's debatable if "wdt:P131*" is more complicated than the program combined with the qualifier query you linked in some diff, but personally, I find more simpler. --- Jura 11:30, 24 February 2020 (UTC)
    Without following the rule of "most local admin territory" cheap hierarchy building will not be possible, however this feature is used in various Wikimedia projects very widely, it's much more relevant than the one-off SPARQL-queries for Georgia like was discussed here. The loss of hierarchy will entail the loss of many other opportunities while the qualifier, on the contrary, creates them. Сидик из ПТУ (talk) 11:45, 24 February 2020 (UTC)
    Here we identified that there are actually two "most local admin territories" to be considered (unless "part of Atlanta in DeKalb county" is created) and infoboxes can handle this. It is known that the ruwiki one doesn't do that and apparently ruwiki lacks the resources to keep it in shape .. so we keep getting these requests here. --- Jura 11:52, 24 February 2020 (UTC)
    There are two "most local admin territories" for Atlanta (Fulton & DeKalb), it matches to sources. There is one "most local admin territory" for Patch Works Art & History Center (Q76461608) (Atlanta). The machine cannot be taught to choose the "most local admin territory" from two or more values without detailed knowledge base. No one will learn the algorithm to select from the list first the city, then the county and finally the state since several thousand such tasks have accumulated over the history of mankind. We suggest improving the functionality, you suggest destroying it. Сидик из ПТУ (talk) 12:11, 24 February 2020 (UTC)
    And the creation of artificial concepts that do not exist in the real world, such as "part of Atlanta in DeKalb county" will make work with Atlanta more difficult. It's not valid administrative territorial entity (Q56061), work with similar items in contrast to the documented property will be less handy and, again, will require a solid knowledge base. Сидик из ПТУ (talk) 12:18, 24 February 2020 (UTC)
    • I don't think people are willing to dismiss transitivity so easily -- it's arguable that we do need it and should strive to preserve it. And North Yorkshire (Q23086) is no counterexample -- if anything it's proof that (a) real-world political subdivisions are confusing, irregular, and difficult, and (b) people have been representing them improperly in Wikidata for a while, meaning we really need some cleanup and a proper fix (whatever that may be). In particular, North Yorkshire is a ceremonial county of England (Q180673) and, therefore, not strictly an administrative subdivision. [See Wikipedia Subdivisions of England: "For non-administrative purposes, England is wholly divided into 48 counties, commonly known [...] as ceremonial counties".] But you probably can't use North Yorkshire (Q23086) as part of your primary P131 hierarchy -- it's guaranteed to fail. (Just look at the comment -- right in Q23086's description! -- directing you over to North Yorkshire (Q21241814), which actually is an administrative subdivision, and which does not encompass e.g. Redcar and Cleveland (Q1434448), meaning it'd be much easier to use Q21241814 as part of a proper, nonoverlapping hierarchy.)
    Can you say a little more about what you mean when you say "not allowing hierarchies to be done"? The argument for enforcing pure transitivity on P131 is that it makes P131 act like the mathematical operator subset (Q177646), meaning that simple wdt:P131* queries always yield proper results. In this sense saying that Patch Works is in Fulton County, or that Atlanta is in Georgia, is perfectly fine. I think your objection to these relations is that you can't list all cities in Fulton County by doing a simple wdt:P131 wd:Q486633 query, or something, but I'm really not sure.
    Have we asked the folks over at WikiProject Country subdivision for their advice on all this? I bet they've put some thought into how best to resolve these situations. [Footnote: I've now asked them.]—Scs (talk) 13:01, 1 March 2020 (UTC)
    Firstly, neither I nor Russian Wikipedia in general came up with the use of ceremonial county of England (Q180673) at located in the administrative territorial entity (P131). As I understand it, the British themselves began to fill out the data in this way. I am not opposed to clarifying this issue, although the ceremonial counties have changed the form of government over time and I fully admit that at the moment the phrase "Most ceremonial counties are, therefore, entities comprising local authority areas, as they were from 1889 to 1974" is correct. We can argue about the powers of the Queen of the United Kingdom, Governor General of Canada (Q390776) or Lord Lieutenant (Q914752) but if the existing hierarchies are in most cases useful then I do not see an error in such an interpretation where ceremonial county of England (Q180673) in located in the administrative territorial entity (P131).
    Secondly, I think that following the main sources we should consider Atlanta a city in Fulton County (and also in DeKalb County) and make the appropriate statements. I consider it will be a bad decision to be guided in the first place by the rule "is completely in" and state Georgia for Atlanta at P131 with counties for other cities. It will simply be a false statement that the municipality of Atlanta is on the same hierarchy level as the counties. Сидик из ПТУ (talk) 10:38, 2 March 2020 (UTC)
    Ah, okay, now I get it: You want P131 to mean "is an administrative subdivision of". That makes sense.
    Or, stated another way, P131 represents a direct child relationship, and the proposed new property simply represents a grandchild relationship, for use in cases where we can't properly describe the situation with two ordinary child relationships. (Indeed, we've got some similarly redundant tags for people. Normally we represent human grandchildren as a pair of child (P40) properties, and siblings as two people having the same parent(s), but if we don't have an entity for the parent, we can use type of kinship (P1039) along with grandchild (Q3603531), sibling (Q31184), etc.) —Scs (talk) 16:36, 2 March 2020 (UTC)
    P.S. When I said "you probably can't use Q23086 as part of your primary P131 hierarchy", I was not referring to you or the Russian Wikipedia; I meant "anybody". But the fact that "the British themselves began to fill out the data in this way" doesn't prove much, either -- as JMabel mentioned in another thread, we shouldn't automatically let popular folksonomies drive our more-precise taxonomic work here. 19:18, 2 March 2020 (UTC)
    And looking at the real situation, it seems that the warning in the description does not forbid the use of North Yorkshire (Q23086) in the P131 but something like different from (P1889). Сидик из ПТУ (talk) 15:16, 2 March 2020 (UTC)
    •   Comment Scs wrote: (quote) I think the point is that you can't write a single SPARQL query; in the general case you have to write a little program, with some loops and if statements, that issues a number of SPARQL queries and makes decisions based on any next level in hierarchy qualifiers it finds. (To be perfectly clear, suppose the question is not, "Show me everything in DeKalb County (Q486398)", but rather, "Show me everything in County X".) (end quote)
    That is not true. Here is single SPARQL query using the proposed query for a search for items in an arbitrary administrative unit:
    # SPARQL code to find items in an arbitrary administrative unit, called Q800000000,
    # using the proposed qualifier, called P8000
    SELECT ?item
    WHERE
    {
      VALUES ?searched_unit { wd:Q800000000 }
      {
        ?item wdt:P131* ?searched_unit .                 # located in the searched unit 
      }
      MINUS
      {
        ?item wdt:P131*/p:P131/pq:P8000 ?other_unit .    # unless next level in hierarchy is a unit
        ?other_unit wdt:P131/^wdt:P131 ?searched_unit .  # at same level in the hierarchy
        FILTER (?other_unit != ?searched_unit)           # and different from the sought unit
      }
    }
    
    Try it! --Dipsacus fullonum (talk) 15:47, 26 February 2020 (UTC)
    Thank you. I apologize for my naïveté about the potential power of complex SPARQL queries. —Scs (talk) 11:32, 27 February 2020 (UTC)
    • It's essentially two queries which works here because there are not too many items involved and P8000 doesn't exist. For testing, Sandbox-Item (P369) can be used.
    I'm curious to see the version for "all bus stops in Georgia by county". According to an addition on Property talk:P131 this would work for that as well. --- Jura 09:52, 29 February 2020 (UTC)
    @Jura1: Here is a version for all bus stops in Georgia by county as requested:
    # Find all busstops in Georgia by county
    SELECT DISTINCT ?busstop ?county
    WHERE
    {
      ?busstop wdt:P31 wd:Q953806 .       # is busstop
      ?busstop wdt:P131+ ?any_county .    # located in county
      ?any_county wdt:P31 wd:Q13410428 .  # which is a county of Georgia, USA
      OPTIONAL {
        ?busstop wdt:P131*/p:P131/pq:P8000 ?switched_county . # the true county if present
        ?switched_county wdt:P31 wd:Q13410428 .               # if it is a county of Georgia, USA
      } 
      BIND(COALESCE(?switched_county, ?any_county) AS ?county)
    }
    
    Try it! --Dipsacus fullonum (talk) 12:17, 29 February 2020 (UTC)
    • Does it assume that the qualifier would be placed on a known layer and the layer is always in the same place of the matrix?
    Would this work if the county was a French department and the French municipality had a switch to the relevant department?--- Jura 09:56, 1 March 2020 (UTC)
    Answer to first question: No. Answer to second question: As I understand English Wikipedia a French municipality (commune) is in only one department. But even if that isn't the case, then the next levels in the French administrative hierarchy are cantons and arrondissements, so a commune should never have the proposed qualifier with a value of a department. Please read the description the proposal ("the value at the next hierarchy level"). But anyway, even with a double incorrect use of the qualifier, the query could be changed to give busstops in France by department, and work. --Dipsacus fullonum (talk) 12:09, 1 March 2020 (UTC)
    I don't think the problem at Wikidata_talk:WikiProject_France/Communes#Communes_multi-départementales is solved. --- Jura 13:02, 1 March 2020 (UTC)
    I don't understand French, but as I understand the point using machine translation of the discussion, the French communes is always in exactly one department, but which department have changed over time. If that is correct, then this proposed qualifer will not be usable for french communes. Instead the values for P131 somewhere in the property chain should use time qualifers as start time (P580) and end time (P582). If you want help with queries with time qualifiers, please ask in Wikidata:Request a query. --Dipsacus fullonum (talk) 14:17, 1 March 2020 (UTC)
    If I recall correctly, there were several problems: one is that they changed over time (not important here), another that that some users include intermediate administrative layers that strech across several departments. It's a similar problem as the Atlanta one, at least if Atlanta had boroughs. --- Jura 20:19, 3 March 2020 (UTC)
    Until 2015, France had two parallel hierarchies of administrative-territorial units. One of them consisted only of cantons, and the other was and remains perfectly transitive. To build a second hierarchy according to it, it is enough to simply indicate arrondissement of France (Q194203). Сидик из ПТУ (talk) 10:42, 4 March 2020 (UTC)
    •   Support - there aren't too many cases that it could be used, however will be useful in some circumstances. --IWI (talk) 00:12, 24 August 2020 (UTC)

    Fails compliance withEdit

       Under discussion
    Descriptionfails compliance of the test defined in the associated item
    Data typeItem
    Example 1Hackers (Q13908) → "fails compliance with" → Bechdel test (Q4165246)
    Example 2instant-runoff voting (Q1491219) → "fails compliance with" → monotonicity criterion (Q6902035)
    Example 3Copeland's method (Q5168347) → "fails compliance with" → independence of irrelevant alternatives (Q3150644)

    MotivationEdit

    We need the opposite of complies with (P5009) to state when an item doesn't comply with the criterion associated with an item. For example:

    Could someone create a "fails compliance with" property? -- RobLa (talk) 02:49, 31 January 2020 (UTC)

    DiscussionEdit

    Summary of Wikidata:Project_chat/Archie/2020/01 conversation: this is what was discussed over at Wikidata:Project chat/Archive/2020/01 as part of the "Reasonably quick way to resolve 'non-compliance property' issue?" topic back in January/February. User:Jura1 suggested modeling this after test taken (P5021) and test score (P5022), allowing us to specify other options besides "complies", "doesn't comply". User:Ghouston suggested instead that we can add qualifiers to this new property if we need to move beyond binary compliance/non-compliance. User:Ls1g suggested a change to the data model to allow statements which negate any existing property, and links to this paper: "Negative Statements Considered Useful" - Hiba Arnaout, Simon Razniewski, and Gerhard Weikum.

    • Comment - Please edit the summary above if you believe there is a problem with it. I'd still prefer taking User:Ghouston's approach as I understand it, which would mean creating a "Fails compliance with" property. -- RobLa (talk) 05:21, 1 April 2020 (UTC)


    • @Jura1:, can you give details of how you think it should be done? You want to replace complies with (P5009) with a new property, such that there's only a single property for defining compliance? Then the statement itself would be meaningless without interpreting the qualifiers, which would make it harder to write queries. Ghouston (talk) 09:56, 3 February 2020 (UTC)
      • I think the explanation on project chat is fairly clear. Please comment there if you think it needs more input. --- Jura 09:58, 3 February 2020 (UTC)
      • @Ghouston:, thank you bringing the conversation to this proposal page. I agree with you that queries seem a lot easier with the addition of "fails compliance with" than queries involving a new regime modeled after test taken (P5021) and test score (P5022). This page seems like a better place to discuss alternatives to "fails compliance with" than the omnibus project chat page. -- RobLa (talk) 18:08, 3 February 2020 (UTC)
    • @Jura1: I don't think it's correct to say that compliance is not binary. A voting system either complies with a criterion or it doesn't; there is no in-between. The reason that table has cells other than Yes or No is because it combines closely-related voting systems into the same row, and closely-related criteria into the same column. In other words, some of the rows in that table are actually classes of voting systems rather than instances of voting systems. Omegatron (talk) 18:56, 9 February 2020 (UTC)
    •   Oppose. There should be a better data model for both this and complies with (P5009) in such cases. Jura1's suggestion looks workable. --Yair rand (talk) 21:47, 5 February 2020 (UTC)
    • Is there any precedent for a statement that's meaningless without interpreting the qualifiers? I can't think of one, but I don't know them all. It would be like X <compliance> Y. Ghouston (talk) 22:21, 5 February 2020 (UTC)
      @Ghouston: disjoint union of (P2738) only allows list values as qualifiers (Q23766486) as a value. --Yair rand (talk) 22:48, 5 February 2020 (UTC)
      • I don't think it's meaningless. It's like the "test taken" mentioned on Project Chat or "significant event". We know that's a valid criterion/test/event for the item, we just don't have full details. The approach seems more suitable for non-binary content like the voting systems description that is planned.
        Also, I don't get why Bechtel test is mentioned. It isn't even used with the other property. --- Jura 23:03, 5 February 2020 (UTC)

    civil classEdit

       Under discussion
    Descriptioncivil position (class) in the Russian Empire, according to the Table of Ranks
    RepresentsActive State Councillor (Q2623484)
    Data typeItem
    Domainчеловек
    Allowed valuescivil rank of the Russian Empire (Q28745974)
    Example 1Daniil Mordovtsev (Q1970722)Active State Councillor (Q2623484)
    Example 2Alexander Gorchakov (Q327020)Chancellor (Q837698)
    Example 3Aleksander Griboyedov (Q15001)State Councillor (Q677455)
    SourceTable of Ranks (Q929093)
    Planned useдобавлю свойство для 100 объектов

    MotivationEdit

    Одно из обычных свойств, наряду с имеющимися military rank (P410) или special rank (P5012). — Redboston (talk) 23:25, 3 February 2020 (UTC)

    DiscussionEdit

    •   Support. An important property for the history.--Arbnos (talk) 14:17, 8 February 2020 (UTC)
    •   Comment. As far as I remember special rank (P5012) was supposed to be used for that purpose, so new property would duplicate existing one. --EugeneZelenko (talk) 14:54, 11 February 2020 (UTC)
      • Исходя из обсуждения того свойства это не следует. Напротив, для свойства special rank (P5012) указан соответствующий элемент Military ranks, special ranks and class rates in Russia (Q4431086). А на странице элемента в описании указано: "звание, присваиваемое сотрудникам, состоящим на службе в правоохранительных органах". Элемент связан со статьёй в википедии w:ru:Специальное звание. Таким образом, это разные свойства. И даже если бы изначально свойство special rank (P5012) предполагало возможность проставления в качестве значения гражданских чинов из Табеля о рангах, то выделение из него нового (предлагаемого) свойства будет иметь положительный эффект в смысле уточнения и систематизации информации по персонам. В качестве дополнительной меры, которая предотвратила бы дублирование, можно прописать соответствующие ограничения для старого и нового свойства.Redboston (talk) 09:29, 14 February 2020 (UTC)

    block creatorsEdit

       Under discussion
    Descriptionnumber of block creators in a blockchain network
    Representsitem
    Data typeQuantity
    Domaincryptocurrency (Q13479982)
    Example 1Tezos (Q55290870) → 430 https://tzstats.com/cycle/204 (roll owners)
    Example 2EOS (Q47494147) → 100 https://eosauthority.com/producers_rank (block producers)
    Example 3MISSING
    See also

    MotivationEdit

    This enables us to track block creators in a blockchain over time which is very useful to judge how decentralized the blockchain is at this point in time.--So9q (talk) 20:42, 22 February 2020 (UTC)

    DiscussionEdit

      Comment If it's a count, then it's not an external identifier. Quantity is what you want, I think. ArthurPSmith (talk) 20:01, 24 February 2020 (UTC)
    Ah, it was somebody else editing your proposal; I undid their change. ArthurPSmith (talk) 20:05, 24 February 2020 (UTC)
    •   Comment Could you include "blockchain" in the description or label? --- Jura 10:06, 25 February 2020 (UTC)
    • Done.--So9q (talk) 11:05, 26 February 2020 (UTC)

    targeted block timeEdit

    MotivationEdit

    It is useful to compare the speed of blockchains by comparing the time to create a block.--So9q (talk) 21:16, 22 February 2020 (UTC)

    DiscussionEdit

    •   Comment I change the datatype. 轻语者 (talk) 09:48, 23 February 2020 (UTC)
      • I changed it back. Quantity is correct. ArthurPSmith (talk) 20:03, 24 February 2020 (UTC)
    •   Support I believe the datetype should be "Quantity" please add the unit, seconds or milliseconds Germartin1 (talk) 17:16, 24 February 2020 (UTC)
    •   Comment Could you include "blockchain" in the description or label? --- Jura 10:26, 25 February 2020 (UTC)
    • Done.--So9q (talk) 21:11, 29 February 2020 (UTC)
    •   Support Would be fairly neat to be able to generate a graph of these values to compare blockchains. --SixTwoEight (talk) 21:06, 3 April 2020 (UTC)
    •   Comment Needs a valid subject item. --SilentSpike (talk) 14:29, 4 April 2020 (UTC)

    staking percentageEdit

       Under discussion
    Descriptionpercentage of the funds that participates actively in a proof-of-stake network
    Representsitem
    Data typeQuantity
    DomainQ13479982
    Allowed unitsQ11229
    Example 1Tezos (Q55290870) → 79 https://tzstats.com/cycle/204
    Example 2COSMOS (no QID yet) → 72 https://www.stakingrewards.com/asset/cosmos
    Example 3MISSING
    See also

    MotivationEdit

    This is a useful measure to judge the health and participation in a PoS-network.--So9q (talk) 21:24, 22 February 2020 (UTC)

    DiscussionEdit

      Comment are there other examples? also you listed it as a percentage but called it a ratio which are different things. BrokenSegue (talk) 21:20, 25 February 2020 (UTC)

    Yes, added one more. Changed to percentage in the title.--So9q (talk) 11:53, 26 February 2020 (UTC)
    •   Support Germartin1 (talk) 18:51, 20 June 2020 (UTC)
    • No at least until 3 examples are provided. BrokenSegue (talk) 23:43, 7 September 2020 (UTC)

    staking lock-up periodEdit

       Under discussion
    Descriptionlock-up period for delegated (staked) funds in a blockchain network
    Representsitem
    Data typeQuantity
    DomainQ13479982
    Allowed unitsdays
    Example 1COSMOS → 21 days https://www.stakingrewards.com/asset/cosmos
    Example 2Tezos (Q55290870) → 0 days (this is what is meant by Liquid PoS)
    Example 3MISSING

    MotivationEdit

    This is an important property in a PoS blockchain because it is the basis for the function of the whole system. Without a lockup period PoS would probably not work. If i understood it correctly lock-up reduces the ability to "hit and run" that causing large fluctuations in staking amounts in a short time (which makes the network vulnerable to attacks, because staking is what defines voting power of the validator) and promotes capital staking that is more long-term. Tezos is different because it implements a delay in payouts of staking rewards instead of locking the capital (like COSMOS does to my knowledge). This means you can move your money but you still wont get your staking rewards before after ~37 days from choosing a delegate.--So9q (talk) 12:15, 26 February 2020 (UTC)

    DiscussionEdit

    •   Oppose @So9q: if COSMOS meets notability rules, please create an item for it and add a third example. If not, please add 2 more. Also, how is it important? Please explain what this represents --DannyS712 (talk) 19:12, 19 March 2020 (UTC)

    validator bond lock-up periodEdit

       Under discussion
    Descriptionthe time period for lock-up of validator safety deposits on a blockchain
    Representsitem
    Data typeQuantity
    DomainQ13479982
    Allowed unitsdays
    Example 1Tezos (Q55290870) → 5 cycles of ~3 days = 15 days
    Example 2COSMOS (no QID yet) → 21 days https://www.stakingrewards.com/asset/cosmos
    Example 3MISSING

    MotivationEdit

    Freezing of safety deposits is an important feature in any PoS network.--So9q (talk) 15:11, 26 February 2020 (UTC)

    DiscussionEdit

    •   Oppose @So9q: if COSMOS meets notability rules, please create an item for it and add a third example. If not, please add 2 more. --DannyS712 (talk) 19:11, 19 March 2020 (UTC)

    transactions per monthEdit

       Under discussion
    Descriptiontransactions during 30 days
    Representsitem
    Data typeQuantity
    Domainpayment systems
    Example 1tezos → 357000
    Example 2ethereum → 21066086 (calculated from https://etherscan.io/chart/tx?output=csv)
    Example 3bitcoin → 9386999 (calculated from https://api.blockchain.info/charts/n-transactions?timespan=30days&format=csv)

    MotivationEdit

    This is a very useful measure that says something about adoption and possible congestion.--So9q (talk) 08:08, 29 February 2020 (UTC)

    DiscussionEdit

    •   Oppose @So9q: please add the other examples --DannyS712 (talk) 19:09, 19 March 2020 (UTC)
    • Done--So9q (talk) 10:14, 20 March 2020 (UTC)

    minimum amount to run a validatorEdit

       Under discussion
    Descriptionminimum amount of a cryptocurrency required to run a validator on a blockchain
    Representsitem
    Data typeQuantity
    Domaincryptocurrency (Q13479982)
    Example 1Tezos (Q55290870) → 1 roll (Q86535507) (=8,000 tezos)
    Example 2Cardano (Q47273538) → no value (no limit imposed)
    Example 3MISSING

    MotivationEdit

    This is a useful metric because it is used by some projects to control the number of validators on a network and to regulate the minimum risk those are willing to take to be allowed to participate in validation of new blocks. If they misbehave they might get slashed (that is they loose some of the bond they put forward to be able to participate)--So9q (talk) 21:04, 29 February 2020 (UTC)

    DiscussionEdit

    •   Oppose don't really see the value of this, sorry --DannyS712 (talk) 19:05, 19 March 2020 (UTC)

    minimum amount required to participate in votingEdit

       Under discussion
    Descriptionminimum amount required to participate in voting on a blockchain with on-chain governance
    Representsitem
    Data typeQuantity
    Domaincryptocurrency (Q13479982)
    Example 1Tezos (Q55290870) → 1 roll (Q86535507) (=8,000 tezos)
    Example 2waves → 1000 WAVES https://docs.wavesplatform.com/en/waves-node/
    Example 3decred → 1 ticket

    MotivationEdit

    This is an important property of a PoS cryptocurrency because it regulates how much investing is necessary to have an influence on voting. This is important because for different PoS systems different amounts of capital is needed for an attacker to take over the network. Such a malicious take-over is believed to have happened recently with Steem, see [6] [7]. In this case the capital was actually already in place in 3 exchanges staked by thousands of users. The colluding of these 3 validators enabled the take-over by a single actor.--So9q (talk) 15:21, 1 March 2020 (UTC)

    DiscussionEdit

    •   Oppose @So9q: please fill in the other two examples, and explain what this means --DannyS712 (talk) 19:06, 19 March 2020 (UTC)

    article in Enciclopedia LibreEdit

       Under discussion
    Descriptionarticle in Enciclopedia Libre Universal en Español
    RepresentsEnciclopedia Universal en Español (Q1340088)
    Data typeExternal identifier
    Allowed values\S+
    Example 1Tenochtitlan (Q13695)México-Tenochtitlán
    Example 2Mexico City (Q1489)Ciudad_de_México_(México)
    Example 3Pocahontas (Q255430)Pocahontas
    Sourcehttp://enciclopedia.us.es/index.php/Especial:Todas
    External linksUse in sister projects: [ar][de][en][es][fr][he][it][ja][ko][nl][pl][pt][ru][sv][vi][zh][commons][species][wd].
    Planned usePopulating interwikis on many other wikis that doesn't have real interwikis on Wikidata
    Number of IDs in source~65000
    Expected completenessalways incomplete (Q21873886)
    Formatter URLhttp://enciclopedia.us.es/index.php/$1
    Robot and gadget jobscheck for HTTP 404 errors

    MotivaciónEdit

    Link many libre wikis that don't have any connection with Wikidata. Enciclopedia Libre was the first fork of Spanish Wikipedia. --Tinker Bell 20:03, 5 March 2020 (UTC)

    DiscussionEdit

    Tinker Bell, Rapunzel

    1. ¿Existe alguna desventaja o inconveniente o debilidad si la Enciclopedia Libre queda finalmente conectada con Wikidata? Sin conocer mucho el sistema, no se me ocurren desventajas.
    2. En caso de que no hubieran desventajas, ¿para qué se hace esta propuesta?, ¿por qué no se procede directamente?

    Saludos. Theardyear (talk) 00:27, 6 March 2020 (UTC)

    • @Theardyear: yo soy Rapunzel en EL. No, no habría ningún inconveniente al crear una propiedad para EL, sino al contrario, muchas ventajas: EL podría usar los datos de Wikidata de muchas formas; y también todos los proyectos Wikimedia podrán enlazar sistemáticamente a EL. Las reglas de Wikidata exigen que las propiedades sean propuestas para que cualquiera opine a favor o en contra, al menos durante una semana. Si nadie se posiciona en contra, la propiedad puede ser creada. Si tienes alguna duda, puedo explicaros mejor. --Tinker Bell 02:49, 6 March 2020 (UTC)
    • I have no opinion against this specific website, but I have a concern that this will open the floodgate of creating properties of countless Wikipedia-like websites (see Wikidata:Project_chat/Archive/2020/02#Is_Wikidata's_purpose_to_provide_links_to_every_(open)_wiki?).--GZWDer (talk) 06:28, 6 March 2020 (UTC)
    ¡Muchas gracias por tus respuestas! Muy amable, Tinker Bell. Saludos.Theardyear (talk) 11:53, 6 March 2020 (UTC)

    Unicode character (item)Edit

       Under discussion
    DescriptionUnicode character representing the item
    Data typeItem
    Domaininstance of (P31)subclass of (P279)* → letter (Q9788)
    Example 1A (Q9659) → See Q9659#P487, each value will be a new item
    Example 2B (Q9705) → See Q9705#P487, each value will be a new item
    Example 3C (Q9820) → See Q9820#P487, each value will be a new item
    Planned usenew items will be created for current values of Unicode character (P487) on instance of (P31) of letter (Q9788). The current values of Unicode character (P487) and Unicode hex codepoint (P4213) will be moved to these new items.
    See alsocode (P3295), Unicode character (P487) and Unicode hex codepoint (P4213)

    MotivationEdit

    Currently Wikidata does not differ abstract symbols A (Q9659) and specific characters representing the symbols. So it may be meaningful to create new items for these Unicode characters. Unicode character (P487) and Unicode hex codepoint (P4213) will be moved to these new items and then a single value constraint will be set.

    Note this does not affect any item about single characters like (Q3595028).GZWDer (talk) 22:02, 11 March 2020 (UTC)

    DiscussionEdit

    •   Comment How will this be different from Unicode character (P487)? And how come the name of the property is "Unicode character (item)" - why is there "(item)" in it? Iwan.Aucamp (talk) 16:37, 12 March 2020 (UTC)
      •   Oppose I get it now. I don't think this makes that much sense. For one the name does not make sense, if this were to be done you should make it rather "represented by character set code" - so it could potentially be more broad so it can cover Morse code (Q79897) and Unicode (Q8819) - but I think you first have to try and get some consensus on the data model here. Iwan.Aucamp (talk) 16:43, 12 March 2020 (UTC)
      • The disambiguator is needed as we can't have two identical labels for properties. --- Jura 21:30, 12 March 2020 (UTC)
    •   Comment Do we have any items for individual unicode codepoints right now? I don't see that there's a real structural need for an item for each one, but some of them may be notable in themselves. On the other hand, for those notable ones (none of the "A's" count I think) what would point to them with a property like this? ArthurPSmith (talk) 17:26, 12 March 2020 (UTC)
    •   Comment @ArthurPSmith: See Wikidata:Requests for permissions/Bot/GZWDer (flood) 3. In most cases, I do not want to reuse items like 𐓃 (Q66360724) for unicode character, as the character does not correspond to single Unicode character (it correspond to two, U+104C3 and U+104EB). This property will not have single value and unique value constraint, while (after migration) Unicode character (P487) and Unicode hex codepoint (P4213) will. "structural need for an item for each one": Each specific character itself has various properties (Unicode character property (Q1853267)) that can not be expressed without dedicated item (example).--GZWDer (talk) 17:44, 12 March 2020 (UTC)
    •   Comment @Iwan.Aucamp: This is really not a new idea and there's some discussion. I am only going to work on this currently (after a break of 18 months) as Unicode 13.0 is released recently.--GZWDer (talk) 17:51, 12 March 2020 (UTC)
      •   Comment @GZWDer: I cleaned up the proposal a bit. I still think this should be more generic though, at the very least I would like to see some actual real example items? Presumably the subject items would be instance of (P31) of Unicode character (Q29654788) which is subclass of (P279) of character (Q32483)? Could we not call this property "codepoint (item)" rather? (see Code point and also maybe code (P3295)) then it is a bit broader than just Unicode (Q8819)? If so I would change to support, I get the need. Iwan.Aucamp (talk) 18:28, 12 March 2020 (UTC)
      •   Comment @GZWDer: "Character" is such an overloaded term and the existing labels lead to confusion. Just explaining that a Unicode Character is not *just* a latin alphabetical character is hard! Please try to disambiguate the meaning upfront, something along the lines of Unicode Code Point (item), Unicode Abstract Character (item), and Unicode Character Encoding (external-identifier | string). -indo (talk) 02:34, 5 November 2020 (UTC)
        • @Iwan.Aucamp, Indolering: In this proposal, it means "abstract characters encoded by the Unicode Standard".--GZWDer (talk) 05:05, 5 November 2020 (UTC)
        • @Iwan.Aucamp: What does that mean? Is there a list of abstract characters somewhere? I'm not being facetious, I'm learning Unicode and this is driving me crazy! Here are all of the potential definitions I could find:
          • Unicode Glossary definition for Abstract Character: "A unit of information used for the organization, control, or representation of textual data. (See definition D7 in Section 3.4, Characters and Encoding.)"
          • Definition 7 in Section 3.4 "A unit of information used for the organization, control, or representation of textual data." followed by a list of vague bullet points, including the following:
            • "The abstract characters encoded by the Unicode Standard are known as Unicode abstract characters."
            • "Abstract characters not directly encoded by the Unicode Standard can often be represented by the use of combining character sequences."
          • The example in Chapter 2 Section 4 figure 2.5 shows how 3 different combinations of code points that all map to a single "abstract character", which (at least in this instance) appears to be a single common grapheme.
            • But that can't be right, because of this bullet point in Section 3.4 definition 7, "An abstract character does not necessarily correspond to what a user thinks of as a “character” and should not be confused with a grapheme."
          • This Character Encoding Model technical note mentions something close to what you are looking for, an Abstract Character Repertoire, "defined as a set of abstract characters to be encoded, normally a familiar alphabet or symbol set. The word abstract just means that these object are defined by convention."
          • But you don't want something that is defined by convention, you want the encoded abstract characters, which sound like a Coded Character Set, "defined to be a mapping from a set of abstract characters to the set of non-negative integers. ... The Unicode concept of the Unicode scalar value (cf. D28, in chapter 3 of the Unicode Standard) is explicitly this code point, used for mapping of the Unicode repertoire."
          • But that's not it either, as a Unicode Scalar Value is just, "Any Unicode code point except high-surrogate and low-surrogate code points. In other words, the ranges of integers 0 to D7FF16 and E00016 to 10FFFF16 inclusive."
        • Please correct me if I am wrong, but I don't think there is a set of "encoded abstract characters", there are just code points (the Universal Coded Character Set) and transformation rules (Universal Transformation Format) which can be used to map between code points that one might consider equivalent. If that's the case, then you shouldn't have a Unicode Abstract Character item at all and use Unicode Code Point terminology
    •   Comment Some symbols may also have multiple characters, like $ (Q11110).--GZWDer (talk) 18:31, 12 March 2020 (UTC)
      •   Comment @GZWDer: If we are trying to duplicate unicode maybe the lexeme namespace is better for this? It seems like in many of these cases you have a character with several different forms (uppercase vs lowercase) which is captured for example in Lexeme:L20817 (though they probably should not be all under "English" language). ArthurPSmith (talk) 18:56, 12 March 2020 (UTC)
        •   Comment @ArthurPSmith: a Unicode character is not a lexeme as it only correspond to a specific writing system, not a specific language. For example, the letter "a" is used in more than 100 languages, but have only one codepoint (if we restrict it to normal small case letter). In a letter point new lexemes about letters actually used in a specific language may be created (e.g. A and a are same letter and will have one lexeme), which is out of scope of the current task.--GZWDer (talk) 19:01, 12 March 2020 (UTC)
          • It's possible to have languages such as "mul". Lexemes have the advantage that they don't require multiple labels nor description. --- Jura 21:30, 12 March 2020 (UTC)
            Sample at (L61046) --- Jura 09:53, 14 March 2020 (UTC)
    •   Comment I could never really figure out the purpose of Unicode character (P487). It's being used in at least four or five different ways. The above would fix that and it could become an external-id property. --- Jura 21:30, 12 March 2020 (UTC)
    •   Strong support I never understood why Unicode characters were mixed with the glyphs and concepts they represented. --Tinker Bell 06:16, 15 March 2020 (UTC)
      • @Tinker Bell: It's a little 'meta' I think, but I feel like I don't understand what is the actual subject of an item that is "about" a Unicode character. GZWDer's proposal is, I think, only to use this property where a current item has more than one Unicode character value. So for example for Chinese characters, there is only 1 Unicode character, so the item and the Unicode character are equivalent. Does that mean the "concept" of that character and the Unicode character are the same, or distinct? For the letter 'A' example, Unicode differentiates upper- and lower-case, and also those other special conditions that are sort of the letter 'A' in other contexts. So in each case where a new item would be created, that item would be "about" the conceptual context of the use of that letter, not specifically or exclusively about it as a Unicode character. Right? Or is that not the point here? ArthurPSmith (talk) 18:37, 16 March 2020 (UTC)
        • It is meaningless to split items about character and glyph of Chinese characters, as Unihan database (using Unicode character as primary key) is about the glyphs. Usually different values (contexts) may be differed by object has role (P3831).--GZWDer (talk) 18:41, 16 March 2020 (UTC)
    •   Question can we change this to lexeme datatype per suggestion above? --- Jura 02:06, 28 March 2020 (UTC)
      • I don't think so - a lexeme may still cover multiple character or sequences of characters. For example ? have seven characters; but they should be in one (translingual) lexeme unless thay are semantically different.--GZWDer (talk) 09:13, 29 March 2020 (UTC)
        • Well, the idea is to use lexemes like (L61046) mentioned above. They would exactly be that. --- Jura 09:15, 29 March 2020 (UTC)
          • In addition, lexemes can not handle characters not in Unicode normalized form, like 著 (U+FA5F) (Q55726748) and 著 (U+2F99F) (Q55738328). I don't think we should have lexemes for them as they have no independent meaning.--GZWDer (talk) 09:22, 29 March 2020 (UTC)
            • It's possible that initially not all can be included. The namespace is still under development and eventually a way can be found. We didn't use items either when no lexemes were available. As each character has a definition, this can be included as S1. The problem with using items is that they require needless repetition of labels and descriptions. Lexemes have all that already included. --- Jura 09:28, 29 March 2020 (UTC)
              • However still some lexemes for symbols may cover multiple characters such as X (L19342). I don't see the point for creating additional lexemes for individual characters with no additional meaning.--GZWDer (talk) 09:43, 29 March 2020 (UTC)
                • I don't think existing entities in some languages should be replaced. They can use the proposed property to point to entities like (L61046) as well. I don't think the question whether or not to create these is much different from the question of creating them as items. If you don't see the point of one, it's unclear why you would want to create the others. Given the 5 or so ways Unicode character (P487) is used, people clearly have problems with the current structure and the more formal approach of the L-namespace could help. --- Jura 09:52, 29 March 2020 (UTC)
                  • An item may easily tie to an specific Abstract Character, while a lexeme is a unit of lexical meaning, comprising a set of Abstract Characters with same semantic meaning. I don't think we should have lexemes for characters with no independent semantic meaning. For CJKV characters, I do not favor creating translingual lexemes for them - English Wiktionary deprecated translingual definitions long ago. --GZWDer (talk) 10:35, 29 March 2020 (UTC)
                    • I think you are mixing "lexeme" and Lexeme: --- Jura 10:53, 29 March 2020 (UTC)
                      • Lexemes should be created for symbols like X (L19342), and if we also create lexemes for individual characters, we will 1. unnecessarily duplicate the definitions and 2. make users confused.--GZWDer (talk) 11:17, 29 March 2020 (UTC)

    ────────────────────────────────────────────────────────────────────────────────────────────────────

    • Can you explain what you think would be duplicated? How users could be confused? (L291359) explains clearly what it's about. For (Q87524936) users would have to find the right language to read the alias to understand what it's about. Seems much more confusing to me. --- Jura 04:43, 31 March 2020 (UTC)

    I have following addition reasons:

    1. You can not add sitelinks to lexemes, so items like Face with Tears of Joy (Q33836537) and (Q3595028) will exist.
    2. Some characters have Unicode aliases (See [8] p924). aliases can not be added to lexemes either.
    3. We will anyway have lexemes for symbols like ( ) - this is a matching pair, and individual characters ( and ) - as a symbol, ( corresponding to multiple codepoints. Users may confuse the symbol with individual Unicode characters if both have lexeme.
    4. Not every Unicode character has meaning, and Unicode names are only names, which does not always tell the meaning of character (like 𗊓 (Q87589786)), and sometimes even unrelated to the meaning. They only exist as aliases, not as definitions.

    --GZWDer (talk) 19:19, 31 March 2020 (UTC)

    • I think it should be possible to solve these too. BTW, I'm not sure if Face with Tears of Joy (Q33836537) should actually have been merged with Q87581513, at least not in the logic you presented above. --- Jura 14:46, 4 April 2020 (UTC)
    Each item is about an "Abstract Character" which may be encoded in multiple codesets (including Unicode). For example, "A" is a Unicode character which is (equals to) "Abstract Character" encoded in Unicode, and the same "Abstract Character" may also be encoded elsewhere. most emojis are also "Abstract Characters", some are encoded in Unicode, some are not. There will be only one item for each "Abstract Character" wherever it is encoded. I think this property should be limited to "Abstract Character" encoded in Unicode (as unencoded "Abstract Characters" are potentially infinite - this is why we have private use area (Q11152836).)--GZWDer (talk) 20:53, 5 April 2020 (UTC)
    •   Support Ok, I think I get the point here, yes let's do this. ArthurPSmith (talk) 19:53, 1 April 2020 (UTC)
    •   Comment There is just too much redundancy in the suggested datatype: compare item at [9] (~900 triples) and lexeme at [10] (~20 triples) --- Jura 14:46, 4 April 2020 (UTC)
      • I don't think this is how we should concern, given the number of Unicode character is limited.--GZWDer (talk) 20:43, 5 April 2020 (UTC)
        • It's a massive redundancy due to a problem in the modeling. Besides, Query Server has problems dealing with them. Items become difficulte to edit when they have a larger number of triples. --- Jura 15:20, 7 April 2020 (UTC)
    •   Strong support per Tinker Bell (talkcontribslogs). Also there should probably be an inverse statement. 1234qwer1234qwer4 (talk) 15:03, 7 April 2020 (UTC)
    • An alternative proposal now at Wikidata:Property proposal/Unicode character --- Jura 15:20, 7 April 2020 (UTC)
    •   Oppose given the redundancy of the proposed datatype. --- Jura 13:20, 13 April 2020 (UTC)
    •   Oppose in favor of Jura's proposal; if we cannot implicitly or explicitly force a single label--a single triple--to be shown for all languages in the interest of efficiency, then this only promotes more bloat. Mahir256 (talk) 00:35, 18 April 2020 (UTC)
    •   Weak support I strongly support spliting Unicode characters from concepts. Perhaps there is an existing property that could be used. --Matěj Suchánek (talk) 11:06, 4 September 2020 (UTC)

    Wikidata glossaryEdit

    Wikidata glossary entryEdit

       Under discussion
    Descriptiondescription of a concept, feature, term or tool as used for Wikidata (in English)
    RepresentsWikipedia:Glossary (Q1389361)
    Data typeString
    Domainitems relevant to a glossary for Wikidata
    Allowed valuesgenerally 2-3 sentences, maybe 7. Start with term in bold. Formatting should be limited and text readable without the formatting: e.g. bolding ("'''"); anchors to other entries: sample [[#Q123456|crossreference]]. Do not use {{Q}} or {{P}}.
    Example 1Cradle (Q55933452) '''Cradle''' is an editing tool to create new Wikidata items based on a form with predefined properties and values.
    Example 2Help:Dates (Q87066524) '''Date''' (or '''time''' or '''timeValue''') is a [[#Q19798645|datatype]] for property values. It allows to enter dates in different precisions and enables date calculations in queries. Hour or minute precision isn't supported. The Wikidata property for the date of foundation ([[Property:P571]]) has such values
    Example 3Wikimedia disambiguation page (Q4167410) '''Disambiguation item''' is a Wikidata item with sitelinks to disambiguation pages. This is its only purpose. Generally, it has a claim with "instance of" (P31)="Wikimedia disambiguation page" (Q4167410).
    Planned use
    Expected completenesseventually complete (Q21873974)
    See also
  • scope and content (P7535): a summary statement providing an overview of the archival collection
  • defining formula (P2534): mathematical formula representing a theorem or law. Maximum length: 400 characters
  • Wikidata glossary anchorEdit

       Under discussion
    Descriptionunique name of term, concept, tool being described in the glossary entry, including related terms or synonyms
    Data typeString
    Template parameter
    Domainitems with property proposed above
    Allowed valuesvalues should be unique names in English
    Example 1Cradle (Q55933452) → "Cradle"
    Example 2Help:Dates (Q87066524) → "Date"
    Example 3Help:Dates (Q87066524) → "TimeValue"
    Example 4Help:Dates (Q87066524) → "Time"
    Planned useavoid duplicate entries and provide stable named links to the glossary. Add unique constraint
    Number of IDs in sourceat least one per entry
    Expected completenesseventually complete (Q21873974)

    Wikidata glossary mentioned entriesEdit

       Under discussion
    Descriptionother glossary entry linked in entry
    Data typeItem
    Domainitems with property proposed above including a reference to another entry
    Allowed valuesitems with property proposed above
    Example 1Help:Dates (Q87066524)Wikibase datatype (Q19798645) (see full sample above)
    Example 2MISSING
    Example 3MISSING
    Planned useadd if applicable
    Expected completenesseventually complete (Q21873974)
    See also


    MotivationEdit

    Some time ago, Filceolaire re-wrote the Wikidata glossary (User:Filceolaire/Draft:Glossary). Given the format of Wikidata:Glossary, only some got included in the glossary. Wikidata:Glossary has changed a bit since, but, in the last two years, it may well be that other users additions are limited to "Lexeme", "Sense", "Form", duplicating what's in another glossary.

    So we currently have a page that doesn't seem to be much used (looking at pageviews), updated (looking at edits) or expanded.

    Wikidata:Glossary is somewhat hard to maintain:

    • Ideally every help page would have at least one short glossary entry associated with it.
    • One can't easily find what has or doesn't have an entry.
    • Duplication with other glossaries happens.
    • The relation to Wikidata items about the described concepts is missing, making it rather unstructured.
    • There is a risk of anchor duplication.
    • Section editing isn't available.
    • Entries may be out of sync from the help page they point to, as editors of the help page may not be aware of the glossary entry.

    This proposes a somewhat different, more structured, approach:

    • entries are added to items
    • similar to scope and content (P7535), we can provide a short specialist written summary
    • users could query the items directly with WQS
    • users could generate a glossary for their needs on the fly
    • to get translations, one will be able to retrieve conveniently named pages like Translations:Wikidata:Glossary/15397819/fr (identified by the number of the QID the entry is on)
    • duplication with other glossaries would be less likely
    • the value of the property could be displayed on the relevant help page

    Other things don't change:

    • A page like Wikidata:Glossary could still be generated.
    • Translators could still use the translation extension (main advantage of the current format).
    • Sample: test list (see Special:Translate)
    • It's still the English version that is the primary edition

    Editing will be similar:

    • Formatting should/might be simpler
    • As users edit entries one by one that wouldn't change much.
    • To change several at once, one can use TABernacle or a spreadsheet with QS.
    • The sample above still needs a link to the edit the underlying item .. or to go through Bridge.

    Other ways for some of the above may be possible, but this structured approach has its advantages. Please help complete the above proposal.

    Dedicated to Filceolaire (Add your motivation for this property here.) --- Jura 13:45, 27 March 2020 (UTC)

    DiscussionEdit

    •   Comment I'm not sure I completely follow what you're trying to do, but shouldn't the glossary entries be monolingual text rather than string datatype, so that translations can be added also? The glossary as it stands is (in principle) translated into a number of different languages. ArthurPSmith (talk) 17:54, 27 March 2020 (UTC)
      • Wikidata glossaries are currently written in English and translated through the Translation Extension. The extension is a convenient way to translate text and keep it in sync (not really efficiently possible with multiple monolingual strings at Wikidata). The more detailed explanation above shows how this wouldn't change with this proposal. The property value is in English, translations can be retrieved from pages like Translations:Wikidata:Glossary/15397819/fr (for an entry on Q15397819). --- Jura 00:27, 28 March 2020 (UTC)

    necessary property for classEdit

       Under discussion
    Descriptionall instances of this class necessarily have the property, even if the property might not be known to Wikidata
    Data typeProperty
    Domainitem
    Example 1human (Q5)date of birth (P569)
    Example 2architectural structure (Q811979)coordinate location (P625)
    Example 3geographic location (Q2221906)coordinate location (P625)
    See also

    This should be a subproperty of properties for this type (P1963).

    MotivationEdit

    I'm thinking about how to make our conception of instance of (P31) and subclass of (P279) more clear and with being more clear also one uniform. It seems to me a key feature of the instance of relationship is that it implies that instances have certain properties. Every human was born at a specific point in time. Every architectural structure has a coordinate location.

    I derivate from the wording of "property for this type" here because I believe it's easier to understand Wikidata if we use class in relation to subclass and don't add the additional word type into our vocabulary to describe the entities in our data model. I would then also seek to rename into "property for this class". ChristianKl❫ 16:30, 16 January 2020 (UTC)

    DiscussionEdit

    ) 17:18, 16 January 2020 (UTC)

    • @Yair rand: It's similar to that distinction but not exactly. The term mandatory implies that it would be mandatory for each item to have a statement. Ontologically it's necessary to have a date of birth to be a human. At the same time that date of birth might be unknown to Wikidata and thus there will be items for people that don't have date of birth filled and that would be fine. ChristianKl❫ 19:52, 17 January 2020 (UTC)
    • @ChristianKl: I guess they could have the values unknown (Q24238356) or not yet determined (Q59496158) if it was the case to have mandatory statements, though. TiagoLubiana (talk) 15:21, 4 February 2020 (UTC)

    Tobias1984 (talk) TomT0m (talk) Genewiki123 (talk) Emw (talk) 03:09, 9 September 2014 (UTC) —Ruud 16:15, 9 December 2014 (UTC) Emitraka (talk) 14:32, 14 October 2015 (UTC) Bovlb (talk) 19:10, 21 October 2015 (UTC) Peter F. Patel-Schneider (talk) 22:21, 23 October 2015 (UTC) ArthurPSmith (talk) 15:51, 5 November 2015 (UTC) --Daniel Mietchen (talk) 20:53, 3 January 2016 (UTC) --Harmonia Amanda (talk) 22:00, 27 February 2016 (UTC) --Lechatpito (talk) --Andrawaag (talk) 14:42, 13 April 2016 (UTC) --ChristianKl (talk) 16:22, 6 July 2016 (UTC) --Cmungall Cmungall (talk) 13:49, 8 July 2016 (UTC) Cord Wiljes (talk) 16:53, 28 September 2016 (UTC) DavRosen (talk) 23:07, 15 February 2017 (UTC) Vladimir Alexiev (talk) 07:01, 24 February 2017 (UTC) Pintoch (talk) 22:42, 5 March 2017 (UTC) Fuzheado (talk) 14:43, 15 May 2017 (UTC) YULdigitalpreservation (talk) 14:37, 14 June 2017 (UTC) PKM (talk) 00:24, 17 June 2017 (UTC) Fractaler (talk) 14:42, 17 June 2017 (UTC) Andreasmperu Diana de la Iglesia Jsamwrites (talk) Finn Årup Nielsen (fnielsen) (talk) 12:39, 24 August 2017 (UTC) Alessandro Piscopo (talk) 17:02, 4 September 2017 (UTC) Ptolusque (.-- .. -.- ..) 01:47, 14 September 2017 (UTC) Gamaliel (talk) --Horcrux (talk) 11:19, 12 November 2017 (UTC) MartinPoulter (talk) Bamyers99 (talk) 16:47, 18 March 2018 (UTC) Malore (talk) Wurstbruch (talk) 22:59, 4 April 2018 (UTC) Dcflyer (talk) 07:50, 9 September 2018 (UTC) Ettorerizza (talk) 11:00, 26 September 2018 (UTC) Ninokeys (talk) 00:05, 5 October 2018 (UTC) Buccalon (talk) 14:08, 10 October 2018 (UTC) Jneubert (talk) 06:02, 21 October 2018 (UTC) Yair rand (talk) 00:16, 24 October 2018 (UTC) Tris T7 (talk) ElanHR (talk) 22:05, 26 December 2018 (UTC) linuxo Gq86 Gabrielaltay Liamjamesperritt (talk) 08:44, 21 June 2019 (UTC) ZI Jony Ivanhercaz (Talk) 11:07, 15 July 2019 (UTC) Gaurav (talk) 22:39, 24 August 2019 (UTC) Meejies (talk) 04:38, 29 August 2019 (UTC) Iwan.Aucamp SilentSpike (talk) Tfrancart (talk) Luis.ramos.pst.ag Sylvain Leroux TiagoLubiana (talk) 15:12, 2 December 2019 (UTC) Albert Villanova del Moral (talk) 15:43, 6 February 2020 (UTC) Clifflandis (talk) 15:10, 18 February 2020 (UTC) --Tinker Bell 16:48, 23 March 2020 (UTC) SM5POR Mkbergman (talk) 19:17, 10 July 2020 (UTC) Toni 001 (talk) 11:03, 11 July 2020 (UTC) The-erinaceous-one (talk) 22:02, 31 August 2020 (UTC) Cdo256 (talk) 06:26, 8 September 2020 (UTC) Antoine2711 (talk) 17:22, 25 September 2020 (UTC) Rehman 07:15, 12 October 2020 (UTC) Susanna Giaccai (talk) 07:22, 22 October 2020 (UTC)

    Nomen ad hoc

      Notified participants of WikiProject Ontology ChristianKl❫ 20:04, 17 January 2020 (UTC)

    There's no community consensus on what "has quality: requirement" means. It could plausibly mean "should", "must" or "necessity" (analog to this property). I believe that it's useful to well defined ways to map relations like this. ChristianKl❫ 08:27, 21 January 2020 (UTC)
    1. How would these three be different (if they are).
    2. How would you indicate the meaning of "necessary" in a structured way on the property you propose? Would it be just in the label (i.e. unstructured)? --- Jura 08:30, 21 January 2020 (UTC)
    1. When talking about policy I see the difference about must and should as the one defined in RFC2119. Should implies room for reasoned expections.
    If we have an entity A and an item about A named I(A) then necessity in the way I propose means that A has the property but I(A) might not have the property as the relevant information might not be known to Wikidata or otherwise publically known. ChristianKl❫ 14:40, 21 January 2020 (UTC)
    So a concept that could get a different item and you would (or could) use on the proposed property? --- Jura 15:47, 21 January 2020 (UTC)
    • Hello @ChristianKl:, I wish you a happy new year 2020 to start. I have time to write. Unfortunately for you, because it falls on you, but it is precisely because I have time. Don't worry, you're not alone (by far). You have to understand the concepts, as you write in your sub-pages. I am writing now, right away, because the contributors seem in a hurry to create nonsense on WD, even if they are asked for time to develop a coherent response on a strongly negative opinion (I take as witness URN formatter (P7470)).
    If I summarize, and tell me if I am wrong: "if use of this class" = "necessary presence of this/these property/ies". I have underlined the term "necessary" which I take from your description. From your first example, we say that Albert Einstein (Q937) is part of Q5, so, as it belongs to this class, we need date of birth (P569) in Albert Einstein (Q937). Does my demonstration reflect your proposal? You give as an example properties for this type (P1963) for identical operation on instance of (P31). Before giving you my opinion, I humbly take you to consider the following, because it will also be useful in the future.
    I have never used properties for this type (P1963) and for the following causes. Do you notice the Data type of P1963? This means that this property is used in other properties. However this is not the case, it is a property used in Items. You get the explanation of this type under Special:ListDatatypes (titled: Property (Wikibase entity id)). The examples can be obtained under Special:ListProperties/wikibase-property. see also (P1659) illustrates my point well: this property is used in the other properties to indicate additional information (similar properties for example, a property on football in connection with a property on football). In short, according to the debate and the description of properties for this type (P1963), the Data type to use must be Items, as here.
    Do you also notice the term "occupation" in the Description of P1963? Well, nothing is introduced on this point in this property.
    Continuing, P31 from P1963 is Wikidata property for property documentation (Q19820110). It is still not the right information (value) for the purpose sought in the debate. formatter URL (P1630) documents properties for example, QED.
    The examples of P1963 give more or less the desired goal: when an Item is "of this nature", it is of a class, and one or more properties can be introduced into the Item.
    We get to the constraints. Why use value requires statement constraint (Q21510864) in this property? Needless. value type constraint (Q21510865) is an Item that may interest you, as it may be useful for your proposal. The relationship can and should be instance or subclass of (Q30208840) as described. Another problem on item requires statement constraint (Q21503247), it is not always possible on an Item to have subclass of (P279), or it should be a suggestion. Last constraint, multi-value constraint (Q21510857) should still be a suggestion constraint (Q62026391).
    Another blunder and not the least: by taking one of your examples at random (I write at random, because it is valid for all the examples that you have put or that you will put), Q5 must necessarily have date of birth (P569). So if we follow this reasoning woman (Q467) must have a date of birth. Impossible. And it’s even more obvious if we used classes. Concerning the classes, we cannot attribute to them characteristics which would impact the subclasses.
    In summary: Data type incorrect, infeasible and comparison (or suggestion of subproperty) with a bad property which is at the beginning an idea almost identical to this proposition (see the proposition of P1963).   Strong oppose and I suggest you already withdrawn in status. Cordially. —Eihel (talk) 21:44, 28 January 2020 (UTC)
    @Eihel: One point of this exercise is to become more clear about what instance of (P31) means. woman (Q467) is not instance of (P31) human (Q5). woman (Q467) subclass of (P279) human (Q5). If this property would exist as proposed a new user who asks themselves is woman (Q467) instance of (P31) human (Q5) or woman (Q467) subclass of (P279) human (Q5) could know that it has to be woman (Q467) subclass of (P279) human (Q5) because human (Q5) has no date of birth.
    The fact that you currently think that woman (Q467) instance of (P31) human (Q5) might be valid even through you are an established user, shows that it's important that we produce clarity here. Apart from woman (Q467) and human (Q5) there are plenty of cases in Wikidata where it's even harder to decide about whether to use instance of (P31) or subclass of (P279) and thus more importent to have clearer policy. properties for this type (P1963) alone doesn't allow you to reason as easily about whether to use instance of (P31) or subclass of (P279) because an item like woman (Q467) might have some of the properties for this type (P1963) but not others in both the case where it's a subclass and the case where it's an instance. ChristianKl❫ 08:17, 29 January 2020 (UTC)

      Comment I believe that is a good property, and arguably clearer than using has quality (P1552) for properties for this type (P1963). But it seems quite similar to properties for this type (P1963) in the sense that they would have an overlap Just thinking out loud, maybe the "mandatory" idea, in the ontological sense, could also be achieved with a new property to qualify properties for this type (P1963). Something in the likes of an "ontological prevalence" with values as "total", "often" or "total for subclass", representing how often the instances of such a class harbor the value of these properties in the real world, regardless of whether we have this information in Wikidata or not. An example of "mandatory for subclass" would be for example, human (Q5) - properties for this type (P1963) - date of death (P570) as all humans that are deceased have a date of death (P570) . TiagoLubiana (talk) 19:21, 4 February 2020 (UTC)

      Oppose because I think properties for this type (P1963) is more flexible. However, if there is a difference between both with respect to enforcability of the constraint then I'm in favor of the more enforcable property. --SCIdude (talk) 17:46, 21 March 2020 (UTC)

      Support Iwan.Aucamp (talk) 20:04, 21 March 2020 (UTC)

    URL match patternEdit

       Ready Create
    Descriptionregex pattern of URL that an external ID may be extracted. Qualifier "URL match replacement value" can overwrite the default \1. Use non-capturing groups when needed "(?:)".
    Data typeString
    Domainproperty
    Example 1IMDb ID (P345) → (one of multiple values) https:\/\/www\.imdb\.com\/(?:title|name|news)\/([a-z0-9]+)(\/.*)?
    <replacement value> \1
    Example 2PubMed ID (P698)https:\/\/pubmed\.ncbi\.nlm\.nih\.gov\/(\d+)(-[^\/]*)?\/
    <replacement value> \1
    Example 3ISNI (P213)https?:\/\/www\.isni\.org\/(\d{4})(| |%20)(\d{4})(| |%20)(\d{4})(| |%20)(\d{4})
    <replacement value> \1 \3 \5 \7
    Example 4ZVG number (P679)http:\/\/gestis-en\.itrust\.de\/nxt\/gateway\.dll\/gestis_en\/0+([1-9]\d+)\.xml.*
    <replacement value> \1
    Example 5CricketArchive player ID (P2698)https:\/\/cricketarchive\.com\/Archive\/Players\/\d+\/\d+\/(\d+)\.html
    <replacement value> \1
    Example 6Fandom article ID (P6262)https:\/\/([a-z0-9\.-]+)\.(wikia|fandom)\.com\/wiki\/(.*)
    <replacement value> \1:\3
    Example 7Geni.com profile ID (P2600)https:\/\/www\.geni\.com\/(?:profile|people)\/[^\/]+\/(\d+)(#.*)?
    <replacement value> \1
    See also

    URL match replacement valueEdit

       Under discussion
    Description(qualifier only) optional qualifier to overwrite the default \1
    Data typeString
    Example 1see above
    Example 2MISSING
    Example 3MISSING

    MotivationEdit

    This will provide a way to extract property and ID from a given URL. A future tool or gadget may benefit from this. GZWDer (talk) 23:46, 26 February 2020 (UTC)

    DiscussionEdit

      Comment Here's an example of how this would look on Fandom article ID (P6262):

    URL match pattern
      https:\/\/([a-z0-9\.-]+)\.(wikia|fandom)\.com\/wiki\/(.*)
    URL match replacement value \1:\3
    0 references
    add reference


    add value

    If a tool wanted to automatically generate a Fandom article ID (P6262) from the URL https://minecraft.fandom.com/wiki/Sheep for example, it would match the regex specified with property against that URL. There are three caputring groups in the regex. The first one is ([a-z0-9\.-]+), and matches "minecraft", the second one is (wikia|fandom) and matches "fandom", and the third one is (.*) and matches "Sheep". The URL match replacement value allows these capturing groups to be put together. \1:\3 turns into minecraft:Sheep, since \N is replaced with the value of the nth capturing group. --SixTwoEight (talk) 01:52, 4 March 2020 (UTC)

    Replacement for external id extraction
      \1:\3
    applies if regular expression matches https:\/\/([a-z0-9\.-]+)\.(wikia|fandom)\.com\/wiki\/(.*)
    0 references
    add reference


    add value
    •   Comment Thanks for the ping Lockal. Something like this will almost certainly help. I don't have time right now to get my head around the alternatives, but I'm very glad to see this. --99of9 (talk) 11:17, 6 October 2020 (UTC)
    • @GZWDer:, sorry for interruption, what do you think about my suggestion above (about reusing of applies if regular expression matches)? Also, inversion of pattern/replacement creates somewhat cleaner representation in case when different URL patterns are using the same replacement (which is impossible it an opposite way: a single URL pattern can never use multiple replacement patterns). If you agree, could you update your proposal, please? --Lockal (talk) 07:58, 13 October 2020 (UTC)
    •   Support Yes, I can see this being very useful, thanks for proposing! ArthurPSmith (talk) 18:19, 6 October 2020 (UTC)
    •   Support I think I prefer this over Wikidata:Property proposal/URL extractor regular expression but I prefer either over nothing. BrokenSegue (talk) 03:54, 19 November 2020 (UTC)
      • Lockal interesting, but Replacement for external id extraction would be \1 in the vast majority of cases? Wouldn't it? --Shisma (talk) 19:13, 19 November 2020 (UTC)
    •   Support per discussion at Wikidata:Property proposal/URL extractor regular expression. --- Jura 12:31, 21 November 2020 (UTC)
      • I added some formatting to the samples above. BTW, should we make "$2" the default replacement value? This could make the qualifier "replacement value" optional. See Property_talk:P973 for some regexes. --- Jura 17:44, 21 November 2020 (UTC)
        • @Jura1: Thanks for clarifying the proposal. Why 2 and not 1? A 2 can always be made into a 1 using non-capturing regex groups. Also I assume you meant \2 not $2. BrokenSegue (talk) 17:50, 21 November 2020 (UTC)
          • At Property_talk:P973, it sometimes ended up being \2. Either because I didn't know better or non-capturing groups aren't supported. I suppose we should pick either $2 or \2. --- Jura 17:59, 21 November 2020 (UTC)
          • @BrokenSegue: It seems that (?:) is supported by Krbot. I added that the qualifier is optional if it's the default \1. --- Jura 08:20, 1 December 2020 (UTC)
    •   Support --Shisma (talk) 13:22, 21 November 2020 (UTC)

    number of deceased by period in this location/countryEdit

       Under discussion
    Descriptionnumber of deaths per year in this country or other geographic region
    Data typeQuantity
    Example 1France (Q142) → 614000 in 2018
    Example 2Italy (Q38) → 633133 in 2018
    Example 3MISSING
    Expected completenessat least one value for the latest available year per country

    MotivationEdit

    Should be possible to query the death per country. And not to be confused with number of deaths (P1120) which stand for a specific event, not a whole country. Bouzinac (talk) 18:14, 21 March 2020 (UTC)

    DiscussionEdit

    •   Comment I would suggest renaming it to 'number of deceased by period'. In this case, the qualifier point in time (P585) should be required. --Tinker Bell 16:36, 22 March 2020 (UTC)
    •   Support - Given that it is renamed to something more specific. If it just for geographic locations i would suggest something like 'deceased by period in location'. Husky (talk) 22:53, 24 March 2020 (UTC)
    •   Comment I'm a bit worried to have another series of properties with countless values on country items. How about placing this on items like demographics of France (Q1172523) ? --- Jura 13:24, 27 March 2020 (UTC)
    •   Oppose I would prefer to reuse number of deaths (P1120), I don't see a good reason to have two different properties. Franzsimon (talk) 13:30, 24 July 2020 (UTC)
      number of deaths (P1120) is for specific event : https://www.wikidata.org/wiki/Q3091167#P1120 = 6 deaths in this event. Whilst the new property would stand for countries (or possibly territorial entities) having death statistics per year. Bouzinac💬✒️💛 20:11, 17 September 2020 (UTC)

    quantification instructionEdit

       Under discussion
    Descriptioninstruction according to which the ingredient should be quantified
    Representsquantification instruction (Q89895195)
    Data typeItem
    Domainitem
    Allowed valuesup to taste (Q89895024),until cup is full (Q89895393) (more?)
    Example 1Bloody Mary (Q207711)material used (P186)Tabasco sauce (Q335016) → [this property] → up to taste (Q89895024)
    Example 2Warp 10 (Q87586496)material used (P186)Upper 10 (Q7898449) → [this property] → until cup is full (Q89895393)
    Example 3Russian Spring Punch (Q26883085)material used (P186)sparkling wine (Q321263) → [this property] → until cup is full (Q89895393)

    MotivationEdit

    most recepies prescribe precise amounts for each ingredient. in these cases we can simply use quantity (P1114) to depict the amount. But some recepies also contain an instruction about how to find the correct quantity: such as the offical recepie for Boody Mary: Tabasco, Celery Salt, Pepper (Up to taste). Loominade (talk) 12:11, 9 April 2020 (UTC)

    Sebleouf
    Teolemon
    Vladimir Alexiev
    Ash_Crow
    d1g
    Dhx1
    Tris T7 TT me
    Gobonobo
    Ainali

      Notified participants of WikiProject Food

    DiscussionEdit

    •   Comment @Loominade: in the meantime, there was Wikidata:Property_proposal/descriptive_solubility created as descriptive solubility (P8459). I suppose I'd support this if more likely values were given. --- Jura 10:54, 18 July 2020 (UTC)
      • Jura1 can you please give an example? --Loominade (talk) 07:49, 20 July 2020 (UTC)
        • You just mentioned up to taste (Q89895024) and until cup is full (Q89895393). If there were more, I might support the proposal. See the series of values given for descriptive_solubility for comparison. --- Jura 07:51, 20 July 2020 (UTC)
          • this is everything that i was able to come up with. will need to read some recipes. if you have an idea for a possible value, let me know. --Loominade (talk) 08:03, 20 July 2020 (UTC)
      •   Oppose I tried to think of more values, but all I came up with are qualitative (rather than quantitative) instructions: heat water "until boiling," cook "until golden brown," stir solution "until solute is completely dissolved," mix batter "until smooth," when using shampoo: "repeat as necessary." Perhaps we could broaden the scope of this property to include those, somehow, otherwise there doesn't seem to be enough demand for the proposed quality. You might also want to ping the Chemistry project; they might have suggestions. The-erinaceous-one (talk) 22:15, 13 September 2020 (UTC)

    compatible withEdit

       Ready Create
    Descriptionthis work, product, object or standard can interact with another work, product, object or standard
    Data typeItem
    Domainitem
    Example 1Replicant (Q7314062)GT-I9300 (Q83637336)
    Example 2libreboot (Q20085696)ThinkPad X200 (Q51954707)
    Example 3exynos4412-i9300.dts (Q90612899)GT-I9300 (Q83637336)
    Example 4sigrok (Q14589876)IEEE-488 (Q1135192)
    Example 5Linux kernel (Q14579)Serial ATA (Q188639)
    Example 6Linux kernel (Q14579)Advanced Host Controller Interface (Q379598)
    Example 7Linux kernel (Q14579)Advanced Configuration and Power Interface (Q379523)
    Example 8Linux kernel (Q14579)Internet protocol suite (Q81414)
    Example 9GNU Compiler Collection (Q178940)C++11 (Q1061570)
    Planned useConvert the Replicant, Libreboot and libsamsung-ipc to use that property. Add dts for devices supported by Replicant, and retrieve it in a tool.
    Expected completenesseventually complete (Q21873974)
    See alsoplatform (P400), operating system (P306), readable file format (P1072), writable file format (P1073), intended public (P2360)

    MotivationEdit

    The idea is to have the ability to describe when hardware, software, protocols, etc are compatible with each other.

    For instance if I want to tell that the GT-I9300 (Q83637336) variant of the Samsung Galaxy SIII Replicant 6.0 0003 or vice versa I could use such property.

    It is different from the platform (P400) property as a given program might be compatible with different platforms (GNU/Linux, Various Microsoft Windows versions, FreeBSD, etc) and uses libusb to interact with various hardware it's compatible with.

    sigrok (Q14589876) runs on GNU/Linux, Mac OSX, Windows, FreeBSD, OpenBSD, NetBSD, Android and supports several oscilloscopes and logic analyzers. The OS it runs on can be expressed by the platform (P400) property but the hardware it supports cannot.

    libsamsung-ipc (Q83639531) is a library that runs on Android and GNU/Linux which supports several modems of several smartphones which use the samsung-ipc protocol. The modems cannot be described as platform either.

    In some cases qualifiers will have to be used to give more context to this "Compatible with" property:

    • The compatible software might run on the device itself or on a host computer to interact with the device:
      • The Talos II mainboard has a BMC (Baseboard Management Controller) which runs GNU/Linux on its ARM processor(s) while GNU/Linux also runs on the main CPU which uses the PowerPC architecture. So here we need to know, for a given software, if it runs on the BMC and supports the BMC hardware that way, or if it runs on the host processor and supports the BMC by talking to it.
      • Some modems have GNU/Linux in some of their cores. The Quectel Osmocom project wiki has some more details on them. As a result you have software support for the modem protocol in Linux for the host and in userspace drivers in stacks like Ofono, but also for the modem SOC where the code is supposed to run on the modem itself. There is even upstream Linux support for the later.
    • In case of protocol the compatibility could be at different levels. For instance you could be compatible with USB interface, or the USB mass storage, but then both have different standards or part of the standard that describe that.  – The preceding unsigned comment was added by GNUtoo (talk • contribs).

    DiscussionEdit

    Should I change it in this proposal, or do I need to wait for more comments before submitting a new proposal? GNUtoo (talk) 19:37, 3 May 2020 (UTC)
    @GNUtoo: No, this means that, for example, if Replicant (Q7314062) <compatible with> GT-I9300 (Q83637336), then GT-I9300 (Q83637336) <compatible with> Replicant (Q7314062). If the property is created, this will be marked in the property as <property> property constraint (P2302) symmetric constraint (Q21510862). --Tinker Bell 03:52, 11 May 2020 (UTC)
    •   Comment the scope seems a bit vague, e.g. wouldn't the items for Linus and Windows end up linking to almost anything? --- Jura 14:42, 12 May 2020 (UTC)
    It could in theory, however I don't see this as an issue, as people still need to follow common sense, and to link what is noteworthy and/or useful. For now there is also operating system (P306) for just being compatible with a specific operating system like Android, GNU/Linux or Windows. platform (P400) can also be used for platforms like Gaming consoles. However I don't see how to express how a given driver (which can run on multiple operating systems for instance) could be compatible with a given hardware component, hence the need for a more generic property. GNUtoo (talk) 20:00, 12 May 2020 (UTC)
    The fact that the property (will) use by design a symmetric constraint (Q21510862) also enables people to only link things one way: If a given driver supports way to many devices and that it's actually useful to tell that a device is supported by this driver, you could simply link things on the device element page and not on the driver page. GNUtoo (talk) 20:04, 12 May 2020 (UTC)
    • Personally, I think a symmetric constraint makes things even worse. Would the OS property be sufficient? --- Jura 05:25, 14 May 2020 (UTC)
    Using operating system (P306) doesn't work: You cannot tell that a specific oscilloscope is compatible with sigrok (Q14589876) because sigrok (Q14589876) isn't an operating system. You also cannot tell that exynos4412-i9300.dts (Q90612899) is compatible with GT-I9300 (Q83637336) because exynos4412-i9300.dts (Q90612899) isn't an operating system either. This is precisely why I proposed this property: because after looking for hours and hours I found no way to express things like that. sigrok (Q14589876) and IEEE-488 (Q1135192) are not platform either. readable file format (P1072) and writable file format (P1073) don't work either for sigrok (Q14589876) and IEEE-488 (Q1135192) as none are file. And abusing intended public (P2360) as compatible be really missleading as hardware or protocol aren't people. GNUtoo (talk) 02:39, 15 May 2020 (UTC)
    • @GNUtoo: I removed the pings to nonexistent projects as the just clutter the discussion with a lot of error messages. ChristianKl❫ 22:03, 11 June 2020 (UTC)
    Thanks GNUtoo (talk) 20:58, 20 June 2020 (UTC)
    •   Comment The completeness seems highly unrealistic. Always incomplete is the likely case. Ainali (talk) 21:12, 29 July 2020 (UTC)
    That would work for me too. I'm unsure what completeness means exactly. As I understood it, in some cases a given software could explicitly only support certain hardware, and that list could be small and finite. For instance Replicant (Q7314062) version 6.0 0003 supported only 11 devices. There might be a bit more devices supported as some more Galaxy Nexus variant might work, but beside that, that's pretty much it. The number of variants is finite. It's just that I didn't have the time to look into which ones we're supposed to support (I'm involved in Replicant). For that version, the kernels are device specific, so the images won't work on a device that is not officially supported. Another example I have in mind is the ralim/ts100 soldering iron firmware that supports very few soldering irons. Rockbox (Q1143754), coreboot (Q286812), libreboot (Q20085696) also support a finite number of devices as part of the code is device specific and writing device specific code is required to add support for a new device, unless the hardware is mostly identical to one already supported, but here too, there will be a finite number of identical devices. But then it also depend on how you define compatibility completeness. For instance a modem can be compatible with Linux in the sense that Linux has a driver to interact with it, but that same modem might also be able to run an upstream Linux kernel. So from a narrow perspective you could make compatibility be complete, but from a broader perspective you don't want to map non relevant things. Note that in the case I just described (which really exists) you can easily differentiate between both by being more precise about the compatibility (for instance that device could be compatible with a dts which shows that the device can run Linux, or with the qualcomm modem driver). GNUtoo (talk) 11:06, 13 August 2020 (UTC)
    •   Support I was trying to link a third party game controller with a game system today. This would help with that. Moebeus (talk) 21:13, 29 July 2020 (UTC)
    •   Comment can we agree not to use it on Linux kernel (Q14579) and similar items? The inverse would be better for these. --- Jura 21:15, 10 August 2020 (UTC)
    This makes sense, however I think we could make that broader, and agree on linking many element to one instead of one to many. GNUtoo (talk) 11:06, 13 August 2020 (UTC)

    local timeEdit

       Under discussion
    Representsqualifier for properties that have a date
    Data typeItem
    Allowed valuestime of the day (Q1260524)
    Example 1Valentina Blackhorse (Q92079066) date of death (P570) 23 April 2020 → 22:22 (Q55812761)
    Example 2Barack Obama (Q76) date of birth (P569) 4 August 1961 → 19:24 (Q55812651)
    Example 32019 Whakaari / White Island eruption (Q77929275) point in time (P585) 9 December 2019 → 14:11 (Q55811653)
    Example 4see query for 1100 others
    Planned usereplace refine date (P4241) in https://w.wiki/aZs
    See alsorefine date (P4241)

    MotivationEdit

    The obituary for Valentina Blackhorse (Q92079066) makes it clear that there is cultural significance given to the time at which this person died. Defining this in Wikidata is not possible at the moment. 1Veertje (talk) 18:03, 16 May 2020 (UTC)

    DiscussionEdit

    ah, that works. Thank you. I'll add "local time" as an alias there. 1Veertje (talk) 21:50, 19 May 2020 (UTC)
      Support To me the qualifier seem valid as people might know the local time but not the whole system that it refers to (Example: UTC time, GPS time, sun time, etc) nor the characteristics (time zone, etc). And I don't see how to do it with refine date (P4241) but I could have missed something. Maybe there is another way to do it but no one suggested it yet and I didn't find any. GNUtoo (talk) 20:02, 20 June 2020 (UTC)
    •   Support even if other qualifiers would be needed. --- Jura 16:41, 26 May 2020 (UTC)
    •   Comment I'll stay in my position: creating a property requires a minimum of 2 examples and the proposal specifies to include 3 examples. (and property creators shouldn't vote for - in that sense IMHO) —Eihel (talk) 09:01, 28 August 2020 (UTC)

    parent languageEdit

       Under discussion
    Descriptionlanguages from which this language derive, may be a proto-language. Examples are Proto-Germanic (PGmc) or Germanic parent language (GPL).
    Representsparent language (Q94583221)
    Data typeItem
    Domainlinguistics (Q8162)
    Allowed valuesvalue instance of (P31) languoid (Q17376908)
    Example 1French (Q150)Middle French (Q1473289)
    Example 2English (Q1860)Early Modern English (Q1472196)
    Example 3Ancient Greek (Q35497)Mycenaean Greek (Q668366)
    Example 4Afrikaans (Q14196)Dutch (Q7411)
    Sourceréférence externe, article de liste de Wikipédia.
    Planned useSur les langues d’Oïl et indo-européennes dans un premier cas, mais servira vite pour toutes les langues
    See also

    MotivationEdit

    Je suis en train de classifier les langues et notamment leurs relations diachroniques entre elles. Cette propriété sera vraiment utile pour lier les langues et générer des arbres linguistiques en diachronie. Lyokoï (talk) 22:47, 16 May 2020 (UTC)

    Popcorndude Nikki SynConlanger Infovarius Finn Årup Nielsen (fnielsen) (talk) Daniel Mietchen (talk) Lore.mazza81   Notified participants of WikiProject Linguistics

    DiscussionEdit

    •   Weak support currently this role is being served by subclass of (P279). I think the case can be made that this is better. Iwan.Aucamp (talk) 10:14, 17 May 2020 (UTC)
      Strong support Upgrading to strong support. I'm pretty sure subclass of (P279) is not ideal for modelling this. Iwan.Aucamp (talk) 21:21, 17 May 2020 (UTC)
      Weak oppose Revised my support. I favour using language based on (P144) parent language / criterion used (P1013) parent language (Q94583221) Iwan.Aucamp (talk) 18:44, 19 June 2020 (UTC)
    @Iwan.Aucamp: There is a big problem for me for (P144), it’s for construct things, not natural thing. This isn’t a conscient choice for anturals languages to have one or more parent language. (P144) is for human work (for artificial language for example), not for natural thing. I didn’t know how futur french are based on, maybe on actual french, but we can’t say more ! But for my new artwork, I always know on what I had based my work. It’s an important differency for me. Lyokoï (talk) 19:03, 19 June 2020 (UTC)
    •   Weak support for this property,   Oppose for this name as it is easily confused with native language (P103).--GZWDer (talk) 10:19, 17 May 2020 (UTC)
      • @Lyokoï, GZWDer: How about "parent language" for the English label? Another possibility is "proto-language" but I think "parent language" may be more appropriate - I think "proto-language" is a kind of "parent language". Iwan.Aucamp (talk) 20:48, 17 May 2020 (UTC)
        • @Iwan.Aucamp, GZWDer: I’m okay for « parent language », it is better I think, no problem for this change. But « proto-language » isn’t the same notion, because proto-language are only reconstructed language. And yes, « proto-language » is a kind of » parent language ». Lyokoï (talk) 20:57, 17 May 2020 (UTC)
    •   Comment @Lyokoï: I think the current value for 'subject item', which is parent language (Q94583221), is not right. If you look at other properties, this should be the item that values for this property should be instances of. For example, for writing system (P282) it is writing system (Q8192) so all values for writing system (P282) must have ??? instance of (P31) writing system (Q8192). The way it is now all values for this property will have to be ??? instance of (P31) parent language (Q94583221) and I don't think that is entirely ideal. I think it would be better to make 'subject item' languoid (Q17376908). Iwan.Aucamp (talk) 21:14, 17 May 2020 (UTC)
      • Actually no, my apologies, it is right as is. I think allowed values need some work though, will do it shortly. Iwan.Aucamp (talk) 21:18, 17 May 2020 (UTC)
    •   Comment @Lyokoï: I removed 'expected completeness' (expected completeness (P2429)), this should only be used for identifiers I believe (see Property_talk:P2429#Should_only_be_used_on_identifiers). Iwan.Aucamp (talk) 21:40, 17 May 2020 (UTC)
    •   Comment @Lyokoï: I looked at Afrikaans (Q14196), and it has Afrikaans (Q14196) based on (P144) Dutch (Q7411), would this not be sufficient for your needs? See this query:
      #defaultView:Graph
      SELECT ?item ?itemLabel ?parentLanguage ?parentLanguageLabel WHERE {
        ?item wdt:P31 / wdt:P279* wd:Q17376908.
        ?item wdt:P144 ?parentLanguage.
        SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en". }
      }
      
      Try it! Iwan.Aucamp (talk) 21:50, 17 May 2020 (UTC)
      @Iwan.Aucamp: Hello, the property P144 isn’t good for lots of languages. Afrikaans is a pidgin due to the mix of some languages. But French isn’t « based of » middle french, it is directly from this parent language. I see P144 like a act due to choices, but most of languages are natural and not based of choice for their evolution. For me Afrikaans have some parent language. Lyokoï (talk) 08:02, 18 May 2020 (UTC)
      I would add that according to the description P144 seems to relate only to works, only due to choices therefore, which is not the case with natural languages. Lyokoï (talk) 08:08, 18 May 2020 (UTC)
    •   Oppose I think using based on (P144) is sufficient. We use it in computer languages to express the same relation. --Tinker Bell 02:37, 18 May 2020 (UTC)
      • @Tinker Bell: Did you have references about that, I’m curious ? Lyokoï (talk) 08:02, 18 May 2020 (UTC)
        • @Lyokoï: I generally agree with Tinker Bell. I get that the word "based on" may not be that great - but it can capture the relation that you are looking for I believe, we can maybe expand based on (P144) to accommodate the case better but I think an important principle is to reduce the proliferation of properties as much as possible in favour of using more general properties and qualifiers where it is not enough. If there are different "based on" like relations you need to capture, maybe that is a good basis for a new property, but I guess you can put multiple languages in the property if you need to, and for cases where there is more than one kind of "based on" relation qualifiers like criterion used (P1013) or determination method (P459) may work. For example Afrikaans (Q14196) based on (P144) Dutch (Q7411) / criterion used (P1013) parent language (Q94583221) or Afrikaans (Q14196) based on (P144) Dutch (Q7411) / determination method (P459) parent language (Q94583221). Here is a query to illustrate how it works for programming languages
          #defaultView:Graph
          SELECT ?item ?itemLabel ?parentLanguage ?parentLanguageLabel WHERE {
            ?item wdt:P31 / wdt:P279* wd:Q9143.
            ?item wdt:P144 ?parentLanguage.
            SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en". }
          }
          
          Try it! Iwan.Aucamp (talk) 15:29, 18 May 2020 (UTC)
          • I understand that, but I think it is not a good way for this property. As I say before, the parental relation between two natural languages is determined by lots of studies because it is a very complex notion. This link, can be resume by a link between to work like P144. The parental relation need its own qualifiers like « concerned linguistic movement » or « based on lexical studies, or historical pronunciation studies, etc. » (Sorry, I didn’t use the WD language here, I just try to explain the difference). The fact that language are naturals and works not should be treated differently. Because the target objects are fuzzy, with imprecise limits, constantly evolving and always studied. The objects concerned by P144 are precise, chosen and of a much smaller range. Finally, and the most important argument I think : the relationship that I propose carries an exclusive value of diachrony. The parent languages must have appeared before the daughter languages. This notion is absent from P144. --Lyokoï (talk) 19:02, 18 May 2020 (UTC)
    •   Comment The WikiProject Languages has not yet been notified. Visite fortuitement prolongée (talk) 19:35, 18 May 2020 (UTC)
    •   Comment Currently this is managed by based on (P144) (such Tsotsitaal (Q1472421) P144 Afrikaans (Q14196) P144 Dutch (Q7411)) and follows (P155) (such Modern Greek (Q36510) P155 Medieval Greek (Q36387) P155 Koine Greek (Q107358) P155 Ancient Greek (Q35497) P155 Mycenaean Greek (Q668366) P155 Proto-Greek (Q1231805)). Visite fortuitement prolongée (talk) 19:35, 18 May 2020 (UTC)
    •   Support A parent language is a much more specific relationship than based on (P144) since it does not just imply "borrowing" some elements from a langage but inheriting core morphological traits (that's the main reason that phylogenetic trees are usable in historical linguistic). Since we have many items on languages and dialects I believe the new property would fit a real need. Alexander Doria (talk) 15:43, 19 May 2020 (UTC)
    •   Support As proposer. Lyokoï (talk) 16:29, 19 June 2020 (UTC)
    •   Weak support, good idea but as the notion is very specific, we need good constraint and checking to make sure the property is correctly used. parent language (Q94583221) could use some improvements too (thanks already @Iwan.Aucamp:  ). Cheers, VIGNERON (talk) 17:33, 19 June 2020 (UTC)




    derived from organism typeEdit

       Under discussion
    DescriptionThe organsim from which a given cell line was derived.
    Data typeItem
    Domainmainly instance of (P31)/subclass of (P279)* cell line (Q21014462) allowed values = instance of (P31)/subclass of (P279)* taxon (Q16521)
    Example 1HeLa (Q847482) -> Homo sapiens (Q15978631)
    Example 2CHO-K1 (Q54812705) -> Chinese hamster (Q2539773)
    Example 3108CC15 (Q27870067) -> house mouse (Q83310)
    Example 4108CC15 (Q27870067) -> Brown Rat (Q184224)
    SourceThis info is available on https://web.expasy.org/cellosaurus/ and is currently uploaded in Wikidata via found in taxon (P703) by the User:CellosaurusBot
    Planned useIn the next release of Cellosaurus, the cell lines on Wikidata would be updated with this property. It would then be used for every run of the bot.
    Robot and gadget jobsThe CellosaurusBot will use it
    See alsoestablished from medical condition (P5166), parent cell line (P3432), autologous cell line (P3578)

    MotivationEdit

    There are 227126 instances/subproperties of cell line on Wikidata as of now (https://w.wiki/Qet).

    The source of those cell lines (as regarding the species) are represented with the property found in taxon (P703). That is a sub optimal modelling.

    The current description of found in taxon (P703) says: "the taxon in which the item can be found". Two logical issues that I believe are crucial:

    1) Cell lines are end products, they cannot be "remade" from new individuals. HeLa cells are derived from a human being, but cannot be found in any individuals of this taxon.

    2) Cell lines can be of mixed origin. This is currently modeled as found in both taxons (exː 108CC15 (Q27870067)), but the cell line would not be found in any of the taxons specifically. It is a new, human-made construct.

    Additionally, having such a property would allow a few other improvements, such as having allowed qualifiers constraint (Q21510851) that refer to the individualː

    • Use of sex or gender (P21) as a qualifier for this property, instead of TO found in taxon (P703) as the taxon is (rigorously) not gendered, but the individual from which it originated is.
    • Sometimes we know the exact individual from which the cell line derived. name (P2561) could be used as a qualifier for named individuals (see "Cocca", the cat, on https://web.expasy.org/cellosaurus/CVCL_V013) .
    • age at event (P3629) could be used when the source is Homo sapiens, and we know the age of the individual when the cell line was originated. Other property, more general for age stages of other taxons, could be created later.
      TiagoLubiana (talk) 20:00, 12 May 2020 (UTC)

    DiscussionEdit


    Andrew Su
    Marc Robinson-Rechavi
    Pierre Lindenbaum
    Michael Kuhn
    Boghog
    Emw
    Chandres
    Dan Bolser
    Pradyumna
    Chinmay
    Timo Willemsen
    Salvatore Loguercio
    Tobias1984
    Daniel Mietchen
    Optimale
    Mcnabber091
    Ben Moore
    Alex Bateman
    Klortho
    Hypothalamus
    Vojtěch Dostál
    Gtsulab
    Andra Waagmeester
    Sebotic
    Mvolz
    Toniher
    Elvira Mitraka
    David Bikard
    Dan Lawson
    Francesco Sirocco
    Konrad U. Förstner (talk)
    Chris Mungall (talk)
    Kristina Hettne
    Hardwigg
    i9606
    Putmantime
    Tinm
    Karima Rafes
    Finn Årup Nielsen
    Jasper Koehorst
    Till Sauerwein
    Crowegian
    Nothingserious
    Okkn
    AlexanderPico
    Amos Bairoch
    Gstupp
    DePiep
    Was a bee
    SarahKeating
    Muhammad Elhossary
    Ptolusque
    Netha
    Damian Szklarczyk
    Kpjas
    Thibdx
    Juliansteinb
    TiagoLubiana
    SCIdude
    Photocyte
    Yusra Haider
    JS
    Hannes Röst
    Kritika Dusad
    T.Shafee(evo&evo) (talk)
    GoEThe
      Notified participants of WikiProject Molecular biology TiagoLubiana (talk) 20:13, 12 May 2020 (UTC)

    • I would expect that there's prior art about naming this relationship. I think that should be investigated before creating this property.
    For how many cell lines do we know more then just the taxon of the originating individual? We could link to an item about that individual. ChristianKl❫ 17:22, 18 May 2020 (UTC)
    @ChristianKl: By prior art you refer to other available properties? Me and User:Amb_sib studied this possibility, and the only other property we found that resembles this is natural product of taxon. That property refers to something that is constantly derived from individuals of a taxon, and not a product of a single individual. We have spent some time looking at ways of modelling it with the current infrastructure, and it does not seem possible.
    Additionally, there are not many cell lines with "notable" sources for linking on Wikidata. I do not have a precise number, but it seems to be way less than 1%. We thought about modeling this as "originated from" and then adding the individual. But this is not standardized in any database. I agree that it would be interesting to link individuals in those special cases, but that would require extra modeling (perhaps a dedicated property/qualifier, even). As of now, HeLa cell line is linked to Henrietta Lacks only by the named after property, which seems suboptimal. TiagoLubiana (talk) 09:59, 20 May 2020 (UTC)
    @TiagoLubiana: By prior art I mean naming of the relationship outside of Wikidata. There are plenty of people in the field of biology that have thought about how to name relationships in biology. The OBO Foundry would be one place to look for prior art. Ideally, we only want to invent a new name for a relationship like this if there either isn't an existing name or we have explicit reasons why the existing name isn't good for what we are doing.
    How do the databases from which you want to import data call this relationship? ChristianKl❫ 10:04, 20 May 2020 (UTC)
    @ChristianKl: Oh, okay, I get your point, thanks for the clarification. User:Amb_sib is responsible for the Cellousaurus database, from where the User:CellosaurusBot imports its edits. It is modeled as "Species of origin", which has a similar meaning. I like the idea of making that it a bit clearer that it comes from a single individual to avoid misunderstandings in Wikidata, as the set of users might not be familiarized with cell lines.
    In OBO, it is not direct. The Cell Line Ontology (http://www.ontobee.org/ontology/CLO) embeds this relation in "derives_from some (epithelial cell and (part of some (uterine cervix and (part of some (Homo sapiens and (has disease some adenocarcinoma))))))" for HeLa cells, for example. It can be (more or less̠) shortened to "derives_from" "epithelial cell " "part_of" "some" "Homo sapiens", which is a modularized combination of the property proposed here with extra info. TiagoLubiana (talk) 11:58, 20 May 2020 (UTC)
    • I looked at "in taxon" (which we consider to be a synonym found in taxon (P703) of RO: X is in taxon y if an only if y is an organism, and the relationship between x and y is one of: part of (reflexive), developmentally preceded by, derives from, secreted by, expressed.
      Do you think developmentally preceded by applies or doesn't to the cell lines? ChristianKl❫ 12:38, 20 May 2020 (UTC)
      • @ChristianKl: Thanks for finding that. I do not think developmentally preceded by applies here, at least in the OBO sense (x developmentally related to y if and only if there exists some developmental process (GO:0032502)). One reason is that cell lines are not derived by any developmental processes. TiagoLubiana (talk) 18:28, 20 May 2020 (UTC)
    • Cell Line Ontology defines "derived from organism". In addition to taxons they also consider "male organism" a valid value.
      We could additionally say HeLa (Q847482) derived from organism Henrietta Lacks (Q1647793). ChristianKl❫ 13:31, 20 May 2020 (UTC)
      • @ChristianKl:I agree that "we could additionally say HeLa (Q847482) derived from organism Henrietta Lacks (Q1647793)". However, this would not be applicable for most cell lines, where we do not know the organism per se, but only informations about it (taxon it belonged to, age, gender, etc). This could be another property, if it seems useful.TiagoLubiana (talk) 18:28, 20 May 2020 (UTC)
    • After thinking about it a bit more I changed the name to derived from organism as I see no reason to deviate from Cell Line Ontology. I don't think we should allow individuals as values but only instance of (P31) of taxon and an item like male animal will still subclass taxon in our system (maybe we can find a qualifier for the individual). I   Support it in that state. ChristianKl❫ 18:45, 20 May 2020 (UTC)
      • @ChristianKl: Hello, thanks for seeing value in the proposal. I prefer to have it as derived from organism than not having it all. For me, "Homo sapiens" is not an organism, but a a taxon. Henrietta Lacks (Q1647793) would be an organism. CLO is a good reference, but I disagree with their wording on this instance. I believe it is an opportunity for Wikidata to be precise, instead of relying on a less-than-optimal description. But as I said before, derived from organism is okay for me too, I just wanted to point these things out. TiagoLubiana (talk) 01:22, 24 May 2020 (UTC)
        • @TiagoLubiana: As far as I understand Cell Line Ontology they chose their wording because they want to be able to state that a given cell not only comes from a Homo Sapiens but in the case of Henrietta Lacks "female homo sapiens". "Female homo sapiens" inturn isn't a taxon in the way the term taxon is normally used in biology. If databases follow the Cell Line Ontology it would be a problem for us to import from their database into a more narrow property.
          It's worth noting that description and name aren't the same thing. derived from organism is a name and not a description. It's useful to make names relatively short and put extra information into the description.
          There's the old Xkcd comic about introducing new standards. Databases interoperatility is a lot easier when different databases use the same term and Wikidata is far from getting other biology databases to adept our naming conventions. While I'm more open to doing original research then EnWiki, original research should still be limited to the cases where it's necessary on Wikidata and here it isn't.
          If we do want to highlite the distinction between classes, I would be okay with derived from organism type. That's still near enough to the Cell Line Ontology that it should be able to be used by researchers who are used to the Cell Line Ontology with the expecation that it means the same thing but would clarify that Henrietta Lacks (Q1647793) isn't a valid value. ChristianKl❫ 17:57, 24 May 2020 (UTC)
      • Thanks for making your point. I would be okay with derived from organism type too, I think it is a good compromise between precision & interoperability. TiagoLubiana (talk) 22:10, 24 May 2020 (UTC)
    •   Support (Disclaimer: I proposed this property originally. It has been changed before and I support it with the modifications) TiagoLubiana (talk) 01:27, 24 May 2020 (UTC)
    •   Oppose Use (or broaden the scope of) natural product of taxon (P1582). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:21, 14 June 2020 (UTC)
      • @Pigsonthewing: Lab-grown cell lines don't seem "natural" to me. ChristianKl❫ 22:46, 14 June 2020 (UTC)
        • @Pigsonthewing: Thanks for commenting. The problem is that "natural products of taxon" represent products that can be recurrently obtained from several individuals of a taxon. Cell lines are derived from one individual, and once that was done, it can never be obtained again. It is subtle, but semantically different. Broadening scope would be to make it less precise, too. But well, we could compromise and change natural product of taxon (P1582)'s meaning, it would be easier, but way less elegant. TiagoLubiana (talk) 23:44, 14 June 2020 (UTC)
    •   Support but I suggest to also add a way to describe the tissue type this was derived from (eg cervical cancer (Q160105) and cervix (Q666412) for HeLa (Q847482) for example) as this would be quite useful. --Hannes Röst (talk) 21:04, 24 June 2020 (UTC)
    •   Support in the form "derived from organism". Also usually, these cell lines evolve away from the original so they can no longer be considered identical to a ready product of the taxon. --SCIdude (talk) 16:33, 22 August 2020 (UTC)
    •   Comment @SCIdude:@Hannes Röst:@ChristianKl:@Pigsonthewing: I'm currently in a talk of Oliver He, lead developer of the Cell Line Ontology. This property seems to be indeed the correct shortcut for linking a cell line with its source. Each cell line is derived from one (or a handful of) specific individual. It is then immortalized and, as USER:SCIdude mention, they evolve away from the original. It has no taxon per se. It is not found in or a natural product of any other living organism. The individual that was sampled, perhaps decades ago, was from a taxon. Maybe "derived from organism" is misleading, as it can look as if we can create a cell line over and over again. TiagoLubiana (talk) 16:44, 25 September 2020 (UTC)
      • The solution in that case is to use a "point in time" qualifier. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:44, 25 September 2020 (UTC)
      • If I understand right you are concerned about the case where cell-line B is a descendend of cell-line A which was taken from an taxon X. Then it makes sense to say that A is derived and originated from X. On the other hand it might be problematic to say that B is derived from X while it makes sense to say it orginated from X. Is that your issue? Given that you do talk to Oliver He, what does he think about the issue? ChristianKl❫ 19:28, 25 September 2020 (UTC)
        • @Pigsonthewing: The point in time solution is interesting, but usually we do not have that information. I see value in adding it as a qualifier whenever possible, though, good suggestion. However, not suitable for natural product, it is essentially different and that would be hacky, in my opinion. Not a natural product, and not from a taxon, but from one (or a defined set) of individuals, one time. TiagoLubiana (talk) 20:29, 29 October 2020 (UTC)
        • @ChristianKl: I think I was not clear enough, then, sorry, that is not quite my issue. Any cell line is derived once and only once from an individual. Both A and B are derived from an individual of a taxon, B has just further drifted away, and I do not see a issue on that. The problem is more one of time, as I see it. The cell line was derived from one individual of a taxon, but cannot be derived ever again. TiagoLubiana (talk) 20:29, 29 October 2020 (UTC)
          • The phrase "derived from" doesn't look to me like it implies that it's possible to derive it again. ChristianKl❫ 13:23, 30 October 2020 (UTC)
            • @ChristianKl: I think it leaves room for ambiguity. It can be read as "once derived from" which indeed does not imply that it can be derived again. It could be read also, though, as "can be derived from". found in taxon (P703) has a similar issue too, but I guess that it generally means that e.g. a gene is expected to be found in multiple (likely any) individual of a taxon. It kind of conceals an expectation, something like "commonly found in". Maybe "once derived from taxon" is good enough, what do you think? --TiagoLubiana (talk) 16:49, 8 November 2020 (UTC)
              • It happens frequently that a label has some ambiguity. We have description to clear up the ambiguity that comes from words used in the label. ChristianKl❫ 18:27, 8 November 2020 (UTC)
                • Okay, fair enough, the description has this purpose, I'm convinced. Should I change the proposal to "derived from" or would you prefer to do it yourself? Thanks for the discussion, by the way. --TiagoLubiana (talk) 14:47, 17 November 2020 (UTC)
                  • @TiagoLubiana: The proposal is at the moment at "derived from organism type". I think the current desciption could be improved to make it more clear. Do you want ot take a stab at it? ChristianKl❫ 16:03, 17 November 2020 (UTC)

    transitive overEdit

       Under discussion
    Descriptionif an item X has a statement with item Y of the relation of the object, any statement with the subject's relation on Y also applies to X
    Data typeProperty
    Example 1instance of (P31)subclass of (P279)
    Example 2part of (P361)part of (P361)
    Example 3anatomical location (P927)anatomical location (P927)

    MotivationEdit

    We lack currently a good way to model transitivity. ChristianKl❫ 12:11, 23 May 2020 (UTC)

    DiscussionEdit

    ChristianKl
    ArthurPSmith
    d1g
    JakobVoss
    Jura
    Jsamwrites
    MisterSynergy
    Salgo60
    Harshrathod50
    Wildly boy
    ZI Jony
    Ederporto
    99of9
    Danrok
    Eihel
    Emw
    Fralambert
    GZWDer
    Ivan A. Krestinin
    Jonathan Groß
    Joshbaumgartner
    Kolja21
    Kristbaum
    MSGJ
    Mattflaschen
    MichaelSchoenitzer
    Nightwish62
    Pablo Busatto
    Paperoastro
    PinkAmpersand
    Srittau
    Thierry Caro
    Tobias1984
    Vennor
    Yellowcard
    Ivanhercaz
    DannyS712
    Tinker Bell
    Bodhisattwa
    Iwan.Aucamp
    Cunme
    NAH
    Gnoeee
    The-erinaceous-one


      Notified participants of WikiProject Properties ChristianKl❫ 12:11, 23 May 2020 (UTC)

    approval of subjectEdit

       Under discussion
    Descriptionused as reference; url of page where the subject of the statement expresses that they want this information to be stored in Wikidata
    Data typeURL
    Example 1MISSING
    Example 2Gereon Kalkuhl (Q64555761) e-mail address (P968) XY (This property as reference) https://www.wikidata.org/wiki/Topic:Vmx703njx7vch68w
    Example 3MISSING

    MotivationEdit

    For some privacy relevant statements it's useful to be able to store explicit permission of the subject of an item that we store the information. ChristianKl❫ 12:02, 24 May 2020 (UTC)

    DiscussionEdit

    •   Support: sounds indeed useful. Nomen ad hoc (talk) 18:35, 24 May 2020 (UTC).
    •   Comment I agree that this is a worthwhile question, but wonder if this couldn't be accomplished by using the talk page (since such authorization can also, in principle, be retracted). I also wonder if there's any way to have the main label from the item page appear on the talk page (and in watchlists). I've had discussions about whether or not ethnicity/religous tagging is appropriate on en.wp before, and am a bit concerned about the gotcha' logic used to say that "if you complain about being categorized as an X on Wikipedia (religion/ethnicity)" you will be so categorized if you say you are a non-observant X. (cf. this BLP/N thread). SashiRolls (talk) 18:39, 24 May 2020 (UTC)
      • There are two separate issues: (1) What should our Living People-policy be? (2) How should we store information about approval. This discussion is supposed to be about (2). I think I will soon start another RfC to amend the Living People-policy to add another status for cases like phone numbers and email addresses. ChristianKl❫ 19:20, 24 May 2020 (UTC)
        • Yes, in the original discussion you link it was suggested this be done on the talk page. What is the advantage of encoding this as a queryable predicate? Would it be an obligatory qualifier on say, phone number, twitter ID, ethnicity, religion, etc.? And for the larger question, is the permission (whether on the TP or encoded into the predicates of the item) reversible/oversightable? SashiRolls (talk) 19:32, 24 May 2020 (UTC)

    ChristianKl
    ArthurPSmith
    d1g
    JakobVoss
    Jura
    Jsamwrites
    MisterSynergy
    Salgo60
    Harshrathod50
    Wildly boy
    ZI Jony
    Ederporto
    99of9
    Danrok
    Eihel
    Emw
    Fralambert
    GZWDer
    Ivan A. Krestinin
    Jonathan Groß
    Joshbaumgartner
    Kolja21
    Kristbaum
    MSGJ
    Mattflaschen
    MichaelSchoenitzer
    Nightwish62
    Pablo Busatto
    Paperoastro
    PinkAmpersand
    Srittau
    Thierry Caro
    Tobias1984
    Vennor
    Yellowcard
    Ivanhercaz
    DannyS712
    Tinker Bell
    Bodhisattwa
    Iwan.Aucamp
    Cunme
    NAH
    Gnoeee
    The-erinaceous-one


      Notified participants of WikiProject Properties ChristianKl❫ 19:21, 24 May 2020 (UTC)

    I do have a deeper problem: Since Wikidata is in CC-0, the data may be reused by third-party service. I think we should somehow indicate whether the user agree the data to be copied to or reused in arbitrary third-party websites (which also includes those not in good proposes). At least not Evil is not what CC-0 intended.--GZWDer (talk) 19:26, 24 May 2020 (UTC)
    Therefore I think we should have a dedicated system to record consents and non-consents. If someone consents to publish private information they should explicitly agree for any reuse of 3rd-party (and conversely, Wikidata may include private information with a consent in third-party website if such website is endorsed by consensus. But what about conflicting statement, viz. Someone do agree to publish private information in another website but not in Wikidata, and data may be imported from that website to Wikidata.)--GZWDer (talk) 19:33, 24 May 2020 (UTC)
    I won't pretend to understand this, maybe you will (understand it). (prior art?) SashiRolls (talk) 20:56, 24 May 2020 (UTC)
    Second thought: I may support this but I do not think this should be the primary way to register approval or consent. Problems are 1. It is not easy to check whether the approval is authentic and 2. The value may be easily distorted. I think the better approach is signed statements.--GZWDer (talk) 19:40, 25 May 2020 (UTC)

    Non volatile storage capacityEdit

       Under discussion
    Descriptiontotal capacity of a type of memory used in electronic devices
    Data typeQuantity
    Allowed unitsyottabyte (Q79752), zettabyte (Q79747), exabyte (Q79745), petabyte (Q79744), terabyte (Q79741), gigabyte (Q79738), megabyte (Q79735), kilobyte (Q79726), byte (Q8799), bit (Q8805), kibibyte (Q79756), mebibyte (Q79758), gibibyte (Q79765), tebibyte (Q79769), pebibyte (Q79774), exbibyte (Q79777), zebibyte (Q79779), yobibyte (Q79781),
    Example 1BeagleBone Green (Q95689317) : has part (P527): Embedded MultiMediaCard (Q11054432): Qualifier: Non volatile storage capacity: 4GB
    Example 2ThinkPad X200 (Q51954707): has part (P527): hard disk drive (Q4439): Qualifier: Non volatile storage capacity: 160GB, has part (P527): hard disk drive (Q4439): Qualifier: Non volatile storage capacity: 250GB
    Example 3W25X64 (Q95770455): Qualifier: Non volatile storage capacity: 8192 KiB
    Example 4floppy disk (Q5293): Qualifier: Non volatile storage capacity: 1,440 kilobyte, 1,200 kilobyte , etc.
    Planned useConvert what I can to use non volatile storage capacity when it's used both for RAM and storage like iPhone 8 Plus (Q39598190), ThinkPad X200 (Q51954707), etc, and where I'm sure that the device doesn't have 160G of RAM but instead 160G of storage, and start adding it to device I know about like the BeagleBone Green (Q95689317) which has a 4GB eMMC storage.
    Expected completenesseventually complete, (might be approximate for formats like DVD9 or CDR 60 or CDR 90)
    See alsomemory capacity (P2928)

    MotivationEdit

      Comment The reason for this is because memory capacity (P2928) has been renamed. --Haansn08 (talk) 10:48, 5 June 2020 (UTC)
    • There is no way to indicate how big is some storage (eMMC, HDD, etc)
    • Having that information is very useful in case of soldered storage like eMMC.
    • The previous attempt used ROM in the name and was rejected only because of that.
    GNUtoo (talk) 05:16, 30 May 2020 (UTC)
    

    DiscussionEdit

    While it could also work in theory, I'm not comfortable with a single property as I think it's prone to confusion in practice:
    • The iPhone 7 (Q26831164) used the same property for the RAM and the storage, without expliciting which component stores that data. The people that adds such information do not necessarily know the type of the component (NAND, eMMC, eSD, etc) and in some cases it may not be possible to know (historical computers that have been destroyed, fictitious computers that comes from science fiction, etc).
    • There is a limited depth in properties of properties. For instance a GT-I9300 (Q83637336) has an eMMC that is well known due to bugs affecting its firmware. That eMMC is like a computer with its own CPU (which runs ARM instructions if I recall well), and most probably has a cache and some RAM. SSD and HDD also have a processor, and some RAM.
    GNUtoo (talk) 23:49, 3 June 2020 (UTC)
    If absolutely nothing about the hardware is known one could use
    For GT-I9300 (Q83637336):
    --Haansn08 (talk) 20:28, 4 June 2020 (UTC)
    Thanks. Now that we know it can work in theory, my remaining concern is if people will always take an extra step to think about how to do it and really do it this way. Do you have any idea how that could work in practice? Could that concern really be an issue in practice? Are there bots or other ways to warn people or to help people doing the extra steps? And do you have any idea of the downsides of the approach I proposed? or the advantages of your approach? Does your approach enable more advanced querries? GNUtoo (talk) 22:25, 4 June 2020 (UTC)
    I think having more general properties is of advantage. I do see why one would want to use the properties non-volatile storage capacity and volatile storage capacity on say a smartphone model. But this distinction really comes from the different components built into the phone, so I think it's also natural to use applies to part (P518). Probably the best method we have to stop people from messing things up are property constraints, for example, to require an applies to part (P518) seperator if multiple storage capacity values are present.
    Other statements could be
    Montecito (Q864328) storage capacity 24 MB applies to part (P518) L3 cache (Q28972917)
    instead of creating a L3 cache size property. We also know the statement refers to volatile memory, because L3 cache (Q28972917) subclass of (P279) volatile memory (Q496533).
    --Haansn08 (talk) 10:14, 5 June 2020 (UTC)
    This could work. What do you think of using memory capacity. Also in that case we might want to require applies to part (P518) by default, always, and not just if there are multiple memory capacity values. Otherwise people could only add one memory capacity, and in that case we wound't be able to distinguish between RAM and storage devices. If a device has a memory capacity of 4GiB, I won't be able to know if it's the RAM or eMMC. My next question would be how your proposal could be implemented? I don't know how to do that. Also I don't have the use case right now, but it might be interesting to support virtual storage (like 2 SSD of 500G for instance), but there is probably a trick for that with memory capacity that would applies to part (P518) to the whole device or something like that. GNUtoo (talk) 05:43, 8 July 2020 (UTC)
      Comment I just learned the property memory capacity (P2928) was storage capacity originally, but has been renamed without discussion (as far as I can tell). I have reverted this change for now. --Haansn08 (talk) 10:55, 5 June 2020 (UTC)

    Tobias1984
    Emw
    Zuphilip
    Danrok
    Bene*
    콩가루
    TomT0m
    DrSauron
    Ruud Koot
    Andreasburmeister
    Ilya
    Toto256
    MichaelSchoenitzer
    Metamorforme42
    Pixeldomain
    User:YULdigitalpreservation
    Dipsode87
    Daniel Mietchen
    Jsamwrites
    Tinker Bell
    FabC
    Jasc PL
    putnik
    Dhx1
    Tris T7
    Peb Aryan
    lore.mazza004
    Rc1959
    Premeditated
    Iwan.Aucamp
    LiberatorG
    Primhill.Computers
    FWVH (passionné d'informatique et d'électronique)
    94rain
    So9q
    Adrijaned
    Sylvain Leroux
    SM5POR
    Haansn08
      Notified participants of WikiProject Informatics

    Rationale for the ping: General computer hardware

    floor areaEdit

       Under discussion
    Descriptionthe area of the floor of a building
    Data typeQuantity
    Domainarchitectural structure (Q811979)
    Allowed unitssquare metre (Q25343)
    Example 1Q96278337 → 12 square metre (Q25343)
    Example 2Palace of Versailles (Q2946) → 63154 square metre (Q25343) [11]
    Example 3MISSING
    Planned usedescribing lean-tos
    See alsoWikidata:Property_proposal/sleeping_capacity Wikidata:Property_proposal/floor_material

    MotivationEdit

    This is less subjective than sleeping capacity. Maybe this is superfluous when we can add area -> 12m2 -> applies to part -> floor --So9q (talk) 14:56, 14 June 2020 (UTC)

    This is useful when I'm adding campsites with lean-to shelters to describe the shelters floorsize without having to create a new part-of item just for the lean-to only to describe the area of the floor.--So9q (talk) 14:07, 17 June 2020 (UTC)

    DiscussionEdit

    It's the same. It's not unhindered floor space, besides unhindered is a hard to define because you can sleep with legs under a table/bench quite easily so I abandoned that and instead model as benched lean-tos. The data consumers will have no way of determining whether you can sleep in the benched lean-to though (short of having an AI a foto from the front).--So9q (talk) 14:11, 17 June 2020 (UTC)
    • For what it's worth, we only have about three items that use "determination method: floor area" (query), so it looks like "area" isn't really being used for this purpose. I would support this if it's clear that it's able to be used for all kinds of floor area, not just the context of sleeping areas in shelters? Andrew Gray (talk) 22:58, 17 June 2020 (UTC)
    • Yes it is for all kinds. --So9q (talk) 21:10, 18 June 2020 (UTC)
    •   Oppose Should we follow the same criteria for every sizing dimension ? For instance, Q12514#P2049 or Q44991996#P2048. I don't think so. Regarding area, you may use Q9188#P2046 formua, too. A good use of qualifiers reduces the number of ultra-specific properties. Amadalvarez (talk) 11:20, 4 September 2020 (UTC)
    •   Support Could give a better discrimination with area (P2046). --Fralambert (talk) 22:10, 26 September 2020 (UTC)

    is exception to constraintEdit

       Under discussion

    MotivationEdit

    At the moment we have plenty of constraints with a lot of violations. A good portion of those constraint violations are justified. For many properties the amount of valid constraint violations is too large to list them all on the property in the constraint section. If we would have a way to tag the valid constraint violations it will be easier to spot the constraint violations that we care about and based on which we should take actions to rectify them. Lucas Werkmeister (WMDE)
    Jarekt - mostly interested in properties related to Commons
    MisterSynergy
    John Samuel
    Sannita
    Yair rand
    Jon Harald Søby
    Pasleim
    Jura
    PKM
    ChristianKl
    Sjoerddebruin
    Salgo60
    Fralambert
    Manu1400
    Was a bee
    Malore
    Ivanhercaz
    Peter F. Patel-Schneider
    Pizza1016
    Ogoorcs
    ZI Jony
    Eihel
    cdo256
      Notified participants of WikiProject property constraints ChristianKl❫ 13:37, 18 June 2020 (UTC)

    DiscussionEdit

    I don't think this is the right solution, as a property may have multiple constraints of the same type and currently it is not possible to refer to a specific statement. See phab:T236295 as a proposal to extand Wikibase data model.--GZWDer (talk) 13:46, 18 June 2020 (UTC)
    @GZWDer: Can you give examples where a property has multiple constraints of the same type and it would be a problem to mark it as an exception of one of the constraints and not the other? ChristianKl❫ 14:24, 18 June 2020 (UTC)
    @ChristianKl: See Property:P18.--GZWDer (talk) 15:19, 18 June 2020 (UTC)
    @GZWDer: image (P18) indeed has multiple instances of the formatter constraint. I however don't see any cases where it's desireable to declare an expection to one of them and not the others. ChristianKl❫ 15:23, 18 June 2020 (UTC)
      Weak oppose; it seems that we should rather improve the constraint definition itself, e.g. by using a single best value constraint (Q52060874) instead of single value constraint (Q19474404). Managing this *in items* does not seem to be a good idea to me. ---MisterSynergy (talk) 12:28, 19 June 2020 (UTC)
    @MisterSynergy: Using single best value constraint (Q52060874) more widely does help with some problems, but there's currently no equivalent for distinct values constraint (Q21502410). ChristianKl❫ 22:51, 19 June 2020 (UTC)
    A separator (P4155) could help to solve such situations much better than just an exception marker. —MisterSynergy (talk) 22:56, 19 June 2020 (UTC)
    The description of separator (P4155) suggests that it's only for single value constraints. Does it work for more then just that constraint? If so, it would likely be good to update the property description. ChristianKl❫ 12:00, 20 June 2020 (UTC)
    Well yes, it does not seem to work for distinct value constraints. We do have a couple of such definitions, which made me think that it does work. Needs to be cleaned up, I guess.
    Yet, there can (and should) be other means to solve these cases. Simply stating that this claim "is exception to (some) constraint" is not very meaningful. For distinct value constraints, one could perhaps better simply use identifier shared with (P4070) as a generic qualifier that suppresses constraint violations. ---MisterSynergy (talk) 08:08, 22 June 2020 (UTC)
    Not, all constraints are mandatory. If you for example take the format constraint (Q21502404) on image (P18) there are plenty of exceptions that are fine. It seems noting those on the represented items is cleaner then noting them in the property.
    Not all distinct value are identifiers and identifier shared with (P4070) doesn't even indicate that the value is a valid exception. ChristianKl❫ 11:10, 22 June 2020 (UTC)
    @Lucas Werkmeister (WMDE): What do you think about making separator (P4155) also work for distinct values? ChristianKl❫ 11:10, 22 June 2020 (UTC)
    If it does not work at the moment, I am not sure whether we should make it work. There is definitely need to handle "unfixable" constraint violations better, but please let's not do it with a unsemantic one like you propose here. ---MisterSynergy (talk) 11:34, 22 June 2020 (UTC)
    @ChristianKl, MisterSynergy: It would probably be possible to support separator (P4155) for distinct values constraint (Q21502410), though it may make the underlying SPARQL query less efficient. I haven’t yet made up my mind whether I like the suggestion or not. --Lucas Werkmeister (WMDE) (talk) 13:05, 23 June 2020 (UTC)
    • I think that could be useful for some constraints/combinations, e.g. distinct values constraint (Q21502410) on taxon name (P225). I wouldn't apply in general, especially not to the sample currently given in the proposal (category for people born here (P1464) → single value constraint (Q19474404)). --- Jura 08:23, 27 June 2020 (UTC)

    suspected external errorEdit

       Under discussion
    Description(use as qualifier) the database towards which this external identifier links made the suspected error
    Data typeItem
    Example 1South America (Q18) VIAF ID (P214) 258766259 → multiple values for exact match (Q96473051)
    Example 2South America (Q18) VIAF ID (P214) 170506329 → multiple values for exact match (Q96473051)
    Example 3MISSING

    MotivationEdit

    Currently, there are many constraint violations in properties like VIAF ID (P214) for single value constraint (Q19474404) and distinct values constraint (Q21502410). Some of them are because of errors within Wikidata and some others are because of errors in VIAF ID (P214). If we would tag the values that are errors in the external database it will be a lot easier for the external database to fix their errors then when they get a list that both contains our errors and theirs. Using this as a qualifier has the additional benefit that we can create queries that list all single value constraint (Q19474404) for VIAF ID (P214) that don't have external error which makes it easier to work with the list of errors because then we can either fix the error on our side or mark the item as an external error and not leave items in our list without being able to take an action that clears the item from our worklist. ChristianKl❫ 13:26, 20 June 2020 (UTC)

    DiscussionEdit

    •   Oppose this info is not relevant to display inside entities, there are constraint violations pages, and other query ways to find out errors Germartin1 (talk) 16:50, 20 June 2020 (UTC)
    • Constraint violation pages don't classify errors and as such mix errors within Wikidata with errors made in external databases. Declaring a statement as an external error is a value judgment that you don't get via a query if you have no way to input the data. ChristianKl❫ 17:30, 20 June 2020 (UTC)
    •   Comment I think I can see the utility of this; however, can we always be certain that something is an error of this sort in an external db? What if there really are two distinct entities that look like the same thing but are really different somehow, so it's not actually an error? How do we tell? ArthurPSmith (talk) 13:24, 22 June 2020 (UTC)
    • @ArthurPSmith: If we have a list of things we believe to be errors in an external database that allows us to talk to the people who make the external database about those things we believe to be errors. To the extend that it turns out that certain statements aren't errors we can remove the claims and see what needs to be done on our side.
    Talking might either mean contacting them or having them take part in Wikidata directly. ChristianKl❫ 18:47, 22 June 2020 (UTC)
    Hmm, maybe a less accusatory property name is needed then? "suspect error" maybe? ArthurPSmith (talk) 20:33, 22 June 2020 (UTC)
    @ArthurPSmith: I changed it to "suspected external error". ChristianKl❫ 18:45, 23 June 2020 (UTC)
    •   Comment A general question to ask oneself: is it an external error or an exception to a constraint defined at Wikidata?
      VIAF as a sample has another issue: is it really productive to look at it and try to handle them like standard external identifiers? VIAF clusters are reorganization reguarly, also based on Wikidata.
      Thirdly, VIAF clusters beyond items for people don't necessarily work that well. Some might say the same about Wikidata though. --- Jura 10:01, 23 June 2020 (UTC)
    @Jura1: This property is designed for those things that are external errors and not just expections to a constraint in Wikidata. The fact that VIAF does reorganization regularly raises hope that they are willing to take our listing of their errors into account when they reorganize. Especially if they can easily get a list of what we consider to be errors in VIAF that excludes the cases where we might have a constraint violation that's not an error on their side. ChristianKl❫ 12:03, 23 June 2020 (UTC)
    • They do that already, at least for people. There is no need for any additional action than adding the additional identifiers to the item. Besides, I don't think the single value constraint on P214 should be read literally. --- Jura 12:11, 23 June 2020 (UTC)
    • While I'm aware of an example where they did it for people I'm not aware of a source that shows that it happens at scale. If there's such a source I would be happy to see it. It would be quite useful in the discussions with dewiki about reusing our IDs.
    Currently, there seem to be plenty of unfixed errors. When I looked at both the single value constraints and distinct value constraints of VIAF ID (P214) I found plenty of erros on our part and on VIAFs part. Currently it seems to be very cumbersome to work through the list of constraint violations because while some errors can be fixed others can't. As a result we don't get data cleanup. Unfortunately, we have a few people who add additional data based on existing VIAF identifiers and as a result the errors accumulate. ChristianKl❫ 18:45, 23 June 2020 (UTC)
    • You could follow Krbot's updates for merged VIAF clusters.
      I doubt it's worth looking into VIAF clusters beyond Q5-items. --- Jura 13:50, 25 June 2020 (UTC)
    •   Support I think this is worth having. ArthurPSmith (talk) 19:18, 24 June 2020 (UTC)
    •   Comment this seems useful, and I agree strongly with the overall idea. But how is this different from the currently practiced approach for example here Peter Müller (Q62333) using reason for deprecation (P2241) together with conflation (Q14946528) or duplicate entry (Q1263068). It seems to me this would achieve the same goals, I assume your approach does not rely on deprecation and allows better modelling? --Hannes Röst (talk) 21:44, 24 June 2020 (UTC)
      • @Hannes Röst: I think the key difference is that this property can be used where we don't deprecated values like example where there are two identifiers for the same person.
        •   Comment it would be good to see some samples. I don't think the one about Q18 is that useful. --- Jura 18:41, 26 June 2020 (UTC)
        •   Comment I agree it would be helpful to see some examples of (i) two external identifiers for the same item and (ii) a single conflated identifier for two or more items. --Hannes Röst (talk) 19:45, 26 June 2020 (UTC)

    sorting weightEdit

       Under discussion
    Descriptionwhen listing multiple properties, properties with a higher sorting weight are supposed to be shown before properties with lower sorting weight
    Data typeNumber (not available yet)
    Example 1instance of (P31) → 100000
    Example 2subclass of (P279) → 9999
    Example 3occupation (P106) → 1000

    MotivationEdit

    We have currently multiple cases where properties have to be sorted. When displaying the normal properties and external-id properties on a page they have to be sorted.

    When suggesting properties to the user according to properties for this type (P1963) there's a need for sorting. The proposed property can be used as a qualifer to help sort that list.

    For qualifiers we might have in future a solution that uses sources the suggested qualifiers from qualifier for this property (P8379) where the sort order can also be specified with this property.

    ChristianKl
    ArthurPSmith
    d1g
    JakobVoss
    Jura
    Jsamwrites
    MisterSynergy
    Salgo60
    Harshrathod50
    Wildly boy
    ZI Jony
    Ederporto
    99of9
    Danrok
    Eihel
    Emw
    Fralambert
    GZWDer
    Ivan A. Krestinin
    Jonathan Groß
    Joshbaumgartner
    Kolja21
    Kristbaum
    MSGJ
    Mattflaschen
    MichaelSchoenitzer
    Nightwish62
    Pablo Busatto
    Paperoastro
    PinkAmpersand
    Srittau
    Thierry Caro
    Tobias1984
    Vennor
    Yellowcard
    Ivanhercaz
    DannyS712
    Tinker Bell
    Bodhisattwa
    Iwan.Aucamp
    Cunme
    NAH
    Gnoeee
    The-erinaceous-one


      Notified participants of WikiProject Properties ChristianKl❫ 10:40, 27 June 2020 (UTC)

    DiscussionEdit

    •   Support seems reasonable though I guess it can be a bit controversial as to what the right value should be. Iwan.Aucamp (talk) 12:19, 27 June 2020 (UTC)
    • Couldn't we just use MediaWiki:Wikibase-SortedProperties for this? Having two different sorting schemes feels like it's going to get complicated. Andrew Gray (talk) 14:11, 27 June 2020 (UTC)
    • I don't think Wikibase-SortedProperties is a good solution for multiple reasons and that it would be best to deprecate it sooner or later.
    Having the data within properties makes it easier to discover how the sorting works for Wikidata users.
    We will have federated Wikibase properties in the future. Having a concept of sorting weight allows sorting of properties from different Wikibases in a consistent manner without having to define all the sorting in one Wikibase.
    Finally, I want a way that can be set more context dependent on properties for this type (P1963) and qualifier for this property (P8379). ChristianKl❫ 18:08, 27 June 2020 (UTC)
    I think there's an argument to be made for centralised sorting being better - with values on a per-property basis, it's much harder to group similar properties together, ensure they are kept in a consistent order, and so on. It feels to me like it would be more difficult to get a broad overview this way around, though I take your point about federated properties. But to be honest I don't really have a strong opinion, whatever works is fine. :)
    I'm still not clear how this property would work, though - is the idea we create the property now and then develop a sorting mechanism which would use it? Andrew Gray (talk) 18:48, 30 June 2020 (UTC)
    • There is already some sort of "weighted sorting" being done by the Wikibase (?) software when adding properties to items. Does that not suffice? —MisterSynergy (talk) 17:06, 27 June 2020 (UTC)
    The goal is to have a system where it's easier for users to change the sorting oder. ChristianKl❫ 18:09, 27 June 2020 (UTC)
    The community managed approach does not work particularly well with MediaWiki:Wikibase-SortedProperties, as opposed to the built-in suggestion mechanism. As far as I understand, the software sort of anticipates the best order of suggested properties based on the data present in an item. This seems much more sophisticated than a static list, where users might even try to push their favorite properties to the front. —MisterSynergy (talk) 18:56, 27 June 2020 (UTC)
    It feels to me like there's some issue with it being intransparent of how the system actually works. Do you know whether it's documented somehow?
    I think it would be great if it would both be documented and also possible for humans to decide what the best order happens to be. ChristianKl❫ 20:27, 27 June 2020 (UTC)
    It's called property suggester (Q86989962) (related: Extension:PropertySuggester (Q30101250), Extension:WikidataEntitySuggester (Q21679299), Help:Suggesters and selectors#Property suggester, …). You can use these items to search for more documentation on mediawiki.org or phabricator—I am not aware whether there is enough of it, however. —MisterSynergy (talk) 20:41, 27 June 2020 (UTC)
    • Is this intended to apply to identifiers too? In general I'd like to see further information about how these priorities should be decided. --99of9 (talk) 02:16, 28 June 2020 (UTC)
    Yes, the idea would be that it can also be used to sort identifiers. ChristianKl❫ 08:55, 30 June 2020 (UTC)
    The idea is to specify semantics about how sorting priorities can be expressed here. Later, when there are disagreements about how to decide the priority in a certain domain we can create policy to solve that. ChristianKl❫ 17:11, 20 November 2020 (UTC)

    number of downloadsEdit

       Under discussion
    Descriptionnumber of downloads of times this application or creative work have been downloaded
    Data typeQuantity
    Domainitems that uses distribution format (P437)digital download (Q54820071)
    Example 1Forgotten Hope (Q24496) > Number of downloads > 250 > distributed by (P750) > Mod DB (Q2983178) > point in time (P585) > current date
    Example 2Desert Combat (Q32225) > Number of downloads > 89,548 > distributed by (P750) > Mod DB (Q2983178) > point in time (P585) > current date
    Example 3SCP: Chamberz (Q79053436) > Number of downloads > 500,000 nature of statement (P5102) > greater than (Q47035128) > distributed by (P750) > Google Play (Q79576) > point in time (P585) > current date (27 february 2020)

    ΛΧΣ21 Vacation9 John F. Lewis (talk) Bene* talk #Reaper (talk) Josve05a (talk) Chris Mason (talk) FunPika Arthena (talk) Wangxuan8331800 (talk) Sjoerd de Bruin (talk) Nicereddy (talk) Syum90 (talk) DrakeCaiman (talk) --George (Talk · Contribs · CentralAuth · Log) Andreasburmeister (talk) Danrok (talk) 18:20, 30 October 2015 (UTC) Macrike (talk) Dispenser (talk) 16:56, 7 July 2017 (UTC) --Zache (talk) 13:34, 12 July 2017 (UTC) SharkD  Talk  06:41, 9 November 2017 (UTC) ZebaX2010 (talk) 00:49, 21 November 2017 (UTC) Sight Contamination (talk) Lewis Hulbert (talk) 20:26, 13 December 2017 (UTC) Jean-Fred (talk) 10:48, 28 February 2018 (UTC) Santer (talk) Cloaker416 (talk) 22:18, 12 June 2018 (UTC) Rampagingcarrot (talk) 19:57, 28 June 2018 (UTC) Diggr (talk) 08:07, 3 July 2018 (UTC) Harsh Rathod Poke me! 09:42, 7 July 2018 (UTC) Kirilloparma (talk) 00:30, 5 August 2018 (UTC) Sir Lothar (talk) 10:10, 10 August 2018 (UTC) Cwf97 (talk) 14:33, 22 October 2018 (UTC) Esteban16 (talk) 00:08, 27 October 2018 (UTC) Peterchanws Brasig Le Yota de Mars YotaMoteuchi (talk) 08:09, 22 May 2019 (UTC) Coloradohusky CptViraj BugWarp ʂɤɲ User:Nw520 Cynde Moya Dexxor Floyd-out CadetPatrick AntisocialRyan   Notified participants of WikiProject Video games--Trade (talk) 11:28, 1 July 2020 (UTC)

    DiscussionEdit

      Comment This should not be limited to video game (Q7889) and software (Q7397). It should only require a statement distribution format (P437)digital download (Q54820071). See

    SELECT ?item ?itemLabel WHERE {
      ?item wdt:P437 wd:Q54820071.
      SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en". }
      ?item wdt:P31 ?inst.
      FILTER(?inst != wd:Q7889 && ?inst != wd:Q7397)
    }
    

    All items with this statement that are not an instance of video game or software.Dexxor (talk) 18:25, 1 July 2020 (UTC)

    Better now? @Dexxor:--Trade (talk) 19:30, 2 July 2020 (UTC)
    Yes. —Dexxor (talk) 10:21, 3 July 2020 (UTC)

      Comment Concerning your examples: where did you find the number of downloads on Mod DB? 250 also seems way too small for Forgotten Hope (Q24496). The only other store I know of that tracks the number of downloads is Google Play (Q79576). Maybe add an Android app as the third example. —Dexxor (talk) 10:19, 3 July 2020 (UTC)

    * 'where did you find the number of downloads on Mod DB? 250 also seems way too small for Forgotten Hope (Q24496)' Here
    The downloads page for Forgotten Hopes lists multiple files with largely varying download numbers. Which one to choose? Maybe the sum of all download numbers as stated in “File statistics”? However, this number cannot really be used to compare mods because mods with many files naturally have a larger total number of downloads. I think that the proposed property should only be used as a qualifier on software version identifier (P348) (when the data item is a mod from Mod DB). —Dexxor (talk) 12:45, 6 July 2020 (UTC)
    'Which one to choose?' The 'Forgotten Hope v.7 Client' and 'Forgotten Hope 0.7 - FULL [win7]' combined files would be my guess. 'I think that the proposed property should only be used as a qualifier on software version identifier (P348) (when the data item is a mod from Mod DB)' The number of Mod Db items are fairly limited. It should be possibly to figure it out for each of them --Trade (talk) 13:21, 6 July 2020 (UTC)

    Image web linkEdit

    MotivationEdit

    To help source images without putting them into Commons (generally to avoid copyright pb). If there is a P18 in a Q, then that new property should'nt exist. Bouzinac (talk) 07:44, 6 July 2020 (UTC)

    DiscussionEdit

    @Pigsonthewing, Pintoch, Jura1, ديفيد عادل وهبة خليل 2, Strakhov: @Pasleim, ShadessKB, NandanaM: as a participant in this discussion, have you since changed your mind? Pamputt (talk) 21:42, 23 August 2020 (UTC)

      Strong oppose I find it weird to have the same property proposal every few years. (2014,2017, 2018) Nothing has changed in principal since the first proposal in 2014. There is no (legal) use for links to unfree pictures, they are harder to maintain than commons links (URLs change, images go offline) and will therefore require a lot of maintenance while providing no improvement. The proposed property would also violate what I perceive as the philosophy of Wikidata and Wikimedia: Spreading free data and knowledge. It is also not clear which image would be selected. There are a lot of commercial images available for most topics (and a lot of agencies that try to push their content). This might cause edit wars over the value of this property and spam edits/items for (self-)promotion of images. About ½ the RfDs i create are because of SEO-Spam. This property could make the problem of SEO-Spam even bigger. All this has already been explained by other users in previous discussions and still this proposal does not discuss these points of view. Why? If I'd create a proposal, that has already been declined several times, I'd put a lot of effort in disproving previous arguments against the proposal.

    tl;drThis proposal is not practicable, not beneficial and against wikimedia principles -- Dr.üsenfieber (talk) 08:52, 12 September 2020 (UTC)

    •   Initial oppose ask to remove "artwork" on https://www.wikidata.org/wiki/Property_talk:P6500 with the protagonists of the proposal and the creator of this property. —Eihel (talk) 10:22, 12 September 2020 (UTC)
    • The proposal comes back again because there is a need : an URL for non-free use/unclear rights image, not storing the image in itself. So as per your absurd argument, URL links are impossible to maintain (website disappearing, not clear if we are free to consult the website URL, spam, etc etc), thus I'd like to propose the suppression of reference URL (P854). Bouzinac💬✒️💛 10:53, 12 September 2020 (UTC)
    Can you clarify on why this is needed and how the benefits would be bigger then the additional effort? Concerning your straw man: I didn't say that they are impossible to maintain, I said they are harder to maintain then commons-links. Using web-links as sources indeed requires a lot of maintenance effort and will decrease the verifiability of statements if not properly maintained. However, reference URL (P854) is still useful, as it increases the verifiability on a larger scale. Allowing links to proprietary images without any constraints would decrease the overall referential integrity, and I fail to see any benefits from this proposal. -- Dr.üsenfieber (talk) 10:43, 14 September 2020 (UTC)
    I'd say the use would for a reader to be inside, for instance, into that item Q5692098 and the reader wishes to see the image result. As the image https://eclipse.gsfc.nasa.gov/5MCSEmap/-1999--1900/-1980-06-12.gif is not very clear to be licence-free, it would be stored only as a link to the website (if the website show the image to any reader without login, then it's semi-free). Then the reader could confront (within few clicks) and verify information between Wikidata and that website. Obviously, if there is already an image (P18) then, there shouldn't be any image link property. It would thus help, in fine, wikidata data quality...
    Anyway, I'd like to understand the seo-spam links. Could you give an exemple so that I can understand your spam-correcting problem ? Bouzinac💬✒️💛 13:05, 14 September 2020 (UTC)
    As far as I see, your example image is not copyrighted (source, also see Wikipedia). You say that it would increase the data quality in Wikidata, but you didn't write how it would do so. It would sure increase the quantity, but it decreases the reusability and the referential integrity. Can you please make clear, how this would increase the quality? Can you also take up the points that have been made in previous discussions? i.e. How does it relate to our goal of building a free ontology (free as in freedom, not free as in free beer)? How do you plan to guarantee referential integrity?
    Well, I don't remember but I searched and was prevented from downloading NASA stuff, uploading them on Commons. So I might be wrong but I believe(d) these images were unfree. Other examples can be also front cover of newspaper. https://gallica.bnf.fr/ark:/12148/bpt6k250185j.item could have been an image link to document the printed édition of L'Humanité (Q1137404) of 8th April 1904. Gallica is an entirely free library but difficult to download client-side/upload commons/indexing. An image link would help semi-automate that task and populate Wikidata with, for instance, newspaper editions.
    Anyway, about SEO-Spam: e.g. Q99306327. This item has only been created to promote the website and causes workload for the user that requests deletion and for the executing administrator. If we'd allow this property, I'm afraid that there might be more spam from providers of commercial content.--Dr.üsenfieber (talk) 14:30, 14 September 2020 (UTC)
    Althought this item is obviously commercial, other items are commercial too ==> Q131005#P856 has very commercial sites too. I agree this Q99306327 item looks very obscure, but who cares ? I might be naive but no one is obliged to visit its link. Bouzinac💬✒️💛 18:52, 14 September 2020 (UTC)

    numeric IDEdit

       Under discussion
    Descriptionthe stable numeric identifier for an entry on a website, used as qualifier for potentially unstable human-readable values
    Data typeNumber (not available yet)
    Allowed valuesAny positive or negative number
    Example 1Kadim Al Sahir (Q1362223)SoundCloud ID (P3040)72830036 (used as a qualifier)
    Example 2Justin Bieber (Q34086)Genius artist ID (P2373)357 (used as a qualifier)
    Example 3Glenn Greenwald (Q5568842)TED speaker ID (P2611)2081 (used as a qualifier)
    Example 4Signal (Q19718090)Instagram username (P2003)8725236333 (used as a qualifier)
    Planned useEnsure that human-readable identifiers (e.g. usernames/slugs) are still current
    Number of IDs in sourceUsually one, but can be more in rare exceptions.
    Expected completenesseventually complete (Q21873974)
    Robot and gadget jobsBots should be used to initially fetch the numeric ID and update the human-readable username/slug if it changes.

    MotivationEdit

    We use human-readable values (e.g. usernames and slugs) as identifiers. These identifiers are easier to obtain and make it possible to link to the full external website experience. However, those are too often unstable and can change resulting in obsolete statements. We have been trying to solve this issue using website-specific properties such as Genius artist numeric ID (P6351) and Twitter user numeric ID (P6552), but this is limiting and biased towards giant digital monopolies. A more proper approach would be to have a generic property that can be used as a qualifier for any potentially unstable identifier. For example, if the only identifier we have for an account on SoundCloud is the human-readable username (e.g. oum), it will be rendered useless once the username changes and it would be difficult to trace the target. As a solution, we should link both the human-readable identifier and, as a qualifier, the site-specific numeric ID (in the oum example: 553726).OsamaK (talk) 06:57, 7 July 2020 (UTC)

    DiscussionEdit

    •   Comment I think Genius artist numeric ID (P6351) is more consistent with Wikidata's concept for external identifier and its formatter URL. It uses a separate property for the stable identifier. The ideal way would be to qualify that with the username. --- Jura 08:01, 7 July 2020 (UTC)
    @Jura1: I feel if we had to generalize a rule on "human-readable identifiers linked to full-featured website" vs. "stable identifiers accessed via an API or otherwise limited website version", I would choose the former human-friendly version to make contributing far more accessible for users regardless of their technical background. Being a cooperative project, this has to bare an immense value. The stabilizing work should be left to bots.--OsamaK (talk) 08:37, 7 July 2020 (UTC)
    It seems somewhat hard to get Wikibase to change for the above to work.
    If the numeric ones are stable, there isn't much input needed once the bot set it correctly. --- Jura 08:41, 7 July 2020 (UTC)
    What kind of change is referred to here? When it comes to social media identifiers for example, we are already using human-friendly identifiers where ever possible. --OsamaK (talk) 08:47, 7 July 2020 (UTC)
    We try(tried) to use stable identifiers. The above samples can only link in your proposal. --- Jura 09:16, 7 July 2020 (UTC)
    It's true that linking cannot be currently implemented with such a generic property. The workaround would be to have a separate property for each stable website identifier or to redefine the existing properties to refer to stable identifiers instead of the human-friendly ones. Both are not practical and our decision making mechanism in Wikidata would fail to get this task done (would take months if not years). I would accept the down side of giving up linking in exchange of one generic property for stable identifiers.--OsamaK (talk) 10:58, 7 July 2020 (UTC)
    •   Oppose The logic seems backwards here to me. I don't understand why we should prioritise human readable identifiers which are unstable? This is Wikidata - machine readable, structured data. You mention in the motivation that these unstable identifiers become useless as soon as they change, but to me that implies that they are inherently useless as a standalone identifier at all times because with just the unstable identifier alone there is no way to tell if it was ever true/untrue without a stable reference.

      In contrast, with a stable identifier, you know it doesn't change - so you can always access the identifier and check if the subject is correct to know that it always was or wasn't correct. I think it makes more sense to use the stable numeric identifiers (the true identifiers), and capture username data separately using website username (P554). In theory, any relevant human readable string (not a true identifier) can be retrieved by machine via access using the numeric identifier. An extended discussion around this topic also took place at Wikidata:Requests_for_permissions/Bot/SilentSpikeBot. --SilentSpike (talk) 11:35, 10 July 2020 (UTC)
    @SilentSpike, ChristianKl: I see your point. If the stable identifier is easily accessible, it should be adopted. In other cases, however, the logic behind using the human-readable property is to lower the technical bar required to contribute, which is an immensely worthwhile goal. At the end, this is what Wikimedia projects have always been about. Wikidata, specifically, has always been described as "read and edited by both humans and machines." If the baseline was to require people to dig into HTML or some (private?) API, we would only be open for a small minority of contributors. We need anyone to be able to fill-in Twitter or Soundcloud username, with minimal barriers. Sustainability and permanence can be achieved by bots without compromising the mission nor utility.--OsamaK (talk) 12:33, 18 July 2020 (UTC)
    •   Oppose per SilentSpike. ChristianKl❫ 18:22, 16 July 2020 (UTC)
    • I agree we should always have both. Not sure if this is the right way to name or qualify the numeric name/id vs the human-readable id. Is there no other current property that can be used to say "additional ID used by this catalog/site/project"? Sj (talk) 15:22, 17 August 2020 (UTC)
    • I propose to introduce a new datatype. See phab:T260639.--GZWDer (talk) 00:59, 18 August 2020 (UTC)

    booking URLEdit

       Under discussion
    Descriptionofficial URL of the item that allows reservation of a seat, service or ticket related to this item
    Representsbooking (Q64883416)
    Data typeURL
    Example 1Bagatti Valsecchi Museum (Q838986)https://fareharbor.com/embeds/book/museobagattivalsecchi
    Example 2Cinema Arcobaleno (Q37158251)http://www.crea.webtic.it/Default.aspx?sc=5066
    Example 3Principe di Savoia (Q7245128)https://gc.synxis.com/rez.aspx?hotel=60010
    Expected completenessalways incomplete (Q21873886)
    See alsowebsite:booking on OpenStreetMap

    MotivationEdit

    This property could be useful for Wikivoyage so that one could buy tickets or booking a room without looking through the website. If a specific property is already set/could be set (e.g. Booking.com hotel ID (P3607)), it must be used ★ → Airon 90 07:49, 20 July 2020 (UTC)

    DiscussionEdit

    • Mhhh... Isn't it a bit too close to "commercial"/"advertising" ? Bouzinac (talk) 08:30, 20 July 2020 (UTC)
    Airon90 Do not modify the interventions of other contributors, please. —Eihel (talk) 20:01, 28 August 2020 (UTC)
    •   Support. That said, your second example leads me to nowhere and probably needs some fixing. Thierry Caro (talk) 00:30, 21 July 2020 (UTC)
    •   Support Google Maps has this feature. We should have it too. NMaia (talk) 14:17, 22 July 2020 (UTC)
    •   Strong oppose I think this is a bad idea as someone who edits OSM a lot and isn't personally a fan of the website:booking tag or similar website namespace tags. Since booking url's change way to often. Plus, the word "booking" is semi-ambiguous and widely different depending on the culture anyway. Which you really have to watch out for with these types of things. For instance in America we don't really consider buying a ticket to tour an art gallery "booking" something. Whereas, it seems like you do from one of your example links. Also, say you add the property to something like a casino that contains hotel, restaurant, bar, and an event center. It's rather ambiguous as to which one of those the booking url applies to or if it's just the casino. Those kinds of confusions happen all the time in OSM. Which is why the website:booking tag has been around since like 2011, but has never really been adopted. It is kind of commercialish to like Bouzinac said. There's also no end to the possible sub url's once you go there. Everyone knows what an official url is and it's usually pretty easy to get to booking page. So, it's better just to stick to the official url. --Adamant1 (talk) 10:00, 11 August 2020 (UTC)
      @Adamant1:
      • «Since booking url's change way to often». First, citation needed. Second, even official websites change and/or disappear (that is why URL archives exist): should we remove the property official website (P856) because it could change, even «too often»?
      • «Plus, the word "booking" is semi-ambiguous and widely different depending on the culture anyway». I'm Italian and we use the verb "prenotare". If the problem is the label, we can decide which is the best one for this property. You cannot oppose without giving a hint about how to fix this problem.
      • «Also, say you add the property to something like a casino that contains hotel, restaurant, bar, and an event center. It's rather ambiguous as to which one of those the booking url applies to or if it's just the casino» Like in OpenStreetMap you map separately hotel, restaurant, bar and casino, even in Wikidata you create single items which will have their own "booking url"
      • «Everyone knows what an official url is and it's usually pretty easy to get to booking page» Let's delete official blog (P1581), web feed URL (P1019), calendar feed URL (P6818), terms of service URL (P7014), privacy policy URL (P7101) and many other property then. Let's use just official website (P856) and one can get info by looking at the site or its source code.
      --★ → Airon 90 17:22, 28 August 2020 (UTC)
    •   Weak oppose Do Wikidata need to start advertising.? Seems to be not a good idea.-❙❚❚❙❙ GnOeee ❚❙❚❙❙ 14:11, 11 August 2020 (UTC)
    Gnoeee many Wikivoyage already have contact details of this type, IMHO. —Eihel (talk) 10:04, 28 August 2020 (UTC)
    •   Weak support as we have a property for the other url, it might be worth having a generic one. --- Jura 16:33, 16 August 2020 (UTC)
      • Not really a priority for the project. --- Jura 06:01, 4 September 2020 (UTC)
    The proponent finds my changes adequate, but does not change the proposal. In addition, the fields are not filled to the best. I change my opinion. —Eihel (talk) 20:14, 28 August 2020 (UTC)
    @Eihel: I said "When I have spare time I will look for another example in order to replace the first one". Now I had spare time before working again and I found another example to replace the first one.
    What do you mean with "the fields are not filled to the best" and why don't you propose a change? We are working together for Wikidata, not judging one's work in an eternal competition :) I hope you will help me in fill the fields to the best and change your mind again --★ → Airon 90 07:10, 29 August 2020 (UTC)

    @Airon90, Thierry Caro, NMaia:

    •   Question Should the label include "official", possibly with a single value constraint? Or should we allow ticket resellers and scalpers? --- Jura 21:46, 28 August 2020 (UTC)
    @Jura1: For sure this proposal is about the *official* booking URL. I am not sure about single value constraint (I don't like generalizations), maybe we can set this constraint and work on eventual errors. --★ → Airon 90 07:10, 29 August 2020 (UTC)
    • Can we add something in the description so that we only end up the organizer's or accommodation's booking system in the property and not every website that allows to book rooms in a given hotel or anybody that resells tickets they just siffoned out of the main url. --- Jura 10:32, 29 August 2020 (UTC)
    @Jura1: I tried my best by putting "Official" in the sentence. If somebody wants to rephrase the description in order to better transmit the meaning of the proposal is welcome! --★ → Airon 90 12:49, 3 September 2020 (UTC)
    Ok. I changed it slightly. --- Jura 15:55, 3 September 2020 (UTC)

    certified asEdit

       Under discussion
    Descriptionstates that an item has a certain certification
    Representscertification (Q374814)
    Data typeItem
    Domainitem
    Allowed valuesany instance of certification (Q374814) or its subclasses
    Example 1Kastel Koz (Q97716007)Grand Site de France (Q1154112)
    Example 2Bill Gates (Q5284)Microsoft Certified Professional (Q1072814)
    Example 3Klaus Gablenz (Q1744899)Project Management Professional (Q1192593)
    Planned useI plan to assign it to some items, but I am suggesting it primarily because of its general value
    Expected completenessno
    See alsoapproved by (P790)

    MotivationEdit

    I believe this property is missing. There's a number of certifications available on Wikidata, but currently I cannot see how to link any objects that bear this certification. approved by (P790) is the nearest I could find, but I think it's not quite suitable. Suggested English alias: "has certification" If I am overseeing something, please let me know. (Also, I am not quite sure how reference/subject item is meant in this template. Hope I got it right.) -- H005 (talk) 11:42, 27 July 2020 (UTC)

    DiscussionEdit

    How does this relate to relevant qualification (P4968)? ChristianKl❫ 11:06, 31 July 2020 (UTC)

    Thanks for pointing that out, I didn't know about this property. However, I do not think it fits the purpose, as its object is restricted to industries/professions/people - a certification can be applied to anything - and its subject is a profession/skill, and not restricted to certifications. Also, it doesn't really state that someone/-thing has this qualification, it merely states that this is relevant to the object. -- H005 (talk) 08:07, 2 August 2020 (UTC)

    I'd appreciate any further comments/votes. -- H005 (talk) 09:15, 10 August 2020 (UTC)

    would it not make sense to have a property "has certificaction" and then a link to the certification item? BrokenSegue (talk) 23:37, 7 September 2020 (UTC)

    Well, that is actually the proposal, just that you are suggesting a different name. Both names would be fine to me. -- H005 (talk) 10:17, 8 September 2020 (UTC)
    •   Support --Tinker Bell 01:40, 17 September 2020 (UTC)
    • Not ready. BrokenSegue suggested "has certification" and I don't see that this has been rejected the property is ready to be created as "certified as". ChristianKl❫ 19:12, 8 November 2020 (UTC)

    Signal numberEdit

       Under discussion
    Descriptionphone number for this person or organization used by the Signal app for secure communications
    RepresentsSignal (Q19718090)
    Data typeExternal identifier
    Domainproperty
    Allowed values\d{10}
    Example 1Ken Klippenstein (Q97940221)tel:2025101268
    Example 2Q15834986tel:4159420460
    Example 3Muck Rack (Q57500196)tel:2125001883
    Sourcehttps://en.wikipedia.org/wiki/Signal_(software)
    Planned useUse it on Ken Klippenstein (Q97940221)
    See alsophone number (P1329), fax number (P2900), TDD number (P8659)

    MotivationEdit

    Ken Klippenstein offers up his Signal number for submitting tips and leaks, so I wanted to add it to his Wikidata item somehow. QRep2020 (talk) 06:26, 31 July 2020 (UTC)

    edit: The larger motivation here is that we should take advantage of the Wikidata knowledge graph to propagate the means of interacting with journalists, activists, etc. in a safe, end-to-end encrypted fashion. The graph already lists, for instance, the NY Times, yet it does not state how to contact the paper if one wishes to do so securely and secretively. Someone like Ken Klippenstein is urging whistleblowers and the like to reach out to him if they have information the public ought to know and so I think adding a property for editors to use to facilitate such efforts is a small price to pay for a positive social impact at large. QRep2020 (talk) 01:55, 12 October 2020 (UTC)

    DiscussionEdit

    •   Comment You should link the examples to Wikidata items that you propose they are for. See other property proposals for how to do this. ArthurPSmith (talk) 17:04, 31 July 2020 (UTC)
    •   Comment @ArthurPSmith, QRep2020: I've fixed some things in the proposal. Also, I think the right datatype is URI, not external identifier. --Tinker Bell 01:37, 3 August 2020 (UTC)
      •   Comment I've read some articles that suggested a person could get a Signal number without using an actual phone number so I was not sure how to classify. In any case, thank you to everyone for helping me with this as it is my first Wikidata property suggestion! QRep2020 (talk) 03:47, 3 August 2020 (UTC)
    •   Question Do we have that many Signal users among our entries? --NMaia (talk) 09:47, 1 September 2020 (UTC)
    •   Comment Any other thoughts or questions? I really think adding this property would contribute to the service. QRep2020 (talk) 17:44, 18 November 2020 (UTC)
      •   Support Listing contact addresses of individual people on Wikidata is complicated from a privacy perspective but not any different then phone numbers that we are already storing. ChristianKl❫ 13:47, 1 December 2020 (UTC)

    Edit

       Under discussion
    Descriptiontranscription of text from an advertisement
    Data typeMonolingual text
    Example 1Heresies 4 Gaysweek advertisement URI (ex. https://iiif.archivelab.org/iiif/heresies_04$127/178,50,1044,859/full/0/default.jpg) has copy "No excuses. No apologies. No compromises. Quite simply a real honest-to-God newspaper. Gaysweek."
    Example 2Heresies 6 Feminist Studies advertisement URI (ex. https://iiif.archivelab.org/iiif/heresies_06$119/214,1865,2090,1204/full/0/default.jpg) has copy "For information about submitting manuscripts or artwork for publication, write to the managing editor"
    Example 3Heresies 6 DYKE A Quarterly advertisement URI (ex. https://iiif.archivelab.org/iiif/heresies_06$120/230,2209,1148,871/full/0/default.jpg) has copy "A Magazine of Lesbian Culture and Politics Featuring Essays, Analysis and Interviews"
    Example 4Heresies 6 Gibbous RISING advertisement URI (ex. https://iiif.archivelab.org/iiif/heresies_06$125/894,2319,696,784/full/0/default.jpg) has copy "Gibbous RISING is not only the description of a partial moon becoming whole, but signifies the growth of women and the rising recognition of feminism and liberation."
    Planned useWe intend to use this property as part of our work with FemNet to represent advertisement copy (from the feminist publication Heresies (https://archive.org/details/heresies_magazine)) in our linked data triples.
    See alsocatchphrase (P6251), motto text (P1451)

    MotivationEdit

    My name is Joel. (This is my first time editing or proposing anything to Wikidata!) I am a research assistant with the FemNet project at the University of Alberta in Edmonton, Alberta, Canada. The goal of this project is to eventually represent all the advertisements from the feminist publication Heresies in linked data triples. In doing preliminary triple writing we are currently using as many Wikidata properties as possible in our data.

    One case, however, for which we could not find a suitable property in Wikidata was for "advertisement copy" - that is, advertisement text usually in the form of an advertising publication's self-description or solicitation to a prospective subscriber/reader. My proposal above attempts to demonstrate how we would like to use this property. As can be seen, the value of this property would essentially be the advertisement copy as a string literal; I hope that "monolingual text" was the right choice for this use case. (If someone reviewing this proposal can think of an alternate way that our project could represent advertisement copy using preexisting properties in Wikidata, we would also be open to that.)

    Thank-you, Jblech (talk) 17:58, 2 August 2020 (UTC)

    DiscussionEdit

    Valentina.Anitnelav Thierry Caro Shisma (talk) Arlo Barnes (talk) Tsaorin (talk) 16:37, 12 November 2019 (UTC) Nomen ad hoc


      Notified participants of WikiProject Narration

    •   Comment this looks interesting, it seems like we already have motto text (P1451), motto (P1546) and catchphrase (P6251). I wonder whether it would make sense to adopt one of these? I see that none of them really match what you want to do since an advertisement slogan isnt really a motto and isnt really a catchphrase. However, given that catchphrase (P6251) only has 300 uses, it seems like a potential idea to extend this -- especially since it seems difficult to distinguish between "advertisement" and simply "well known for" and probably these instances often overlap. --Hannes Röst (talk) 14:34, 6 August 2020 (UTC)
    Ex 1) <Heresies