Talk:Abstract Wikipedia/Early mockups

@Denny and DVrandecic (WMF): In these mockups, you assumes a function have an unique name. Are labels intended to be unique? In Wikidata, property labels are only unique per language; it is possible that "foo" means one thing in English and another in German.--GZWDer (talk) 03:55, 21 July 2020 (UTC) Reply

@GZWDer: Thanks for asking! Here I assume labels are unique per type and per language. I first assumed, they should be unique over the whole language, but that lead to a few really ugly labels, and it seems sufficient to relax that to be unique per type and language. That is similar to Wikidata items, which are unique per language and description. --DVrandecic (WMF) (talk) 16:18, 21 July 2020 (UTC) Reply

@Denny and DVrandecic (WMF): How is individual function in composition stored?

• Referred by ZID - this makes it not easily portable to other instances (e.g. importing function from test Wikilambda will break)
• Referred by name - 1. A function does not have single name, it have one per language; 2. Referred by name is prone to vandalism 3. This require individual implementation having unique names
• Other ideas: Referred by GUID, Referred by hash

--GZWDer (talk) 04:35, 22 July 2020 (UTC) Reply

@GZWDer: By ZID. Cross-wiki importing of multiple installations is not envisioned. I'm not sure about cross-wiki calling ({{#lambda:...}}), but I suppose we'd have to rely on ZIDs, too, to avoid too much complexity/magic. Jdforrester (WMF) (talk) 09:16, 22 July 2020 (UTC) Reply

@GZWDer: Regarding different instances of Wikilambda, we'll figure that out later. My first hunch is to rely on a namespacing mechanism. --DVrandecic (WMF) (talk) 14:14, 22 July 2020 (UTC) Reply

@Denny, DVrandecic (WMF), and Jdforrester (WMF): Note: what I said is if we have a test Wikilambda, it will be a pain to move content (i.e. function definitions and implementations) between Wikilambda and test Wikilambda. By comparison, templates and modules can be easily transwikied, or even copied directly.--GZWDer (talk) 14:17, 22 July 2020 (UTC) Reply

@GZWDer: thanks for clarifying! Yes, that's a good point. We'll probably need something like a "bootstrap" content that will have fixed ZIDs for testing purposes. --DVrandecic (WMF) (talk) 14:22, 22 July 2020 (UTC) Reply

@Denny, DVrandecic (WMF), and Jdforrester (WMF): This is not enough, especially when new features are introduced and there is some content in both projects.--GZWDer (talk) 16:33, 22 July 2020 (UTC) Reply

I am assuming that the Constructor is basically like a template - you fill it in with the values (Wikidata ID's, dates, numbers) in a particular context. So the Abstract WikiText for the first examples might look something like {{Z272377|Q311440|Q1253|Q81066|1 Jan 2017}} or maybe more like {{Z272377|K1:Q311440|K2:Q1253|K3:Q81066|K4:2017年01月01日}} to handle optional keys etc. Hopefully there would be a UI to fill in the form so you don't have to look up those ID's separately. So then the English (or any other language) renderer takes that template and produces the text as you illustrate. Would it make sense to call the filled-in template an object of type "Succession (Z272377)"? And then the renderer just takes that object as value, rather than specifying each of the keys separately? Anyway, thanks for these mockups, they make a lot of sense to me generally! ArthurPSmith (talk) 14:58, 22 July 2020 (UTC) Reply

Yes, the Constructor represents the base data elements necessary for construction of natural language, whereas the Renderer is the implementation that transforms that data to produce the natural language. In the web interface mockup, I think you make a good point that the data entry for the Constructor ought to be clear that the thing on which it's operating is a data structure of a particular Constructor type. The subheading in the Renderer tries to indicate something to this effect, but I'm wondering are you thinking it might be helpful to lay that out more clearly in the UI (e.g., nesting the function arguments under the expected type string of the constructor)? I haven't spoken at length with teammates, but I think we expect a fair amount of autosuggest type input boxes to simplify things for users, yes! The shorthand template syntax you provided may be a way to do it that's familiar, although in the context of a particular content wiki it may make more sense to support localized renderer names (which would be enumerated in the wiki of functions) - but actually, were you sharing that syntax thinking about the wiki of functions, the content wikis, or both? Different examples of this nature have been shown in different documents, but I was curious about your take. Suffice it to say there's much to be worked out and we will want to examine a number of approaches and this is slodeware and all that, but really good questions you raised! --ABaso (WMF) (talk) 12:54, 24 July 2020 (UTC) Reply