User talk:Joshbaumgartner

Previous discussion was archived at User talk:Joshbaumgartner/Archive 1 on 2016-02-26.

See discussion.

Dear Josh,

After reading comments at Wikidata:Property proposal/Archive/45#mentioned in, it seems reasonable to include aliases that add value to the property P1441. Please take a look at the new aliases (mentioned in|mentioned by|cited in|cited by), and let us know if these are suitable to the property P1441.

After testing over the searches

https://www.wikidata.org/w/index.php?search=mentioned+in&title=Special:Search&profile=advanced&fulltext=1&ns0=1&ns120=1

https://www.wikidata.org/w/index.php?search=cited+by&title=Special:Search&profile=advanced&fulltext=1&ns0=1&ns120=1

we can see the property (P1441) appearing in the top results. Consequently, the creation of new properties may not be needed.

Kind regards,

FPA.

I agree that aliases should be added liberally to existing properties, especially when a property proposal is not done on the basis that an existing property is sufficient. At a minimum, the rejected property name should be added as an alias to all existing properties that were mentioned as supposedly able to the job instead.

Hi Josh,

Out of the blue. Are you aware of any property that can be used to create a list of identifiers?

For example: Wikidata:Property proposal/list of identifiers

A property that allow the user to list identifiers under this property. We may somehow benefit from a property (List of identifiers), in which we could list DOIs, or ISBNs, or other identifiers related to publications.

Potential applications: Such property could be used to list retractions in the field of Biology (e.g. List of retraction in the topic: Invasive Species OR Database of retraction regarding... OR any tag stating the main purpose), and the concept can be extrapolated to other fields. To create a list of papers "Comments on", and other applications can still come out of this.

Would you know some pathways to cluster identifiers (e.g. DOIs)? If such property does not exist, would that be a feasible property to create, since it may deals with special flags. If the creation is not possible we can perfectly understand.

Example template

#####################################################################################################################################

#####################################################################################################################################

#####################################################################################################################################

‎List of identifiers

   Under discussion

Description	property for listing identifier (Q853614) such as DOI (P356), ISBN publisher prefix (P3035), ISBN-10 (P957), PubMed ID (P698), PMCID (P932) and a few others
Represents	database (Q8513) of identifier (Q853614)
Data type	External identifier
Domain	item
Example 1	wikiretracted database (Q119721137) →
Example 2	wikicomments database (Q119777158) →
Example 3	wikicitingretracted database (Q119778483) →
Source	https://wikiletters.org and http://retractiondatabase.org/RetractionSearch.aspx? and https://retractionwatch.com/ and others
Number of IDs in source	over 60000 retractions and articles citing-retractions, over 6000 articles being commented upon, and other webservices not listed here.
Expected completeness	always incomplete (Q21873886)
Implied notability	Wikidata property for an identifier that does not imply notability (Q62589320)
Formatter URL	https://wikiletters.org?AWD_ID=$1
Robot and gadget jobs	bots could connect existing databases for retracted articles, citing-retracted-papers, and NLP natural language processing (Q30642) can be used to identify comments and classify open-access citations via Citation Typing Ontology (Q44955364) and WikiCite (Q21831105);

Motivation

Regarding publications, meta:Wikidata allows items for scientific publications to display the tag (is retracted by (P5824)). However, to create a collection of desired items may require computationally expensive SPARQL-query-processing, which can under some circumstances exceed limits for processing time, and results may also change over time due to updated and new items in Wikidata.

The creation of a property that allows the clustering of identifiers enables Wikidata to group items for many purposes such as systematic reviews, organising specific digital libraries, and clustering items for a number of applications.

Note

If such a technique for storing the grouping of items via their identifiers already exists in Wikidata, then disregard this request.

Discussion

• As proposers: wiki-community 00:00, 26 June 2023 (UTC)

#####################################################################################################################################

#####################################################################################################################################

#####################################################################################################################################

Regards,

FPA.

That is a great question and I will have to ponder it a bit. Let me think on it a bit and I will get back to you, perhaps make a comment on that proposal.

Hi Josh,

Thanks for the prompt reply. Please let me know when you have the answer about feasibility to implement it.

We have not yet proposed this property (list of identifiers), because we rather get some insight from you concerning the feasibility of a property that allows the listing of identifiers (DOIs, ISBNs and so on).

