Open main menu

Wikidata talk:Property proposal/Archive 2

Active discussions

Instructions / best practices for property proposals

If anyone interested in creating (or already working on) documentation with instructions or best practices for creating property proposals?

I tried unsuccessfully to find something like this before starting my first property proposal earlier this week. I managed to muddle through by reading the documentation for {{Property proposal}} and looking at other proposals. However, since a good help page might reduce the number of sloppy or incomplete proposals it could have benefits beyond simply guiding newbies through the process.

I can write a draft for the "how to" instructions but would need input from experienced editors for anything beyond that. —ShelleyAdams (talk) 14:32, 29 September 2017 (UTC)

Count me in. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:49, 29 September 2017 (UTC)

Gadget for property creation?

I wonder if anybody has tried writing a gadget / script / robot / whatever to help create properties once they are marked as ready. The creation of the property itself could be left to the user (as this requires extra care for the datatype) but then the transfer of the data from {{Property proposal}} to statements on the property and {{Property documentation}} on the talk page could be automated I think. − Pintoch (talk) 12:10, 18 December 2017 (UTC)

Lint errors in proposals

I recently checked Special:LintErrors/html5-misnesting and fond 1k+ such errors in all the proposals, any idea to fix them, or is this a bug (mismatching)? --Liuxinyu970226 (talk) 03:49, 7 January 2018 (UTC)

I suspect {{Ping project}} and {{TranslateThis}}. Matěj Suchánek (talk) 09:28, 7 January 2018 (UTC)

Best practice suggestion

I would like to humbly propose a possible best practice for property proposals:

Relevant WikiProjects should be notified about a property proposal, using {{Ping project}}. To that end,

  • the proposer should identify and notify relevant WikiProjects when submitting the proposal (in the best case, it’s an easy way to find some {{Support}}ers);
  • discussion participants should feel encouraged to notify WikiProjects which they feel are relevant, but which have not yet been pinged;
  • and property creators should consider whether relevant WikiProjects have been notified before creating a property.

The purpose of this is to avoid creating properties without the knowledge or approval of the related WikiProject. If a property in a certain area is created and the people most active in that area (the WikiProject members) are not aware of it, then at best the property will remain mostly unused, and at worst the result will be inconsistent data modelling, since some people will now use the new property whereas others will use the existing, older solution by the WikiProject.

This assumes that there is no reason why someone would not want to notify a WikiProject. I’m not aware of the existence of any “toxic WikiProjects”; however, in the hypothetical situation of a schism between group A (who form a WikiProject A), who wants to model data in way X, and group B (not part of that WikiProject), who wants to model data in way Y, it would seem to me that group B creating a property without notifying WikiProject A doesn’t really solve any problems, and some reconciliation between groups A and B is needed anyways. --Lucas Werkmeister (talk) 23:37, 1 February 2018 (UTC)

Sounds good to me. Is it something we need a formal vote on? It looks very consensual. − Pintoch (talk) 03:27, 2 February 2018 (UTC)
If no one objects, I don’t think we need a vote… the main question would be where to put this so that people find it :)
However, Harmonia Amanda brought up a valid point on IRC the other day (log – it was actually a week ago, I’m just terrible at following up ☹): for Technical Element Score (P4815), she notified related WikiProjects via their talk page instead of via {{Ping project}}. I’m not going to judge which way is “better” (I guess the talk page is less intrusive but has a slightly higher risk of being missed?), but since that’s certainly a valid way to notify projects, the text needs to be modified to mention it, so it doesn’t sound like {{Ping project}} is the only acceptable form of notification. --Lucas Werkmeister (talk) 16:38, 9 February 2018 (UTC)

About creation of new proposal to link with other created

Hi! We at Wikimedia Mexico trough @Andycyca: proposed the creation of CONABIO ID (P4902) due the donation by CONABIO, a Federal Agency of the Mexican Government, of 208 488 elements to be used as new IDs. But in the database we received linked with the CONABIO's ID we have also the Enciclovida ID, which is an open encyclopaedia by the same agency that can be susceptible to be a new proposal. In fact they homologated their URL with the ID number to have the same structure before the donation to Wikidata. The structure of the database we have is:

  • conabio_id (the future P4902)
  • enciclovida_id (the new property?)
  • nombre_cientifico (scientific name by CONABIO)
  • nombre_comun (popular name of the species in Mexico)
  • enciclovida_url (the URL of each species in Enciclovida)

