Wikifunctions:Project chat

Welcome to the Project chat, a place to discuss any and all aspects of Wikifunctions: the project itself, policy and proposals, individual data items, technical issues, etc.

Other places to find help:

• Wikifunctions:Administrators' noticeboard
• Wikifunctions:Report a technical problem
• Wikifunctions:FAQ

SpBot archives all sections tagged with {{Section resolved|1=~~~~}} after 1 day and sections whose most recent comment is older than 30 days.

edit
Archives
2023/08 2023/09 2023/1 2023/10 2023/11 2023/12 2024/01 2024/02 2024/03 2024/04 2024/05 2024/06 2024/07 2024/08 2024/09 2024/10 2024/11 2024/12 2025/01 2025/02 2025/03 2025/04 2025/05 2025/06 2025/07 2025/08

Using Days of Roman year with unknown month

I tried to implement the function month of Day of Roman year unknown (Z26166), but the simple implementation month of Day of Roman year unknown, composition (Z26171) doesn't work, suggesting that void (Z24) is treated like an error somewhere. Considering that we should start handling dates with unknown values, I hope that it is possible to solve this issue.

It is also necessary now to update the converters of Day of Roman year (Z20342) in order to handle unknown values. Dv103 (talk) 21:10, 10 July 2025 (UTC)

It looks like two of the test cases are faulty. I have disconnected those and added </nowiki>Z26189, which passes. It looks like it was a caching issue. All tests are passing so I have re-connected the implementation. GrounderUK (talk) 09:36, 12 July 2025 (UTC)

I’m not sure about updating the converters for Z20342 but I don’t have an alternative proposal. Before we do so, we should agree what to do about implementations that do not handle such dates. For example, should Z16137 return Z41 if both months are Z24 (the objects are the same but whether the “unknown” values represent different months is “unknowable”). GrounderUK (talk) 13:04, 12 July 2025 (UTC)

Why are you not sure about updating the converters? Are there downsides I am not aware of?

By the way, Z16098's converters should be updated too.

As of the already existing functions, we should go through them and decide for each one. As of Z16137, for example, I think two unknown months should be treated as the same (mostly for practical reasons, since it is the comparing function for Z16098). Dv103 (talk) 13:15, 12 July 2025 (UTC)

I wouldn’t change the converters at this stage because they support the underlying types as they were originally defined. As far as I know, changing the existing type definitions has not been proposed. We should consider the advantages and disadvantages of such a change when it is proposed. GrounderUK (talk) 10:39, 13 July 2025 (UTC)

