User talk:Huntster/Archive 1

This page is an archive. Please do not modify it. Use the current page, even to continue an old discussion.

Autopatroller

Hello, Huntster! I am just letting you know that I have added the autopatroller flag to your account, as you are a trusted user on Wikidata. If you have any questions or concerns, please don't hesitate to contact me or leave a message at the Project chat. Thanks, Bináris (talk) 01:17, 15 February 2013 (UTC)

Thanks Bináris! I look forward to doing some useful work here. It'll be so nice to have the interwikis in one centralised location. Huntster (talk) 11:44, 15 February 2013 (UTC)

Borrado de declaración

Hola Huntster. No entiendo el sentido de esta edición y espero que no continúes eliminando contenidos parecidos, complica mucho la importación de datos a las infoboxes. Estos datos añadidos en un bloque donde se define el inicio y el final del acoplamiento son más fáciles de tratar que si se hace por separado, es casi imposible recuperarlos para mostrarlos en una infobox. Si tienes interés en cambiar el modelo no hace falta que borres el anterior, WD permite que convivan diversas formas de recopilar información. Y si piensas que es imprescindible el cambio, además de explicar el motivo, sería un detalle que avisaras ya que estos cambios afectan a multitud de artículos. Gracias.--Kette~cawiki (talk) 11:40, 24 July 2021 (UTC)

Kette~cawiki, Google Translate is not being clear enough, so I'm not sure exactly what you're referring to. I'm going to guess that this is about refine date (P4241) being removed from significant event (P793)? Sub-properties within significant event (P793) are meant to be independently defining to the item being mentioned. Because refine date (P4241) is meaningless by itself, it should not be used in significant event (P793), and only in main properties like point in time (P585) and similar. Sub-properties should not define other sub-properties. Remember also, significant event (P793) is meant to be a chronological summary of events, while properties like UTC date of spacecraft launch (P619) or service retirement (P730) should contain more specific details. — Huntster (t @ c) 06:06, 25 July 2021 (UTC)

Hola, vuelve a repetirse la situación. Mi trabajo consiste en dotar a las fichas (infoboxes) de la capacidad de importar todo su contenido de WD. Una de estas plantillas és ca:Plantilla:Infotaula vol espacial, el equivalente a en:Template:Infobox spaceflight. Todo fue facil hasta que tuve que importar los datos que proporcionaba la subplantilla: en:Template:Infobox spaceflight/Dock, no habia nada que pudiera utilizar en WD y tuve que crear una estructura de datos basada en significant event (P793) con el valor docking and berthing of spacecraft (Q557450), la primera vez que se subiero este tipo de datos fue en Apollo 11 (Q43653) → special:diff/980244556. Tampoco encontre ninguna estructura que me permitiera importar los valores de en:Template:Infobox spaceflight/IP y cree estructuras nuevas que otros editores han ido utilizando. Estas estructuras de datos han durado años sin que nadie comentara nada y ahora tu substituyes calificadores (qualifiers) sin ninguna explicación. No estoy en contra de que añadas pero si de que borres, ¿has tenido en cuenta si alguien utilizaba estas estructuras? ¿Existe alguna discusión o propuesta para que borres elementos que llevan años utilizándose? Vuelvo a recordarte que pueden coexistir diversas formas/estructuras de datos, que para borrar algo hay que tener en cuenta que alguien lo puede estar utilizando. Igualmente que no borré start point (P1427) y UTC date of spacecraft launch (P619), que llegó a proponerse su supresión, cuando empecé a usar significant event (P793) = rocket launch (Q797476) por si alguien los estaba utilizando. Por eso considero que no debes borrar elementos de estructuras que llevan funcionando años sin consensuarlo con nadie. Recuerda que WD no es mas que una colección de datos que no sirven de nada si no se convierten en información cuando se utilizan en los diversos projectos de Wikimedia, de hecho, la razón de existir de WD es la de servir de base de datos centralizada para los diversos proyectos que configuran Wikimedia, en consecuencia sí hay que tener en cuenta las necesidades de quien importa estos datos. Si la decisión es tuya, personal, debe quedar constáncia que no estoy de acuerdo y, por lo tanto, este tipo de ediciones tuyas no tiene consenso, no has dado ninguna explicación del porque borras elementos que llevan utilizándose años.--Kette~cawiki (talk) 18:19, 15 November 2021 (UTC)