That may be a very unique property that can also support researchers making use of ResearchGate. Particularly, because RG retired the section projects (https://www.researchgate.net/researchgate-updates/retiring-projects), and not only myself but potentially many other researchers can benefit from this property to bring and list their research-outcomes via identifiers under a single wikidata-item (e.g. Outcomes from project-A).

Thanks in advance for the time given to this matter.

Sincerely,

FPA.

I do not work with identifiers a whole lot so I do not have a good answer for your original question, sorry.

Another attempt by Uli and Tm to re-hash the same old word games to try and claim some kind of victory from a discussion that closed years ago. Stale at this point, as they have not bothered to reply since last comment. That discussion had no consensus at the end, and the only action item was my withdrawal of my proposed addition of text to the Help:Label page when it was clear that there was no agreement to change that page. These two would like us to believe this meant my agreement with their ideas instead, but that's completely illogical. This particular question of label style remains without consensus thus the discussion infers no change to pre-existing policies and guidelines, to which I adhere. If Uli and Tm would like to actually engage in discussion on the subject matter at hand instead of a word game of interpreting past discussions, that could be very useful and I would be happy to discuss that.

(Info @ User:Emu) Have you already forgotten the administrative advice of 29 June 2023 or have you decided to simply ignoring it? It reads:

"But the opinions of an apparent big majority in a given field might give users some sort of guidance as to where their zeal is best put into action.".

You have repeatedly demonstrated that you could care less what anyone else has to say unless it backs your particular vision of the world, including 'administrative advice', but feel free to beat your dead horse if you must. Or just go back to trying to start edit wars like you have threatened to before. Forgive me if I don't join you in that. However, if you actually have something substantive to discuss, I remain at your disposal.

You got your case thrown out not once, but twice in one month, by different administrators. I don't mind that you have your preferred label format, but even if there is not a consensus on that, there is certainly a broad consensus that whatever form the label uses, the other form(s) should be in the aliases. Unfortunately, your attempts to start edit wars have been sloppy, and you have been so eager to change the label you have forgotten to change/add the alias at the same time. I get making that mistake occasionally, but nearly every label edit you have made lately has done this so it must be laziness, no? Or are you intentionally going against what very much is a consensus that frankly I've never seen a single user voice any form of opposition to?

Again with the same shenanigans? You seem to forget the discussions and try again and again to impose YOUR own names (i.e. without the manufacturers) on the labels against what was discussed again and again and where several users prefered other names (i.e. with the manufacturers). This is the fourth, fifth or sixth attempt that you make? And then you claim that "frankly I've never seen a single user voice any form of opposition to", well you are clearly "have" a ocassionally severe case of amnesia, i.e. as a reminder, just this discussion, the other that you closed, the discussions as the last one in 29 June 2023.

Wikidata_talk:WikiProject_Aviation/Properties#New_section_"Labels_and_descriptions" yourself said that "As there is clearly no consensus to keep my additions, I withdraw my submission and this should close this matter. If anyone wants to discuss specifics about labels or properties, I look forward to discussing those in their own thread." when you tried to impose your own views,", i.e. as this addictions were rejected you continue to attempt to impose them by stealth even after 2,5 years latter.

Now taking your own words, "You have repeatedly demonstrated that you could care less what anyone else has to say unless it backs your particular vision of the world, including 'administrative advice', but feel free to beat your dead horse if you must.".

I know you are upset that I am not to be bullied. It must really chap your hide, I get it. It does remain the same as before...bring something substantive to the discussion, or I don't have much to tell you. Your inability to do so is telling.

Stop lying in your resume and closing all discussions. Wikidata_talk:WikiProject_Aviation/Properties#New_section_"Labels_and_descriptions" was pretty clear to what the consensus was, but only continue to try and impose this rejected by policy every month, sometimes with just two weeks apart for several years.

And you keep going back to the same trough, trying to convince yourself you won some argument years ago, but not once bringing up anything material to the discussion today to justify your harassing behavior, much less make any attempt to engage in an objective manner on the actual content.

Your policy change was rejected by all that participated in that discussion and also your attempts that you made at the time of imposing that policy by stealth (and still do till today). It is you that thinks that nothing was discussed. It was you that said that you were against "requiring or prohibiting manufacturer information in aircraft labels" YET it is you again and again that is trying by stealth to "prohibiting manufacturer information in aircraft labels", to the contrary of what all other users said in Wikidata_talk:WikiProject_Aviation/Properties#New_section_"Labels_and_descriptions.

So it is you that, for the last years, have not "make any attempt to engage in an objective manner on the actual content" but continue with your solo act.

I include the manufacturer name in many aircraft labels so your presumption that I am 'prohibiting' them is completely wrong. I am not following a strict add or delete policy for manufacturer names. You do seem set on adding them, and many times, I've found you have added a completely non-sensical one, even added ones that don't even exist, which I found quite humorous.

Yourself said that, when you attempted to change policy, you were "withdrawing my proposed text which did not gain consensus in discussion ". Yet, again and again and again try to impose your attempt to change policy, that, again, was rejected in Wikidata_talk:WikiProject_Aviation/Properties#New_section_"Labels_and_descriptions".

In that discussion, that change policy, pushed by you, was rejected mainly because of your attempt to change that policy to omite, by default, the manufacturers names, so yes, your numerous and contiguous actions for more than 2,5 years have been, by you always deleting the manufacturers name, have been de facto a attempt by stealth to "prohibiting manufacturer information in aircraft labels".

So, yes, your actions are the problem, not other users.

You keep pointing back to the fact we agreed not to change a project page guideline at that time, and so we kept the existing "For aircraft families, labels should be succinct and cover the range of the family." Everyone knows this already. However, you think this somehow backs your effort to enforce the inclusion of incorrect or even non-existent manufacturer names in labels? That's a strange conclusion.

The discussion was clear to the fact that anyone else said what is linked\posted above and the fact still is that after 2,5 years it is only you that is trying to ignore it by deleting manufacturers names from the main labels of hundreds of itens, several times again and again, to the contrary of what was discussed, as stated not only by me in this talk page several times that you are trying to enforce a policy that was also pushed by you but rejected. The case is clear as are your attempts to pretend that is otherwise.

You think the consensus was to include incorrect and non-existent manufacturer names in labels?

You think that the consensus was to delete the names of manufacturers from the main label of hundreds of items, as you continually do?

Joshbaumgartner still is and always was the only person in the entire Wikidata-project to delete the manufacturer's names again and again, against all other participants like Tm, [[Esquilo]], myself and the administrative advice of 29 June 2023 of [[Emu]].

It reads:

"But the opinions of an apparent big majority in a given field might give users some sort of guidance as to where their zeal is best put into action.".

You are repeating your inaccurate statements. Do you have anything new to offer, have you ever offered a reasonable and objective relevant rationale for your position? No...as ever, no. Try coming up with just one good reason why I shouldn't be following the current policies and guidelines, and I'll take it seriously. Absent that, I'll keep following the rules, thank you very much.

Dear Josh,

I hope you are doing well,  

We are a group of researchers from King’s College London working on developing WQT (Wikidata Quality Toolkit), which will support a diverse set of editors in curating and validating Wikidata content.  

We are inviting you to participate in an online workshop aimed at understanding the requirements for designing effective and easy-to-use user interfaces (UI) for three tools within WQT that can support the daily activities of Wikidata editors: recommending items to edit based on their personal preferences, finding items that need better references, and generating entity schemas automatically for better item quality.

The main activity during this workshop will be UI mockup sketching. To facilitate this, we encourage you to attend the workshop using a tablet or laptop with PowerPoint installed or any other drawing tools you prefer. This will allow for a more interactive and productive session as we delve into the UI mockup sketching activities.

Participation is completely voluntary. You should only take part if you want to and choosing not to take part will not disadvantage you in any way. However, your cooperation will be valuable for the WQT design. Please note that all data and responses collected during the workshop will be used solely for the purpose of improving the WQT and understanding editor requirements. We will analyze the results in an anonymized form, ensuring your privacy is protected. Personal information will be kept confidential and will be deleted once it has served its purpose in this research.

The online workshop, which will be held on April 5th, should take no more than 3 hours.  

If you agree to participate in this workshop, please either contact me at kholoud.alghamdi@kcl.ac.uk or use this form to register your interest https://forms.office.com/e/9mrE8rXZVg

Then, I will contact you with all the instructions for the workshop.  

For more information about my project, please read this page:  

https://king-s-knowledge-graph-lab.github.io/WikidataQualityToolkit/

If you have further questions or require more information, don't hesitate to contact me at the email address mentioned above.

Thank you for considering taking part in this project.

Regards  

stale discussion

You are completely ignoring why Huntster, a well-respected sysop in several wikipediae, wrote to you. It was him (!), who had started the discussion about your "removing manufacturers again from titles again", not me.

As always you choose to ignore what others have to say and mark any discussion as closed when it is not. You continue wilfully to ignore what was discussed in Wikidata_talk:WikiProject_Aviation/Properties#New_section_"Labels_and_description and what consensus was achieved as per your own words in closing that discussion you said "Looking at the original post of this thread, the OP was opposed to some text I added to the Wikidata talk:WikiProject Aviation/Properties page. As there is clearly no consensus to keep my additions, I withdraw my submission and this should close this matter. If anyone wants to discuss specifics about labels or properties, I look forward to discussing those in their own thread.". There was no consensus to remove the manufacturers name from the main label so there was consensus to keep it as it was.

So much so that you said that you were "withdrawing my proposed text which did not gain consensus in discussion", proposal that said "Names of specific models should not be used unless they are also used as the most common label for the entire family as well as the specific model.".

Ans yet, two years after that discussion, you are trying to impose that "policy" by fiat and against what was discussed and the consensus of the status quo. So no your actions are not as what you claim to be as "The issue raised in this thread has been resolved, it was a mere technical issue". Also you the making the false accusations of "Hounding, edit warring, false accusations, and even hijacking a discussion thread on my talk page to continue your harassment is unfortunately to be expected from you." are precious taking into account who is the one going against what was discussed.

So, if you have any respect for what was discussed revert your edts. Otherwise your actions speak of your bad faith with what was discussed and with the other users. ~~~~

Yes, Huntster did start the conversation, not you, that's the point! Setting up your soap box up in the middle of a conversation that had nothing to do with you is just plain rude. The issue raised in that discussion was resolved, so it was closed. Now that you have started your own conversation, which is what you should have done at first, I can address the issues you are raising. Oh wait, you didn't raise any issues here, you just are complaining about me closing my discussion with another user. Well frankly, your opinion doesn't matter when it comes to my discussion with another user, so if it bothers you that my conversation with that individual was resolved, then...too bad, get over it.

I have no idea why Tm keeps parroting the same ridiculous idea that because we didn't reach a consensus to paint the car red, that must mean the consensus was to paint it green. That's just completely illogical. Holding up a discussion which reached no consensus as the key exhibit to prove a consensus is not too effective. Continuing to repeat the line that just because we didn't agree on Plan A means we agreed on Plan F, though? That just takes a special level of stubbornness to pull off.

You folks are a broken record, and this is one that no doubt will keep playing the same tired tune over and over again, immune to any inputs, ideas, or even logic.

The fact is that neither of you have ever demonstrated a clear reason why the label format I use is a real problem, or why your preferred format is . You have raised some valid points in the past, and those I addressed, not that I ever expect either of you to ever acknowledge that, you have demonstrated exactly zero ability to make that kind of concession now that you are so dug in on this. Tm might think my actions speak of bad faith, and admittedly they do appear to be trying to destroy any good faith one might have in their involvement. I never give up hope though, so if either of you have anything substantive to add, I'm happy to discuss it.

Hi, I'll try to keep it short for once :-) any idea how to add this WD, I figured we can "deduct" it when comparing lap times/average speed ( taking into account a statistical serie of lap times within a season or a longer duration, at the considered track, for a rider ( or using the average of the whole field and compare it to the average the/some previous time the same competition class (P2094) was on that track...usually I wager everybody is x seconds slower on wet compared to dry, some more and others ) but having something to "mark", indicate this for events could be interesting to compare dry lap times only ( "filter out" wet ones events/races/practice or qualifying session ) or wet lap times only ( the opposite ). Thanks in advance

This is an excellent question as there is not a clear and clean set of properties that currently exist for this, but at the same time, it is super important information for events to give users a full picture of the event...even beyond motorsport. Aviation incidents or public gatherings of other sorts come to mind where this would be valuable. A 'prevailing conditions' property where simple things like 'wet'/'dry' with the possible use of qualifier applies to part (P518) for certain laps in changing conditions. I would be wary about trying to statistically deduce this, as there can be many reason for laps to be slower than normal, and it should have a valid third-party reference if we are going to add this. We also can add specific climactic information if available such as temperature (P2076) or precipitation height (P3036) if those are recorded. I certainly think it is valuable to know the conditions when evaluating race performance. Maybe a new property or some need to be made?

As for third party references, as far as those I'm using ( and I'm talking official time sheets published by the organizer/race direction ) , there's only limited ( while useful ) informations communicated, usually track condition is said wet or dry only ( and only one value for the whole race for example - sometimes the infos is inferred i.e : red flag/caution flag for rain at a specific time ) and weather nice, cloudy, rain ( although for weather I might have not listed all the values used yet ), in motoGP ( ( the most detailled infos I've seen so far ) I think they give hygro, track temp, air temp, wind speed, wind direction.