Z6821 already returns dates with undefined values (try for example with World's Peace Jubilee and International Musical Festival (Q3769110)), and this has been discussed in the section "Indicating unknown day/month values in Day of Roman Year" of this page, so I would say that the introduction of unknown months and days are now official.

My idea was to modify the converters in order to pass null and None when there is an unknown value (mantaining the current behaviour in all the other cases). Dv103 (talk) 11:04, 13 July 2025 (UTC)

To my mind, there is a clear distinction between allowing voids in the Wikidata objects and allowing them in the underlying types. I’m afraid I missed the way the discussion drifted towards an assumption that the underlying types would also change, but I maintain that this is still only an assumption until there is a formal proposal to change them. The change you propose for the converters seems reasonable in itself, but I am very uncomfortable with the idea that we might expect all date functions (present and future) to handle an unspecified month.@DMartin (WMF) GrounderUK (talk) 13:18, 13 July 2025 (UTC)

Yes, I'm still concerned that most DORY functions don't have a well-defined output when the input has an unknown value in it. Take Day of Roman Year to Day number in year Z20357 as an example. Unless we end up propagating the uncertainty and (not desirable or possible yet) returning e.g. "unknown natural number", then those functions should return an error (which they currently would). So therefore we just leave them as they are? Then we can wrap compositions operating on Wikidata datetimes to only call those functions when the DORY within a Wikidata datetime Z6061 was certain (or ?equivalently, had a precision <= day). I imagine it won't harm us to have code converters that can deal with voids/nulls, so I personally don't want to block it, but I do expect troubles ahead no matter what we do. --99of9 (talk) 13:51, 14 July 2025 (UTC)

The link to precision is an interesting one. It sort of implies that era+year and era+year+month are valid, whereas era+year+[unknown month]+day might not be (its semantics happen to be problematical). What would the precision be for a yearless date? A yearless and dayless date is presumably just a Z16098, but what about a day (>0) with neither year nor date?

I’ve added a comment to Wikifunctions:Type proposals/Julian calendar date, suggesting a less narrowly defined type (essentially a supertype, with the option of also representing more or less precise Gregorian calendar dates. A further refinement to that could be to include a key for Z6062. -- GrounderUK (talk) 18:50, 17 July 2025 (UTC)

Thanks all for restarting this discussion. We've arrived at these challenges because of the decision to use DORY for import of dates from Wikidata, which in various discussions has seemed desirable and well justified, compared to creating a new date type for that purpose.

To my mind, that decision already implies the redefinition of DORY functions, including read/display/convert, to handle unknown month and day, because Wikidata fetches are creating DORY instances with the new unknown-value conventions, and function-writers are naturally going to use those instances with various functions that handle DORY.

I'm thinking we can satisfactorily figure out the problematic cases (like those above) on a case-by-case basis. Some of those cases probably should return errors, as mentioned above; I wonder if it would make sense to change some to return Kleenean values (e.g., Z16137).

Having said all that, I'm open to all other ideas and even revisiting previous decisions if needed. DMartin (WMF) (talk) 03:51, 15 July 2025 (UTC)

Following your suggestion, I've created kleenean compare months (Z26280) and kleenean compare days of Roman year (Z26271) (I think same month (Z16137) and same Day of Roman Year (Z20348) should not be changed, since they are the default comparing functions). Dv103 (talk) 08:15, 15 July 2025 (UTC)

Thanks for the reply @DMartin (WMF). I don’t think we need to revisit the decision to use DORY within the date object in Z6061K1 (although I am open to revisiting that if the impact on pre-existing types turns out to be significant).

I fundamentally disagree with your second paragraph. In most cases, the Z6061K1 will be a valid object of type: Gregorian calendar date, and in such cases it is perfectly reasonable to use the display functions for that type. We might also reasonably assume that the same display functions could be used for a prospective Julian calendar date type. The special case of unknowns might also be handled by the same functions, but that is not necessarily the best option. If we intend to create a new type for values like “July 2025”, then we might create that type’s display functions in advance, but these would all need to be re-defined once the new type became available.

When it comes to what function-writers are naturally going to do, I can’t be sure, of course! In the case where the Wikidata object contains a valid Gregorian calendar date or Day of Roman year, we shouldn’t expect any difficulties. Whether we’d convert a Julian date to Gregorian would, I guess, depend. But even allowing for a yearless Gregorian date would already imply dispatching by type, and allowing for monthless dates is no different, conceptually. When we come to consider more formal union types, we’ll need to consider something like Wikifunctions:Type proposals/configuration of functions for given types, but perhaps this can be generalised for use in conjunction with lightweight enumerations. In any event, wrapping existing functions with conditions is the default option, and if a new function is to be defined, it can reasonably accept the whole Z6061 (which might imply a need to define converters for that type).

I don’t believe that Z6061 requires a read function, so I don’t currently see any need to change any of the read functions for existing types, at this time. I am not implacably opposed to changing the DORY converters, but I believe that is inconsistent with a “case-by-case basis” and I am still struggling to see the advantages. I am inclined to defer changing the converters from code, in particular, since that would tend to propagate the unknowns into the Gregorian calendar date space, where there are around seventy functions to consider.

I’m happy to help out where I can, but let’s take this step by step and begin by agreeing where we’re headed. GrounderUK (talk) 11:50, 15 July 2025 (UTC)

I'm not shure I've understand well, but are you proposing to create different types for fully-defined Gregorian dates and partially-defined Gregorian dates? If this is the case, I'm not actually convinced with this proposal, since it would create a zoology of types with nearly identical semantics, and the need to duplicate many functions to do very similar operations with these two types.

As of your last paragraph, the main advantage of completely support unknown values it the current DORY would be the possibility to use all the normal DORY-related functions also with dates that come from Wikidata where reasonable. For functions that don't make sense to define with unknown values, instead, I see nothing wrong in raising an error for certain inputs (like for example the division functions that are not well-defined when the second parameter is equal to 0).

As of the number of current functions that whould need an update, currently there are 31 functions that require a DORY input: of those, at least 4 don't need to be updated and 11 are display functions, so only 16 functions need to be updated (considering that we must create some way to display partially-defined dated, no matter what). Considering that updating a function usually is not very time-consuming (it usually just requires to add an initial check), and considering that some functions don't need to be updated because unknown inputs just don't make any sense, this task should quite doable.

For Gregorian calendar dates, instead, there are 57 functions with Z20420 in input, 18 of which are display functions. Here we would still need to do a bit more work, but it is not too much yet (as always, a non-neglegible fraction of those function don't need to be updated because they already don't make sense with unknown inputs). Also consider that, with the creation of new types, considering that the functions that need to be updated to quite reasonable operations that people would expect to do also to partially unknown dates (for example: "add 1 year" is reasonable to do even if the month is unknown), these functions would instead need to be duplicated (and the creation of a new function requires a lot more work rather than just updating the existing ones). Also consider that creating new tipes, also functions that will be created in the future will need to be duplicated. Dv103 (talk) 13:23, 15 July 2025 (UTC)

Thank you for your reply, most of which I agree with. To be clear, I am not making a specific proposal. All I am saying is that “non-standard” dates could be restricted to Wikidata objects for the time being. We already have a proposal for Julian calendar date, and we need to decide how to proceed with that. But beyond displaying something sensible, I’m not seeing handling “non-standard” Wikidata dates as a high priority. Do we know what proportion of Wikidata dates are “non-standard”? GrounderUK (talk) 17:36, 15 July 2025 (UTC)

@Dv103 thanks for explaining your reasoning, I changed my mind based on your arguments. --DVrandecic (WMF) (talk) 11:09, 18 July 2025 (UTC)

Thanks, @GrounderUK. I take your points, and I agree that we should take this step by step and begin by agreeing where we’re headed.

I'm not aware of any estimates for what proportion of Wikidata dates contain unknown values. I get the impression it's fairly common, based on anecdotal observations. I have JSON files for 6 fairly typical entities on my machine and they contain 7 such instances: 4 with month & day unknown and 3 with day unknown, out of 87 instances of the time datatype. (These unknowns are in Hickory, NC and Douglas Adams.) In Wikidata documentation, the use of unknown values is included as a legitimate option. DMartin (WMF) (talk) 02:57, 16 July 2025 (UTC)

Thanks. I’m thinking of a function that casts the Z6061K1 to a valid object of the correct type, so if we just have the year, this would return a Z20159 or, if only the year is missing, a Z20342. I don’t know what it should do if only the month is unknown, but my instinct is to return the input object (a Z6061). Because validation against zero is not in place for existing days, I’m inclined to cast to the type that would be appropriate if the day were not zero, in a parallel function or controlled by a Boolean flag. Thoughts, anyone? GrounderUK (talk) 11:02, 16 July 2025 (UTC)

Thanks! We can also consider having this expanded use of Z6061K1 (to hold an instance of Z20159 or Z20342 sometimes) implemented by the fetch function code (built in code that could be easily updated in this way), and thus avoid the need for defining and using an explicit casting function.

I need to ask for clarification of your sentence beginning with "Because". Are you saying that for unknown days, we'd cast to Z20342 and allow Z20342K2/day to be 0 for unknown days (which is already the current direction)? If so, I don't understand the need for a parallel function or Boolean flag. I'm missing something; could you please clarify? DMartin (WMF) (talk) 20:12, 16 July 2025 (UTC)

Basically, it depends! The context either requires a known value for the day or it does not, and this would be indicated by setting the flag or calling the alternate function (as the case may be). For example, calling Z25907 requires a known day whereas calling Z25901 does not. (Z20367 is an example that produces a semantically incorrect result for a day equal to 0, if that value represents “unknown”.)

We could certainly consider implementing some of this logic in the fetch function code, but I don’t see that being able to handle the cases of unknown months or days, when this may or may not matter (depending on the context). In practice, it would mean we would generally have to interrogate the type, so I’d be inclined to defer any such change until we are introducing support for Julian dates. On that subject, my current thinking is that we might avoid a strict Julian calendar date type and also support, for example, Old Style dates and the en:Swedish calendar (with its infamous 30th February, 1712) with the same type. It’s only a small step from there to a more general type that also supports Gregorian calendar dates (as a subtype). GrounderUK (talk) 22:55, 16 July 2025 (UTC)

@DMartin (WMF) From test case Z26404, it appears that Z6064K5(“timezone”) can be set to Z16660 zero by Z6821, but this is not a valid value in the Z16683 type, where zero must be Z16661. I don’t think it’s causing any immediate problems but test case result validation will naturally read 0 as neutral, and the discrepancy is hard to spot. GrounderUK (talk) 19:02, 20 July 2025 (UTC)

Thanks! I will get this fixed and then report back here when the fix has been deployed. DMartin (WMF) (talk) 01:15, 21 July 2025 (UTC)

Just following up – this was deployed, about 5 days ago, and I have confirmed it's working. DMartin (WMF) (talk) 04:58, 11 August 2025 (UTC)

Read and display functions for Natural language (Z60)

language to language tag (Z14329) and language tag to language (Z860) might be set as the read and display functions for Natural language (Z60). I think this would make a fairly large number of functions available as embedded functions (including all the read and display functions for supported types). There are around a hundred functions with Z60 in their inputs but I reckon around half of these would remain unavailable if we decide to make this change (based on this search) GrounderUK (talk) 08:49, 24 July 2025 (UTC)

Interesting idea to just use the codes. Actual read and display functions need two arguments, so we'd need to wrap those functions, but they could indeed be reasonable defaults. I'm not sure what your search query is trying to show (many of those functions seem to have other argument types that are also readable and output types that are displayable). --99of9 (talk) 12:14, 24 July 2025 (UTC)

I’m not sure we’d need to wrap display functions for the types supported as inputs to embedded functions. The search is just what was left after I excluded various types that are not supported, so it should include all the functions that might be supported by enabling read and display functions for Z60 (so none of them should currently be available to embed). I reached the maximum size for the search terms, so I couldn’t exclude any more types. GrounderUK (talk) 14:25, 24 July 2025 (UTC)

Thanks for the suggestion! We have recently discussed adding Natural language (Z60) support to embedded function calls (only as inputs). As we've indeed seen that it would enable lots of new functions for embedding, we've added it to the scope for this quarter. Our intention is to add support by having a Natural languages lookup field that would allow editors to search through available Z60 objects by their labels and select one. The selected language would be inserted as a Zid, for example {{#function:Z23468|Q144|Z1003}}. We could very well add a read function to the type as well, but then we'd have to deal with double support of language codes and zids, which needs additional engineering work and might be prone to validation errors and confusion. We are tracking this work in phab:T400165 and I've included this suggestion as a possible solution. If there are strong reasons to also link a read function to the type, please follow-up in the task so that we can work out how to enable this double support. In such case, we should decide on a different function to be used as a read function, as read functions require a second argument (language) and Z860 doesn't have one. Otherwise, I believe our preferred solution is to go ahead with the custom selector and provide a nicer user experience. Geno (WMF) (talk) 17:11, 24 July 2025 (UTC)

Thanks @Geno (WMF). I wasn’t suggesting we might do this instead of what you are proposing, but we might do it sooner, even if we have to wrap Z860 to provide the second argument.

The Wikifunctions component also allows languages to be found by searching on their code or their ZID, so I hope that will also be an option for embedded function calls. I think what we ultimately require is quadruple support, so that the user can also specify the language as a Wikidata item reference.

I don’t know why displaying a language is not currently within scope, but I think it’s important to consider the solution options for that at the same time, even if implementation occurs later. The main challenge for community functions here is that we have no way for such a function to convert a language code to a ZID and no way to extract a label from a Z60 even if we have the ZID. This leaves us with nothing to display other than the text of the Z60K1/code itself. GrounderUK (talk) 22:16, 24 July 2025 (UTC)

@GrounderUK: To clarify, if we do what you ask and add a reader function for Z60s, it will break the code we are writing and we will have to write more. So we are saying we should be sure we can justify spending more time (and thus money). Adding a display function for Z60s does not break that code, but is not planned work. We could do it, but (as I said below) I don't think it's a good idea with that proposed function as its output is terrible. Jdforrester (WMF) (talk) 22:36, 24 July 2025 (UTC)

Thanks, James. For the avoidance of doubt, I haven’t asked anybody to do anything. Nor am I likely to do so in the absence of a community consensus. (But if you could just sort phab:T366459, that would be much appreciated.) I imagine the language code to ZID lookup would have to be a built-in function, so that would require a separate Feature request in any event. GrounderUK (talk) 23:11, 24 July 2025 (UTC)

@GrounderUK: In terms of the display function, I think Z14329 would give readers a very poor experience. Language codes as a plain piece of text aren't obviously telling the user something, and the codes aren't familiar to many users; even experts will be confused by some (think e.g. of Z1547, code es-419). Also, that function doesn't take into account the context language, which all display and reader functions are required to do. Maybe we should wait on that side until we have agreement on what a better function would be, and build it? I'd be happy to help create a candidate function, though maybe it should return HTML so we can link the language label to something or style it? Jdforrester (WMF) (talk) 17:18, 24 July 2025 (UTC)

Thanks, James. I’m afraid we haven’t really got a grip on how we give the end-user options so that the function result looks and behaves the way the contributing community wants it to. Consider this simple example:

Hanover (German: Hannover) is a German city. w:simple:Hanover

In this sentence, the first “German” is a link to the German language article (provided by a template call: {{lang-de|hannover}}). That’s the Simple Wikipedia article, of course, not Simple Wiktionary or English Wikipedia. The editorial rule here is already quite complicated: if the label for an item in the language of the function’s context differs from the label in some other language (specified or derived), also provide (in parentheses, say) the label in the other language (typically in italics) together with the name of the other language (positioned relative to the label and separated from it according to the style appropriate to the context) as a link to the article appropriate to the context. (Compare w:fr:Hanovre, where the French « en langue » template prefixes "en " and separates the link from the following colon with a space.) GrounderUK (talk) 11:50, 25 July 2025 (UTC)

@GrounderUK: Exactly, I think a conversation (here? on Talk:Z11?) about what ideally we'd want to be able to show to readers, and then maybe what compromises we'd accept (ahead of features/consensus/magic AGI/etc.) before rushing to connect a given Function as the display Function for the Type. Jdforrester (WMF) (talk) 15:03, 31 July 2025 (UTC)

It’s rather a question for the content contributors who will be using embedded functions, I think. Maybe we should have a separate forum for the wider community? @Sannita (WMF) GrounderUK (talk) 21:33, 30 August 2025 (UTC)

@GrounderUK Sorry for taking this much to answer. I don't have an answer as to where to store the discussion. Being something that involves at 99% community, I'd say community should decide where to host it. I guess a new page for the scope it's a good idea, but I'm not willing to make a decision on behalf of the community. Sannita (WMF) (talk) 10:07, 7 September 2025 (UTC)

Heads up regarding labels containing "claim"

In order to support qualifiers and references, we're going to deploy a new type that directly corresponds to Wikidata snak. We don't want to use "snak" in its label, so we've decided to call it Wikidata claim. We think it's the best available choice, but it's not perfect: "claim" hasn't been used consistently in Wikidata practice over the years, so different folks may have different understandings of it. In particular, it's possible to think that it's synonymous with statement, because we've been using "claims" properties in Z6001/2/4/5/6 to hold a list of statements. (That choice was based on its usage in Wikidata JSON files, which I think would better be called "statements".)

To help avoid confusion, I'm planning to change those "claims" property labels to "statements". Also, there are about 36 functions with "claim" or "claims" in their English label, and I'd like to (carefully) change those, wherever appropriate, to statement/statements. We have a Glossary page where I can also make it clear once and for all what we mean by" claim". I'm interested to know if folks feel comfortable with these proposed changes; please feel free to comment! --DMartin (WMF) (talk) 05:22, 6 August 2025 (UTC)

Fair enough. I'm probably responsible for a fair chunk of those "claim" labels, because my vague mental definition of that word that includes both statements and snaks. But I'd much prefer you define it more precisely than to expect everyone to learn a made up word "snak". So I support this change. --99of9 (talk) 01:26, 7 August 2025 (UTC)

Thanks, @DMartin (WMF). It doesn’t help that there are different kinds of Snaks, does it!

As I understand it, these Snaks are just ways of expressing predicates. What we’re calling a “Wikidata statement” (or “claim”, for short) is basically a predicate attached to a Wikidata item as subject.

This new Wikidata property claim (Z6007) (whatever we decide to call it) looks like it’s a proposition with such a predicate as its subject. Arguably it’s just a kind of qualifier applying to the predicate (or some part of it: its Z6003K3/value).

I’m not sure what our broader plans are for Wikidata qualifiers, but I think I’d rather go with a label aligned with that general idea: something like Wikidata statement qualifier (as long as we’re clear it’s never the subject that’s being qualified) or Wikidata value qualifier, perhaps? GrounderUK (talk) 10:25, 7 August 2025 (UTC)

That makes sense. However, Wikidata property claim (Z6007) will be used both for qualifiers and for references, just as snaks are used for both -- so there's no need to have a distinct type with qualifier in the name. Each qualifier will be an instance of Wikidata property claim (Z6007), and each Wikidata reference (Z6008) will contain a list of such instances. DMartin (WMF) (talk) 00:08, 8 August 2025 (UTC)

But does that mean we'll be mixing up which "snaks" are actually qualifiers and which are actually references? How will we be able to tell whether it is one or the other? 99of9 (talk) 01:46, 8 August 2025 (UTC)

That will be known by where they appear, either in Z6003K5/qualifiers or Z6003K6/references (new properties mentioned in the next post below). DMartin (WMF) (talk) 04:33, 8 August 2025 (UTC)

Ah, thanks for your clarification, @User:DMartin (WMF).

As I see it, the problem is that “Wikidata property claim” is generally confusing and technically incorrect. In simple terms, given a triple where the first element is the subject, the second and third elements considered together are traditionally described as the “predicate” (述語). The subject and predicate taken together constitute the proposition or claim. Understanding the subject from the context is fine (as a kind of zero anaphora), but it will always be confusing to call a predicate a claim.

References are a little different because they apply to the entirety of the Wikidata statement. Given that, it’s not clear why they are anything more than a list of Wikidata items. Sticking with what we’ve got, a list of “Wikidata predicates” seems less confusing than a list of “Wikidata property claims”, but perhaps “Wikidata statement predicate” might be preferable.

Adopting this traditional sense of predicate does create a clash with the current label for Z6003K2, but re-labelling that to something like “property type” would be likely to enhance clarity (occurs 29 times in the main namespace). Conversely, suggesting that “claim” (78 occurrences) and “statement” (98) are anything other than interchangeable risks causing more confusion, especially where they have already been translated. GrounderUK (talk) 12:15, 8 August 2025 (UTC)

Thanks, @GrounderUK. I've also had reservations about using "claim", but I've just taken a look at the Wikidata Glossary page, and it's actually describing "claim" the way we've started to use it. For example, it says A claim consists of a property (such as location) and either a value (e.g., Germany) or one of the special cases "no value" and "unknown value". (In fairness, the glossary page muddies the waters in some other places where it mentions "claim" -- but the quote just above is from the definition of "claim" and provides a strong validation of the way we are starting to use it.)

Note: I'm inclined to drop the word "property" from Wikidata property claim (Z6007), as it seems like another potential source of confusion.

You make good points about "predicate", and I'm sympathetic to them, but that's not perfect either because in the semantic web and RDF world it's commonly used pretty much interchangeably with "property" – and it's also used that way in the Wikidata glossary page; e.g. it says a claim uses a property to express the predicate of a triple and a value to express the object of a triple.

Wikidata reference (Z6008) was motivated by ReferenceRecord in Wikidata, which is a list of Snaks. DMartin (WMF) (talk) 05:55, 11 August 2025 (UTC)

Ah, thanks for the reference @DMartin (WMF). As I understand it, « ReferenceRecord(Snak {Snak} » defines a structure where the first Snak relates the source to the Statement, whereas all the Snaks in the list have this first Snak as their subject, representing propositions about the source-as-reference. I’m not sure it’s a good idea to flatten this structure, even though the original nesting should always be recoverable from it.

Thanks also for your further thoughts on the English label for Z6007. I certainly agree that removing “property” would be a step forward. However, “Wikidata claim”, on its own, reads as a proposition asserted by or on Wikidata. Although there is such a proposition, the fact that the subject is elided deserves a mention. I can see that “predicate” may also be a source of confusion but I can find no other English word that has its traditional meaning. I have used qualifiers such as “headless” or “anaphoric” to emphasise the fact that the subject is implicit, but I’m wondering whether we might use something like “contextual” here, in order to clarify that the subject is indicated by the position of the headless claim?

In any event, I think we need to look again at “Wikidata claim type”, since this seems to relate only to the object in the triple (Z6003K3 and Z6007K3). Given the instances, “Wikidata value type” should work, although “type” is a bit weak here and liable to be confused with the data type. How do you feel about “Wikidata value status”? GrounderUK (talk) 09:25, 11 August 2025 (UTC)

Thanks @GrounderUK for pointing out the semantics of the snaks in a ReferenceRecord; I hadn't seen that documented anywhere but yes, it makes sense. However, we are not doing any flattening – at least, not with respect to what we get in JSON from Wikidata. What's in the JSON is essentially just a list of snaks. It's represented in a slightly complicated way, but it does not distinguish structurally between the first snak and the other snaks. Given that, and given that we generally are trying to mirror what comes from Wikidata (with minimal adjustments as needed for Wikifunctions), I thinking we don't need to introduce structure that's not present to begin with (and not clearly documented to my knowledge). In other words, I'm thinking it's sufficient to carefully maintain the order of the snacks, and document what's going on in an appropriate place (I still have some documentation work ahead of me.).

Regarding "Wikidata claim", we are using "claim" as our replacement for the term "snak", which I'm "claiming" is pretty well warranted by what the Wikidata glossary says about "claim", and we are using the prefix "Wikidata" just to indicate that the content and the representation are taken from Wikidata, in the same way that we have labeled "Wikidata statement", "Wikidata lexeme", etc.

"Contextual claim" is a nice idea, but I'm not convinced the longer label is necessary if we just cleanly define "claim" as synonymous with "snak". To my mind, although there is an association of "claim" with "proposition", I don't think the association is that strong for most people, so it's okay to use it in our own way here. Does anyone else want to weigh in on this?

Regarding "Wikidata claim type", that's motivated because it's imported from "snak type" and we're just replacing "snak" with "claim". I agree that "claim" isn't a perfect choice, but once we've documented what we mean by it (partly by reference to the Wikidata glossary), I think it will work out to do that terminology substitution consistently. Also, I'd say the notion of "snak type" doesn't just characterize the object of a triple; it characterizes the snak as a whole. For example, a snak of type "no value" says: for the (implicit, contextual) subject, there is no value for the given property, whereas a snak of type "value" says : for the (implicit, contextual) subject, there is this value for the given property. DMartin (WMF) (talk) 00:02, 14 August 2025 (UTC)

Thanks, @DMartin (WMF). Forgive my multiple replies. I agree that Wikifunctions should follow what Wikidata actually does, rather than what I think its documentation says. As I almost said, the special interpretation of the first Snak in the list should not be a problem. GrounderUK (talk) 08:08, 14 August 2025 (UTC)

I agree that by characterising the state of a proposition’s predicate, we are indirectly characterising the proposition as a whole (without considering the representation). But considering any proposition represented as R(a,b), it is only b that is characterised by the “Snak type”. This corresponds to a finite state machine where the initial state of the proposition is “some value” and the possible transitions are triggered by the provision of a value (making the state “value”) or the assertion that there is no such value (making the state “no value”). In more formal terms the pattern conflates existential quantification with variable binding, which makes it harder to find a meaningful name. The FSM framing avoids that, and since we’re calling b a “value”, “value state” is neutral terminology. GrounderUK (talk) 09:32, 14 August 2025 (UTC)

When it comes to using the word “claim” without explicit qualification, it seems we may just have to agree to differ. I’m happy to avoid the word altogether (except when the truth of a proposition is doubted), but this will prove difficult if the word is co-opted to serve as a synonym for “predicate” (in the normal sense of the word).

Looking at translations of functions currently using the word “claim”, it seems that it has been consistently translated as if it said “statement”, so avoiding the word should only affect English labels. It will be interesting to see how Wikidata property claim (Z6007) might be translated, but so far we only have Italian “Affermazione Wikidata” (contrasting with “Dichiarazione Wikidata”), which, I feel (@Dv103), suffers from the same difficulty as the English in distinguishing the case where the subject is explicit from the case where it is not. GrounderUK (talk) 12:30, 14 August 2025 (UTC)

"Affermazione" in Italian is basically sinonym with "dichiarazione" (similar on how in English "declaration" and "claim" are basically the same word with different etymologies). I've actually never seen "affermazione" used on Wikidata, because there only "dichiarazione" is used meaning both "declaration" and "claim". "Affermazione" is just my first attempt to distinguish the two concepts (that I agree need to be separated here on Wikifunctions somehow). Dv103 (talk) 12:37, 14 August 2025 (UTC)

Thanks for these comments! Yes, most snaks are a property plus a value, and the subject is not made explicit, because that's given by what the snak is attached to. And the same for Wikidata property claim (Z6007), which is meant to capture exactly what's captured by PropertySnak (which, at least for now, is documented to be no different than Snak). And yes, the different types of snaks complicate things. I'm planning to say more about this on this page, probably a little later today. DMartin (WMF) (talk) 21:17, 7 August 2025 (UTC)

Z20420 with unknown values

@99of9@GrounderUK@DMartin (WMF) I represent this question, given @DMartin (WMF)'s last edits. Should we allow Gregorian calendar date (Z20420) to have unknown values, or should Gregorian calendar date (Z20420) only accept completely known dates, and Wikidata time (Z6064) use a different type that encodes for possibly unknown dates? Dv103 (talk) 08:25, 12 August 2025 (UTC)

I think it depends on what we plan to do with non-Gregorian dates. Please see my comment at Wikifunctions:Type proposals/Julian calendar date#Discussion. Ultimately, I favour a pure proleptic Gregorian calendar date type. We may also want an imprecise version that can support the Wikidata concept of precision. This would mainly be to support conversions between calendars. GrounderUK (talk) 09:09, 12 August 2025 (UTC)

Just to be clear – when you say "pure ..." type, does that mean that unknown values would not be supported? And if so, what would be the arguments for disallowing unknown values? To my mind, it's very natural to allow for unknown values in dates – particularly unknown day and/or month, and I'm not currently aware of strong reasons to forbid them in Gregorian calendar date (Z20420). (On the other hand, if we have an imprecise date type, as you've mentioned, then I suppose we could require that type to be used for unknown values.) DMartin (WMF) (talk) 18:10, 19 August 2025 (UTC)

Yes, a pure type would forbid unknown values. I agree that it is a natural requirement to support imprecise or uncertain dates, which is why I say it depends. But it is also clear that the Gregorian calendar date type was never intended to support these (“A Gregorian calendar date identifies a specific day using the Gregorian calendar system introduced in 1582”). It also doesn’t support decades, centuries or millennia, so I think it makes more sense to create a new type that supports these rather than complicate the existing type. This new type could include Wikidata calendar model (Z6063) and the appropriate subset of Wikidata time precision (Z6062). GrounderUK (talk) 09:55, 20 August 2025 (UTC)

gadget to copy label to mul?

Many of our test labels should basically be the same in all languages. For example Z27549. I wonder if someone could write a gadget to one-click-copy the label from an existing language into the label for the user's interface language (or mul). That would speed up the labelling of new items. --99of9 (talk) 01:32, 19 August 2025 (UTC)

About Vector 2022 skin in this wiki

Hi. I have something that needs to be clear. How does this wiki is the only wiki that have the Vector 2022 skin optimized for mobile view? In other wikis, it's not optimized for mobile view and we have to zoom the page to see the content, but in Wikifunctions we don't have to do that. Although I have already enabled the responsive mode in global preferences page, but Wikifunctions is still the only wiki that has the Vector 2022 skin for mobile optimized, it does no effects in other wikis. I have checked this wiki and it seems there's no related configuration in MediaWiki:Vector-2022.css or MediaWiki:Common.css, so it might be related to some deep configurations. I also mentioned about this in here but there's no response. Nvdtn19 (talk) 09:51, 22 August 2025 (UTC)

@Nvdtn19: It's an experimental mode built by the Web team, of which we are the first (and so far, only) wiki to take advantage. I believe that the long-term plan is (or was?) to convert all wikis over to it eventually, but I am not involved, sorry. Jdforrester (WMF) (talk) 13:51, 26 August 2025 (UTC)

@Jdforrester (WMF): Oh... So is there any way to contact them? I wanna ask when will this feature be available in remaining wikis. Nvdtn19 (talk) 05:57, 7 September 2025 (UTC)

Detect/flag when inputs have identical names?

For example, Describe the class of a class (Z27173) has two class parameters in English at time of writing. YoshiRulz (talk) 18:13, 25 August 2025 (UTC)

Wikifunctions & Abstract Wikipedia Newsletter #215 is out: Accessing Wikidata items now possible from embedded function calls; Wikifunctions available on 65 Wikitionaries

There is a new update for Abstract Wikipedia and Wikifunctions. Please, come and read it!

In this issue, we announce that it is now possible to access Wikidata items from embedded function calls, we also inform that Wikifunctions is now available on 60 more Wiktionaries, and we take a look at the latest software developments.

Want to catch up with the previous updates? Check our archive!

Enjoy the reading! -- User:Sannita (WMF) (talk) 14:57, 29 August 2025 (UTC)

Content error

Why is display day of the week (Z24041) failing for Sunday (Z17409) when embedded, for "", "Z1002" and "en"

Sunday

Sunday

Sunday

(but Monday and Sunday might succeed)? GrounderUK (talk) 21:16, 30 August 2025 (UTC)

Is developing a general conjugation function possible?

Hello, I mainly contribute to the French Wiktionary and I am currently exploring Wikifunctions. I noticed that you have a Conjugate être (Z21599) function. Looking at the code, I see that all forms are hard-coded. This is a shame, because all the forms are already present on Wikidata : L1882.

So my first question is, why does not this function use Wikidata lexeme?

More generally, some contributors to the French Wiktionary have experimented with the Wikidata lexeme trying to develop modules that would use this data. The main issue is that calling data from Wikidata requires setting the Lexeme-ID, which is highly not user-friendly at all, because the wikicode becomes highly cryptic.

My second question is about this problem. Would it be possible to develop a function that would generate the conjugation (are anything else using the Wikidata lexeme forms) of any French verbs? For example a function that would take only two inputs: the name of the verb (for example "être") and the language (for example "fr/French")? Pamputt (talk) 06:00, 2 September 2025 (UTC)

Hi, I concur to what Pamputt said, AFAIK right now it’s impossible to associate lexeme IDs to wiktionary pages, so we have to manually indicate them in the wikitext if we want to use their data. And to answer your second question, I already developped a Lua module on frwikt that does exactly that, it’s just no deployed yet. Maybe it could be ported here, but there is a lot of code and associated data. — Danÿa (talk) 11:11, 2 September 2025 (UTC)

As a side note, the “futur antérieur” forms in the JS implementation of Z21599 are incorrect. I would have fixed them myself but I don’t have the required perms. — Danÿa (talk) 12:01, 2 September 2025 (UTC)

Thanks for pointing that out. I hope I’ve fixed them correctly! GrounderUK (talk) 12:41, 2 September 2025 (UTC)

That’s perfect :) — Danÿa (talk) 16:42, 2 September 2025 (UTC)

Sorry for replying in reverse order. I think linking Wiktionary pages to Wikidata lexemes is just a hard problem. Wikidata lexeme reference to string (Z19310) may be of some use when using the visual editor on a Wiktionary that supports embedded functions. For example,

{{#function:Z19310|L1882}}. "L1882"? {{#function:Z27423|L1882}}

evaluates to « L1882. "L1882"? être ». I never needed to type in "L1882", but this lookup is only available in the embedded functions editor (or in the Wikifunctions object editors).

The more general case of finding a lexeme given some text is not currently possible using Wikifunctions. We can’t even find all the lexemes with representations (of forms) equal to some string… yet. We are reliant on the development team for this sort of capability and, as far as I can tell, it is not currently planned. GrounderUK (talk) 15:12, 2 September 2025 (UTC)

It’s an historical artifact, I believe. When Wikifunctions integration with Wikidata began, it always failed for L1882 (fr) être. We can implement a new version at any time but I’ve been waiting for a consensus on Wikifunctions:Type proposals/French tenses.

We now have types for Grammatical gender (m/f) (Z25340) and Grammatical number (singular / plural) (Z26934), but we need grammatical tense before we can define a conjugation properly. Ultimately, we should be able to return a full conjugation given only a lexeme reference (similar to Latin first declension table (Z26333), but with no hardcoded text).

I support the principle of specifying lexemes using strings in a particular language and I’m happy to draft or comment on a Feature request for this to be supported, based on the discussion here. In the mean time, we can look at “perfectly regular” conjugation functions (like Conjugate regular -er verb (Z21617)), with a view to supporting the regular exceptions (like « payer »), accepting that we cannot determine whether a particular string represents an irregular verb, unless we hardcode the exceptions (or, at least, the mapping to the irregular verb’s lexeme reference). Even then, we’d still have the « ressortir » problem, but perhaps a text convention might address those odd cases? GrounderUK (talk) 14:27, 3 September 2025 (UTC)

Ultimately, we should be able to return a full conjugation given only a lexeme reference (similar to tableau de la 1e déclinaison en latin (Z26333), but with no hardcoded text).

When I opened this discussion, this was exactly what I had in mind. Technically, I am not sure to follow everything. Yet get a Lexeme data directly from a string would be very useful for readability. Pamputt (talk) 17:54, 3 September 2025 (UTC)

I think that this proposal could be relevant here. Dv103 (talk) 10:17, 6 September 2025 (UTC)

Wikifunctions:Human languages reorganisation

There is a discussion at Wikifunctions talk:Human languages#Updating the list about a remake of the page; I am posting here to increase the discussion's visibility. Xeroctic (talk) 15:32, 3 September 2025 (UTC)

Decision tables for natural language generation

I like tables and spreadsheets and I have looked at Wikifunctions:Abstract Wikipedia/2025 fragment experiments and I have thinked about what can help writing the functions and especially understanding the rules before. One possibility for such a thing are decision tables. I have created a subpage of my user page with an example. The basic idea is writing down known variants of a specific type of sentence and then thinking about the rules what change the output. For every property new columns are added to the table. There are historic examples of programming languages based on decision tables. A programming language I looked at a bit was the experimental programming language DETAB-X. Do you think the approach with using decision tables can help by creating implementations for other natural languages. Hogü-456 (talk) 20:48, 3 September 2025 (UTC)

@Hogü-456: I don't quite understand what the value of this kind of table would be. Won't there be hundreds of rows for even the most trivial fragment? Who would be helped by this? Shouldn't the entries instead be Test cases for the individual Functions? Jdforrester (WMF) (talk) 21:19, 3 September 2025 (UTC)

The decision table in the example is complete for this specific kind of fragment. It is the german version of Z26043. I think writing the rules down in such a structured way can help when creating the function. It is a tool to use before creating the function to get an overview about what to pay attention to when implementing it. There are also fragments with many rules and so there are limitations of it. After creating the function it is necessary to create Test cases to look if the function does work as expected. I will try to explain it more at the subpage of my user page. This can help people understanding how to use it. Hogü-456 (talk) 19:45, 4 September 2025 (UTC)

WikiProject Wiktionary functions

I've created the page Wikifunctions:WikiProject Wiktionary functions to coordinate the creation of functions specifically aimed at Wiktionary. Both contributors to Wikifunctions and Wiktionaries are invited. In particular, here is a proposal of the first function properly aimed at Wiktionaries. Dv103 (talk) 10:16, 6 September 2025 (UTC)

@Dv103:: Before we can sign off on Wikifunctions I would like my previous concerns to be addressed (i.e. demonstrating why this would be a substantial improvement over Lua). Maybe @Koavf and Juwan would be interested. But I appreciate your efforts here. Ioaxxere (talk) 04:51, 8 September 2025 (UTC)

Confirming interest, lamenting ignorance to be of any use. :/ ―Justin (koavf)❤T☮C☺M☯ 04:54, 8 September 2025 (UTC)

ditto with Justin. Juwan (talk) 10:45, 8 September 2025 (UTC)

I'll try to answer your previous concerns:

• The ability to write high-performance functions — ideally in a compiled language like C, not Python

As already answered, the performance issue is already mitigated through caching, that completely removes the necessity to run the code for each page rendering.

• The ability to call functions from within a template (say {{#invoke:wikifunction|Z12345|{{{input}}}}} or mw.wikifunction(Z12345, input) within Lua)

For now it's not possible.

• The ability to write reusable code, such as being able to create a helper function Z98765 and use it inside the other functions Z98766, Z98767, etc. with minimal performance overhead

This is already possible (as for the performance, consider the presence of caching) and one of the main advantages of Wikifunctions.

• (Ideally) the ability to access external data in a way equivalent to the mw.wikibase or mw.title APIs in Lua, and perhaps even directly query the database in a way similar to https://quarry.wmcloud.org/

For now not possible.

In general, I think that the main advantage of Wikifunctions is the centralisation of code, with a focus for small language editions of Wiktionary (considering that porting Lua modules and adapting them can become very difficult for small communities). Another great advantage is the possible integration with Wikidata, allowing the centralisation of data between language editions.

Consider for example the conjugation tables: now in the English Wiktionary there are lots of templates that handle the conjugation tables of various parts of speech of numerous languages, most of which require a manual input to handle all the possible conjugation patterns and all the irregolarities. With this proposal, instead, it could be possible to unify all those modules in a single Wikifunctions function, that automatically chooses the proper conjugation table (by language of the lexeme, part of speech and eventual other useful gammatical features) and fills it with the form taken from wikidata.

The idea being that, in order to create the conjugation table of the Latin verb placeō in a small-community Wiktionary language edition, instead of having to import the template la-conj and to call it through {{la-conj|2+.opt-semi-depon.noimp|placeō}} (having to read through the documentation to understand how to generate the specific conjugation pattern of this particular verb), it could be possible to write something like {{#function:Znnnnnn|L281501|}} (with both the search of the ZID of the function and the LID of the lexeme facilitated in the Visual Edit mode), with no other action needed by the local Wiktionary community.

Finally, for @Juwan and @Koavf, even if you don't have tecnical knowledge in coding, it's still very useful for us to understand what it is actually needed on Wiktionaries. Dv103 (talk) 18:07, 8 September 2025 (UTC)

Language shortcuts

@Arlo Barnes: as the creator of the page. The shortcut WF:ldn was recently created as a shortcut for the page on Láadan. I think this, and future redirects, should be moved to subpages of WF:HL, as many shortcuts may need to be made, at least one for each language (they probably need to be at least partially capitalised to prevent confusion with translation subpages). Xeroctic (talk) 11:10, 6 September 2025 (UTC)

So it would be WF:HL/LDN because WF:HL/ldn would be the translation page, for example? But WF:HL just redirects, so WF:human languages/ldn would be the actual translation page for the main list, and perhaps WF:human languages/LDN/ldn for the subpage. Arlo Barnes (talk) 16:35, 6 September 2025 (UTC)

The all-capitals term would probably be best for the shortcut, as is practice on English Wikipedia and probably other wikis (the current shortcut is mixed case, but due to being after the namespace colon, it can be presented as all-lowercase unlike the last part of subpages). Additionally, I am unsure whether translation pages are necessary for redirects (unlike the pages they target). Xeroctic (talk) 18:54, 6 September 2025 (UTC)

The English Wikipedia has w:Category:Redirects from ISO 639 e.g. w:ISO 639:abc. YoshiRulz (talk) 00:12, 7 September 2025 (UTC)

Next Wikifunctions & Abstract Wikipedia Volunteers’ Corner is tomorrow!

We remind you that our next Wikifunctions & Abstract Wikipedia Volunteers’ Corner will be tomorrow, September 8, at 17:30 UTC (link to the meeting).

Unless you have many questions, we will follow our usual agenda, giving updates on the upcoming plans and recent activities, having plenty of time and space for your questions, and building a Function together.

See you at the Corner! -- User:Sannita (WMF) (talk) 13:39, 7 September 2025 (UTC)

Wikilinks in HTML fragments

In Wikitext, Wikilinks are automatically generated, and the parser automatically checks whether the link is valid, and colors the link accordingly. Considering that Wikifunctions functions have to directly output HTML fragments, how should they output Wikilinks? Dv103 (talk) 12:05, 8 September 2025 (UTC)

Wikifunctions & Abstract Wikipedia Newsletter #216 is out: Copying function calls from one Wikipedia to another

There is a new update for Abstract Wikipedia and Wikifunctions. Please, come and read it!

In this issue, we announce that it is now possible to use natural languages as a default value in embedded function calls, we discuss the latest news in Types, and we take a look at the latest software developments.

Want to catch up with the previous updates? Check our archive!

Enjoy the reading! -- User:Sannita (WMF) (talk) 16:04, 8 September 2025 (UTC)