Kette~cawiki, while I understand the frustration with getting the infobox to work, I'll repeat myself: It is not the responsibility of Wikidata to fit the shape that ca.wiki or any others demand, it is the responsibility of the individual wiki to correctly implement the data provided. Otherwise the project will be pulled in a dozen different directions and warped until everything is an unusable mess. Fix the infobox template so that it can use the data provided, and ensure it is flexible enough to accommodate changes. If you design the infobox in such a way that it only works in one and only one way, then you have a serious problem. Allow for additional inputs. — Huntster (t @ c) 14:30, 17 November 2021 (UTC)

Aquest no és el cas, ets tu qui està canviant les estructures de dades que funcionen fa anys, editant uns pocs ítems, el que representa que la major part dels articles es veuen bé i en uns quants desapareixen les dades. La infotaula està creada amb aquella estructura de dades molt abans que comencesis a canviar-les, sense acordar-ho amb ningú. Encara que estigués d'acord amb l'estructura que has creat, que no ho estic, no puc canviar el codi pels «quatre» articles que has canviat. Si fos el cas, caldria implementar tots els Items per canviar el codi, i mentrestant s'ha de mantenir l'estructura que funciona des de fa temps. I no, no és mal codi, l'estem exportant a un bon grapat de Projectes, pots veure el resultat als articles de cawiki. Pots comparar com queden després dels canvis: ca:Apollo 11 que has editat amb ca:Apollo 12 que encara no has esborrat res, la diferència esta a la part baixa de la infotaula (infobox)--Kette~cawiki (talk) 14:41, 17 November 2021 (UTC)

If you don't understand the fallacy and danger of the model you're proposing, then nothing I say will change your mind. — Huntster (t @ c) 15:49, 17 November 2021 (UTC)

No es tracta de canviar d'opinió cap dels dos, es tracta de poder mantenir dues estructures diferents fins que es prengui per consens la decisió de quina és la més adient. No demano de esborrar el que tu edites, no, però per compatibilitat s'han de mantenir les estructures que han funcionat fins ara fins que tots els articles estiguin homogeneitzats, no es pot fer un codi per dada article, la infotaula és per tots els articles del tema, no podem codificar una plantilla per cada tipus d'estructura. Tinc la impressió de que no entens com funcionen les plantilles que importen les dades de WD. Aprofito per comentar que no sóc l'unic que puja dades amb aquest esquem.-Kette~cawiki (talk) 16:02, 17 November 2021 (UTC)

Yes, I do know how such templates work, and that they are capable of such flexibility. But you have touched upon the true danger of relying on Wikidata in this manner: anything can be changed at any time, across any item, and potentially cause problems in an endless variety of ways. Compound this with the potential of multiple projects wanting to store and use data in their own particular way, which leads to chaos.

There are virtually no standards of operation here, very little in the way of "best practices". The Wikimedia Foundation essentially turned the keys over with zero guidance, and unlike how policies and procedures were developed to govern operations on the sister projects, that hasn't really happened here.

Sorry for the rant, but this is a problem that has been bothering me a great deal for some time now. Wikidata is very useful for storing information and sources for easy retrieval, but it is not (yet/at all) useful as a distribution platform. It won't be until clear standards are written that state when and how particular sub-properties should be used. — Huntster (t @ c) 17:21, 17 November 2021 (UTC)

Commons category

Q15640183 is just a redirection to Q1136659. If any it should be removed from it and added to Q837515 - הנדב הנכון (talk) 08:21, 1 November 2021 (UTC)

הנדב הנכון: solar thermal collector (Q837515), solar water heater (Q15640183), and solar water heating (Q1136659) are three separate items. solar water heater (Q15640183) is a subclass of solar thermal collector (Q837515), and is a facet of solar water heating (Q1136659). None are redirects, so I'm not sure what you're talking about, and all have wiki articles associated with them and cannot be redirected in the first place. — Huntster (t @ c) 12:29, 1 November 2021 (UTC)

Ah, I see the issue, I think. solar water heater (Q15640183) and solar water heater (Q99147642) are duplicates. I'll take care of that. — Huntster (t @ c) 12:30, 1 November 2021 (UTC)

demolished or destroyed (Q56556915)