Should we create another property for Enciclovida? If yes, how we can link one with the other? Or we can use the Mix and match tool to make the upload and matching at the same time? Any support will be really appreciated, I'm newbie managing the donations we are receiving! Thanks, --ProtoplasmaKid (talk) 07:08, 21 March 2018 (UTC)

@ProtoplasmaKid: Please can you give some example values for each of the above, with the associated QIDs? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 07:24, 21 March 2018 (UTC)
Thanks @Pigsonthewing:, AndY! Each element have this values:
conabio_id enciclovida_id nombre_cientifico nombre_comun enciclovida_url (URL in Enciclovida)
1ANIM 1000001 Animalia Animales http://enciclovida.mx/especies/1000001
54481HYMEN 10054481 Paratiphia aequalis subsp. aequalis Avispa de las flores http://enciclovida.mx/especies/10054481
--ProtoplasmaKid (talk) 06:50, 22 March 2018 (UTC)

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

@ProtoplasmaKid: Thank you. Yes, I think a new "Enciclovida ID" property should be proposed. Do you need help with that? As to how we import two sets of IDs from one set of data, I'm still not clear on the best approach for that, but both sets can certainly be used as separate Mix'n'Match catalogues. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:06, 3 April 2018 (UTC)

Number of ids in source and expected completeness on Wikidata

We have expected completeness (P2429) to indicate if Wikidata could (ideally) record all the cases where this property holds. Many identifier properties have not been tagged yet with this metadata, which would be quite useful I think. I have updated the property proposal to accept |expected completeness= so that people can record this information directly when proposing properties (see Wikidata:Property proposal/org-id.guide ID for an example). I propose to add it to the template (Wikidata:Property_proposal/Proposal_preload) so that editors can discover this feature easily, adding as comment the possible values (qids) to use.

Also, it would be nice to add a second piece of metadata: the number of identifiers stored in the third-party source. This way, we could directly compare the number of uses on Wikidata to this number, and get a better idea of the coverage. Do we already have a property to store this number? − Pintoch (talk) 13:47, 7 February 2018 (UTC)

There is data size (P3575) which could maybe serve the purpose of giving a count of the number of id's? ArthurPSmith (talk) 21:06, 7 February 2018 (UTC)
Nice! But it seems like this property was designed to store quantities of information, which isn't really the same thing… Maybe we could make it more general, but it might go against the original spirit. − Pintoch (talk) 08:28, 8 February 2018 (UTC)

I have proposed a property along these lines here. − Pintoch (talk) 12:42, 17 February 2018 (UTC)

I have made a template that uses the property: it can be used to display the coverage in Wikidata of a given property. It works like this: {{User:Pintoch/coverage|3153}}

Crossref funder ID (P3153)70.2% complete

Do you think we could integrate that somehow to {{Property documentation}}? (maybe without the progress bar, just the percentage?) Of course this is an approximation as it just based on the number of uses in Wikidata: there can be duplicate values on both sides. − Pintoch (talk) 20:07, 4 March 2018 (UTC)

Sure, that looks good to me. How does it handle the cases where wikidata has more than the "number of records" count? I think @Jura1: has done most of the work on that template, so you probably should discuss with them. ArthurPSmith (talk) 15:49, 5 March 2018 (UTC)
Most discussion of that template took place at Template talk:Property documentation. Laddo (among others) did a lot of work on it.
--- Jura 04:17, 6 March 2018 (UTC)
Of course, I should have looked there first… − Pintoch (talk) 08:26, 6 March 2018 (UTC)
@ArthurPSmith: yeah it looks weird for GRID ID (P2427):
GRID ID (P2427)115.6% complete
I'm not sure what to do about it… We could cap it to 100% but we would be hiding interesting information (the fact that we hold these redirected values). − Pintoch (talk) 08:26, 6 March 2018 (UTC)
I really like this feature, it will be very helpful I think, also values exceeding 100%, we can add a (link to a) small explanation what reasons that could possibly have. --Marsupium (talk) 18:19, 5 April 2018 (UTC)

