About this board

Previous discussion was archived at User talk:Metamorforme42/Archive 1 on 2016-04-18.

SM5POR (talkcontribs)
SM5POR (talkcontribs)

Are there situations when a "#" character does not delimit a fragment identifier but should be encoded with "%23" to prevent a web client from detaching before transmitting the URI to the server? If so, we may have to define a mechanism to tell the difference. I just added a qualifier object has role (P3831)fragment identifier (Q1440450) to the formatter statement, not intended as an actual proposal, but rather as an illustration of the general idea (I iried has part(s) (P527) first but the constraints didn't allow that; ideally I'd like to say "object has part" but there is no such qualifier, so object has role (P3831) will do).

Metamorforme42 (talkcontribs)

Hi, this issue is open since 2017. Since 2022, it is also part of :phab:T314382 goal, which is still work in progress. However, there is a workaround with https://wikidata-externalid-url.toolforge.org. I added it to P9963, but we still need to wait for the cache to be updated to see the result (about 24h). If you have new elements to bring into the discussion, feel free to add them.

For more details about fragments identifiers, you can refer to https://www.rfc-editor.org/rfc/rfc3986.

SM5POR (talkcontribs)

Thanks; are we thus supposed to temporarily amend the formatter URL (P1630) and similar properties while we wait for the Phabricator ticket to be resolved? Seems like we should keep the current (old, non-working) format statement for reference pending the resolution then.

Ah, the temporary format is given prefered rank, of course (I just had a look at Larousse Online French Dictionary ID (P11118) to see what you did)! And has quality (P1552) URL redirection (Q1236807) is a good idea. I think I'll add reason for preferred rank (P7452) currently valid value (Q71536244) to indicate that things are supposed to change in the future.

Yes, I'm familiar with the IETF RFC series of documents; it's a true treasure trove of Internet history and lore. RFC 1300: Remembrances of Things Past (Q47463874) is a gem ("Jobs were to look for and Gates were to close"). And even as RFC 4042: UTF-9 and UTF-18 Efficient Transformation Formats of Unicode (Q47470295) was published as an April Fools' Day Request for Comments (Q1322187), it's actually a reasonable thing to implement, if you use the appropriate computer architecture.

I was just browsing RFC 3986 and related editions to try to figure out whether fragment identifier (Q1440450) should be considered part of (P361) a URL or a URI; I didn't find a clear answer since the abbreviation "URL" is essentially absent in more recent editions, replaced by "URI".

Metamorforme42 (talkcontribs)

Yes, we should keep the old URL as normal rank.

Good idea for the P7452.

Well, URLs are a subclass of URI, and the RFC 3986 states fragment identifier is a part of URI in Appendix A (first line).

Reply to "URL encoding of fragments"

Misinformation a subclass of Wikibase reason..?

5
SM5POR (talkcontribs)

Hi, I suggest you take a look at the current thread Wikidata:Project chat#Should cites IMDb (Q103598310), cites Wikidata (Q103598309) and cites Wikipedia (Q103598308) exist? (started 26 January, maybe soon archived), somewhere near the middle of it, where I post sort of a "case study" of why we currently have more than 9,000 technically valid (constraint-wise) potential reasons for deprecation, about two thirds of which seem to be outbreaks of COVID-19.

I conclude that this is due to misinformation (Q13579947) being a subclass of (P279) Wikibase reason for deprecated rank (Q27949697), which you made it on 30 October 2022, apparently in connection with declaring fake news (Q28549308) an instance of (P31) the same, though I don't see that it made any difference to fake news (Q28549308).

I consider removing that subclass statement, since a Wikidata internal entity (Q21281405) should hardly have any subclass items that aren't themselves internal entities, but before doing so I would appreciate any comments you may have on this matter.

I also consider drafting a property constraint as an attempt to discourage future subclass declarations like this one, but first I will probably need to learn more about the constraint system to make sure I get it right.

Metamorforme42 (talkcontribs)

Hello @SM5POR,

I don't remember exactly why I made this subclass declaration, but I guess it was related to special:diff/1761174400, which had a constraint violation. I probably tried to fix this using the subclass statement, before realizing I should use P31 instead and I probably forgot to remove the subclass statement.