Hi Huntster, I have removed your change to Q56556915 because I think this is a status, not an entity, an therefore not a subclass of an entity. Okay? -- Gerd Fahrenhorst (talk) 07:52, 6 November 2021 (UTC)

Gerd Fahrenhorst, I feel like demolished or destroyed (Q56556915) can be more than simply a conservation status, and it seems to be a logical subset of former entity (Q15893266) (after all, something that is destroyed is by its very nature a former entity). However, I will not challenge your removal. Can you think of any other way to show a relationship with the broader spectrum of entity conditions? — Huntster (t @ c) 09:05, 6 November 2021 (UTC)

Thanks a lot for helping me!

You help fixed many of my newbie mistakes, and I really appreciate that :) I'm trying to make an unified infobox for all stuff rocketry, and this is the first article to be implemented. CactiStaccingCrane (talk) 04:51, 9 November 2021 (UTC)

CactiStaccingCrane, it's no problem. I make mistakes too, because Wikidata is so vast and complicated. I've simply been around the Wiki ecosystem since 2004. Please ask questions any time, and I'll help to the best of my ability. — Huntster (t @ c) 05:00, 9 November 2021 (UTC)

Wait what? You are here since 2004? That's a really long time! CactiStaccingCrane (talk) 05:03, 9 November 2021 (UTC)

CactiStaccingCrane, lol, yeah. I'm an admin on en.wiki and commons, though I'm not very active anymore. Life has a funny way of doing that the older I get. Wikidata is nice because it's just pure data, and I love it. No prose or flowery language to worry about. — Huntster (t @ c) 05:06, 9 November 2021 (UTC)

I have a feeling that Wikidata, not Wikipedia, is the thing that we are gonna send to aliens. Just logic and no fluff. CactiStaccingCrane (talk) 05:08, 9 November 2021 (UTC)

CactiStaccingCrane, I think you're right on that count. Just need a few billion more items! — Huntster (t @ c) 05:12, 9 November 2021 (UTC)

I just finished my documentation of the infobox template here: en:Template:Infobox rocket. Do you think that these properties are accurate for the job? CactiStaccingCrane (talk) 08:07, 12 November 2021 (UTC)

CactiStaccingCrane, an issue I see is an over-reliance of of (P642) for properties. While unfortunately of (P642) tends to be widely used, it is rarely correct. I've been trying to fix instances I come across with criterion used (P1013) or has characteristic (P1552), as appropriate. Somtimes of (P642) is useful, like "Manufacturer - Of - Entity", but often you see "Mass - Of - Takeoff" which is just not correct (for both Of and Takeoff) but unfortunately still used a lot. If there is some way to accept alternate properties in a hierarchy, such as "criterion used (P1013) > of (P642)", that might be more useful under a wider variety of use cases. Once it's more widely implemented it will be easier to see what works and what doesn't. My brain is simply too overwhelmed by recent IRL stuff to troubleshoot very much.

Oh, one other concern is that using Wikidata information does not allow for conversions of measurements, which is something that will cause some significant backlash on en.wiki, I suspect. — Huntster (t @ c) 03:00, 13 November 2021 (UTC)

Thanks a ton for your help! About measurement, one way that you can get around it by putting both imperial and metric unit and state one of them is preferred (because the source said so). CactiStaccingCrane (talk) 05:38, 13 November 2021 (UTC)

CactiStaccingCrane: I used to do this exact thing when I first started on WD, but at some point was informed that it caused issues. It's been too long for me to remember anything specific, but I do recall there being problems with doing that, because I hard stopped adding them. Hmm. And, to be fair, if you're not using metric then you're doing it wrong, lol. — Huntster (t @ c) 07:57, 13 November 2021 (UTC)

person or organization (Q106559804)

I see that you reverted a change to 'person or organization' Q106559804. As it currently stands, the subclass relationships state that everything inheriting from 'person or organization' is simultaneously a person and an organization. It would appear that these relationships are backward. A person is a 'person or organization', and an organization is a 'person or organization.' This issue is causing me considerably annoyance in editing OpenStreetMap, because the editor that I'm using (correctly) warns if the map asserts that a geographic feature is a person, so every time I touch something like a boundary line, I get hundreds of spurious warnings. Since you already reverted the fix once, I thought I'd contact you here. – The preceding unsigned comment was added by Ke9tv (talk • contribs) at 09:02, 16 December 2021‎ (UTC).