New properties to be created for Lexeme

Hello all,

As you may know, a new type of data will be started on Wikidata very soon: Lexicographical data. You can see an overview of the data model here. Note that this document describe the general structure, but just like on Wikidata before, the editors will be very free to organize data as they want, to create the needed properties, not necessarily following the examples that this document contains.

When the deployment is made and editors start playing around with Lexemes, we expect a lot of new properties to be created. Many properties to describe words (derived-from, homonym, pronunciation, translation, synonym, connotation, register...) will need to be created. Maybe some properties that already exist for concepts will be reused.

We expect many of people, both from the Wikidata community and Wiktionaries, to come and submit new properties, or give opinion on the other proposals. We will need people who are willing to handle this discussions about lexicography and languages, and who feel comfortable with these topics.

Obviously I don't want to interfere in the volunteers process, so my question is: do you need anything from me that could help you handling this future increase of activity? For example, should we make a specific communication to attract the attention of editors on the new properties to review and comment?

(I'm pinging the current property creators: @Ayack, Paperoastro, MichaelSchoenitzer, Emw, Izno: @Mattflaschen, JakobVoss, 99of9, ArthurPSmith, Kolja21: @Micru, Tobias1984, Viscontino, Jonathan Groß, PinkAmpersand: @Yellowcard, Thierry Caro, Ivan A. Krestinin, Nightwish62, Fralambert: @Danrok, MSGJ, GZWDer, Joshbaumgartner, Srittau: @Almondega, Jura1, Pintoch:)

Thanks a lot, Lea Lacroix (WMDE) (talk) 10:15, 16 April 2018 (UTC)

We need at least
  • Wikidata:Property_proposal/Lexemes to be created and linked
  • Help:Lexemes to be created and filled
  • Several more help pages such as Special:ListDatatypes need to be extended
  • one or more prepared example proposal. Are there any lexeme property that would definitely be needed so we can prepare them as proposal?
  • a list of existing properties to be used with lexemes

-- JakobVoss (talk) 11:03, 16 April 2018 (UTC)

Is there one person or a small group of people or a wikiproject that could be considered a reliable resource to answer questions if we're not sure about something? Is there a primary responsible party for this? ArthurPSmith (talk) 14:05, 16 April 2018 (UTC)
Thanks for your suggestions Jakob, and I see that the subpage is now created :D
Indeed, we have some work to do on documentation. At the beginning, things will mostly happen on Wikidata:Lexicographical data but once the processes and infrastructure are more stable, we'll have to update all the relevant doc pages.
"Derived from" could be a simple example (the data type would be another Lexeme). "Pronunciation" is an interesting case, since I don't know what format people will prefer: one of the existing standards, a link to a recording, it may have qualifiers for the region, etc.
ArthurPSmith: I try to connect all the people who are interested in the project on Wikidata talk:Lexicographical data and this is where all the announcements will happen. I'll also reach directly the Wiktionaries when needed. I pinged Wikidata:WikiProject Languages to ask if they can help regarding the languages.
What do you mean by "primary responsible party"? Lea Lacroix (WMDE) (talk) 14:23, 16 April 2018 (UTC)
Léa, it would be good to start Wikidata:WikiProject Lexicographical data to assemble the people interested in discussing the properties, and to be able to ping them, or to list the existing properties in their page. I don't think Wikidata talk:Lexicographical data is a good place for that.--Micru (talk) 14:30, 16 April 2018 (UTC)
I just created redirects to Wikidata:Lexicographical data and I'd prefer to start with one page instead of fragmented discussion. Everyone interested in working with Lexemes should be interested in this page. If it grows we can split but top-down organizing will lead to dead end pages. -- JakobVoss (talk) 14:39, 16 April 2018 (UTC)
+1. I'd like to avoid duplicated the content too much. There is already a list of interested people on Wikidata:Lexicographical data/How to help that we can update, and I'm sure we can have the template that allows pinging a list of people as well. Lea Lacroix (WMDE) (talk) 14:43, 16 April 2018 (UTC)
Ok, then add it to the todo list :D --Micru (talk) 15:50, 16 April 2018 (UTC)
Léa, the "How to help" list I think addresses my question of who to contact with questions. Thanks! ArthurPSmith (talk) 15:05, 16 April 2018 (UTC)
Can we do now property proposal? For the datatype, is it possible to modify Wikidata:Property proposal/Proposal preload? We need the "Form" datatype, and maybe a way to make the difference between Q-items and L-items. Tubezlob (🙋) 15:15, 16 April 2018 (UTC)
Sure, if everything is ready, people can start making proposals.
For the new datatype, there will be Lexeme, Form, and later Sense (not deployed in the first version, so should stay out of it for now). Lea Lacroix (WMDE) (talk) 15:34, 16 April 2018 (UTC)
So if I understood correctly the data type for Form will be deployed on the first version? --Micru (talk) 15:50, 16 April 2018 (UTC)
Yes, the new datypes for the first version will be Lexemes and Forms. See Wikidata:Lexicographical data/Documentation#What is included in the first version. Tubezlob (🙋) 16:01, 16 April 2018 (UTC)
Out of curiosity, are existing properties going to be used for both Q and L-space, or are they separate? Thanks. Mike Peel (talk) 15:38, 16 April 2018 (UTC)
Yes, the properties will be in common. So for example maybe for pronunciation it is possible to use IPA transcription (P898). Tubezlob (🙋) 15:54, 16 April 2018 (UTC)
@Mike Peel: properties will be in the same namespace so technically not separated, but my understanding is that de facto they will be separated by uses and constraints (in the same way country (P17) and country of citizenship (P27) are separated, first one for places, second one for human) but in some specific cases (like IPA transcription (P898)), there could be some overlap. Should we allow it or should we prevent it, I don't know and I'm neutral on this. Cdlt, VIGNERON (talk) 16:53, 16 April 2018 (UTC)
I made a first proposal: Wikidata:Property proposal/synonym. Tubezlob (🙋) 18:39, 16 April 2018 (UTC)
Yeah. There will be a new constraint type to indicate for each property if it should only be used on items or properties or lexemes. This way it should be easy for you to say if a specific property is used on the wrong entity type and find them. --Lydia Pintscher (WMDE) (talk) 18:41, 16 April 2018 (UTC)

Reorganization of subpages

These subpages are barely used:

I propose to delete them and move existing proposals on those pages to Wikidata:Property proposal/Generic and add Wikidata:Property proposal/Lexemes.--Micru (talk) 14:37, 16 April 2018 (UTC)

Please reorganize as you like, I did a start at Wikidata:Property proposal/navbar/text but cutting down the number of subpages surely will help. -- JakobVoss (talk) 14:39, 16 April 2018 (UTC)
  Support ArthurPSmith (talk) 15:03, 16 April 2018 (UTC)
Are subpages actually needed, or could we just have a single page that lists all proposals? Thanks. Mike Peel (talk) 15:36, 16 April 2018 (UTC)
I quite like watching a specific subpage that I am interested in an commenting on all proposals that get added there. − Pintoch (talk) 15:39, 16 April 2018 (UTC)
  SupportPintoch (talk) 15:39, 16 April 2018 (UTC)
  Done --Pasleim (talk) 07:45, 24 April 2018 (UTC)
@Pasleim: Could you also update the PLbot so that on Wikidata:Property proposal/Overview appear the Lexeme proposals? Thanks!--Micru (talk) 07:56, 24 April 2018 (UTC)

Creating properties for Lexemes

Hello all,

@Ayack, Paperoastro, MichaelSchoenitzer, Emw, Izno: @Mattflaschen, JakobVoss, 99of9, ArthurPSmith, Kolja21: @Micru, Tobias1984, Viscontino, Jonathan Groß, PinkAmpersand: @Yellowcard, Thierry Caro, Ivan A. Krestinin, Nightwish62, Fralambert: @Danrok, MSGJ, GZWDer, Joshbaumgartner, Srittau: @Almondega, Jura1, Pintoch:

WikibaseLexeme is now live :) Would it be possible to go through the current property proposals and create the ones that reached a consensus, so people can start creating and editing Lexemes and Forms? Thank you very much! Lea Lacroix (WMDE) (talk) 11:20, 23 May 2018 (UTC)

