Talk:Abstract Wikipedia/Examples

Active discussions

This exampleEdit

The example uses the English word "encyclopedia". This is maybe not a good example, because it uses the word in its US spelling (without mentioning anywhere that this is the US spelling). British English spells the word as "encylopaedia". --Gereon K. (talk) 21:54, 28 October 2020 (UTC)[]

Both orthographies are valid. This wiki is just using the common orthography looking like "Wikipedia" (not Wikipaedia): it is not meant to be read and understood just by Brits. And well, it the "ae" digraphs is old and not really good English as it was originately a ligature, at the time that England was "anglicized" based on old Latin and later Norman. Do you want to include the really native Celtic orthography for Britain? Is it really a problem for understanding? Note that this wiki has US-English as its default language (there's no support for the [en-us] locale as it is entirely aliased to [en]). You are free to translate this page to [en-gb] if you wish to have an pure Oxford English version... But I think this is waste of time. We have better and more valuable needs for the really missing translations. verdy_p (talk) 09:06, 31 October 2020 (UTC)[]

Global templates @Edit

Abstract Wikipedia would could use global templates for all Wikipedia. TemplateData would be used from Wikidata or Abstract Wikipedia. The template itself would be used from Abstract wiki (website), in a similar way to Wikidata. Global templates could be written in a similar way to this {{'''@'''template name|parameters...}} to distinguish them from local templates {{}}. BoldLuis (talk) 18:15, 21 March 2021 (UTC)[]

@BoldLuis: This project is not attempting to solve the entire problem of "Global templates". It will partially solve the problem of templates-as-data-calculators, in a cross-wiki way. You can see more details about this, in my reply at this thread. I hope that helps. Quiddity (WMF) (talk) 18:30, 24 March 2021 (UTC)[]
I hope it can be the beginning of a good tool. --BoldLuis (talk) 11:43, 26 March 2021 (UTC)[]

Object_with_modifier_and_ofEdit

This page currently has the example:

Instantiation(
      instance: San Francisco (Q62),
      class: Object_with_modifier_and_of(
        object: center,
        modifier: And_modifier(
          conjuncts: [cultural, commercial, financial]
        ),
        of: Northern California (Q1066807)
      )
),

Which gets turned into: San Francisco is the cultural, commercial, and financial center of Northern California.

I'm skeptical of the suitability of a function like Object_with_modifier_and_of as a primitive concept that can be rendered in many languages. Like so many English prepositions, of is incredibly polysemous. It can indicate a relationship of ownership, partitivity, agency, composition, and more. Just check out wikt:of.

It seems very naive to think that for any given language, the same renderer will produce suitable output for all of

  • (center, cultural, Northern California)
  • (daughter, first, Alice)
  • (plinth, solid, marble)
  • (sculptor, celebrated, David)
  • (arm, right, David)
  • (member, (oldest, surviving), The Beatles)

etc. I realize it's just a mocked up example, but I think it's important not to misrepresent the problem as easier than it is. (And this is just the tip of the iceberg with this example, but it seems like a good place to start.) Colin M (talk) 05:10, 18 April 2021 (UTC)[]

@Colin M: You're absolutely right, that example is indeed not good. What it does is that it mixes the grammatical layer (as in "object with modifier and of") with the semantic layer (instantiation). In the end, the semantic layer needs to be implemented by the grammatical layer, and this might look different from language to language (or not).
The problem, as you correctly identify, is not so much the modifiers but the of. What we would need here is to acknowledge that this center (or member or daughter) is a relational noun which takes another noun (here Northern California or The Beatles or Alice) as an argument and creates a noun phrase. It would be up to the individual relational noun to express the relation correctly in a given language. So, instead of Object with modifier and of it really should be two different constructors here: one that adds modifiers, and one that builds a relational noun phrase out of two nouns (with the realization depending on the head).
I admit to intentionally have taken a bad example in order to quickly cast the idea of how this could work in the mind of an English reader without using too much grammatical jargon. But also to show the incomplete and iterative state the library that we are building will probably permanently be in. I expect us to mix grammatical and semantic levels all the time, and to fix these issues and refactor situations when we notice that they don't work in different languages.
A good example of how this could look like when it is taken seriously - a good example of where I expect us to arrive after a few months - can be seen in how Grammatical Framework has resolved the situation with the N2 type and the mkN2 function (search for these on the RGL synopsis).
In short, yes, you are entirely correct - that part is a bad example. If we wanted to make it more realistic I would rewrite it towards this:
Instantiation(
      instance: San Francisco (Q62),
      class: modify(
        object: relational_noun_location_constraint(
          noun: center,
          location_constraint: Northern California (Q1066807)
        ),
        modifier: And_modifier(
          conjuncts: [cultural, commercial, financial]
        )
      )
),
and I would still not be happy with it, because I am still mixing semantic (instantiation) with grammatical (noun) terminology, but at least I got rid of the "of". And I would keep pushing these rewrites until they work in the languages we support. But, as said, I expect that to be am imperfect and iterative approach. --DVrandecic (WMF) (talk) 22:56, 19 April 2021 (UTC)[]
Thanks for the thoughtful response. Though if I imagine looking at the new version without the knowledge of the intended meaning (and without any knowledge of the real-world referents), my first thought might be to render it as something like "San Francisco is a cultural, commercial, and financial center in Northern California." I wonder whether "location constraint" is the best way of thinking of the relation here, since I would regard constructions like "X was the religious center of the Y culture", or "X is the moral center of the film" as being parallel.
It also strikes me as significant that the modifiers here are non-intersective. That is, calling SF a "financial center" is not saying 1) SF is a center and 2) SF is financial. (In contrast with e.g. "San Francisco is a bustling center located in Northern California.") In English, this distinction doesn't have any syntactic effect, but in other languages it does. e.g. in Spanish un periodista simple = "a naive journalist", un simple periodista = "a mere journalist".
By the way, am I right in thinking that this is simplifying away the detail of having to select "sense sub-entities" from lexemes like "center"? i.e. we would need to specify that we're talking about the figurative "locus" sense of the word "center", rather than the sense of, say, the center of a geometrical shape, or the position in hockey, right?
And just to reiterate, my reason for poking holes here isn't just pedantry for its own sake, but because I think this speaks to the higher-level question of how complex these expressions might end up having to be, which in turn is very relevant to the question of how accessible this will be to new editors. How long will an editor have to spend reading documentation and examples and engaging in trial-and-error before they're able to encode a 'simple' fact like the above? 10 minutes? An hour? Multiple hours? If this work is limited to specialist editors, then I worry it will be hard to get coverage off the ground. Colin M (talk) 17:16, 20 April 2021 (UTC)[]
Indeed, if different languages make a difference, we might need to encode that difference before we can render the text in that language with the necessary fidelity. I am hoping for a path that would allow a user to use a less specific constructor if that is sufficient for their language, and then another user to use the more specific one in order to allow the rendering in the languages that require it.
To give an example: it is OK to use the constructor uncle at first, but this wouldn't allow for the text to be rendered in a language such as Turkish (IIUC) which requires to know whether the uncle is by blood or by marriage. We still could render the English text, but the Turkish text would need more specificity. One could imagine a workflow that identifies all the places that need more specificity for given languages and then ask contributors for that information, etc.
I understand and agree that there will be a challenge in the UX for creating and maintaining the abstract content, particularly if the constructors are numerous, subtle in their difference, and complex. There are a few ideas on how to handle that, such as using an ML-based classifier to suggest translations from natural language input to possible abstract representations. Or a system that allows to start with a rough, vague sentence, and then slowly get increasingly specific and detailed, using step-by-step decision points. I certainly do not expect contributors to write anything like Instantiation(Q62, modify(relational_noun( by hand! That will be a form-based, guided experience.
That certainly will be a much slower and involved experience than the current one. But I hope that it won't create a bigger barrier to contribution than the current system. But yes, you precisely identified one of the crucial big question marks and risks of this project. We are aware of this, and I am happy with any early explorations such as these that help us with understanding the problem space better. We are aware of this issue and are planning accordingly - nevertheless, if between now and then we manage to understand the issue better, I'd be more than happy. That will allow us to plan and work more effectively when we get there.
To make it explicit: I indeed hope for a UX that allows people to start working on simple sentences as this one without any previous training. But it might take some time to build a sentence like this. --DVrandecic (WMF) (talk) 00:09, 21 April 2021 (UTC)[]
in Abstract_Wikipedia/Examples/Jupiter#Sentence_1.3 you used separate "and" constructor. --QDinar (talk) 19:21, 19 September 2021 (UTC)[]
Yes, I intentionally use different examples with different constructors, in order to show that I am not assuming a specific library of constructors. I assume that the community will be much better equipped in creating a library of constructors than I will in my ad-hoc manner. So, in one place I might use an and constructor, in another I might use a different one. That's all part of the plan to make it clear that there is no library that we will just use, but that we will need to create it ourselves. -- DVrandecic (WMF) (talk) 23:40, 24 September 2021 (UTC)[]
in this code, order of nesting is not correct. it should be like this:
Instantiation(
      instance: San Francisco (Q62),
      class: modify(
        object: relational_noun_location_constraint(
          noun_with_modifier(
            noun: center,
            modifier: And_modifier(
              conjuncts: [cultural, commercial, financial]
            )
          location_constraint: Northern California (Q1066807)
        ),
      )
),
though i do not like this idea, i propose alternative way: Structured text. --QDinar (talk) 19:30, 19 September 2021 (UTC)[]
Agreed, a location_constraint certainly makes a lot of more sense than of. But I do not understand what the modify constructor in you example does. -- DVrandecic (WMF) (talk) 23:43, 24 September 2021 (UTC)[]
Return to "Abstract Wikipedia/Examples" page.