Ke9tv: yes, this is a conundrum. The issue I was trying to prevent was all the downstream items that use person or organization (Q106559804) but ultimately rely on person (Q215627) and organization (Q43229) (such as manufacturer (P176) requiring organization (Q43229) as a constraint). How could we restructure these items to satisfy both your requirements and the logical tree?

I've written and rewritten this several times over the past little while, looking at different angles. Is it really going to be best to have person or organization (Q106559804) as the subclass of person (Q215627) and organization (Q43229), and force items like manufacturer (Q13235160) to have subclasses of both person and organisation with natures of statement sometimes (Q110143752)? Looking further into things, this whole tree is really messy.

Thank you for reaching out and communicating. I should have done that in the first place. — Huntster (t @ c) 20:43, 16 December 2021 (UTC)

'Person or organization' would be a superclass of 'person' and 'organization', not a subclass. 'Manufacturer' would be a subclass of 'person or organization' rather than just of 'organization'. And I think that Wikidata already has some concept like 'legal person' that's already in the right relation in the tree. Ke9tv (talk) 23:08, 16 December 2021 (UTC)

Ke9tv, yes, I worded those relationships poorly. The issue is that Manufacturer would have to be subclass of both Person and Organisation, since a manufacturer can be either, and is why I proposed using "Sometimes" for both to denote Manufacturer could be either/or (since there is no better term I can find here). And yes, I had to work on the Person -> Legal Person -> Natural Person -> Human tree a bit earlier since it was all sorts of wonky. — Huntster (t @ c) 01:08, 17 December 2021 (UTC)

Not so.

Person or Organization ---subclass---> Person

Person or Organization ---subclass---> Organization

Person or Organization ---subclass---> Manufacturer

A Manufacturer is a Person or Organization. A Person is a Person or Organization. An Organization is a Person or Organization. Manufacturer does not subclass Person directly; it subclasses the Person or Organization class above Person.

If you do it the way you describe, you are asserting that all manufacturers are both persons and organizations. It's conceivable that there would be a class somewhere, probably called something like Sole Proprietorship, that would inherit from both Person and Organization. (A type of organization that always is identified with a single person.) But they way you're trying to structure it is just wrong, and it's causing problems elsewhere. Please put it back! Ke9tv (talk) 02:24, 17 December 2021 (UTC)

Ke9tv, not all Persons are Organisations and not all Organisations are Persons. While many/most types of Organisations could be defined as Persons, there are exclusions. As I've said, if Organisation and Person (or whatever) are set as "nature of statement (P5102): sometimes (Q110143752)" when parents of manufacturer (Q13235160), it would hopefully be apparent that they are not both. I'm seeking better alternatives, though. For now, I'll revert to the previous version of "person or organization" so your efforts are not impeded, but the way it was prior to all of this cannot work in the long run, because it de-couples the subitems from this top-level item. — Huntster (t @ c) 05:22, 17 December 2021 (UTC)

(Jumping in because these warnings have caught the attention of the OpenStreetMap community.)

Can you elaborate on why manufacturer (P176) requires person or organization (Q106559804) to have sometimes-qualified superclasses? Its value-type constraint (Q21510865) is already qualified with both person (Q215627) and organization (Q43229), thus allowing the value to be a subclass of either. If a value of manufacturer (P176) is merely a subclass of person or organization (Q106559804) but not person (Q215627) or organization (Q43229), it's underspecified, isn't it?

sometimes (Q110143752) is an invaluable tool, but some uses would be analogous to what OSM calls a "troll tag". It would be pedantic to duplicate statements about each of the members of a dyad (Q29431432) onto the dyad itself, however qualified. I don't think the average SPARQL query author would appreciate having to filter out sometimes (Q110143752) subclasses of person (Q215627) when querying for entities that are recursively a subclass of organization (Q43229).

– Minh Nguyễn ^💬 05:53, 19 December 2021 (UTC)

Did you run into constraint problems when merging manufacturer (Q18244268) (previously an occupation, subclass of creator) into manufacturer (Q13235160)? I'd suggest undoing that merge so that we have separate items for a manufacturer as an occupation and a manufacturer as a role in the production process. (Some languages have quite distinct words for either concept, which you've now conflated.) Most corporate instances of manufacturer (Q13235160) are already separately instances of items like enterprise (Q6881511), but a separate "manufacturing organization" item would be reasonable if you're trying to minimize the number of instance of (P31) statements on manufacturer items. Minh Nguyễn ^💬 06:08, 19 December 2021 (UTC)