Examples required

Hi everyone. I'd like to suggest that a minimum of three examples of use are required in property proposals and that the corresponding module is adapted so that it has three, or more, distinct fields for examples. This would contribute to:

  1. save the supporters/opposers some time, since they won't have to individually investigate the intended use of some properties;
  2. as a possible consequence, encourage users to participate in the discussions;
  3. make the use clearer for the future;
  4. ensure that properties can have and will have at least three uses from the beginning; and
  5. infer some data constraints that would be needed for each property, especially the patterns that external identifiers meet, since it's not possible to infer anything from only one example.

I'd love to read your comments. Thanks in advance! --abián 13:40, 3 June 2018 (UTC)

See discussion here: Property talk:P1855#Multi or single value? - we should maybe invite those who raised it there here, or discuss further there. ArthurPSmith (talk) 20:51, 3 June 2018 (UTC)
Thanks, ArthurPSmith! I should clarify that this thread isn't about the property Wikidata property example (P1855), it's just about the examples that are given on property proposals. Nonetheless, both threads are related, the one you link is quite interesting and I hadn't read it, so thank you again for pointing it out. --abián 21:31, 3 June 2018 (UTC)
Pinging ‎Pintoch, JakobVoss, Jura1, Thierry Caro, Lymantria, -revi, Danrok, ArthurPSmith, who have created properties recently. --abián 15:07, 6 June 2018 (UTC)
  • Can you add three samples that illustrate that it's useful (where missing samples lead to the illustrated disadavantages or samples present had the advantage) ;)
    If a property works or not is generally only seen once there are dozens of uses and constraints are gradually refined depending on actual uses. Zero, three or 10 uses don't really matter. At least, that's my opinion. I find it easier to pick good samples once there are plenty of uses.
    --- Jura 15:20, 6 June 2018 (UTC)