But we have to keep in mind this is the cream of the crop, so 95% or more of the cases ( national level races ) the race direction ( or whoever publish this information ) only gives basic infos to the public, like, I imagine, the ones I listed above.

For more detailed weather information ( changing conditions at a specific time, amount of precipitation, etc... ) I imagine one might have to query specific meteorology database with the track coordinate in order to pull precise data for certain date and time ( FP/QP/Race date and time ).

As for the new property, can we reach a schema usable in WD for the cases you alluded to ? ( aviation incidents and public gathering ) which would also work for the vast majority of motorsports events ( not just the most affluent one like MotoGP and F1 which probably make more detailed information available to fans ).

TL/DR : do you have an example to illustrate the cases you're thinking about ? so we can tweak/experiment what we can do with the informations we have ( your case(s) + the races I'm working on ) within the constraint of WD, and maybe see more clearly the schema we would need, and therefore perhaps the contours of the new property(ies)...

Would you be in favor of creating a ( several ) property (ies) to store the best lap time of each participant of a race during qualification practice session(s), possibly {{general classification of qualification practice participants}} ( leaving it open for creation of QP1, QP2, QPx when it applies ) ?

This could allow to get some cool stats like compare the time gap between P1 of QPx and race results for a specific rider/driver year-to-year ( on the same track ) or race-to-race ( for a whole season ), maybe see some progress pattern... here's a mock-up