Mxn, see Wikidata:Project chat#Mutually exclusive "instance of"s for further discussion on the issue. Ex: Grumman (Q463261), because organization (Q43229) has been decoupled from manufacturer (Q13235160), all those errors are present. manufacturer (Q13235160) could either be a subclass of person or organization (Q106559804) which would be a subclass of person (Q215627) and organization (Q43229), or it could be a subclass of person (Q215627) and organization (Q43229) which could be subclasses of person or organization (Q106559804). I don't care which, but the first method makes the OSM community angry, and the second requires statements of Person and Org to show that Manufacturer could be one or the other, but not both. To date, no one has found anything that would make the second feasible.

I never said sometimes (Q110143752) was required, but simply a suggestion for what could help with the above issue. It's obviously not ideal, and I won't implement it. At this point I'm just beyond frustrated with a very broken system that I cannot meaningfully affect without pissing everyone off. I'll just get used to not caring if there are errors in items. *shrug* — Huntster (t @ c) 14:33, 20 December 2021 (UTC)

Regarding series, follows and followed by

I saw you reverted this edit. What I was trying to accomplish with that is a way to represent the mission's belonging to multiple series. For example: SpaceX Crew-1 is the first one in the Commercial Crew Pogram (followed by Crew-2) but not the first one in the overall series of flights of the Crew Dragon (follows DM-2). This is something that cannot be done (as far as I know) using the simple 'follows' and 'followed by' properties. What other alternative structure do you propose to represent these cases? Cheers, josecurioso ❯❯❯ Tell me! 13:25, 26 December 2021 (UTC)

Josecurioso, in that case, you can't use Dragon 2 (Q17122887) as the series, because that encompasses all Dragon 2 flights, including crew, cargo, and private spaceflight. I would use the already existing part of (P361)Commercial Crew Program (Q96375343) and add qualifiers follows, followed by, and series ordinal to that. But if you still want to use part of the series (P179) just make sure to use the most specific item possible, which again is Commercial Crew Program (Q96375343). Crew Dragon (Q105095031) would be a broader set of data, and Dragon 2 (Q17122887) would be even broader. — Huntster (t @ c) 13:54, 26 December 2021 (UTC)

solar panel (Q774583) and has part(s) (P527)

