[02:03:58] let it be [02:04:22] whispered words of wisdom (re @lucaswerkmeister: the conjunctive case can make for wonderfully concise sentences: „Sei n ∈ ℕ, x, y ∈ ℝ, p prim. Dann ist…”) [04:34:00] Hi, I guess "definitive" is too strong, I'm just interested in any discussions of Q-id, especially looking backwards at that design decision from the perspective of "should we do it again for Z-ids". (re @vrandecic: Hi Adam! I'm not sure what you mean with "definite discussion about Q-Identifiers"?) [05:07:44] to me it just seems obvious that it needs to be stable non-natural-language ids [06:13:17] One of the project goals is to support logic written in near-natural, translatable language. So while there will be synthetic IDs used behind the scenes, for efficiency and so that stable handles survive refactoring, it's surprising to an outsider like me to see the raw IDs used in conversation, in queries, and made visible anywhere in the interface. When chatting in English or writing code we should be able to say "equals", I [06:34:30] Using numbers is good for language neutrality, and we Wikimedians love language neutrality as a value. [06:34:31] But using numbers in natural conversation in English, German, Hebrew, or any other human language quickly gets undecipherable for everyone except the people who use these numbers VERY often. [06:34:54] I totally see it in Wikidata discussions. I think I understand Adam's "decoder ring" comment. [06:36:33] I am interested in Wikidata, but I don't use it as often and as deeply as some other people who say P154 and Q368 without explaining what they are. (These are made up random numbers.) I don't understand these conversations, sometimes to the point of being unwelcome. [06:37:21] Thanks, wikilinksbot, for reminding me not to use random Q numbers 🤦🏽‍♂️ [06:39:11] More seriously, the wikilinksbot that explains the number in Telegram after the message is not really a perfect solution. [06:40:25] When I mention Q and P numbers, I usually mention the human-readable name in the language of the conversation. [06:41:09] that's why I get annoyed with the bot reacting to my messages, I try to include [06:41:19] that's why I get annoyed with the bot reacting to my messages, I try to include the name when writing anyway [06:44:11] unless it's p31 and I'm talking to people familiar with wikidata, or we already established which property we're talking about, or something like that [06:44:19] that's exactly why i made the bot 😜 (re @amire80: I am interested in Wikidata, but I don't use it as often and as deeply as some other people who say P154 and Q368 without explaining what they are. (These are made up random numbers.) I don't understand these conversations, sometimes to the point of being unwelcome.) [06:46:35] what I initially wanted was for the bot to be able to edit people's messages directly (if it has admin rights) to add the links to the messages themselves. but there is no way to edit someone else's message in Telegram (re @amire80: More seriously, the wikilinksbot that explains the number in Telegram after the message is not really a perfect solution.) [06:46:57] (plus, it could possibly be seen as even more disruptive, idk) [06:55:35] Potential feature request: suppress the bot if matching label text is already present in the message. (re @Nikki: that's why I get annoyed with the bot reacting to my messages, I try to include the name when writing anyway) [06:57:36] or a piece of text to suppess it? [07:03:38] matching label text is tricky, you might not write it *exactly* the name, or the label might be generic enough to match something else in the message (thinking of "of" and "name") [07:04:45] I'd still just like a way to tell it not to react to my messages [07:07:01] I imagine something like a #supress that can matched pretty easily [07:07:58] I often don't even realise I've written something that the bot is going to react to until it does [07:08:49] like sparql queries, URLs which just happen to contain a capital p followed by a number, example IDs like amir's earlier... [07:10:31] and writing that every time is just as much work as deleting the bot's reaction each time, except more confusing for people who don't know why so many messages have a weird hashtag in them [07:32:19] I've tried to make it so that item IDs that are part of a URL are not linked, but parsing plain text to find what is and isn't part of a URL is... not as easy as i would like. it shouldn't do that though, so feel free to forward any counter-examples to me so I can try to exclude them with regex [07:34:21] as for sparql queries: remember that the bot messages aren't really meant for the one who posts, but for everyone else. i still find it useful to know which properties/items are used in sparql queries (even if they're just examples), as it makes it easier to visualize what the query does without running it. either way, issues & pull requests are always welcome https://github.com/jhsoby/telegram-wikilinksbot 😊 [08:01:49] what I mean by examples is completely arbitrary numbers, like p123, q12345 (re @jhsoby: as for sparql queries: remember that the bot messages aren't really meant for the one who posts, but for everyone else. i still find it useful to know which properties/items are used in sparql queries (even if they're just examples), as it makes it easier to visualize what the query does without running it. either way, issues & pull requests [08:10:11] Some people thought that exposing these numbers in Wikidata is important – but I do not remember why. (re @Adam: One of the project goals is to support logic written in near-natural, translatable language. So while there will be synthetic IDs used behind the scenes, for efficiency and so that stable handles survive refactoring, it's surprising to an outsider like me to see the raw IDs used in conversation, in queries, and ma [08:15:45] (Also interesting that the Q/Z IDs are not some long UUIDs so, as Amir said, experienced people *can* use them) [08:16:59] and I find it easier to read conversations that don't have bot reactions taking up a bunch of space on the screen, I don't like how it makes it hard to see who's talking either (since the last message is the bot, not the person), I put up with it for other people's messages despite not wanting to see it, so other people will have to put up with copying queries into the query service ui for my messages [08:21:18] I imagine because the id is what's stable - anything else can change, and if you want people to use them, they need to be easy to find (re @Jandit: Some people thought that exposing these numbers in Wikidata is important – but I do not remember why.) [09:40:51] To take an example from another domain, a book is referred to by its title, sometimes with year or author to disambiguate. The title may change by edition, publisher, and it can be translated. But library catalog numbers on the other hand are only used to identify a book in a very limited range of contexts, like when you need to physically remove the book from a shelf. [09:47:23] "easy to find" does seem like a good lens, I've noticed that the wikidata query service includes brilliant autocompletion to search for terms a replace with a Q-id. I can imagine that a wikidata query in natural language should be possible to make directly. [09:47:23] As for the query's stability, it can be stored or cached internally as machine codes, and when labels change that would be reflected in the rendering. (re @Nikki: I imagine because the id is what's stable - anything else can change, and if you want people to use them, they need to be easy to find) [09:48:56] As I understand it, wiki functions will be headed in that direction, so very curious about the plans to accomplish a natural-language-ification of the interface. [11:52:24] Given your following comments, my understanding is not that you are against ZIDs (or QIDs) per se, but rather that you're against them being exposed? (re @Adam: Hi, I guess "definitive" is too strong, I'm just interested in any discussions of Q-id, especially looking backwards at that design decision from the perspective of "should we do it again for Z-ids".) [12:20:54] I prefer not to pick a side at this point, I'd like to start by reading any history about our decision to use Q-id as the canonical (and only) handle for entities, whether there has been a public retrospective, and how our experiences with Q-id has informed the design of Z-id. (re @vrandecic: Given your following comments, my understanding is not that you are against ZIDs (or QIDs) per se, but rather that you're against them bein [12:23:06] Another issue I'm wondering about is what to do if wikibase or wikifunctions are widely adopted and we're no longer the only authority issuing Q and Z numbers. [12:27:36] The stable identifier is actually a full URL to the entity, so both the label and bare Q-id are shorthand with the same meaning, and built-in, nonportable assumptions. (re @Adam: Another issue I'm wondering about is what to do if wikibase or wikifunctions are widely adopted and we're no longer the only authority issuing Q and Z numbers.) [13:03:37] there are already several places using wikibase and assigning their own qids [14:12:51] Hello we're seeking a person who can talk about Wikipédia abstract [14:12:52] You can submit your proposal at wikiarabia conference [14:12:53] in English : https://www.wikiarabia2021.com/en_GB/?fbclid=IwAR07_Ge-ZdbldAddWm1B0OM_mz2BhWZ-F8cJqylxVnDI3qt2ANGR08QeyLA [14:14:04] Hello we're seeking a person who can talk about Wikipedia abstract [14:14:04] You can submit your proposal at wikiarabia conference [14:14:05] in English : https://www.wikiarabia2021.com/en_GB/?fbclid=IwAR07_Ge-ZdbldAddWm1B0OM_mz2BhWZ-F8cJqylxVnDI3qt2ANGR08QeyLA [19:20:16] Hello everyone, [19:21:01] As I promised, I have begun my work of using Wikifunctions to add support of biomedical formula and classifications. [19:21:46] I know that this can be a bit marginal. But, this can be very vital for medical practionners. [19:22:40] I have created and edited https://notwikilambda.toolforge.org/wiki/Z10016 [19:23:12] Here, I have to raise several limitations that I found [19:25:54] There is a major problem in holding the login session for my account. I get strangely disconnected after every two edits. This can be a token problem. I had this problem in Wikipedia before 2011 and that is why many of my contributions at that time [19:25:55] have not been considered in my edit history. [19:26:09] There is a major problem in holding the login session for my account. I get strangely disconnected after every two edits. This can be a token problem. I had this problem in Wikipedia before 2011 and that is why many of my contributions at that timehave not been considered in my edit history. [19:26:19] There is a major problem in holding the login session for my account. I get strangely disconnected after every two edits. This can be a token problem. I had this problem in Wikipedia before 2011 and that is why many of my contributions at that time have not been considered in my edit history. [19:27:32] The second matter I faced is that the system messages are not user-friendly. They are hard to understand if you do not know the Wikifunctions data model. [19:31:24] The third matter is that several variable types are still missing as far as I looked for. Many formula in Biomedicine are based on real numbers (floating-point representations). As well, Wikidata items can be good as objects to several statements for functions to enhance the semantic features of the developed project. [19:32:54] That being said, I have to thank @lucaswerkmeister and @vrandecic for developing the system although it should be further enhanced. In fact, the runtime of the JavaScript code is long. [19:36:43] I am sorry for not being able to contribute more to the project in the last months. But, I will try to be more active in the project during the next months. [23:51:08] Thank you for reporting those issues. They are all valid issues. [23:51:46] The first one is an issue with the session lengths on NotWikiLambda. Once we launch our beta installation that should be gone. [23:52:35] The second matter is something we are currently working on and will keep working on. This should get better over the coming months and until launch. [23:54:39] The third matter will not be fixed. It is intentional to let numbers be created as a type defined by contributors. We will not provide numbers as a built-in type. This is also an effort to keep us honest: if we can implement numbers within the system as a type, that will demonstrate that our type system can work. We expect that with the end of the current phase, we should be able to support contributer-created types.