Thanks for your interest, Jura. :-)
Concerning 5, this pattern would have been clearer with three examples. While vivaldi_technologies_as.776cc66357fe4df3 makes us investigate further to infer the pattern, vivaldi_technologies_as.776cc66357fe4df3, apple_inc.4c9baa063908dbd8 and microsoft_corporation.c86cc6059119a54b definitely tells us the identifier is a string, a dot and a 16-byte hash. For other property types and constraints, it mainly makes us easier to understand the domain and the range. For instance, <Douglas Adams (Q42), date of birth (P569), 11 March 1952> can be insufficient, while <Douglas Adams (Q42), date of birth (P569), 11 March 1952>, <Abul-Abbas (Q335860), date of birth (P569), 770> and <Harry Potter (Q3244512), date of birth (P569), 31 July 1980> let us see the big picture, check if date of birth (P569) will overlap another property, consider reducing its scope, etc. More examples will probably be needed for properties that can be used in several namespaces (e.g., lexemes, items, properties) or properties that may work both as a value and as a qualifier, as a value and as a reference, etc. I agree that constraints must be gradually refined depending on actual uses, that shouldn't change.
About 4, when the property was created, the creator, or another editor, would add the three or more suggested statements to their corresponding entities so that we have no unused (useless) properties.
Anyway, this is probably not a great change and it would just require editing Module:Property proposal so that these three examples are demanded in advance by the module. This saves us the effort of requesting some examples with a comment or looking for them for every proposal we read. --abián 17:26, 6 June 2018 (UTC)
Not in all cases I think that more than one or two examples are useful. When it comes to numbers as external ID's, for instance, it should be sufficient. Lymantria (talk) 16:56, 6 June 2018 (UTC)
Thanks for commenting, Lymantria! I find those examples important to know the kind of information that is provided by the external source and its quality, since these examples are usually direct pointers to that information. When I check some proposals for external IDs (not too often), I always have to search for additional identifiers to get to the idea of how useful or complete that source is. A specific property for a source with too few IDs, or a source whose entries are mostly empty, won't be useful for us. I also find these examples important to fulfill the purpose 4. --abián 17:47, 6 June 2018 (UTC)
  Support definitely. -- JakobVoss (talk)