Hello, for what concerns this rollback, please notice that has part(s) (P527) is the inverse property of part of (P361), i.e., Xhas part(s) (P527)Y should be used when Ypart of (P361)X, not when Ysubclass of (P279)X. In other words, property has part(s) (P527) should be used for asserting the parts the subject is made of, not its possible sub-types.
The correct property for what you want to express is disjoint union of (P2738) (that I'd be going to use, if you agree). --Horcrux (talk) 09:06, 18 February 2022 (UTC)

Horcrux: No wonder, I can't say I've ever seen this property in use. It is non-intuitive in name and in use. Some of its constraints are...strange, such as requiring list of values as qualifiers (Q23766486) and of (P642); if a property requires a singular set of constraints in all applications, why have them at all when they can simply be assumed as part of the property? Makes no sense. This really should be re-examined. — Huntster (t @ c) 18:13, 18 February 2022 (UTC)

Changes in ÑuSat (Q28803027)

Hi, thanks for helping figuring out the right measurements. I was not sure and placed in the provided order - length/width/height. What is your logic in changing this numbers? I would like to know to use it in the future.- Cofcorpse (talk) 15:16, 14 July 2022 (UTC)

Oh, I think I understand know, I placed them in the wrong properties and you fixed it, correct?- Cofcorpse (talk) 15:20, 14 July 2022 (UTC)

Cofcorpse: Correct! When measurements are given with no specific mention of what they correspond to, the unspoken and near-universal rule is that the order goes "length-width-height". And, when I looked at the numbers compared to a visualization of the NuSat spacecraft in its intended orientation, the numbers match length-width-height.

Also, I would ask in the future to not use any Wikipedia project as a source, since self-edited sources are inherently unreliable. If the Wiki article has useable information, then that information should have a third-party source already. — Huntster (t @ c) 16:33, 14 July 2022 (UTC)

Yes, I added external source also. And wikipedia appeared as a source because I imported values from it using some gadget. I won't do it this way in the future. Thanks for answer!- Cofcorpse (talk) 16:35, 14 July 2022 (UTC)

Cofcorpse, you're correct, I should have specified using a Wiki article as the only source. I see those value importers being used with wild abandon on Wikidata, and far too often when I check the local wiki to pull an actual citation the article turns out to not have any. Regardless, thanks for your work on the NuSat entries! — Huntster (t @ c) 16:42, 14 July 2022 (UTC)

James McDivitt (Q364476)

Duplicates will be deleted or merged by bot in a few days, so it is not required to undo edits manually. Matlin (talk) 18:29, 18 October 2022 (UTC)

Matlin: The bot only gets exact duplicates, correct? I should have been more specific in my note, as this wasn't an exact duplicate but an inexact entry...namely the existing item was for the U.S.-specific brigadier general, and the item added was for the generic brigadier general. Import issues are pretty widespread...I often see importers adding generic "Kennedy Space Center" as a launch site when the specific pad is already present, or generic "Falcon 9" when the specific model is already present. The issue is that some importers don't check what they're importing, creating a mess others have to clean up. — Huntster (t @ c) 18:56, 18 October 2022 (UTC)

Artemis 1

Hi Huntster, by undoing my edit, you modified the data in Spanish Wikipedia. I don't understand much about wikidata, but that made the image description to be in English. Astromessier (talk) 22:24, 16 November 2022 (UTC)

Astromessier, just add a Spanish description to the main image. The local Spanish template should really just default to no description if a Spanish one isn't available, but in the meantime, just add a localized description. Just don't remove any others. — Huntster (t @ c) 22:32, 16 November 2022 (UTC)

@Astromessier, I should add that an image can have multiple language descriptions. Just add a new media legend (P2096) sub-property. I've added a rough Spanish translation, but please correct the phrasing as I'm sure I got it wrong, lol. — Huntster (t @ c) 22:33, 16 November 2022 (UTC)

Thanks, I was just going to ask you about languages. I thought that by selecting "Spanish" above, the data were edited only in that language, my mistake. Astromessier (talk) 22:51, 16 November 2022 (UTC)

Astromessier, I understand! If you ever have questions about working on Wikidata, please don't hesitate to ask. — Huntster (t @ c) 00:43, 17 November 2022 (UTC)

Thanks for teamwork

Thanks for adding statements to Kennedy Space Center Launch Complex 39 (Q845774), especially related to inception and construction. Senator2029 07:08, 25 November 2022 (UTC)

Call for participation in a task-based online experiment

Dear Huntster,

I hope you are doing good,

I am Kholoud, a researcher at King's College London, and I work on a project as part of my PhD research, in which I have developed a personalised recommender system that suggests Wikidata items for the editors based on their past edits.

I am inviting you to a task-based study that will ask you to provide your judgments about the relevance of the items suggested by our system based on your previous edits. Participation is completely voluntary, and your cooperation will enable us to evaluate the accuracy of the recommender system in suggesting relevant items to you. We will analyse the results anonymised, and they will be published to a research venue. The study will start in late January 2022 or early February 2022, and it should take no more than 30 minutes.

If you agree to participate in this study, please either contact me at kholoud.alghamdi@kcl.ac.uk or use this form https://docs.google.com/forms/d/e/1FAIpQLSees9WzFXR0Vl3mHLkZCaByeFHRrBy51kBca53euq9nt3XWog/viewform?usp=sf_link I will contact you with the link to start the study.

For more information about the study, please read this post: https://www.wikidata.org/wiki/User:Kholoudsaa In case you have further questions or require more information, don't hesitate to contact me through my mentioned email.

Thank you for considering taking part in this research.

Regards Kholoudsaa (talk) 17:43, 13 December 2022 (UTC)

Axiom 2

Hello. I see that you have removed the distinction MS1/MS2. But if you go to the Axiom web site the name of the files of both Saudis is clearly labeled MS+1.jpg and MS+2.jpg.

Hektor (talk) 08:23, 15 February 2023 (UTC)

@Hektor: Well that's certainly deeply hidden. I would not have guessed to look at the image filenames of all things for that data, since it isn't posted anywhere else that I've found. Good catch. — Huntster (t @ c) 14:18, 15 February 2023 (UTC)

@Hektor: Also, if by chance you come across any more information on Ali AlGamdi that narrows down his identity, it would be useful to create an item for him to add to the backup crew section. Right now the name is just too common and the only additional info I've seen published is that he's a Royal Air Force pilot. — Huntster (t @ c) 14:27, 15 February 2023 (UTC)

I got this : https://pbs.twimg.com/media/FoxhWmIXsAQJ6qs?format=jpg&name=large Hektor (talk) 15:05, 15 February 2023 (UTC)

Nice, thanks. — Huntster (t @ c) 15:51, 15 February 2023 (UTC)

Cause of death in the Montreal Airbnb fire

Hi there. As you'll see, I had previously added that statement as well for the two victims of the fire in Wikidata. But I removed that as I undid your subsequent re-addition because we don't yet know what caused the fire. It's still possible this could have been arson, a deliberately set fire, in which case the deaths would not be accidental. I'm sure that we will get a statement soon enough from the Montreal fire department and will have reliable sources indicating that this was an accident or not. So let's just wait? Shawn à Montréal (talk) 16:04, 29 March 2023 (UTC)

@Shawn à Montréal, of course, your reasoning is sound. Honestly, I only added it because of the flag that "Cause of death" should be accompanied by "Manner of death". — Huntster (t @ c) 19:17, 29 March 2023 (UTC)

Yes me too! I only did it when I saw that flag but then I realized it's premature. thx, Shawn à Montréal (talk) 20:19, 29 March 2023 (UTC)

Has part(s) vs. has part(s) of the class?

Hi, with additions like [1], wouldn't has part(s) of the class (P2670) be better than has part(s) (P527)? Since the thing being linked to isn't actually part of the telescope, so shouldn't be inverse? Thanks. Mike Peel (talk) 15:46, 14 May 2023 (UTC)

@Mike Peel: If that is your suggestion then I gladly accept. I've had issues using that property in the past (such as it's constraint against anything using subclass of (P279) which makes no sense) so I have an unfortunate habit of avoiding it. Thanks for the heads up. — Huntster (t @ c) 16:22, 14 May 2023 (UTC)