But I agree with the whole reasoning you did. Feel free to remove the subclass. By the way, P31 of fake news (Q28549308) (currently, business (Q4830453)) is clearly wrong.

A new constraint to avoid this situation again would certainly be great, so you also have my support for that.

SM5POR (talkcontribs)

Thanks for the explanation, we seem to agree on the appropriate cause of action then. I'm not in a hurry, as I'd like the other editors taking part in the discussion to see the effects of this class tree structure.

As you noticed, your edit on Chuck Norris (Q2673) was reverted by an anonymous IP about an hour after you made it; I don't know why. One thing I found peculiar about your edit is however that you have added the false statement in Wikidata yourself merely to be able to deprecate it, a kind of preventive action to counteract rumors or "fake news". Is that common practice on Wikidata?

It was only a couple pf weeks later that another anonymous IP changed instance of (P31) of fake news (Q28549308) from industry (Q268592) to business (Q4830453). I actually think the latter has an element of truth to it, although I probably wouldn't express it in such a direct way. Consider for example Steve Bannon's infamous Infowars channel or Rupert Murdoch's media empire (including Fox "News"). I doubt they have been pushing Trump's delusions and other fringe conspiracies over the years merely for ideological reasons; there is apparently a lot of money involved in advertising aimed at a captive audience.

As the investigative reporter's mantra reads: "Follow the money."

I have modeled the constraint partly on the one designed to limit the number of direct subclasses of entity (Q35120), but added instance of (P31) as a suggested replacement since that's likely where another reason of deprecation should go.

subclass of (P279)property constraint (P2302)none-of constraint (Q52558054)

item of property constraint (P2305)Wikibase reason for deprecated rank (Q27949697)
replacement property (P6824)instance of (P31)
constraint status (P2316)mandatory constraint (Q21502408)
Metamorforme42 (talkcontribs)

For Chuck Norris, yes it's kind of preventive. The fake news propagated on Wikipedia (fr:special:diff/198235847), so I added it in Wikidata in the hope other Wikipedias editors could easily check the information and revert if it is added on their local wiki. Usually, when I patrol on wikipedia, it helps me to be able to rely on Wikidata for this kind of edits. Ultimately, I hope we will be able to write bots to automatically revert most of the fake-death announcements based on this kind of Wikidata statements…

For fake news (Q28549308), is the ambiguity coming from "fake news" = "piece of (intentionally false) information" versus "(fake) news media"? IMO, this item is about the first, and not the second.

For the constraint, maybe add a constraint clarification (P6607)?

SM5POR (talkcontribs)

You are right about "fake news"; didn't think about that ambiguity. But that's true for the word "news" as well, right? Still, there is only one sense news (L4311) for the English lexeme (S1), and it refers to the distribution of news, not the individual new item. In Swedish, the singular form "nyhet" refers to the news item, while the plural definite form "nyheterna" could mean either the news media, or a number of news items (nyhet (L46958)).

I hesitate to write clarifications in natural language; I'd prefer attaching an item and use the label and description, like the reasons for deprecation. Also see Property talk:P6607#Suggestion: Write constraint clarifications as full sentences for Lucas Werkmeister's proposal.

Reply to "Misinformation a subclass of Wikibase reason..?"
SM5POR (talkcontribs)

I just discovered your User:Metamorforme42/Ambassadors page. I'm somewhat involved with the Wikidata:WikiProject Data Quality/Issues/P642 and have tried to sort out how to deal with Wikidata:WikiProject Data Quality/Issues/P642#Qualifying positions, occupations, and roles using of (P642) in different ways.

One thing I found was that of (P642) has been used on different items to tell both which country an ambassador serves and which country he or she has been sent to. That made me suggest two new properties in service of and assigned to to replace of (P642) for these two purposes. I expect to see them used for other than diplomatic roles as well.

In preparation for writing the actual property proposals, I'd like to receive feedback on how well these qualifiers translate into other languages than English just in case additional qualifiers may be needed, since translation issues has been a major factor behind the decision to deprecate of (P642). I have posted some questions about this on Wikidata talk:WikiProject Data Quality/Issues/P642/Property labels#Seeking language advice on future qualifier proposals, but for some reason I seem unable to get other editors to even comment on what I write, much less answer my questions.