Looks good to me − encouraging more examples is useful. I am not sure about making that a hard *requirement* but I do not have strong feelings about that. − Pintoch (talk) 08:36, 7 June 2018 (UTC)
  • Given the problem with unused properties, maybe we could actually require 5. I don't think these necessarily need to be the ones that will be on the property itself, but we do have too many property that aren't actually used. For identifiers, maybe we should require 20 uses in "described at URL". These can be bot-converted once the property is available.
    --- Jura 08:44, 7 June 2018 (UTC)
    • 20 is definitely too much, and 5 would be fairly annoying I think. − Pintoch (talk) 06:42, 10 June 2018 (UTC)
      • Contributing to Wikidata is annoying? I think if a user can't find 5 samples easily, I doubt they will be doing it later and it just leads to waste of time.
        --- Jura 06:50, 10 June 2018 (UTC)
        • Oops, sorry for this blasphemy! Of course contributing to Wikidata is just pure joy! No seriously it is annoying to have to input these examples in a setting where the property is not available yet, either as wikicode or with another generic property as you are proposing. − Pintoch (talk) 07:02, 10 June 2018 (UTC)
          • One would just need to add 5 qids and 5 values in the proposal template.
            For the 20, it's the standard way to input this, even easier than actually adding a separate property.
            --- Jura 07:05, 10 June 2018 (UTC)
  Support I think it's reasonable to at least allow for more examples, and mention something like "if the property has multiple uses or examples that are fairly different from each other, feel free to add multiple examples". I have nothing against making 3 examples mandatory either if people want that, although 20 uses (even for identifiers) would be fairly annoying (I expect most external IDs are not matched and added manually outside of this bot proposal process).--Reosarevok (talk) 19:21, 9 June 2018 (UTC)
  • It's doable with standard tools (No bot proposal needed) and makes sure that the possible property actually gets used. Given the endless flow of unused properties, this something we need to address.
    --- Jura 06:50, 10 June 2018 (UTC)

I've adapted Wikidata:Property proposal/Proposal preload, Module:Property proposal and Module:Property navbox so that they can work with an arbitrary number of required and optional parameters for examples. We just have to change local num_required_examples = 0, line 148, to set the number of required examples. For now, it seems that no one disagrees about demanding three examples at least, while there's no consensus about demanding a higher number. I think we can start with three; if consensus changes at some point in the future, we'll be able to change that number easily. Nonetheless, it can be a good idea to wait some days until the use of parameters like example 1, example 2, etc. is generalized; in this way, we'll avoid annoying warnings in current proposals, most of which are still using example. Thanks for all your comments! --abián 21:25, 13 June 2018 (UTC)

  Done. Three examples are required by the template from now on. This can be easily changed at any time if consensus changes or if our experience suggests this is a bad idea. Thanks again! --abián 21:48, 16 June 2018 (UTC)

"marked as ready"

Wikidata:Property proposal/LilyPond notation has been marked as ready by ArthurPSmith. Does this mean that a property creator is going to create it, or is there some other process that needs to be done first? Jc86035 (talk) 17:33, 16 July 2018 (UTC)

Wikidata:Property proposal/Header says: Once consensus is reached, change status=ready on the template, to attract the attention of a property creator. So a property creator should create it very soon. Matěj Suchánek (talk) 07:13, 17 July 2018 (UTC)

Image that shows location of an item within a larger object

BeefCutTenderloin.png shows the location of tenderloin within a beef.

I can imagine many auto parts have the same kind of locator image. Science and biology could probably use this too.

Is there already a property for that? I could not find one in the existing/proposed properties.

Thanks! Syced (talk) 23:54, 16 July 2018 (UTC)

Property creation script

Hi,