GPS Navstar / SVN numbers

It seems that GPS sats Navstar number is generally different from SVN number. I'll wait with doing more fixes, maybe you'd like to do it yourself. Regards, —Mykhal (talk) 10:39, 3 June 2023 (UTC)

It took me a minute to understand what you were referring to as those edits were back in 2021, heh. Looking at Gunter's site, seems you're right. I can sweep through the GPS series and do the renaming, hopefully tomorrow, I'm just heading out on a short trip at the moment. — Huntster (t @ c) 14:31, 3 June 2023 (UTC)

I've planted ~hidden pings into several of my yesterday edits… so they did not work? Anyway, I just wanted to prevent any misunderstandings / edit battles .. so it seems we agreed on the topis. I have already stared adding missing Navstar 1 etc .. (but stopped for Navstar 12 for now, which I don't see confirmed by NASA NSSDCA). —Mykhal (talk) 14:42, 4 June 2023 (UTC)

@Mykhal: Unfortunately no, the pings didn't work. I know of no way to ping someone within the edits themselves. Yes, we agree the numbering is off. However, I'd like to propose using a uniform naming system for the GPS units so that they're more easily recognizable by name, rather than using the USA designations, which are also used for a wide variety of other spacecraft. Navstar # is a possibility, but I would actually propose to use GPS SVN # for them. All units have an assigned number, and having GPS in the name makes it instantly recognizable. Thoughts? — Huntster (t @ c) 14:50, 4 June 2023 (UTC)

(Interesting, wikilinks to users in summary edits (with whatever label, I often use '.') normally work as ping at least in some wikipedias.) Satellite related stuff is only my hobby (and I may be exaggerating), so I don't want to dispute on primary names / labels. —Mykhal (talk) 11:49, 5 June 2023 (UTC)

Hello

Hello, how can you link these two articles?

https://es.wikipedia.org/wiki/Antonia_Tejera_Reyes_(M%C3%A9dium_canaria)

https://it.wikipedia.org/wiki/Antonia_Tejera_Reyes 87.223.207.41 08:39, 4 July 2023 (UTC)

Done: Antonia Tejera Reyes (Q2876814): Spanish psychic and medium (1908-1983). It requires merging the two WD items, which is most easily done with a gadget (but requires having an account). — Huntster (t @ c) 11:09, 4 July 2023 (UTC)