general classification of QP	Kazuki Watanabe edit competition class JSB1000 ranking 1 duration 108.330 second laps completed 20 lap 0 references add reference Katsuyuki Nakasuga edit competition class JSB1000 ranking 2 duration 108.481 second laps completed 18 lap 0 references add reference
		add value

edit: for whatever reason the mock-up look better here

Without this kind of property I've been using Q106611407#P710 for a test, in this precise case with time gap (P2911) ( could do it with duration (P2047) ) but it obviously lacks clarity, as anybody else than myself stumbling upon it would have a hard time differentiate it with Q106611407#P2321.

I forgot to thank you for your answer to my previous question/request, I've created the items, sub-classes of collision (Q238053) as you suggested and started to use them.

As usual any input from you will be greatly appreciated.

This is a lot to process and it looks like you are working on adding a serious amount of great data here. I'll probably have to take some time before I can really get a complete response, but a few things to jump up right away.

First, I think coverage of practice sessions is great, but they should be separate items from the race, so for example, a separate QID for the race, qualifying, and each practice session. Then for each, the same general classification property can be used to list results of that session.

I am a bit worried as the number of qualifiers goes up. First, it is a problem for references, as not all sources actually cover all of the data points. Also you can't add qualifiers to qualifiers, so it limits the ability to add further definition. If there are more than two or three qualifiers for a value, I think we should consider either adding new properties to better capture the qualifier values, or that the original value warrants becoming its own item.