Since you are apparently familiar with the diplomatic roles and relations, maybe you cam provide some ideas from your point of view?

Metamorforme42 (talkcontribs)
Reply to "Positions and qualifiers"
VIGNERON (talkcontribs)
Metamorforme42 (talkcontribs)

Bonne remarque. J’imagine qu’il vaut mieux être assez large sur les alias pour permettre de trouver facilement. Vu qu’on a aussi l’expression « verser un pot-de-vin » = « soudoyer », on peut s’attendre à trouver l’élément en cherchant « pot-de-vin » tout court. Je viens de le remettre du coup.

Reply to "soudoiement"

Keep list and position separate

3
Summary by Metamorforme42

✓ Done: item untangled.

Germartin1 (talkcontribs)

Please untangle Q113561213 this is the position and not the Wikipedia list.

See as an example: Q32208, and then use property has list

Metamorforme42 (talkcontribs)
Germartin1 (talkcontribs)

Ah ok, didn't know that. Thanks for the effort!

2001:7D0:81E6:EF80:1CC5:ED1C:90E7:2DF4 (talkcontribs)

Hi. You have been undoing some corrections to ambassador classes. I'd appreciate if you didn't do this wihtout explanation and by ignoring comments by multiple other users. Please see page histories (e.g. here [here), where I've expalined why it is erroneous to use P31 for ambassdor classes the way you do. In edit summary I also linked to Talk:Q65262380 where I provided further references, including reference to User talk:Metamorforme42/Ambassadors where serveral rejected this part of your schema years ago for obvious reason.

2001:7D0:81E6:EF80:1CC5:ED1C:90E7:2DF4 (talkcontribs)

I accidentely linked to talk page history. I meant to link to item history such as this. In addition to references previously provided in Talk:Q65262380, see also some more recent comments here.

Metamorforme42 (talkcontribs)

Hi, I gave explanations on Wikidata_talk:WikiProject_Heads_of_state_and_government#Current_consensus_about_ambassadors_structure. Please give your opinion there In short, IMO the structure you tried to introduce does not make sense. Since I had no response in 2 weeks, I started to replace with the most common structure on items I saw since it would at least allow me to search for duplicates. I would prefer if we reach a consensus. And, if your solution is retained, it would be better to use a declared bot (instead of using multiples IP) to make the change to each related item at once.

Please give your opinion on Wikidata_talk:WikiProject_Heads_of_state_and_government#Current_consensus_about_ambassadors_structure, and explain why exactly you think subclass of (P279) is more appropriate.

Rang obsolète de version logicielle non-stable et fr.wikipedia.org

12
Summary by Metamorforme42

Sur le non-usage du rang obsolète pour les anciennes versions de logiciels, en particulier pour les versions non-stables, et l’affichage en infobox sur Wikipédia.

Jona (talkcontribs)

Bonjour (je vois que ta langue maternelle est le français comme moi),

Tu as modifié le rang des versions bêta de QCAD de "obsolète" vers "normal".

Ce changement fait apparaître toutes ces versions bêta dans l'infobox de QCAD sur fr.wikipedia.org et ce n'est pas souhaitable.

Est-ce que la solution de remettre le rang de ces versions à "obsolète" te convient ?

Cordialement,

Jona

Metamorforme42 (talkcontribs)

Bonjour,

cette solution ne convient pas, c’est une mauvaise utilisation du rang obsolète (voir Aide:Rangs#Rang obsolète) car l’information apportée par ces déclarations ne sont pas des « connaissances dépassées » (la version 2.1.1.0 RC1 a bien été publiée le 28 décembre 2006, il y a même une source). Utiliser le rang obsolète empêcherait par exemple de faire une frise chronologique avec l’historique de publication des versions.

Pour corriger l’infobox sur wikidata, on peut :

  • corriger le modèle sur frwiki pour qu’il n’affiche par défaut qu’une seule valeur pour chaque type de version (la dernière en date) ;
  • mettre en rang préféré la dernière version stable et la dernière version avancée (ce que je viens de faire);
  • dans le cas spécifique de Qcad, puisque la dernière version avancée remonte à 2007 on peut aussi dans l’infobox préciser de ne pas l’afficher puisqu’elle n’est pas pertinente soit en modifiant directement le modèle (voir fr:Discussion modèle:Infobox Logiciel#Version avancée), soit en mettant un - dans la valeur de l’infobox sur le champ (dernière version avancée (ça n’a pas l’air supporté pour l’instant sur cette infobox).
Jona (talkcontribs)

@Metamorforme42 Oui, donc si la (ou les) version avancée est plus petite que la version stable (et qu'il n'y a donc pas de raison d'afficher de version avancée), pour le moment, il n'y a pas de solution sans changer le modèle de l'infobox. C'est bien ça ?

Metamorforme42 (talkcontribs)

Oui, c’est bien ça. Je vais voir pour essayer d’ajouter sur fr:modèle:infobox logiciel la dernière solution avec le - qui me semble simple à mettre en œuvre techniquement même si dans l’idéal pas suffisante.

Jona (talkcontribs)

A mon avis, la solution la plus propre serait de n'afficher les versions avancées que si elles ont le rang "préféré".

Metamorforme42 (talkcontribs)

Quid des logiciels dont la version avancée est justement une version en rang préféré mais dont la date quand même plus ancienne que la dernière version stable ? Le rang préféré est bien adapté (car c’est la dernière version avancée), mais la condition à l’affichage n’est pas suffisante : il faut faire une comparaison de dates.

De même, lorsqu’il n’y a qu’une seule version avancée et qu’une seule version stable publiée (on est bien d’accord, ça n’est qu’une situation temporaire, et ce cas de figure est certainement peu fréquent), l’usage sur wikidata est de laisser le rang en normal donc les versions ne s’afficheraient pas dans l’infobox.

J’ai ajouté la solution dont je parlais. Ça n’est pas suffisant selon moi, mais ça devrait nous permettre de contourner le problème jusqu’à ce que l’on gère ça de manière propre.

Jona (talkcontribs)
Metamorforme42 (talkcontribs)

Sur enwiki, ils utilisent le modèle {{Wikidata}} directement sur la page. J’ai modifié, ça devrait marcher maintenant.

Jona (talkcontribs)

Pour Godot, c'est la version 4.0 qui doit être la version avancée. La version 3.5 est déjà sortie ! ;-)

Metamorforme42 (talkcontribs)

Désolé, je n’avais pas vu ! Par contre il manque la date de publication est-ce tu sais si c’est le 28 juin 2020 (date de publication de la référence) ou s’il y a une date connue plus tôt ?

Metamorforme42 (talkcontribs)

Ah en fait, j’en ai trouvé une plus récente « 4.0 alpha 13 », et l’annonce 4.0 c’était juste pour dire qu’ils commençaient à travailler sur la 4.x, mais il n’y avait pas encore de version alpha « publiée » (tout était sur la branch master).

Jona (talkcontribs)
Summary by Metamorforme42

Contexte: Lexeme_talk:L6873

VIGNERON (talkcontribs)

Salut,

Merci pour ton message et le split de "livre"@fr. Les lexèmes ce n'est pas toujours simple donc merci d'y participer (je vois que tu as fait pas mal de contributions, merci beaucoup ; j'avais un peu abandonné les lexèmes en français pour ceux en breton mais j'y reviens depuis quelques temps), à plusieurs cela n'en sera que mieux !

Metamorforme42 (talkcontribs)

C’est bien normal que je corrige moi même, étant à l’origine de l’erreur, et d’autant que des outils pour assister les scissions n’existent pas encore.

Merci pour les éclaircissements qui tu m’as apporté sur Lexeme_talk:L6873. C’est un peu moins confus pour moi, même si ça reste très compliqué… surtout parce que je n’ai presque aucune connaissance en linguistique.

Ça me fait plaisir de voir que les lexèmes en français n’est pas un projet à l’abandon. En espérant que l’intégration aux wiktionnaires attire d’autres contributeurs !

VIGNERON (talkcontribs)

Oui, cela devrait être normal, malheureusement tout le monde n'en fait pas autant, donc vraiment merci ;)

Je ne suis pas expert non plus en linguistique, du coup en général je me réfère aux sources dès que j'ai le moindre doute.

Comme tu peux le voir sur cette requête, il y a beaucoup de monde actif sur les lexèmes en français (même s'il en faudrait bien plus). Oui, l'intégration aux wiktionnaires pourrait aider, l'arrivée des fr:Wikifunctions devrait aider aussi (car cela oblige à bien structurer les lexèmes).

Autorisation Rang dans série

3
Summary by Metamorforme42
LearnKnowGive1 (talkcontribs)

La toute récente modification / suppression de P1545 : Rang dans la série pour (Q21510851) pour "Titulaire" P1308 pose un probleme d'organisation et d'ordre avec des csq ds wkpdia

Voir ainsi par exemple Q70495960 avec l'occupation successive des différents fauteuils de l'académie française

D'ou la remodif selon le principe

"Germain Habert est le 1er titulaire du fauteuil 12 de l'Ac. Fr."


Nb : la structuration avec rand remplacement.... permet d'alimenter les palettes + infobox dans les bio Wikipédia. Successions puis composition à telle date.

Metamorforme42 (talkcontribs)

Merci de l’avoir rajouté, j’avais oublié cette valeur possible.

LearnKnowGive1 (talkcontribs)

No soucy, c'est bcp d'energie (pr un prescripteur et non un "technicien") pr organiser les datas** ds le temps et l'espace et fluidifier l'ensemble

**(après avoir sourcer et sécuriser)

nb : et en passant, si le coeur vs en dit, je vs laisse regarder dans les bio des académiciens, les palettes (bandeaux verts normalement au nb de 3 pr l'Ac.Fr.) de bas de pages wikipédias (certaines sont absentes, partielles... bref pas uniformes... et ne sait à date mettre tout cela au carré) // Complément, les fauteuils 1 à 14 sont finalisés ds wikidata, le reste à suivre...

Summary by Metamorforme42

Séparation des éléments suite à mauvaise fusion.

Hsarrazin (talkcontribs)

Hello,

You recently undid one of my 2014 edits, claiming this item is NOT a list...

Considering both the wp articles listed ARE indeed lists, I think there is a problem with this item...

Indeed, in 2019, Russian Ambassador to New Zealand (Q28155230) that was not a list, was MERGED with Russian Ambassador to New Zealand (Q16158136), that was, thus leading to the problem...

This merge should probably be undone... and both items clearly separated... in the meantime, I readded the claim about the "list", because, obviously, all linked articles are lists...

[edit] je viens de m'apercevoir que nous sommes tous 2 francophones :)

lorsque j'ai fait la déclaration concernant cet élément, il s'agissait déjà, incontestablement d'une liste, car les 2 articles liés sont explicitement des listes d'ambassadeurs...

je pense que le problème vient de la fusion opérée en 2019 avec l'élément Russian Ambassador to New Zealand (Q28155230), qui n'est relatif qu'à la "fonction"...

il faudrait sans doute défaire cette fusion, et recréer 2 éléments distincts, l'un relatif à la fonction, et l'autre regroupant les articles de liste en relation, avec une déclaration "liste de" (l'autre élément)...

en attendant, j'ai annulé l'annulation, car, très clairement, les 2 articles liés sont bien des listes... et c'est l'élément abusivement fusionné en 2019 qui n'en était pas une...

Bien cordialement,

Hsarrazin (talkcontribs)

Re-bonjour, après discussion avec un admin, nous avons procédé à la séparation des 2 éléments... les 2 sont désormais liés par des déclarations qui devraient empêcher leur fusion accidentelle ultérieure :)

Metamorforme42 (talkcontribs)
Hsarrazin (talkcontribs)

effectivement, nous n'avons pas creusé cet aspect, la déclaration ayant été reprise de la situation antérieure... le plus gros du travail a consisté à remettre au bon endroit chaque déclaration, à créer des liens entre les 3 éléments fonction, liste et catégorie, et de remettre d'aplomb tous les éléments biographiques qui étaient liés au mauvais élément...

Bonne journée ! :)