Orbits around Lagrange points

Hi! I see you reverted my edits to P397/Q186447 to specifiy that JWST orbits around L2. What's wrong with that? wp:en states that an orbit "is the curved trajectory of an object such as the trajectory of a planet around a star, or of a natural satellite around a planet, or of an artificial satellite around an object or position in space such as a planet, moon, asteroid, or Lagrange point." I was simply reflecting the last part to Wikidata. Don-vip (talk) 14:02, 24 July 2023 (UTC)

@Don-vip: Wikipedia can say whatever it wants, it is not WD. Please remember to not conflate the two, especially considering the multitude of wiki language sites we have. The property specifically refers to astronomical bodies, physical objects, which a Lagrange point is not. — Huntster (t @ c) 17:50, 24 July 2023 (UTC)

@Huntster: OK I understand my mistake. The WD property label in French (my native language) is "orbite autour de" (literally "orbits around") but I didn't see the English definition is much more strict with "parent astronomical body". How do you think we could in Wikidata express the fact JWST orbits around L2? Don-vip (talk) 18:44, 24 July 2023 (UTC)

@Don-vip: That's interesting, and is a real problem with properties saying different things in different languages. What would the proper translation be? I'm limited on time right now, but I'll take a look at what the majority of languages say in a bit. Regarding JWST, I'm just not sure an additional property is needed. It already states destination point (P1444)L2-Earth-Sun (Q15725510)has characteristic (P1552)halo orbit (Q1133479) and type of orbit (P522)halo orbit (Q1133479)relative to (P2210)L2-Earth-Sun (Q15725510). — Huntster (t @ c) 19:24, 24 July 2023 (UTC)

@Huntster you're right it seems there enough information in JWST item, thank you. I'm not sure what would be a more appropriate translation. A literal translation would be "corps céleste parent" but I don't think any native French-speaking person would say that. I will discuss it with other French people. Don-vip (talk) 20:57, 24 July 2023 (UTC)

@Don-vip: Sounds good, thank you! — Huntster (t @ c) 01:03, 25 July 2023 (UTC)

VIASAT-3(.1)

Please don't remove authoritative sources based aliases. Thanks. —Mykhal (talk) 15:46, 11 August 2023 (UTC)

@Mykhal: What in the world are you talking about? The SATCAT has no decimal places, and "ViaSat-3" is redundant to what is already present, as well as potentially confusing with the overall name of the satellite fleet. — Huntster (t @ c) 15:49, 11 August 2023 (UTC)

Please ignore the fact I did mention "decimal point" when adding a name from the satellite catalogue. I think that the NORAD SATCAT name (string) deserves to be there as an alias at least, as it probably won't change. —Mykhal (talk) 15:53, 11 August 2023 (UTC)

And I really don't understand you, the addition is not redundant, rather a subset / substring of the current main label (not just a letter case variant). Regards, —Mykhal (talk) 15:57, 11 August 2023 (UTC)

I could understand it only from a perspective of a wikidata searcher, but that would not be correct approach. I guess you understand that multiple different items can have identical labels / aliases. —Mykhal (talk) 16:03, 11 August 2023 (UTC)

@Mykhal: I understand now. Sure, no issue there, though it's unfortunate Space Command (they took the SCN catalog over from NORAD) decided to assign a generic name to their entry rather than its proper name. As for redundancy, any person searching for or starting to type "ViaSat 3" or "VIASAT-3" or any variation thereof will return ViaSat-3 Americas (Q118125207), because Search ignores hyphens and capitalization. — Huntster (t @ c) 16:04, 11 August 2023 (UTC)

I've seen if from another angle (during learning about it, without having any prerequisite info in this topic) - that's unfortunate for ViaSat-3 being the name of a constellation, while ViaSat-1 and 2 being standalone sats :) —Mykhal (talk) 16:09, 11 August 2023 (UTC)

.. Btw, thanks for the correction. I still use Celestrak's (who still claims NORAD) data instead of space-track's because of user agreement, but I guess the former acquires them from the latter. —Mykhal (talk) 17:07, 11 August 2023 (UTC)

Oh goodness, I wonder why they still claim that? USSPACECOM took over from NORAD in 1985! — Huntster (t @ c) 17:09, 11 August 2023 (UTC)