Thanks a lot for this great insight!!

I agree with your idea about separate QIDs.

I'll try to work in this direction for one race ( I think there's some kind of sandbox feature in WD, do you think it could be used to improve the workflow while we experiment with the structure ? ( compared to actual pages with no traffic like the pages I'm working on )

One thing useful to mention, I'm not sure yet how to link race, FPs, QPs together using the like of part of (P361), follows (P155), series ordinal (P1545), followed by (P156), etc...

What label to use for the whole event ( usually a week-end ) which comprises all the items ( FPx, QPx, WU, race sometimes twice if there's two races for the category in the same week-end ) and how to link it to the current championship and to other events which constitute the season, I might have an idea for the serie I'm currently working on {{2021 All Japan Road Race Championship Round 1 Sugo}} but I'm not sure it'd work for all cases.

As for the references, so far I only added data with existing references, although I didn't add them to WD mainly due to laziness :-) barring me to investigate how to add them with QuickStatements, here's another item on my to-do list while you'll be thinking about it haha.

I didn't get what you meant with the inflation of the number of qualifiers, but it will probably clear up if you point me to an actual example.

If you don't mind, I'd get back to you in 10 days or 2 weeks on this, see where you are, but feel free to elaborate/complete your answer in the meantime if you feel like to.

Thanks again

Maybe setting up a sandbox for development would be handy, but I see no harm in just working on the kinds of races you are currently doing (low-traffic ones) to work out the structure. I hadn't thought about it, but you are probably right, there should be a QID for the entire event, and all of the sessions should be part of (P361) that parent. Naming will probably differ based on the series and how their events are structured. I could see '1950 British Grand Prix weekend' with parts including '1950 British Grand Prix', '1950 British Grand Prix qualifying', etc., as in Formula 1 it is common to refer to the entire event of the round as 'the weekend' (even if not strictly on those days). In MotoGP, I'm not as sure on how things are structured, so maybe the labels would be a little different. For series that have multiple races per event (Formula E for one) something like 2021 Diriyah ePrix (Q105680379) with parts '2021 Diriyah ePrix Race 1' and '2021 Diriyah ePrix Race 2', '2021 Diriyah ePrix qualifying', etc. I don't think I'm too worried about the actual labels themselves (they aren't sourced and can be easily changed), but it is good to get the actual structure down. It will allow for using tools like QuickStatements to add large amounts of data, and could really improve our coverage of these races.

As for qualifiers, don't worry about it for now, that has more to do with a fundamental Wikidata issue, in that we use qualifiers in a couple of different ways they weren't originally designed for and there are inherent problems with that, but that's a lot bigger than this, so we can work within the way things are done.

Hopefully are away for an awesome reason like seeing a real race, but in any case, I'll add to this as things come to mind and look forward to chatting on your return.

Hi,

I tried a few things with the structure, you can see an embryo of 2 different tree structures here, whether we use the relationship part of (P361)/has part (P527)

• between one particular instance/year of the whole championship and every events/weekends that year ( case 1 )

or

• between that particular instance/year and every category/class such as J-GP3 (Q99541008), JSB1000 (Q100166372), raced that year... ( case 2 )

Previously I also used Q100151585#P3450 and Q100151585#P793 to link a specific class/category's season and the races it consists of...

Could you have a look and tell me if you favor one way over the other ( or even something different ).

NB: no awesome reason for the previously planned hiatus of 10 days/2 weeks except letting you breathe a little and giving myself time ( it didn't take much as you can see ) to get to the next roadblock in that "structure journey" :-)

Thanks

Hi,

Should did not finish (Q1210380), did not qualify (Q99288021), did not start (Q1210382), not classified (Q99291555) be allowed as value for ranking (P1352) ?

I'm contributing on motorcycle races/riders and I often see lap time sheets without a ranking usually because the rider didn't cover at least 75% of the race distance due to a mechanical failure (Q15831488), accident (Q171558), collision (Q238053), engine failure (Q46375738) before reaching that threshold, for the other riders who endure the same fate but cover the minimum number of laps, their ranking appears and they score points according to that ranking.

What would you suggest/advise ?

current situation for those covering more than 75% of the race distance, on the lap time sheets usually given a ranking, eligible for points

⟨ 2020 JSB1000 Sugo Race 1 (Q106237519)    ⟩ general classification of race participants (P2321) ⟨ Kousuke Akiyoshi (Q1145868)    ⟩
ranking (P1352) ⟨ 14 ⟩
laps completed (P5349) ⟨ x lap ⟩
end cause (P1534) ⟨ mechanical failure (Q15831488)    ⟩

for those covering less than 75% of the race distance, on the lap time sheets usually given no ranking, appears as not classified (Q99291555), not eligible for points

current situation

⟨ 2020 JSB1000 Sugo Race 1 (Q106237519)    ⟩ general classification of race participants (P2321) ⟨ Kousuke Akiyoshi (Q1145868)    ⟩
ranking (P1352) no value Help
laps completed (P5349) ⟨ x lap ⟩
end cause (P1534) ⟨ mechanical failure (Q15831488)    ⟩

proposed modification

⟨ 2020 JSB1000 Sugo Race 1 (Q106237519)    ⟩ general classification of race participants (P2321) ⟨ Kousuke Akiyoshi (Q1145868)    ⟩
ranking (P1352) ⟨ Q99291555 ⟩
laps completed (P5349) ⟨ x lap ⟩
end cause (P1534) ⟨ mechanical failure (Q15831488)    ⟩

for those who retire

current situation

⟨ 2020 JSB1000 Sugo Race 1 (Q106237519)    ⟩ general classification of race participants (P2321) ⟨ Kousuke Akiyoshi (Q1145868)    ⟩
ranking (P1352) no value Help
laps completed (P5349) ⟨ x lap ⟩
end cause (P1534) ⟨ mechanical failure (Q15831488)    ⟩

proposed modification

⟨ 2020 JSB1000 Sugo Race 1 (Q106237519)    ⟩ general classification of race participants (P2321) ⟨ Kousuke Akiyoshi (Q1145868)    ⟩
ranking (P1352) ⟨ Q55669390 ⟩
laps completed (P5349) ⟨ x lap ⟩
end cause (P1534) ⟨ mechanical failure (Q15831488)    ⟩

something else...

By the way we should compare did not finish (Q1210380), did not qualify (Q99288021), did not start (Q1210382), not classified (Q99291555), make sure they behave the same way...looking forward to reading your comment Serpicozaure (talk) 16:13, 10 April 2021 (UTC)

edit: see also if we merge retirement (Q55669390) with did not finish (Q1210380) or something...

This is an excellent question. I do think we should capture all participants, classified or not, in some way. It does seem that ranking (P1352) is a required qualifier of general classification of race participants (P2321), but I like the use of 'no value' to indicate they did not get classified/receive a ranking, so I think that works okay-ish. the problem with using not classified (Q99291555) or retirement (Q55669390) as a value for ranking (P1352) is that the property is a quantity data type, so we would have to create a new property you could link items to for that. As for all of the possible items (did not finish (Q1210380), etc.) and how they behave, different race series may have slightly different definitions and rules that apply to these so how they are used may differ from series to series or year to year as regulations are changed. What exactly retirement (Q55669390) and did not finish (Q1210380) are supposed to cover is a bit vague, but I could see there being two different things covered here, one being the official status/result as determined by race officials, and the other a more general reference to the action of retiring from an event independent of how it is officially logged. However, I'm not sure how important that distinction is, and if it is even clear with the two as they are now, so a merging might be okay for now, and a new item can be created if a future user sees value in a differentiation and can adequately define the new item.

What bothered me in the first place is, I can't use did not finish (Q1210380), retirement (Q55669390), did not qualify (Q99288021), did not start (Q1210382) nor not classified (Q99291555) with ranking (P1352) because it requires a quantity data type.

However I've seen them used with end cause (P1534) but I feel there's a chronological/causality issue here, one suffer a mechanical failure (Q15831488) or whatever else and thus has to did not finish (Q1210380) or retirement (Q55669390)...how do you see it ? if you agree, using did not finish (Q1210380), retirement (Q55669390), did not qualify (Q99288021), did not start (Q1210382) shoudn't be possible with end cause (P1534), if we ignore/don't know the cause then we should leave blank/not fill it, and modify end cause (P1534) so it didn't accept those values or raise a warning...

Well I certainly agree that something like did not finish (Q1210380) should not be used with end cause (P1534) and that should be reserved for the reason for such a DNF, not the DNF itself. Perhaps something along the lines of award received (P166) used as an additional qualifier with a value of did not finish (Q1210380), etc. would do it, though probably not actually award received (P166). We have points for (P1358) for the actual number of points awarded, but I don't know of an existing good property for DNF, etc. 'awards' to be listed under, so I would support a new property to do this.

Josh, why are you regularly going around removing the name of the manufacturer from aircraft item titles? What policy or guideline is being enforced here, because it feels like personal preference, and it certainly goes against common naming practices across all projects.

Labels in WD have a very different purpose than article or category names, and in fact are not names at all. Take F-16 Fighting Falcon (Q100026) for example. The name of this item is "Q100026". While exact details on how labels are implemented is still in development for Wikidata (see Help:Label), there are some things we have been implementing since the first days of the project.

1. There is no need, and in fact it is counter-productive to try, to attempt to correlate labels with names used on other projects. Our name is "Q#". While it is perfectly logical for Wikipedia or Commons to include manufacturer names in aircraft article names in order to ensure consistent avoidance of duplication, that is not an issue for WD labels.
2. Labels do not need to be unique. There can be 100 items with the same label on WD without any issue. For this reason, long labels with disambiguation elements are not desirable. Disambiguation is instead the role of the description. Thus it not valuable to have the manufacturer in the label of an aircraft item, but it is valuable to add it to the description.
3. Aliases are a unique system to WD and work very differently from redirects on other projects. Thus it is valuable to have an alias that matches various other project names for their aircraft articles, and doing that further removes the value of including the manufacturer in the label.

So this is why the manufacturer name is not required to be included in the label, but is there harm in retaining it in the label anyway even if it is not required? To answer this, one needs to go deeper into what aircraft items on WD really represent. For the most part aircraft items are for classes of aircraft. If every instance of that aircraft class was manufactured by the same manufacturer, than it would not necessarily be a problem to include the manufacturer in the label, as that would be accurate. While not required, it would not be inaccurate either, so not a particular problem. However, take the aforementioned example (F-16 Fighting Falcon (Q100026)). This class includes instances manufactured by General Dynamics, SABCA, Lockheed Martin, and so on. Including any one of these in the label for the entire class would be not only not required, but would in fact be inaccurate as well for a great number of the instances of that class.

Instead, there are several accurate methods of making sure the manufacturer information is accurately included in an item:

1. Include it in the description. This is actually quite valuable, and for aircraft, descriptions that have the basic info of year (first flown), function (primary design role) and manufacturer (initial designing/building entity) make it very easy to quickly identify the correct entity when searching.
2. Include it in the aliases. This ensures searches which include the manufacturer name will discover the entity.
3. Add a manufacturer (P176) claim. This makes it both machine and human readable and allows qualifiers and references.
4. Add a official name (P1448) claim with correct qualifiers and references.

Yes, I do know how labels function, in detail, thanks. I was hoping for documented specific best practices. Help:Label is woefully inadequate to its purpose, like most help topics here, so I suppose such documentation simply doesn't exist. Less talking down to would have been appreciated.

The problem, as often is the case, is that you must trade off technical desires for functional usability. WD's mindset against this is what makes me fear the signal-to-noise ratio will eventually (well, fairly rapidly) overwhelm things. Already, the vast import of journal article titles has made finding some common terms so difficult its just not worth pursuing when building new items.

Unfortunately, you are not wrong about the lack of good documentation for WD practices. The project certainly could do with better documentation on a wide number of issues.

That said, I'm not sure why you first decided to denigrate my efforts as merely enforcing 'personal preference', and then upon receiving a detailed response, denigrated that as 'talking down to' you. Statements along those lines make a rational discussion difficult. I would certainly never presume to 'talk down' to any other editor, it would be far to presumptuous. I simply provided a detailed rationale because #1) you asked, and #2) I am well aware of the incomplete nature of current guidelines and policies on WD.

As for your general statements about the mindset of WD, I don't know exactly what you are getting at there. What 'functional useability' is it that we are losing out on due to 'technical desires'? Also, what do you mean by common terms being difficult to find due to journal articles being included? And why does this deter you from creating new items? Do you have some specific examples of these issues?

I'm sorry, Josh, my frustrations with the site and practices got the better of me. I think my mind was moving along the lines of "templating the regulars".

As for the last part, my concern is third party usefulness. Yes, internally it may be desirable for labels to be as you describe, but that decreases usability by others who may not be as knowledgeable or specifically inclined. WD already has a monumentally more steep learning curve than any other Wikimedia project, it seems unfortunate to make it even more opaque than it already can be. Regarding common terms, when adding values to properties I'm inundated with journal article titles (and to a much lesser degree, book chapters and magazine articles) that obfuscate more useful returns in the dropdown. Not knowing the system's back end, I'm at a loss of how it might be improved, but it is beyond frustrating when trying to find a useful item.

No problem, I get frustrated myself with things, so consider it forgotten.

I do see third party use as an area that has never been adequately worked out. In this vein, labels are one of the worst offenders, if you will. Since labels are both one of the easiest things to access from other projects, and they appear at first glance the same way as article names do, there are a lot of templates and scripts on other projects that simply grab the label to use directly in their own project and assume they are treated the same way as article names (I know some of my early templates on Commons did just this). One problem with this though is that if they want to change how it appears on their project, the easiest (or at least most expedient) way is to come to WD and change the label. Also, if the WD label is changed later, it likewise changes the third party project page and people get a bit miffed at that sometimes. People also get frustrated if WD uses a different scheme for labels than the third party site does for article names. On the WD side, you could potentially have different third party users desiring different labels for the same thing. Fundamentally, this is a WD problem because labels are not handled like claims, and so cannot be referenced, ranked or qualified which is how we would normally handle data. Thus it is far better if a third party instead only pulls claims (such as a official name (P1448) claim) which can be properly referenced and qualified, and we can support multiple claims in parallel so no need to argue which stays and which goes. However, that is an entire new level of work and learning curve to be overcome and as you correctly mention, the learning curve on WD is already steep. I have no good answer for this!

The journal articles do seem to be a bit spammy. For me, it seemed for a while I was wading through endless drop downs of genes and proteins to try and find things. I guess depending on how a search is worded, a different set of spam will appear in your way. The sheer quantity of items in the database is making it harder and harder. I remember when we used to celebrate our 1 millionth, 2 millionth, etc. milestones, but now with 100+ million items, that seems a long way back. Given that we seem to be only scratching the surface on several topics, we could be in the billions before too long. One thing I've been doing is if I know the label is likely to be similar to other items, I add an alias which matches the label with a simple word such as 'aircraft' appended. For example, search for "Boston" and you get a ton of items. Search for "Boston aircraft" and you get right to the DB-7 item. I've seen others doing this too (I didn't invent the tactic), but it is hardly universal or standardized, so it is still not a real answer to the problem. Again, I have no true good answer, just trying to do what I can. I'm trying to think of a use case in which it is more difficult to find an item on account of it not including dab info such as the manufacturer. I would really like to dig into such a case and see what we can do to improve the situation. In any case, let's keep sharing ideas and info. Thanks!

This is a kind reminder that the following properties were created more than six months ago: maximum thrust (P2228), compressor type (P1221), time to altitude (P2362), takeoff roll (P2430). As of today, these properties are used on less than five items. As the proposer of these properties you probably want to change the unfortunate situation by adding a few statements to items.