For the sake of openness, I have released my script to create properties here: https://github.com/wetneb/wikidata-bots/tree/master/createprop That does not mean I recommend anyone running it, nor does it represent any commitment to maintain this pile of crap.

I will be mostly away from the internet in the coming months so I will not create properties as regularly as I have been striving to for the past few months. − Pintoch (talk) 15:04, 25 July 2018 (UTC)

New properties on independence

I'm trying to replicate all old infoboxes on Wikipedia to new Wikidata Infoboxes eg Belarus on cy-Wikipedia. declaration of independence (Q1464916) exists; is there an equivalent property? I think we also need: 'independence from (which state)' and 'Independence recognized (date)' as exists on enwiki infoboxes. Can / should all three properties be created? Llywelyn2000 (talk) 07:29, 17 November 2018 (UTC)

I wonder if "significant event" and qualifiers would be a better option - significant event: declaration of independence ; point in time: 25/8/1991; follows: USSR? This lets you express a lot of fine nuance and multiple different types of dates without a proliferation of properties. Andrew Gray (talk) 16:47, 24 November 2018 (UTC)
  • I'd use "inception date". It can be qualified with "object has role" or "criterion used". --- Jura 07:07, 25 November 2018 (UTC)

Specialized property proposal forms

The property proposal preload is growing quite steadily and I am worried that this makes the process of proposing properties a bit daunting to newcomers. Many fields are only applicable to some datatypes, so I wonder if it would make sense to propose dedicated preloads for external identifiers for instance, and remove the parameters applicable to them from the generic preload. Thoughts? − Pintoch (talk) 11:59, 4 December 2018 (UTC)

@Pintoch: That would be quite useful (especially for external IDs). Jc86035 (talk) 17:55, 4 December 2018 (UTC)

Is it acceptable to expand the scope of a property after it has been accepted?

Hi all

A while ago I submitted a property proposal for model item (P5869), which at the time I expected to be only providing best practice examples for classes of items, e.g William Shakespeare (Q692) is an example of playwright (Q214917). I've now had people suggest it could also be used to show best practice examples for use of properties as well, e.g Diary of Anne Frank (Q6911) as a good example of the use of has edition (P747).

Do I have to ask somewhere to expand the use of this property to include providing examples? Or should I simply change the description? I realise there may be levels of changing the usage of a property, e.g an expansion of usage vs completely changing the use.

Thanks

--John Cummings (talk) 00:04, 18 December 2018 (UTC)

I can't find any specific instructions about this (which should be written somewhere), but it seems that it's just down to community choice in the same way that proposing a new property is done. The descriptions and property constraint (P2302) can simply be edited on the property page to change the scope once decided. Here is a good example of one that has already changed - 'Member of' changed to allow organisations as well as people. NavinoEvans (talk) 11:13, 18 December 2018 (UTC)
@John Cummings, NavinoEvans: yes indeed, you can just discuss this change on the property talk page. To make the discussion more visible you could (for instance) ping users involved in the property proposal. − Pintoch (talk) 14:23, 18 December 2018 (UTC)

How to model status of change requests?

What is a good way to model whether a change request has been accepted or rejected by some authority? For example, ISO 639-3 has a formal process where anyone can submit change requests. Some requests get accepted, others get rejected. I’d like to model this in Wikidata, but I’m not sure how. See ISO 639-3 change request 2008-040 (Q61639834) for an ISO 639-3 change requests which has been adopted (this would be the reference for the claim); and see list of rejected requests. — Sascha (talk) 17:00, 8 February 2019 (UTC)

With significant event (P793) and items to indicate accepting or rejection events? ArthurPSmith (talk) 18:15, 8 February 2019 (UTC)
@ArthurPSmith: Thank you! Like this? Acceptance: significant event (P793) of ISO 639-3 change request 2008-040 (Q61639834); Refusal: significant event (P793) of ISO 639-3 change request 2014-053 (Q61686517)Sascha (talk) 15:32, 11 February 2019 (UTC)
The same issue has been brought up on Wikidata Project Chat; probably best to continue the discussion there. — Sascha (talk) 15:35, 11 February 2019 (UTC)
Return to the project page "Property proposal/Archive 2".