- Abstract-Wikipedia - lists.wikimedia.org

Re: [Abstract-wikipedia] How to store wikitext along the structured content?
by Grounder UK 29 Jul '20

29 Jul '20

I'm replying to Denny's original message. I've read other replies and James's phabricator overview and I think I understand the problem. Except I don't. So I'm stepping back to the requirements and constraints. Constraint 1 is that text entered by humans must be stored as human-readable text (encoded, obviously). So, labels and aliases and "source code" are primarily text. If you need to store the text as JSON, that's fine, but I was imagining that the human text, as entered, would be translated into an abstract form (with Zs and Ks etc) and it is the abstract form that gets stored as JSON. Yes, it's dynamic (on-the-fly) during the editing process, but the human enters text we care about and the machine turns it into an object we care about. The text entered is a text and the interpreted text (object) is another text. Translations are translations of a source. You can translate the text entered into another language, and that's another text. Or you can translate the derived form, and that's a different text. But if the translation is fully automated, you might treat it as "mere" presentation: a visualisation of underlying data. Maybe it makes sense to store such a thing, especially if a human has seen it, even more so if they have relied on it, but do we have a Requirement to store all translations up-front? I don't think so. We store it in the language it was entered in (preferably with metadata that identifies the language) and maybe we store it in a small number of different languages (always having at least two would be nice). Beyond that, I think you're talking about sub-pages per language (but let's not jump to solutions). Constraint 2 is that text is bound to its context. A good example of this is comments in source-code. The word "in" indicates the binding. The comment doesn't point to some text, it is the text, right there, "in" the source code. Constraint 1 ("C1") applies: it is stored as entered, where entered. If you later want to tidy up the source code and replace comments with pointers to comments and/or translations, that's fine. But C1 still applies, so you have a new version of the source-code and you still have the old version. When it comes to documentation outside of comments, that's just a text (as written). It might be written as a multi-lingual text, but more than bi-lingual is stretching it a bit for most of us. The bi-lingual text may be a collaboration with a machine translator, but I would only see that as a Requirement when one of the languages is WMF's own synthetic language (ZKspeak, to coin a phrase). That is, I might compose my text in DeepL and paste its English into the ZObject documentation. For us, that is the text as written (C1 applies). If I also paste in the text I composed in a different language, that's fine; that's another text as written (C1 applies). (If I make a comment to that effect, that's just text where entered, but it's interesting metadata, so there may be a Requirement to capture the metadata. Either way (or both ways) C1 applies.) Requirement 1 might be that any text can be entered as Wikitext. Ah, but the JSON can't be Wikitext... Well, that isn't the Requirement. We can enter the text as Wikitext (so C1 applies). If it must be translated into text that can be JSON, that's fine. We still have the Wikitext and now we also have a translation; that's another text. Does the above guide us toward a Solution? Well, it's not A, because we don't have many translations in the JSON blob. But maybe we have three: the source human text, the interpreted ZK text and a translation into a second language. It's not B (but I don't understand B). I think we do have "secondary wikitext" but it might be implemented as "primary wikitext" with secondary translations as sub-pages (somewhat optionally), as in Meta. It would be the JSON blob that would be secondary (in a logical sence): some transformation of a primary text. If the JSON needs to be primary, you can treat it that way; then its human source pretends to be "about" the primary object. It's a bit like C, but it's not a big blob and it's probably not parallel. Maybe it's a primary Meta-like wiki that is linked by common reference (ZID) to the JSON blobosphere. Well, that sounds a lot like D, but... It's not D, because the Meta-like wiki page for a ZObject is not a sub-page of a non-wiki page. Wikipedia pages are not sub-pages of their Wikidata Item's page, but you can look at them as if they are. We can link from one Wikipedia to another directly, or we can link through Wikidata. I know callable functions are a bit different but, as I said at the beginning, I don't understand the problem. Hopefully this input will still be of benefit to somebody who does, however. Best regards, Al. On Wednesday, 29 July 2020, <abstract-wikipedia-request(a)lists.wikimedia.org> wrote: > Send Abstract-Wikipedia mailing list submissions to > abstract-wikipedia(a)lists.wikimedia.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.wikimedia.org/mailman/listinfo/abstract-wikipedia > or, via email, send a message with subject or body 'help' to > abstract-wikipedia-request(a)lists.wikimedia.org > > You can reach the person managing the list at > abstract-wikipedia-owner(a)lists.wikimedia.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Abstract-Wikipedia digest..." > > > Today's Topics: > > 1. Re: Two different kinds of information? (Andy) (Denny Vrandečić) > 2. How to store wikitext along the structured content? > (Denny Vrandečić) > 3. Re: Two different kinds of information? (Denny Vrandečić) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 28 Jul 2020 13:57:52 -0700 > From: Denny Vrandečić <dvrandecic(a)wikimedia.org> > To: "General public mailing list for the discussion of Abstract > Wikipedia (aka Wikilambda)" <abstract-wikipedia@lists. > wikimedia.org> > Subject: Re: [Abstract-wikipedia] Two different kinds of information? > (Andy) > Message-ID: > <CA+bik1eS56HuAqtd6O-4OS-kexUzfvu0u4hsYfXtxc83Fms42w@ > mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Hi Al, > > just one quick request - can you set up your answers to the mailing list in > such a way that it doesn't break the thread? (I am not sure how, maybe > someone else can chime in, but right now, your answers start a new thread > instead of continuing the previous one). > > Louis Lecaillez had a similar issue initially, but managed to resolve it, > for which I am thankful. > > If not, it is OK, but I thought I'd ask. > > Thank you! > Denny > > > On Tue, Jul 28, 2020 at 8:23 AM Grounder UK <grounderuk(a)gmail.com> wrote: > > > Hi, Andy! Welcome! > > I do like your idea of being clear about basic "facts" and details. I > > think it will be key in the selection of "statements" that go into an > > "article", in whatever language is required. I don't think we can say how > > many levels of information there might be, but we can already see > something > > from how Wikipedia pages are put into categories. > > > > "France is a country in Europe" and "in western Europe" and "in the > > European Union", just to mention three categories. The first is an > > important fact of geography, but is the second more helpful? All > countries > > in western Europe are (1) a country and (2) in Europe and (3) to the > west. > > (3) feels more like a detail, but if we tell you France is in Europe, > what > > is the first question you might ask? It might be, "Is it in the European > > Union?" or "How big is it?" or "Do many people live there?" So I would > > expect us to give you those facts or details (FAQs) as well. > > > > Facts about facts and statements about claims are a whole other topic, > but > > if a "fact" is disputed, we do need to know how to show this. If you look > > at Wikidata, you will see that the United Kingdom has been a sovereign > > state since 1927. This is untrue. But if 1927 is not the answer to the > > question "How long has the UK been a country (or sovereign state)?", what > > is? "Since 1707, 1801 or 1922", depending on the details. Luckily for > you, > > France has "always" been a country, despite now being the fifth republic > > (since 1958). > > > > So, sometimes the Property of an entity is not a simple value or > > relationship. It might be better to think about it as a relationship to a > > "disagreement" or debate. Then, a "fact" is an entity's relationship to > an > > absence of "disagreement", a "consensus", as Wikipedia would call it. > Part > > of this consensus is the meaning of an entity's label. For example, > English > > Wikipedia thinks "oxygen" is the chemical element ("O") and "its most > > stable form" ("O2", "dioxygen"). French Wikipedia thinks > > "oxygène" is just the element. Wikidata has statements (mostly) about the > > element but the "Identifiers" (external authorities) are for the English > > Wikipedia concept, not the French one. The point is, it is clear that > there > > might be some confusion! We have a separate item for dioxygen and for > ozone > > and (in theory) for atomic oxygen (and there are others) so we can give > you > > all of the oxygen facts, mostly grouped by form (allotrope and/or state). > > Think of that as a disambiguation page enriched with detail... It's an > > interesting use case (or test case), I think. > > > > Best regards, > > Al. > > > > On Tuesday, 28 July 2020, <abstract-wikipedia-request@ > lists.wikimedia.org> > > wrote: > > > >> Send Abstract-Wikipedia mailing list submissions to > >> abstract-wikipedia(a)lists.wikimedia.org > >> > >> To subscribe or unsubscribe via the World Wide Web, visit > >> https://lists.wikimedia.org/mailman/listinfo/abstract-wikipedia > >> or, via email, send a message with subject or body 'help' to > >> abstract-wikipedia-request(a)lists.wikimedia.org > >> > >> You can reach the person managing the list at > >> abstract-wikipedia-owner(a)lists.wikimedia.org > >> > >> When replying, please edit your Subject line so it is more specific > >> than "Re: Contents of Abstract-Wikipedia digest..." > >> > >> > >> Today's Topics: > >> > >> 1. All work is preliminary (Denny Vrandečić) > >> 2. Two different kinds of information? (Andy) > >> > >> > >> ---------------------------------------------------------------------- > >> > >> Message: 1 > >> Date: Mon, 27 Jul 2020 12:43:05 -0700 > >> From: Denny Vrandečić <dvrandecic(a)wikimedia.org> > >> To: Abstract Wikipedia list <abstract-wikipedia(a)lists.wikimedia.org> > >> Subject: [Abstract-wikipedia] All work is preliminary > >> Message-ID: > >> <CA+bik1dNtpbA3H2_O= > >> 8H8iyNrBPMbpQeAaOb04EpEaoLxCWSZQ(a)mail.gmail.com> > >> Content-Type: text/plain; charset="utf-8" > >> > >> Hello all, > >> > >> one of the things we have been discussing in the team is that we want to > >> do > >> as much of our work in the open. At the same time, we're a distributed > >> team > >> and starting to form a shared understanding of the task at hand. Due to > >> the > >> COVID situation, we didn't have the opportunity to have a project kick > >> off, > >> where we meet for a few days and make sure that we are fully aligned and > >> use the same words and have the same thinking. > >> > >> That's both an opportunity, but also a risk, as it might lead to > >> divergence > >> in what we are saying and writing. > >> > >> We have two possible ways forward - either we vet documents and > >> discussions > >> internally every time, in order to present a more unified view on the > >> project, or we just drop that and we publish our documents and plans in > >> the > >> open immediately, with the understanding that this is merely > preliminary, > >> that there might be inconsistencies. We might discuss and disagree with > >> each other publicly in Phabricator tasks and on this mailing list and on > >> the wiki pages - but in the end, this is also an opportunity to together > >> with you build a common understanding and share the process of > developing > >> the project vision and implementation. > >> > >> So, in that light, we still have a small backlog of internal documents > >> that > >> we want to get out, and by the end of this week, most of the state of > the > >> work should be in the open, and we will move more and more of our > >> discussions to the public, to eventually have them all in the open. > >> > >> Here is a document I have been working on for a while, it is the core > >> model > >> of how the evaluation and representation of data, functions, and > function > >> calls in Wikilambda may work. Again, there is no agreement on this yet. > It > >> differs from the AbstractText prototype implementation, and there is a > >> list > >> of main differences at the end, and it also has not all the answers yet. > >> > >> Thanks to, particularly Arthur P. Smith for many comments and rewriting > of > >> some of the sections, thanks to Lucas Werkmeister for his valuable input > >> (and, even more important, for his work on GraalEneyj), thanks to Cyrus > >> Omar for his advice and pointers, and thanks to Adam Baso, James > >> Forrester, > >> and Nick Wilson for their internal comments. > >> > >> https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Function_model > >> > >> Feedback on this would be extremely valuable, and you can see there are > >> many open questions left. > >> > >> Stay safe, > >> Denny > >>

1 0

emails and lists (WAS: Two different kinds of information? (Andy))
by Željko Blaće 28 Jul '20

28 Jul '20

On Wed, 29 Jul 2020 at 01:51, Grounder UK <grounderuk(a)gmail.com> wrote: > Well, let's see, Denny... > I predict that omitting the name of the person I'm replying to will have > the effect you desire. (How logical is that?) > Fingers crossed! (...sorry, everyone) > Al. > > On Wednesday, 29 July 2020, < > abstract-wikipedia-request(a)lists.wikimedia.org> wrote: > >> Send Abstract-Wikipedia mailing list submissions to >> abstract-wikipedia(a)lists.wikimedia.org >> >> To subscribe or unsubscribe via the World Wide Web, visit >> https://lists.wikimedia.org/mailman/listinfo/abstract-wikipedia >> or, via email, send a message with subject or body 'help' to >> abstract-wikipedia-request(a)lists.wikimedia.org >> >> You can reach the person managing the list at >> abstract-wikipedia-owner(a)lists.wikimedia.org >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of Abstract-Wikipedia digest..." Hey all - Yes it is getting hard, but also nice to see constant influx of curious people joining in, also very in depth discussions in the list. Expecting for the email replies to list to be neat is a bit too late in 2020 as general use of good style deteriorated for at least last 2 decades... ...if there is going to be a bit of effort on this side - I think it should start with adding more instruction info to footer, than establishing introduction-to and maybe FAQ list? Best Z

1 0

Re: [Abstract-wikipedia] Two different kinds of information? (Andy)
by Grounder UK 28 Jul '20

28 Jul '20

Well, let's see, Denny... I predict that omitting the name of the person I'm replying to will have the effect you desire. (How logical is that?) Fingers crossed! (...sorry, everyone) Al. On Wednesday, 29 July 2020, <abstract-wikipedia-request(a)lists.wikimedia.org> wrote: > Send Abstract-Wikipedia mailing list submissions to > abstract-wikipedia(a)lists.wikimedia.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.wikimedia.org/mailman/listinfo/abstract-wikipedia > or, via email, send a message with subject or body 'help' to > abstract-wikipedia-request(a)lists.wikimedia.org > > You can reach the person managing the list at > abstract-wikipedia-owner(a)lists.wikimedia.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Abstract-Wikipedia digest..." > > > Today's Topics: > > 1. Re: Two different kinds of information? (Andy) (Denny Vrandečić) > 2. How to store wikitext along the structured content? > (Denny Vrandečić) > 3. Re: Two different kinds of information? (Denny Vrandečić) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 28 Jul 2020 13:57:52 -0700 > From: Denny Vrandečić <dvrandecic(a)wikimedia.org> > To: "General public mailing list for the discussion of Abstract > Wikipedia (aka Wikilambda)" <abstract-wikipedia@lists. > wikimedia.org> > Subject: Re: [Abstract-wikipedia] Two different kinds of information? > (Andy) > Message-ID: > <CA+bik1eS56HuAqtd6O-4OS-kexUzfvu0u4hsYfXtxc83Fms42w@ > mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Hi Al, > > just one quick request - can you set up your answers to the mailing list in > such a way that it doesn't break the thread? (I am not sure how, maybe > someone else can chime in, but right now, your answers start a new thread > instead of continuing the previous one). > > Louis Lecaillez had a similar issue initially, but managed to resolve it, > for which I am thankful. > > If not, it is OK, but I thought I'd ask. > > Thank you! > Denny > > > On Tue, Jul 28, 2020 at 8:23 AM Grounder UK <grounderuk(a)gmail.com> wrote: > > > Hi, Andy! Welcome! > > I do like your idea of being clear about basic "facts" and details. I > > think it will be key in the selection of "statements" that go into an > > "article", in whatever language is required. I don't think we can say how > > many levels of information there might be, but we can already see > something > > from how Wikipedia pages are put into categories. > > > > "France is a country in Europe" and "in western Europe" and "in the > > European Union", just to mention three categories. The first is an > > important fact of geography, but is the second more helpful? All > countries > > in western Europe are (1) a country and (2) in Europe and (3) to the > west. > > (3) feels more like a detail, but if we tell you France is in Europe, > what > > is the first question you might ask? It might be, "Is it in the European > > Union?" or "How big is it?" or "Do many people live there?" So I would > > expect us to give you those facts or details (FAQs) as well. > > > > Facts about facts and statements about claims are a whole other topic, > but > > if a "fact" is disputed, we do need to know how to show this. If you look > > at Wikidata, you will see that the United Kingdom has been a sovereign > > state since 1927. This is untrue. But if 1927 is not the answer to the > > question "How long has the UK been a country (or sovereign state)?", what > > is? "Since 1707, 1801 or 1922", depending on the details. Luckily for > you, > > France has "always" been a country, despite now being the fifth republic > > (since 1958). > > > > So, sometimes the Property of an entity is not a simple value or > > relationship. It might be better to think about it as a relationship to a > > "disagreement" or debate. Then, a "fact" is an entity's relationship to > an > > absence of "disagreement", a "consensus", as Wikipedia would call it. > Part > > of this consensus is the meaning of an entity's label. For example, > English > > Wikipedia thinks "oxygen" is the chemical element ("O") and "its most > > stable form" ("O2", "dioxygen"). French Wikipedia thinks > > "oxygène" is just the element. Wikidata has statements (mostly) about the > > element but the "Identifiers" (external authorities) are for the English > > Wikipedia concept, not the French one. The point is, it is clear that > there > > might be some confusion! We have a separate item for dioxygen and for > ozone > > and (in theory) for atomic oxygen (and there are others) so we can give > you > > all of the oxygen facts, mostly grouped by form (allotrope and/or state). > > Think of that as a disambiguation page enriched with detail... It's an > > interesting use case (or test case), I think. > > > > Best regards, > > Al. > > > > On Tuesday, 28 July 2020, <abstract-wikipedia-request@ > lists.wikimedia.org> > > wrote: > > > >> Send Abstract-Wikipedia mailing list submissions to > >> abstract-wikipedia(a)lists.wikimedia.org > >> > >> To subscribe or unsubscribe via the World Wide Web, visit > >> https://lists.wikimedia.org/mailman/listinfo/abstract-wikipedia > >> or, via email, send a message with subject or body 'help' to > >> abstract-wikipedia-request(a)lists.wikimedia.org > >> > >> You can reach the person managing the list at > >> abstract-wikipedia-owner(a)lists.wikimedia.org > >> > >> When replying, please edit your Subject line so it is more specific > >> than "Re: Contents of Abstract-Wikipedia digest..." > >> > >> > >> Today's Topics: > >> > >> 1. All work is preliminary (Denny Vrandečić) > >> 2. Two different kinds of information? (Andy) > >> > >> > >> ---------------------------------------------------------------------- > >> > >> Message: 1 > >> Date: Mon, 27 Jul 2020 12:43:05 -0700 > >> From: Denny Vrandečić <dvrandecic(a)wikimedia.org> > >> To: Abstract Wikipedia list <abstract-wikipedia(a)lists.wikimedia.org> > >> Subject: [Abstract-wikipedia] All work is preliminary > >> Message-ID: > >> <CA+bik1dNtpbA3H2_O= > >> 8H8iyNrBPMbpQeAaOb04EpEaoLxCWSZQ(a)mail.gmail.com> > >> Content-Type: text/plain; charset="utf-8" > >> > >> Hello all, > >> > >> one of the things we have been discussing in the team is that we want to > >> do > >> as much of our work in the open. At the same time, we're a distributed > >> team > >> and starting to form a shared understanding of the task at hand. Due to > >> the > >> COVID situation, we didn't have the opportunity to have a project kick > >> off, > >> where we meet for a few days and make sure that we are fully aligned and > >> use the same words and have the same thinking. > >> > >> That's both an opportunity, but also a risk, as it might lead to > >> divergence > >> in what we are saying and writing. > >> > >> We have two possible ways forward - either we vet documents and > >> discussions > >> internally every time, in order to present a more unified view on the > >> project, or we just drop that and we publish our documents and plans in > >> the > >> open immediately, with the understanding that this is merely > preliminary, > >> that there might be inconsistencies. We might discuss and disagree with > >> each other publicly in Phabricator tasks and on this mailing list and on > >> the wiki pages - but in the end, this is also an opportunity to together > >> with you build a common understanding and share the process of > developing > >> the project vision and implementation. > >> > >> So, in that light, we still have a small backlog of internal documents > >> that > >> we want to get out, and by the end of this week, most of the state of > the > >> work should be in the open, and we will move more and more of our > >> discussions to the public, to eventually have them all in the open. > >> > >> Here is a document I have been working on for a while, it is the core > >> model > >> of how the evaluation and representation of data, functions, and > function > >> calls in Wikilambda may work. Again, there is no agreement on this yet. > It > >> differs from the AbstractText prototype implementation, and there is a > >> list > >> of main differences at the end, and it also has not all the answers yet. > >> > >> Thanks to, particularly Arthur P. Smith for many comments and rewriting > of > >> some of the sections, thanks to Lucas Werkmeister for his valuable input > >> (and, even more important, for his work on GraalEneyj), thanks to Cyrus > >> Omar for his advice and pointers, and thanks to Adam Baso, James > >> Forrester, > >> and Nick Wilson for their internal comments. > >> > >> https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Function_model > >> > >> Feedback on this would be extremely valuable, and you can see there are > >> many open questions left. > >> > >> Stay safe, > >> Denny > >>

1 0

Two different kinds of information?
by Andy 28 Jul '20

28 Jul '20

Hi, I am new in this abstract-wikipedia mail list. If should be two layers of information? First: net of facts, like France (Q142) is a country (Q6256). <Q142> <rel_is> <Q6256> . and all detailed facts which should be understanded by computer. Second. usual human-readable sentences like Wikipedia, except they will language-independent like UNL? Or combine this two approaches?

2 1

Re: [Abstract-wikipedia] Two different kinds of information? (Andy)
by Grounder UK 28 Jul '20

28 Jul '20

Hi, Andy! Welcome! I do like your idea of being clear about basic "facts" and details. I think it will be key in the selection of "statements" that go into an "article", in whatever language is required. I don't think we can say how many levels of information there might be, but we can already see something from how Wikipedia pages are put into categories. "France is a country in Europe" and "in western Europe" and "in the European Union", just to mention three categories. The first is an important fact of geography, but is the second more helpful? All countries in western Europe are (1) a country and (2) in Europe and (3) to the west. (3) feels more like a detail, but if we tell you France is in Europe, what is the first question you might ask? It might be, "Is it in the European Union?" or "How big is it?" or "Do many people live there?" So I would expect us to give you those facts or details (FAQs) as well. Facts about facts and statements about claims are a whole other topic, but if a "fact" is disputed, we do need to know how to show this. If you look at Wikidata, you will see that the United Kingdom has been a sovereign state since 1927. This is untrue. But if 1927 is not the answer to the question "How long has the UK been a country (or sovereign state)?", what is? "Since 1707, 1801 or 1922", depending on the details. Luckily for you, France has "always" been a country, despite now being the fifth republic (since 1958). So, sometimes the Property of an entity is not a simple value or relationship. It might be better to think about it as a relationship to a "disagreement" or debate. Then, a "fact" is an entity's relationship to an absence of "disagreement", a "consensus", as Wikipedia would call it. Part of this consensus is the meaning of an entity's label. For example, English Wikipedia thinks "oxygen" is the chemical element ("O") and "its most stable form" ("O2", "dioxygen"). French Wikipedia thinks "oxygène" is just the element. Wikidata has statements (mostly) about the element but the "Identifiers" (external authorities) are for the English Wikipedia concept, not the French one. The point is, it is clear that there might be some confusion! We have a separate item for dioxygen and for ozone and (in theory) for atomic oxygen (and there are others) so we can give you all of the oxygen facts, mostly grouped by form (allotrope and/or state). Think of that as a disambiguation page enriched with detail... It's an interesting use case (or test case), I think. Best regards, Al. On Tuesday, 28 July 2020, <abstract-wikipedia-request(a)lists.wikimedia.org> wrote: > Send Abstract-Wikipedia mailing list submissions to > abstract-wikipedia(a)lists.wikimedia.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.wikimedia.org/mailman/listinfo/abstract-wikipedia > or, via email, send a message with subject or body 'help' to > abstract-wikipedia-request(a)lists.wikimedia.org > > You can reach the person managing the list at > abstract-wikipedia-owner(a)lists.wikimedia.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Abstract-Wikipedia digest..." > > > Today's Topics: > > 1. All work is preliminary (Denny Vrandečić) > 2. Two different kinds of information? (Andy) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 27 Jul 2020 12:43:05 -0700 > From: Denny Vrandečić <dvrandecic(a)wikimedia.org> > To: Abstract Wikipedia list <abstract-wikipedia(a)lists.wikimedia.org> > Subject: [Abstract-wikipedia] All work is preliminary > Message-ID: > <CA+bik1dNtpbA3H2_O=8H8iyNrBPMbpQeAaOb04EpEaoLxCWSZQ(a)mail.gm > ail.com> > Content-Type: text/plain; charset="utf-8" > > Hello all, > > one of the things we have been discussing in the team is that we want to do > as much of our work in the open. At the same time, we're a distributed team > and starting to form a shared understanding of the task at hand. Due to the > COVID situation, we didn't have the opportunity to have a project kick off, > where we meet for a few days and make sure that we are fully aligned and > use the same words and have the same thinking. > > That's both an opportunity, but also a risk, as it might lead to divergence > in what we are saying and writing. > > We have two possible ways forward - either we vet documents and discussions > internally every time, in order to present a more unified view on the > project, or we just drop that and we publish our documents and plans in the > open immediately, with the understanding that this is merely preliminary, > that there might be inconsistencies. We might discuss and disagree with > each other publicly in Phabricator tasks and on this mailing list and on > the wiki pages - but in the end, this is also an opportunity to together > with you build a common understanding and share the process of developing > the project vision and implementation. > > So, in that light, we still have a small backlog of internal documents that > we want to get out, and by the end of this week, most of the state of the > work should be in the open, and we will move more and more of our > discussions to the public, to eventually have them all in the open. > > Here is a document I have been working on for a while, it is the core model > of how the evaluation and representation of data, functions, and function > calls in Wikilambda may work. Again, there is no agreement on this yet. It > differs from the AbstractText prototype implementation, and there is a list > of main differences at the end, and it also has not all the answers yet. > > Thanks to, particularly Arthur P. Smith for many comments and rewriting of > some of the sections, thanks to Lucas Werkmeister for his valuable input > (and, even more important, for his work on GraalEneyj), thanks to Cyrus > Omar for his advice and pointers, and thanks to Adam Baso, James Forrester, > and Nick Wilson for their internal comments. > > https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Function_model > > Feedback on this would be extremely valuable, and you can see there are > many open questions left. > > Stay safe, > Denny >

2 1

Reasoning over ontologies
by Grounder UK 28 Jul '20

28 Jul '20

Thanks, Adam. I'm changing the subject just to get this "out there" because what you said about "intricate parse trees" reminded me of this paper, which I came across last night. https://www.sciencedirect.com/science/article/pii/S1570826817300367 It occurs to me that our early stage of Content Selection might initially be realised or instantiated as a focused ontology (focused on some Wikidata Item of interest). The authors of this paper say: "We developed the Inference Inspector, a novel Protégé plugin that alerts the author to the changes to key entailment sets that have occurred as a consequence of a modelling action." If we replace "modelling action" with "NLG/human interaction", maybe we have ourselves an interesting feedback loop? Wikipedia contributors could interact with these extracted ontologies to see, in generated natural language, the consequences of changes. Here, the changes I have in mind are to the linguistic knowledge rather than the encyclopedic content, but they are not different in principle. The goal would be to evolve the Renderers (considered more as data than function, whilst acknowledging that the functions are also data). Continuously evolving Renderers are a deliverable from this project, aren't they? I know Protégé has a pretty wide user base, but it doesn't include me. Does anyone have any practical experience they'd like to share? Best regards, Al. On Sunday, 26 July 2020, <abstract-wikipedia-request(a)lists.wikimedia.org> wrote: > Send Abstract-Wikipedia mailing list submissions to > abstract-wikipedia(a)lists.wikimedia.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.wikimedia.org/mailman/listinfo/abstract-wikipedia > or, via email, send a message with subject or body 'help' to > abstract-wikipedia-request(a)lists.wikimedia.org > > You can reach the person managing the list at > abstract-wikipedia-owner(a)lists.wikimedia.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Abstract-Wikipedia digest..." > > > Today's Topics: > > 1. Re: Conjugation and Declension Functions (Adam Sobieski) > (Adam Sobieski) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 26 Jul 2020 15:22:07 +0000 > From: Adam Sobieski <adamsobieski(a)hotmail.com> > To: "General public mailing list for the discussion of Abstract > Wikipedia (aka Wikilambda)" <abstract-wikipedia(a)lists.wiki > media.org> > Subject: Re: [Abstract-wikipedia] Conjugation and Declension Functions > (Adam Sobieski) > Message-ID: > <CH2PR12MB4184F449E9BE14DF0C61D8F5C5750(a)CH2PR12MB4184.namprd > 12.prod.outlook.com> > > Content-Type: text/plain; charset="windows-1252" > > Al, > > Inverse parsing makes sense. The parse tree in your example is expressive. > Your example also shows a means of describing nouns or noun phrases as > being Wikidata entities which would facilitate producing hyperlinks in > resultant articles. > > It could be that some of the natural language generation functions on > Wikilambda will, instead of concatenating strings, work with trees or > tree-based data. The classes for things like phrases, clauses, sentences, > and so forth, could be tree-based or contain tree-based data. The matter > could be one of producing intricate parse trees (or using an equivalent > object model) from Wikidata data to then inverse parse into natural > language sentences. > > > Best regards, > Adam > > From: Grounder UK<mailto:grounderuk@gmail.com> > Sent: Saturday, July 25, 2020 8:12 PM > To: abstract-wikipedia(a)lists.wikimedia.org<mailto:abstract-wikip > edia(a)lists.wikimedia.org> > Subject: [Abstract-wikipedia] Conjugation and Declension Functions (Adam > Sobieski) > > You're welcome, Adam. > > Far be it from me to disagree with Reiter and Dale (and I don't). I find > it odd, however, that you put "hit<…>(Context, Array)". I wonder how, in > our Wikipedic context, we get the idea of a verb? And why do we put it > outside our array? > > The reality is that Wikipedias are about things, in the main: people, > places, objects, types and historical events. These things have properties > and different types of involvement in events, but I guess more than half > the time we have to invent (or select or find...) a suitable verb for the > set of objects we find to be related (from the claims in Wikidata). If > English didn't demand a finite verb, our Wikipedia would manage perfectly > well without them, just as Wikidata does (although they "lurk" within > Properties). > > To my way of thinking, if there is any substance of note in the sense of > the verb, it must be in the array of Senses (never mind their lexical > form). Of course, you might reason that we start with an array of "involved > senses" and infer the verb, which we can then inflect. It's part of > Lexicalization rather than Realization, in other words. Maybe that is > generally so, but I am not convinced that we should immediately assume that > it must be so in our Wikipedic context. > > For me, in any event, Realization in our context is just the final > transformation of a near-final representation of our content, so I wouldn't > expect it to change the sequence of ideas or change around syntactic roles. > If you're deriving roles and sequences, then you're doing Lexicalization > (or you're at a higher level) and you won't generally know what the verb is > going to be at that stage (how could you?). It could be "strike", "hit" or > "bat", for example. And the involvement of a bat in our array might be a > good reason to choose the verb "bat" or a good reason to avoid it, > depending on the particular context. If we choose "bat" as the verb, we > will probably also drop it from the instrument role because that role is > implied by the verb ("hit with a bat"). That "fact" will also keep us from > choosing the verb "bat" if we need to refer to the bat as an object (to > specify that it was her father's bat, for example). If the verb "bat" is > going to subsume the instrument role, the instrument must be wholly > indefinite ("hit with 'any old' bat" rather than "hit with one of the > bats"). > > Returning to Reiter and Dale, I think it makes sense to view this problem > in reverse, as inverse parsing. As they say, you can parse the three forms > into a single "logical form" (which some might call "abstract content") and > there must be some loss of information in this process, since we cannot > guarantee that we will get back to the form we started with if we invert > the parsing. It is this lost information that we need to retain when we > have parsed (for future reference) and to have available before we proceed > to Realize (or "render"). Our logical "manual of style" is what we might > use to derive the missing information that we must have available, if we > cannot infer it from the selected Wikidata content. > > To begin again at the end, I might say we can parse "Bobby batted the > ball" as something like: Sentence< {comment: here, Sentence = Subject + > Verb Phrase} > Subject< Noun Phrase< Noun <Alias<"Bobby">, entity<Q???>> >> > + Verb Phrase< {comment: here, Verb Phrase = Verb + Instrument + Direct > Object} > Verb< Sense<"hit">, Tense<simple past>, Voice<active>> > + Instrument< Noun Phrase< Noun< Sense<"bat">> + Determiner<indefinite>> > + Direct Object< Noun Phrase< Noun< Sense<"ball">> + Determiner<definite>> > >>. > > Assuming I've parsed that correctly (and it's been a few years since I had > to), we can assert that this "logical form" shall be valid input into our > Realization function. What do we get back? "Bobby hit the ball with a bat". > I had to cheat, of course. The reason, I suppose, is that the subsumed noun > phrase was prepositional and non-prepositional noun phrases, in English, > tend to attach themselves to their verbs ("I gave him it" versus "I gave it > to him", for example). So when I surfaced the subsumed instrumental, "with > a bat" (which is more interpretation than parsing), the result was > naturally in the wrong order, coming between the verb and the existing > non-prepositional noun phrase, "the ball". The order shouldn't matter to > the renderer, unless it's explicit. But I did say that I wouldn't expect > Realization to change the sequence of ideas, and then it had to because > "Bobby hit with a bat the ball" is un-English in any unfanciful context > (although perfectly understandable). Full disclosure, as they say! > > So, if interpretive parsing surfaces subsumed elements, some > Lexicalization may be required to establish a "logical form" that is valid > input into Realization. Alternatively, we might consider that to occur > within the inverse of Referring Expression Generation, since it is loosely > analogous to surfacing nouns from pronouns and might be considered to be a > kind of anaphora (locally, at least, it is likely to be exophoric: "batted" > implies an unspecified bat, as discussed above, but surfacing it renders it > endophoric, if you'll forgive the pun, and thus anaphoric at that level). > > By the way, Reiter claims to have written or admits to writing the main > articles on natural language generation in the English Wikipedia. You can > find the links in: https://meta.wikimedia.org/wik > i/Abstract_Wikipedia/Related_and_previous_work/Natural_language_generation > . > > Best regards, > Al. > > On Saturday, 25 July 2020, <abstract-wikipedia-request(a)lists.wikimedia.org > <mailto:abstract-wikipedia-request@lists.wikimedia.org>> wrote: > Send Abstract-Wikipedia mailing list submissions to > abstract-wikipedia(a)lists.wikimedia.org<mailto:abstract-wikip > edia(a)lists.wikimedia.org> > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.wikimedia.org/mailman/listinfo/abstract-wikipedia > or, via email, send a message with subject or body 'help' to > abstract-wikipedia-request(a)lists.wikimedia.org<mailto:abstra > ct-wikipedia-request(a)lists.wikimedia.org> > > You can reach the person managing the list at > abstract-wikipedia-owner(a)lists.wikimedia.org<mailto:abstract > -wikipedia-owner(a)lists.wikimedia.org> > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Abstract-Wikipedia digest..." > > > Today's Topics: > > 1. Re: Conjugation and Declension Functions (Adam Sobieski) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sat, 25 Jul 2020 17:43:55 +0000 > From: Adam Sobieski <adamsobieski(a)hotmail.com<mailto: > adamsobieski(a)hotmail.com>> > To: "General public mailing list for the discussion of Abstract > Wikipedia (aka Wikilambda)" <abstract-wikipedia(a)lists.wiki > media.org<mailto:abstract-wikipedia@lists.wikimedia.org>> > Subject: Re: [Abstract-wikipedia] Conjugation and Declension Functions > Message-ID: > <CH2PR12MB41848A048AE721573F59A218C5740(a)CH2PR12MB4184.namprd > 12.prod.outlook.com<mailto:CH2PR12MB41848A048AE721573F59A218 > C5740(a)CH2PR12MB4184.namprd12.prod.outlook.com>> > > Content-Type: text/plain; charset="windows-1252" > > Thank you all for the comments and feedback thus far. > > > > I would like to indicate that we could also utilize the expressiveness of > JavaScript/TypeScript for array literals with object literal elements. In > this alternative approach, arguments could be placed into an array of > objects which each attach a thematic role to an argument. “Bobby”, “ball” > and “bat” could be objects of type Noun, and we could pass to a function an > array literal of object literals to get at the desired concepts of: (1) > sequence, (2) roles, (3) values. That is rather the matter: attaching > thematic roles to elements of a sequence of arguments. > > > > To the example pseudocode: > > > > Noun Bobby; > > Noun ball; > > Noun bat; > > > > hit<voice::active, tense::past, aspect::perfective, > mood::indicative>(context, [ {role: ‘agent’, value: Bobby}, {role: > ‘patient’, value: ball}, {role: ‘instrument’, value: bat} ]) --> “Bobby hit > the ball with the bat” > > hit<voice::active, tense::past, aspect::perfective, > mood::indicative>(context, [ {role: ‘agent’, value: Bobby}, {role: > ‘instrument’, value: bat}, {role: ‘patient’, value: ball} ]) --> “Bobby, > with the bat, hit the ball” > > hit<voice::active, tense::past, aspect::perfective, > mood::indicative>(context, [ {role: ‘instrument’, value: bat}, {role: > ‘agent’, value: Bobby}, {role: ‘patient’, value: ball} ]) --> “With the > bat, Bobby hit the ball” > > > > or, if the grammatical arguments (voice, tense, aspect, mood) are > properties of the context object: > > > > hit(context, [ {role: ‘agent’, value: Bobby}, {role: ‘patient’, value: > ball}, {role: ‘instrument’, value: bat} ]) --> “Bobby hit the ball with the > bat” > > hit(context, [ {role: ‘agent’, value: Bobby}, {role: ‘instrument’, value: > bat}, {role: ‘patient’, value: ball} ]) --> “Bobby, with the bat, hit the > ball” > > hit(context, [ {role: ‘instrument’, value: bat}, {role: ‘agent’, value: > Bobby}, {role: ‘patient’, value: ball} ]) --> “With the bat, Bobby hit the > ball” > > > > A downside would be that the function signatures would resemble: > > > > hit<…>(Context, Array) > > > > or > > > > hit<…>(Context, Array<RoleNounPair>) > > > > An upside would be expressiveness with which to indicate desired output > paraphrases. > > > > These topics are discussed in Building Natural Language Generation Systems > by Reiter and Dale [1], in chapter 6 on Surface Realization, in section 6.8 > on Bidirectional Grammars, pages 194 – 195, where the authors indicate that > while “a parser might produce the same logical form for the following three > sentences: > > > > 1. Mary gave John a ball. > 2. Mary gave a ball to John. > 3. John was given a ball by Mary. > > > > “The input to a realizer, however, should explicitly provide a means of > choosing among these forms; the alternative is to choose at random.” (as > noted, another alternative is to select using a manual of style). > > > > The authors also indicate that Winograd [2] provided a list of paraphrases > for consideration: > > > > 1. Jon bought a painting for Vina. > 2. Jon bought Vina a painting. > 3. Vina was bought a painting by Jon. > 4. What Jon bought Vina was a painting. > 5. What Vina was bought by Jon was a painting. > 6. It was a painting that Jon bought for Vina. > 7. It was Jon that bought Vina a painting. > 8. It was Vina that Jon bought a painting for. > > > > On the topic of “a” or “the”, definite or indefinite noun phrases, we can > note a discussion in Reiter and Dale [1], section 5.4.2, on page 145. That > is another important discussion topic. > > > > In the set of approaches under discussion, by making use of grammatical > arguments (e.g. voice, tense, aspect, mood) and by placing thematic roles > on elements of a sequence of arguments, we have an expressiveness beyond > that of predicate calculus with which to distinguish paraphrases. > > > > > > Best regards, > > Adam > > > > [1] Reiter, Ehud, and Robert Dale. Building natural language generation > systems. Cambridge university press, 2000. > > [2] Winograd, Terry. "Language as a cognitive process." (1983). > > From: Adam Sobieski<mailto:adamsobieski@hotmail.com<mailto:adamsobieski > @hotmail.com>> > Sent: Friday, July 24, 2020 7:07 PM > To: General public mailing list for the discussion of Abstract Wikipedia > (aka Wikilambda)<mailto:abstract-wikipedia@lists.wikimedia.org<mailto: > abstract-wikipedia(a)lists.wikimedia.org>> > Subject: Re: [Abstract-wikipedia] Conjugation and Declension Functions > > In addition to broaching the discovery, encoding and reuse of > language-specific patterns, which I view as a discussion topic when > comparing and contrasting approaches (see: the DRY principle [1] and the > abstraction principle [2]), and indicating how conjugation and declension > functions would facilitate the discovery, encoding and reuse of these > patterns, I would like to share some topics which arose as I explored > adding the thematic relation [3] of instrument to the agent-patient pair. > > When exploring how best to add the thematic relation of instrument to the > agent-patient pair (e.g. adding “using the bat” to “Bobby hit the ball”), I > observed that, for the same input grammatical arguments, there was a set of > possible output paraphrases: > > > 1. “Bobby hit the ball using the bat” > 2. “Bobby, using the bat, hit the ball” > 3. “Using the bat, Bobby hit the ball” > > I wondered: how might we be able to generate each? > > One possibility is indicated. There could be a type for each thematic > relation [3]. Then, using explicit type conversions to these types, we > could have different functions for different sequences of input arguments. > > That is, > > hit<voice::active, tense::past, aspect::perfective, > mood::indicative>(context, (Agent)Bobby, (Patient)ball, (Instrument)bat) > --> “Bobby hit the ball using the bat” > hit<voice::active, tense::past, aspect::perfective, > mood::indicative>(context, (Agent)Bobby, (Instrument)bat, (Patient)ball) > --> “Bobby, using the bat, hit the ball” > hit<voice::active, tense::past, aspect::perfective, > mood::indicative>(context, (Instrument)bat, (Agent)Bobby, (Patient)ball) > --> “Using the bat, Bobby hit the ball” > > or > > hit<voice::active, tense::past, aspect::perfective, > mood::indicative>(context, Bobby as Agent, ball as Patient, bat as > Instrument) --> “Bobby hit the ball using the bat” > hit<voice::active, tense::past, aspect::perfective, > mood::indicative>(context, Bobby as Agent, bat as Instrument, ball as > Patient) --> “Bobby, using the bat, hit the ball” > hit<voice::active, tense::past, aspect::perfective, > mood::indicative>(context, bat as Instrument, Bobby as Agent, ball as > Patient) --> “Using the bat, Bobby hit the ball” > > These functions could each wrap the use of patterns (as indicated in > previous email) and attempt to realize output sentences utilizing the > arguments in the same sequence in which they were provided. This would, > however, mean that the callers of the functions would be responsible for > “shuffling” the input arguments to express the desired paraphrase ((1), > (2), (3)). > > There are, of course, other approaches to consider and other possibilities > to consider with respect to addressing the matter of outputting the example > paraphrases. > > Any thoughts on these topics? > > > Best regards, > Adam > > [1] https://en.wikipedia.org/wiki/Don%27t_repeat_yourself > [2] https://en.wikipedia.org/wiki/Abstraction_principle_(compute > r_programming) > [3] https://en.wikipedia.org/wiki/Thematic_relation > > P.S.: We could also put the grammatical arguments on the context object > (context.voice, context.tense, context.aspect, context.mood, et cetera) and > then make use of generic parameters for other uses. > > From: Adam Sobieski<mailto:adamsobieski@hotmail.com<mailto:adamsobieski > @hotmail.com>> > Sent: Thursday, July 23, 2020 7:38 PM > To: General public mailing list for the discussion of Abstract Wikipedia > (aka Wikilambda)<mailto:abstract-wikipedia@lists.wikimedia.org<mailto: > abstract-wikipedia(a)lists.wikimedia.org>> > Subject: RE: Conjugation and Declension Functions > > > I had an idea about discovering, encoding and reusing patterns in > languages that I would like to share with the group. > > > > The following is rough-draft pseudocode for a function with which to > generate sentences for the verb “to kick”. The function has generic > parameters for voice and tense and parameters for context, agent and > patient. > > > > Clause kick<V, T>(Context context, Noun agent, Noun patient) > > { > > switch(V) > > { > > case voice::active: > > switch(T) > > { > > case tense::past: > > case tense::present: > > return join(" ", [ > > agent, > > conjugate_en(“kick”, V, T, …), > > “the”, > > patient > > ]); > > case tense::future: > > return join(" ", [ > > agent, > > “will”, > > conjugate_en(“kick”, V, T, …), > > “the”, > > patient > > ]); > > … > > } > > case voice::passive: > > switch(T) > > { > > case tense::past: > > return join(" ", [ > > “the”, > > patient, > > “was”, > > conjugate_en(“kick”, V, T, …), > > “by” > > agent > > ]); > > case tense::present: > > return join(" ", [ > > “the”, > > patient, > > “is”, > > “being”, > > conjugate_en(“kick”, V, T, …), > > “by” > > agent > > ]); > > … > > } > > } > > } > > > > and > > > > kick<voice::active, tense::past>(context, Bobby, ball) returns “Bobby > kicked the ball”. > > > > In English, most combinations of tense, aspect, mood and voice are > expressed periphrastically, using constructions with auxiliary verbs. After > implementing a number of these for similar verbs, per the above example, we > would notice a pattern. That pattern could be expressed as something > resembling: > > > > Clause pattern123<V, T>(Context context, Verb verb, Noun agent, Noun > patient) > > { > > switch(V) > > { > > case voice::active: > > switch(T) > > { > > case tense::past: > > case tense::present: > > return join(" ", [ > > agent, > > conjugate_en(verb, V, T, …), > > “the”, > > patient > > ]); > > case tense::future: > > return join(" ", [ > > agent, > > “will”, > > conjugate_en(verb, V, T, …), > > “the”, > > patient > > ]); > > … > > } > > case voice::passive: > > switch(T) > > { > > case tense::past: > > return join(" ", [ > > “the”, > > patient, > > “was”, > > conjugate_en(verb, V, T, …), > > “by” > > agent > > ]); > > case tense::present: > > return join(" ", [ > > “the”, > > patient, > > “is”, > > “being”, > > conjugate_en(verb, V, T, …), > > “by” > > agent > > ]); > > … > > } > > } > > } > > > We could then simply express that the verb “to kick” is an instance of > pattern pattern123 with something resembling: > > > > Clause kick<V, T>(Context context, Noun agent, Noun patient) > > { > > pattern123<V, T>(context, new Verb(“kick”, …), agent, patient); > > } > > or > > > Clause kick<V, T>(Context context, Noun agent, Noun patient) > > { > > pattern123<V, T>(context, getVerb(“https://…#kick”), agent, patient); > > } > > and this pattern could be reused for a large number of verbs. > > This use of patterns should extend to scenarios where there are more > parameters for other thematically-related nouns: > > > > Clause kick<V, T>(Context context, Noun agent, Noun patient, Noun > instrument) > > { > > pattern1234<V, T>(context, new Verb(“kick”, …), agent, patient, > instrument); > > } > > For English, there might be more generic parameters than those for voice > and tense; we could add those for aspect and mood (e.g. pattern1234<V, T, > A, M>(…)). > > In conclusion, with generic programming and functions for conjugation and > declension, we have expressiveness with which to discover, encode and reuse > language-specific patterns. > > > Best regards, > Adam Sobieski > > >

2 1

Abstract-Wikipedia Digest, Vol 1, Issue 90
by Grounder UK 26 Jul '20

26 Jul '20

Nice one, Adam! I'm liking the constraints paradigm because it follows the real-world domain, conceived of as an inverse pyramid: Not all claims are expressed in a Wikipedia, and of those Not all claims are codified in Wikidata, and of those Not all claims are "salient", given our topic of interest, and of those, Not all claims are yet expressible as natural language output, and of those, Not all claims are expressible in the target language, and of those, Natural language generation filters apply for sense, volume... Funnelled into rendering: "I sat at my desk, stared into the garden and thought '42 will do' . I typed it out. End of story." Douglas Adams (Q42) Do you have a link for that OU paper [1]? Best regards, Al. On Sunday, 26 July 2020, <abstract-wikipedia-request(a)lists.wikimedia.org> wrote: > Send Abstract-Wikipedia mailing list submissions to > abstract-wikipedia(a)lists.wikimedia.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.wikimedia.org/mailman/listinfo/abstract-wikipedia > or, via email, send a message with subject or body 'help' to > abstract-wikipedia-request(a)lists.wikimedia.org > > You can reach the person managing the list at > abstract-wikipedia-owner(a)lists.wikimedia.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Abstract-Wikipedia digest..." > > > Today's Topics: > > 1. Re: Conjugation and Declension Functions (Adam Sobieski) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 26 Jul 2020 15:38:35 +0000 > From: Adam Sobieski <adamsobieski(a)hotmail.com> > To: "General public mailing list for the discussion of Abstract > Wikipedia (aka Wikilambda)" <abstract-wikipedia(a)lists.wiki > media.org> > Subject: Re: [Abstract-wikipedia] Conjugation and Declension Functions > Message-ID: > <CH2PR12MB41847550B85B34171077395FC5750(a)CH2PR12MB4184.namprd > 12.prod.outlook.com> > > Content-Type: text/plain; charset="windows-1252" > > We could also view the matter as being one of specifying a set of > constraints [1][2] with which to describe a desired sentence. > > That is, the syntactic sugar: > > (1) hit<voice::active, tense::past, aspect::perfective, > mood::indicative>(context, [ {role: ‘agent’, value: Bobby}, {role: > ‘patient’, value: ball}, {role: ‘instrument’, value: bat} ]); > > could be viewed as indicating a number of simultaneous constraints with > regard to a desired sentence. With an expression tree model, we could form > expressions for a constraint-based system while making use of objects in > scope. > > > 1. constraints.add(expr.equals(expr.symbol(‘verb’), > expr.constant(getVerb(‘https://example.com/verb#hit’)))); > > The generic arguments “<voice::active, tense::past, aspect::perfective, > mood::indicative>” could translate or map to: > > > 1. constraints.add(expr.equals(expr.symbol(‘voice’), > expr.constant(‘active’))); > 2. constraints.add(expr.equals(expr.symbol(‘tense’), > expr.constant(‘past’))); > 3. constraints.add(expr.equals(expr.symbol(‘aspect’), > expr.constant(‘perfective’))); > 4. constraints.add(expr.equals(expr.symbol(‘mood’), > expr.constant(‘indicative’))); > > Next, to the array of role-adorned nouns, “[ {role: ‘agent’, value: > Bobby}, {role: ‘patient’, value: ball}, {role: ‘instrument’, value: bat} ]”: > > > 1. constraints.add(expr.equals(expr.property(e0, ‘role’), > expr.constant(‘agent’))); > 2. constraints.add(expr.equals(expr.property(e0, ‘value’), > expr.constant(Bobby))); > > > 1. constraints.add(expr.equals(expr.property(e1, ‘role’), > expr.constant(‘patient’))); > 2. constraints.add(expr.equals(expr.property(e1, ‘value’), > expr.constant(ball))); > > > 1. constraints.add(expr.equals(expr.property(e2, ‘role’), > expr.constant(‘instrument’))); > 2. constraints.add(expr.equals(expr.property(e2, ‘value’), > expr.constant(ball))); > > > 1. constraints.add(expr.holds(‘occursInSentenceBefore’, Bobby, ball)); > 2. constraints.add(expr.holds(‘occursInSentenceBefore’, ball, bat)); > > There exists mappings from the information in the generic function > invocation (1) to rough-draft pseudocode for describing a set of > constraints ((a) – (m)). > > We could also add scalars as arguments when adding constraints to a set. > For instance, we could add scalar arguments to (l) and (m): > > constraints.add(expr.holds(‘occursInSentenceBefore’, Bobby, ball), 0.5); > constraints.add(expr.holds(‘occursInSentenceBefore’, ball, bat), 0.5); > > Constraint-based approaches are both expressive and extensible. With a set > of weighted constraints describing a desired output sentence, we could then > invoke a sentence realizer: > > realizeSentence(constraints) --> “Bobby hit the ball with the bat” > > > Best regards, > Adam > > [1] Piwek, Paul, and Kees Van Deemter. Constraint-based natural language > generation: A survey. Technical Report 2006/03, Computing Department, The > Open University, 2006. > [2] https://en.wikipedia.org/wiki/Constraint_programming > > From: Adam Sobieski<mailto:adamsobieski@hotmail.com> > Sent: Saturday, July 25, 2020 1:43 PM > To: General public mailing list for the discussion of Abstract Wikipedia > (aka Wikilambda)<mailto:abstract-wikipedia@lists.wikimedia.org> > Subject: RE: Conjugation and Declension Functions > > > Thank you all for the comments and feedback thus far. > > > > I would like to indicate that we could also utilize the expressiveness of > JavaScript/TypeScript for array literals with object literal elements. In > this alternative approach, arguments could be placed into an array of > objects which each attach a thematic role to an argument. “Bobby”, “ball” > and “bat” could be objects of type Noun, and we could pass to a function an > array literal of object literals to get at the desired concepts of: (1) > sequence, (2) roles, (3) values. That is rather the matter: attaching > thematic roles to elements of a sequence of arguments. > > > > To the example pseudocode: > > > > Noun Bobby; > > Noun ball; > > Noun bat; > > > > hit<voice::active, tense::past, aspect::perfective, > mood::indicative>(context, [ {role: ‘agent’, value: Bobby}, {role: > ‘patient’, value: ball}, {role: ‘instrument’, value: bat} ]) --> “Bobby hit > the ball with the bat” > > hit<voice::active, tense::past, aspect::perfective, > mood::indicative>(context, [ {role: ‘agent’, value: Bobby}, {role: > ‘instrument’, value: bat}, {role: ‘patient’, value: ball} ]) --> “Bobby, > with the bat, hit the ball” > > hit<voice::active, tense::past, aspect::perfective, > mood::indicative>(context, [ {role: ‘instrument’, value: bat}, {role: > ‘agent’, value: Bobby}, {role: ‘patient’, value: ball} ]) --> “With the > bat, Bobby hit the ball” > > > > or, if the grammatical arguments (voice, tense, aspect, mood) are > properties of the context object: > > > > hit(context, [ {role: ‘agent’, value: Bobby}, {role: ‘patient’, value: > ball}, {role: ‘instrument’, value: bat} ]) --> “Bobby hit the ball with the > bat” > > hit(context, [ {role: ‘agent’, value: Bobby}, {role: ‘instrument’, value: > bat}, {role: ‘patient’, value: ball} ]) --> “Bobby, with the bat, hit the > ball” > > hit(context, [ {role: ‘instrument’, value: bat}, {role: ‘agent’, value: > Bobby}, {role: ‘patient’, value: ball} ]) --> “With the bat, Bobby hit the > ball” > > > > A downside would be that the function signatures would resemble: > > > > hit<…>(Context, Array) > > > > or > > > > hit<…>(Context, Array<RoleNounPair>) > > > > An upside would be expressiveness with which to indicate desired output > paraphrases. > > > > These topics are discussed in Building Natural Language Generation Systems > by Reiter and Dale [1], in chapter 6 on Surface Realization, in section 6.8 > on Bidirectional Grammars, pages 194 – 195, where the authors indicate that > while “a parser might produce the same logical form for the following three > sentences: > > > > 1. Mary gave John a ball. > 2. Mary gave a ball to John. > 3. John was given a ball by Mary. > > > > “The input to a realizer, however, should explicitly provide a means of > choosing among these forms; the alternative is to choose at random.” (as > noted, another alternative is to select using a manual of style). > > > > The authors also indicate that Winograd [2] provided a list of paraphrases > for consideration: > > > > 1. Jon bought a painting for Vina. > 2. Jon bought Vina a painting. > 3. Vina was bought a painting by Jon. > 4. What Jon bought Vina was a painting. > 5. What Vina was bought by Jon was a painting. > 6. It was a painting that Jon bought for Vina. > 7. It was Jon that bought Vina a painting. > 8. It was Vina that Jon bought a painting for. > > > > On the topic of “a” or “the”, definite or indefinite noun phrases, we can > note a discussion in Reiter and Dale [1], section 5.4.2, on page 145. That > is another important discussion topic. > > > > In the set of approaches under discussion, by making use of grammatical > arguments (e.g. voice, tense, aspect, mood) and by placing thematic roles > on elements of a sequence of arguments, we have an expressiveness beyond > that of predicate calculus with which to distinguish paraphrases. > > > > > > Best regards, > > Adam > > > > [1] Reiter, Ehud, and Robert Dale. Building natural language generation > systems. Cambridge university press, 2000. > > [2] Winograd, Terry. "Language as a cognitive process." (1983). > > From: Adam Sobieski<mailto:adamsobieski@hotmail.com> > Sent: Friday, July 24, 2020 7:07 PM > To: General public mailing list for the discussion of Abstract Wikipedia > (aka Wikilambda)<mailto:abstract-wikipedia@lists.wikimedia.org> > Subject: Re: [Abstract-wikipedia] Conjugation and Declension Functions > > In addition to broaching the discovery, encoding and reuse of > language-specific patterns, which I view as a discussion topic when > comparing and contrasting approaches (see: the DRY principle [1] and the > abstraction principle [2]), and indicating how conjugation and declension > functions would facilitate the discovery, encoding and reuse of these > patterns, I would like to share some topics which arose as I explored > adding the thematic relation [3] of instrument to the agent-patient pair. > > When exploring how best to add the thematic relation of instrument to the > agent-patient pair (e.g. adding “using the bat” to “Bobby hit the ball”), I > observed that, for the same input grammatical arguments, there was a set of > possible output paraphrases: > > > 1. “Bobby hit the ball using the bat” > 2. “Bobby, using the bat, hit the ball” > 3. “Using the bat, Bobby hit the ball” > > I wondered: how might we be able to generate each? > > One possibility is indicated. There could be a type for each thematic > relation [3]. Then, using explicit type conversions to these types, we > could have different functions for different sequences of input arguments. > > That is, > > hit<voice::active, tense::past, aspect::perfective, > mood::indicative>(context, (Agent)Bobby, (Patient)ball, (Instrument)bat) > --> “Bobby hit the ball using the bat” > hit<voice::active, tense::past, aspect::perfective, > mood::indicative>(context, (Agent)Bobby, (Instrument)bat, (Patient)ball) > --> “Bobby, using the bat, hit the ball” > hit<voice::active, tense::past, aspect::perfective, > mood::indicative>(context, (Instrument)bat, (Agent)Bobby, (Patient)ball) > --> “Using the bat, Bobby hit the ball” > > or > > hit<voice::active, tense::past, aspect::perfective, > mood::indicative>(context, Bobby as Agent, ball as Patient, bat as > Instrument) --> “Bobby hit the ball using the bat” > hit<voice::active, tense::past, aspect::perfective, > mood::indicative>(context, Bobby as Agent, bat as Instrument, ball as > Patient) --> “Bobby, using the bat, hit the ball” > hit<voice::active, tense::past, aspect::perfective, > mood::indicative>(context, bat as Instrument, Bobby as Agent, ball as > Patient) --> “Using the bat, Bobby hit the ball” > > These functions could each wrap the use of patterns (as indicated in > previous email) and attempt to realize output sentences utilizing the > arguments in the same sequence in which they were provided. This would, > however, mean that the callers of the functions would be responsible for > “shuffling” the input arguments to express the desired paraphrase ((1), > (2), (3)). > > There are, of course, other approaches to consider and other possibilities > to consider with respect to addressing the matter of outputting the example > paraphrases. > > Any thoughts on these topics? > > > Best regards, > Adam > > [1] https://en.wikipedia.org/wiki/Don%27t_repeat_yourself > [2] https://en.wikipedia.org/wiki/Abstraction_principle_(compute > r_programming) > [3] https://en.wikipedia.org/wiki/Thematic_relation > > P.S.: We could also put the grammatical arguments on the context object > (context.voice, context.tense, context.aspect, context.mood, et cetera) and > then make use of generic parameters for other uses. > > From: Adam Sobieski<mailto:adamsobieski@hotmail.com> > Sent: Thursday, July 23, 2020 7:38 PM > To: General public mailing list for the discussion of Abstract Wikipedia > (aka Wikilambda)<mailto:abstract-wikipedia@lists.wikimedia.org> > Subject: RE: Conjugation and Declension Functions > > > I had an idea about discovering, encoding and reusing patterns in > languages that I would like to share with the group. > > > > The following is rough-draft pseudocode for a function with which to > generate sentences for the verb “to kick”. The function has generic > parameters for voice and tense and parameters for context, agent and > patient. > > > > Clause kick<V, T>(Context context, Noun agent, Noun patient) > > { > > switch(V) > > { > > case voice::active: > > switch(T) > > { > > case tense::past: > > case tense::present: > > return join(" ", [ > > agent, > > conjugate_en(“kick”, V, T, …), > > “the”, > > patient > > ]); > > case tense::future: > > return join(" ", [ > > agent, > > “will”, > > conjugate_en(“kick”, V, T, …), > > “the”, > > patient > > ]); > > … > > } > > case voice::passive: > > switch(T) > > { > > case tense::past: > > return join(" ", [ > > “the”, > > patient, > > “was”, > > conjugate_en(“kick”, V, T, …), > > “by” > > agent > > ]); > > case tense::present: > > return join(" ", [ > > “the”, > > patient, > > “is”, > > “being”, > > conjugate_en(“kick”, V, T, …), > > “by” > > agent > > ]); > > … > > } > > } > > } > > > > and > > > > kick<voice::active, tense::past>(context, Bobby, ball) returns “Bobby > kicked the ball”. > > > > In English, most combinations of tense, aspect, mood and voice are > expressed periphrastically, using constructions with auxiliary verbs. After > implementing a number of these for similar verbs, per the above example, we > would notice a pattern. That pattern could be expressed as something > resembling: > > > > Clause pattern123<V, T>(Context context, Verb verb, Noun agent, Noun > patient) > > { > > switch(V) > > { > > case voice::active: > > switch(T) > > { > > case tense::past: > > case tense::present: > > return join(" ", [ > > agent, > > conjugate_en(verb, V, T, …), > > “the”, > > patient > > ]); > > case tense::future: > > return join(" ", [ > > agent, > > “will”, > > conjugate_en(verb, V, T, …), > > “the”, > > patient > > ]); > > … > > } > > case voice::passive: > > switch(T) > > { > > case tense::past: > > return join(" ", [ > > “the”, > > patient, > > “was”, > > conjugate_en(verb, V, T, …), > > “by” > > agent > > ]); > > case tense::present: > > return join(" ", [ > > “the”, > > patient, > > “is”, > > “being”, > > conjugate_en(verb, V, T, …), > > “by” > > agent > > ]); > > … > > } > > } > > } > > > We could then simply express that the verb “to kick” is an instance of > pattern pattern123 with something resembling: > > > > Clause kick<V, T>(Context context, Noun agent, Noun patient) > > { > > pattern123<V, T>(context, new Verb(“kick”, …), agent, patient); > > } > > or > > > Clause kick<V, T>(Context context, Noun agent, Noun patient) > > { > > pattern123<V, T>(context, getVerb(“https://…#kick”), agent, patient); > > } > > and this pattern could be reused for a large number of verbs. > > This use of patterns should extend to scenarios where there are more > parameters for other thematically-related nouns: > > > > Clause kick<V, T>(Context context, Noun agent, Noun patient, Noun > instrument) > > { > > pattern1234<V, T>(context, new Verb(“kick”, …), agent, patient, > instrument); > > } > > For English, there might be more generic parameters than those for voice > and tense; we could add those for aspect and mood (e.g. pattern1234<V, T, > A, M>(…)). > > In conclusion, with generic programming and functions for conjugation and > declension, we have expressiveness with which to discover, encode and reuse > language-specific patterns. > > > Best regards, > Adam Sobieski > > > >

2 1

Conjugation and Declension Functions
by Adam Sobieski 26 Jul '20

26 Jul '20

Louis indicated that we should consider modeling and approaches encompassing the features of all languages [1]. Factors that affect verb conjugation are numerous and we can envision a verb conjugation function which gathers these factors together from across languages, a function resembling: conjugate(language, stem, person, number, gender, tense, aspect, mood, voice, formality, clusivity, transitivity, valency, evidentiality) The following example utilizes a Context parameter as we haven’t yet discussed global variables. The following example uses a “::” syntax for enums. The following example shows that, with multilingual conjugation and declension functions, we could encapsulate multilingual conjugation and declension in language-specific convenience functions, perhaps resembling: kick<T>(Context context, Noun agent, Noun patient) { join(" ", [ agent, context.conjugate("en-US", "kick", person::second, agent.number, agent.gender, T, aspect::perfective, mood::indicative, voice::active, context.formality, clusivity::no, transitivity::transitive, valency::transitive, context.evidentiality), "the", patient ]) } and, as expected: kick<tense::past>(context, Bobby, ball) would produce: “Bobby kicked the ball”. It appears that there are a multitude of ways to approach implementing NLG-related Wikilambda functions. Conjugation and declension functions could be components of some approaches. What do you think about conjugation and declension functions? Best regards, Adam [1] https://wals.info/

3 6

Conjugation and Declension Functions (Adam Sobieski)
by Grounder UK 26 Jul '20

26 Jul '20

You're welcome, Adam. Far be it from me to disagree with Reiter and Dale (and I don't). I find it odd, however, that you put "hit<…>(Context, Array)". I wonder how, in our Wikipedic context, we get the idea of a verb? And why do we put it outside our array? The reality is that Wikipedias are about things, in the main: people, places, objects, types and historical events. These things have properties and different types of involvement in events, but I guess more than half the time we have to invent (or select or find...) a suitable verb for the set of objects we find to be related (from the claims in Wikidata). If English didn't demand a finite verb, our Wikipedia would manage perfectly well without them, just as Wikidata does (although they "lurk" within Properties). To my way of thinking, if there is any substance of note in the sense of the verb, it must be in the array of Senses (never mind their lexical form). Of course, you might reason that we start with an array of "involved senses" and infer the verb, which we can then inflect. It's part of Lexicalization rather than Realization, in other words. Maybe that is generally so, but I am not convinced that we should immediately assume that it must be so in our Wikipedic context. For me, in any event, Realization in our context is just the final transformation of a near-final representation of our content, so I wouldn't expect it to change the sequence of ideas or change around syntactic roles. If you're deriving roles and sequences, then you're doing Lexicalization (or you're at a higher level) and you won't generally know what the verb is going to be at that stage (how could you?). It could be "strike", "hit" or "bat", for example. And the involvement of a bat in our array might be a good reason to choose the verb "bat" or a good reason to avoid it, depending on the particular context. If we choose "bat" as the verb, we will probably also drop it from the instrument role because that role is implied by the verb ("hit with a bat"). That "fact" will also keep us from choosing the verb "bat" if we need to refer to the bat as an object (to specify that it was her father's bat, for example). If the verb "bat" is going to subsume the instrument role, the instrument must be wholly indefinite ("hit with 'any old' bat" rather than "hit with one of the bats"). Returning to Reiter and Dale, I think it makes sense to view this problem in reverse, as inverse parsing. As they say, you can parse the three forms into a single "logical form" (which some might call "abstract content") and there must be some loss of information in this process, since we cannot guarantee that we will get back to the form we started with if we invert the parsing. It is this lost information that we need to retain when we have parsed (for future reference) and to have available before we proceed to Realize (or "render"). Our logical "manual of style" is what we might use to derive the missing information that we must have available, if we cannot infer it from the selected Wikidata content. To begin again at the end, I might say we can parse "Bobby batted the ball" as something like: Sentence< {comment: here, Sentence = Subject + Verb Phrase} Subject< Noun Phrase< Noun <Alias<"Bobby">, entity<Q???>> >> + Verb Phrase< {comment: here, Verb Phrase = Verb + Instrument + Direct Object} Verb< Sense<"hit">, Tense<simple past>, Voice<active>> + Instrument< Noun Phrase< Noun< Sense<"bat">> + Determiner<indefinite>> + Direct Object< Noun Phrase< Noun< Sense<"ball">> + Determiner<definite>> >>. Assuming I've parsed that correctly (and it's been a few years since I had to), we can assert that this "logical form" shall be valid input into our Realization function. What do we get back? "Bobby hit the ball with a bat". I had to cheat, of course. The reason, I suppose, is that the subsumed noun phrase was prepositional and non-prepositional noun phrases, in English, tend to attach themselves to their verbs ("I gave him it" versus "I gave it to him", for example). So when I surfaced the subsumed instrumental, "with a bat" (which is more interpretation than parsing), the result was naturally in the wrong order, coming between the verb and the existing non-prepositional noun phrase, "the ball". The order shouldn't matter to the renderer, unless it's explicit. But I did say that I wouldn't expect Realization to change the sequence of ideas, and then it had to because "Bobby hit with a bat the ball" is un-English in any unfanciful context (although perfectly understandable). Full disclosure, as they say! So, if interpretive parsing surfaces subsumed elements, some Lexicalization may be required to establish a "logical form" that is valid input into Realization. Alternatively, we might consider that to occur within the inverse of Referring Expression Generation, since it is loosely analogous to surfacing nouns from pronouns and might be considered to be a kind of anaphora (locally, at least, it is likely to be exophoric: "batted" implies an unspecified bat, as discussed above, but surfacing it renders it endophoric, if you'll forgive the pun, and thus anaphoric at that level). By the way, Reiter claims to have written or admits to writing the main articles on natural language generation in the English Wikipedia. You can find the links in: https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Related_and_previous_wor… . Best regards, Al. On Saturday, 25 July 2020, <abstract-wikipedia-request(a)lists.wikimedia.org> wrote: > Send Abstract-Wikipedia mailing list submissions to > abstract-wikipedia(a)lists.wikimedia.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.wikimedia.org/mailman/listinfo/abstract-wikipedia > or, via email, send a message with subject or body 'help' to > abstract-wikipedia-request(a)lists.wikimedia.org > > You can reach the person managing the list at > abstract-wikipedia-owner(a)lists.wikimedia.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Abstract-Wikipedia digest..." > > > Today's Topics: > > 1. Re: Conjugation and Declension Functions (Adam Sobieski) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sat, 25 Jul 2020 17:43:55 +0000 > From: Adam Sobieski <adamsobieski(a)hotmail.com> > To: "General public mailing list for the discussion of Abstract > Wikipedia (aka Wikilambda)" <abstract-wikipedia(a)lists.wiki > media.org> > Subject: Re: [Abstract-wikipedia] Conjugation and Declension Functions > Message-ID: > <CH2PR12MB41848A048AE721573F59A218C5740(a)CH2PR12MB4184.namprd > 12.prod.outlook.com> > > Content-Type: text/plain; charset="windows-1252" > > Thank you all for the comments and feedback thus far. > > > > I would like to indicate that we could also utilize the expressiveness of > JavaScript/TypeScript for array literals with object literal elements. In > this alternative approach, arguments could be placed into an array of > objects which each attach a thematic role to an argument. “Bobby”, “ball” > and “bat” could be objects of type Noun, and we could pass to a function an > array literal of object literals to get at the desired concepts of: (1) > sequence, (2) roles, (3) values. That is rather the matter: attaching > thematic roles to elements of a sequence of arguments. > > > > To the example pseudocode: > > > > Noun Bobby; > > Noun ball; > > Noun bat; > > > > hit<voice::active, tense::past, aspect::perfective, > mood::indicative>(context, [ {role: ‘agent’, value: Bobby}, {role: > ‘patient’, value: ball}, {role: ‘instrument’, value: bat} ]) --> “Bobby hit > the ball with the bat” > > hit<voice::active, tense::past, aspect::perfective, > mood::indicative>(context, [ {role: ‘agent’, value: Bobby}, {role: > ‘instrument’, value: bat}, {role: ‘patient’, value: ball} ]) --> “Bobby, > with the bat, hit the ball” > > hit<voice::active, tense::past, aspect::perfective, > mood::indicative>(context, [ {role: ‘instrument’, value: bat}, {role: > ‘agent’, value: Bobby}, {role: ‘patient’, value: ball} ]) --> “With the > bat, Bobby hit the ball” > > > > or, if the grammatical arguments (voice, tense, aspect, mood) are > properties of the context object: > > > > hit(context, [ {role: ‘agent’, value: Bobby}, {role: ‘patient’, value: > ball}, {role: ‘instrument’, value: bat} ]) --> “Bobby hit the ball with the > bat” > > hit(context, [ {role: ‘agent’, value: Bobby}, {role: ‘instrument’, value: > bat}, {role: ‘patient’, value: ball} ]) --> “Bobby, with the bat, hit the > ball” > > hit(context, [ {role: ‘instrument’, value: bat}, {role: ‘agent’, value: > Bobby}, {role: ‘patient’, value: ball} ]) --> “With the bat, Bobby hit the > ball” > > > > A downside would be that the function signatures would resemble: > > > > hit<…>(Context, Array) > > > > or > > > > hit<…>(Context, Array<RoleNounPair>) > > > > An upside would be expressiveness with which to indicate desired output > paraphrases. > > > > These topics are discussed in Building Natural Language Generation Systems > by Reiter and Dale [1], in chapter 6 on Surface Realization, in section 6.8 > on Bidirectional Grammars, pages 194 – 195, where the authors indicate that > while “a parser might produce the same logical form for the following three > sentences: > > > > 1. Mary gave John a ball. > 2. Mary gave a ball to John. > 3. John was given a ball by Mary. > > > > “The input to a realizer, however, should explicitly provide a means of > choosing among these forms; the alternative is to choose at random.” (as > noted, another alternative is to select using a manual of style). > > > > The authors also indicate that Winograd [2] provided a list of paraphrases > for consideration: > > > > 1. Jon bought a painting for Vina. > 2. Jon bought Vina a painting. > 3. Vina was bought a painting by Jon. > 4. What Jon bought Vina was a painting. > 5. What Vina was bought by Jon was a painting. > 6. It was a painting that Jon bought for Vina. > 7. It was Jon that bought Vina a painting. > 8. It was Vina that Jon bought a painting for. > > > > On the topic of “a” or “the”, definite or indefinite noun phrases, we can > note a discussion in Reiter and Dale [1], section 5.4.2, on page 145. That > is another important discussion topic. > > > > In the set of approaches under discussion, by making use of grammatical > arguments (e.g. voice, tense, aspect, mood) and by placing thematic roles > on elements of a sequence of arguments, we have an expressiveness beyond > that of predicate calculus with which to distinguish paraphrases. > > > > > > Best regards, > > Adam > > > > [1] Reiter, Ehud, and Robert Dale. Building natural language generation > systems. Cambridge university press, 2000. > > [2] Winograd, Terry. "Language as a cognitive process." (1983). > > From: Adam Sobieski<mailto:adamsobieski@hotmail.com> > Sent: Friday, July 24, 2020 7:07 PM > To: General public mailing list for the discussion of Abstract Wikipedia > (aka Wikilambda)<mailto:abstract-wikipedia@lists.wikimedia.org> > Subject: Re: [Abstract-wikipedia] Conjugation and Declension Functions > > In addition to broaching the discovery, encoding and reuse of > language-specific patterns, which I view as a discussion topic when > comparing and contrasting approaches (see: the DRY principle [1] and the > abstraction principle [2]), and indicating how conjugation and declension > functions would facilitate the discovery, encoding and reuse of these > patterns, I would like to share some topics which arose as I explored > adding the thematic relation [3] of instrument to the agent-patient pair. > > When exploring how best to add the thematic relation of instrument to the > agent-patient pair (e.g. adding “using the bat” to “Bobby hit the ball”), I > observed that, for the same input grammatical arguments, there was a set of > possible output paraphrases: > > > 1. “Bobby hit the ball using the bat” > 2. “Bobby, using the bat, hit the ball” > 3. “Using the bat, Bobby hit the ball” > > I wondered: how might we be able to generate each? > > One possibility is indicated. There could be a type for each thematic > relation [3]. Then, using explicit type conversions to these types, we > could have different functions for different sequences of input arguments. > > That is, > > hit<voice::active, tense::past, aspect::perfective, > mood::indicative>(context, (Agent)Bobby, (Patient)ball, (Instrument)bat) > --> “Bobby hit the ball using the bat” > hit<voice::active, tense::past, aspect::perfective, > mood::indicative>(context, (Agent)Bobby, (Instrument)bat, (Patient)ball) > --> “Bobby, using the bat, hit the ball” > hit<voice::active, tense::past, aspect::perfective, > mood::indicative>(context, (Instrument)bat, (Agent)Bobby, (Patient)ball) > --> “Using the bat, Bobby hit the ball” > > or > > hit<voice::active, tense::past, aspect::perfective, > mood::indicative>(context, Bobby as Agent, ball as Patient, bat as > Instrument) --> “Bobby hit the ball using the bat” > hit<voice::active, tense::past, aspect::perfective, > mood::indicative>(context, Bobby as Agent, bat as Instrument, ball as > Patient) --> “Bobby, using the bat, hit the ball” > hit<voice::active, tense::past, aspect::perfective, > mood::indicative>(context, bat as Instrument, Bobby as Agent, ball as > Patient) --> “Using the bat, Bobby hit the ball” > > These functions could each wrap the use of patterns (as indicated in > previous email) and attempt to realize output sentences utilizing the > arguments in the same sequence in which they were provided. This would, > however, mean that the callers of the functions would be responsible for > “shuffling” the input arguments to express the desired paraphrase ((1), > (2), (3)). > > There are, of course, other approaches to consider and other possibilities > to consider with respect to addressing the matter of outputting the example > paraphrases. > > Any thoughts on these topics? > > > Best regards, > Adam > > [1] https://en.wikipedia.org/wiki/Don%27t_repeat_yourself > [2] https://en.wikipedia.org/wiki/Abstraction_principle_(compute > r_programming) > [3] https://en.wikipedia.org/wiki/Thematic_relation > > P.S.: We could also put the grammatical arguments on the context object > (context.voice, context.tense, context.aspect, context.mood, et cetera) and > then make use of generic parameters for other uses. > > From: Adam Sobieski<mailto:adamsobieski@hotmail.com> > Sent: Thursday, July 23, 2020 7:38 PM > To: General public mailing list for the discussion of Abstract Wikipedia > (aka Wikilambda)<mailto:abstract-wikipedia@lists.wikimedia.org> > Subject: RE: Conjugation and Declension Functions > > > I had an idea about discovering, encoding and reusing patterns in > languages that I would like to share with the group. > > > > The following is rough-draft pseudocode for a function with which to > generate sentences for the verb “to kick”. The function has generic > parameters for voice and tense and parameters for context, agent and > patient. > > > > Clause kick<V, T>(Context context, Noun agent, Noun patient) > > { > > switch(V) > > { > > case voice::active: > > switch(T) > > { > > case tense::past: > > case tense::present: > > return join(" ", [ > > agent, > > conjugate_en(“kick”, V, T, …), > > “the”, > > patient > > ]); > > case tense::future: > > return join(" ", [ > > agent, > > “will”, > > conjugate_en(“kick”, V, T, …), > > “the”, > > patient > > ]); > > … > > } > > case voice::passive: > > switch(T) > > { > > case tense::past: > > return join(" ", [ > > “the”, > > patient, > > “was”, > > conjugate_en(“kick”, V, T, …), > > “by” > > agent > > ]); > > case tense::present: > > return join(" ", [ > > “the”, > > patient, > > “is”, > > “being”, > > conjugate_en(“kick”, V, T, …), > > “by” > > agent > > ]); > > … > > } > > } > > } > > > > and > > > > kick<voice::active, tense::past>(context, Bobby, ball) returns “Bobby > kicked the ball”. > > > > In English, most combinations of tense, aspect, mood and voice are > expressed periphrastically, using constructions with auxiliary verbs. After > implementing a number of these for similar verbs, per the above example, we > would notice a pattern. That pattern could be expressed as something > resembling: > > > > Clause pattern123<V, T>(Context context, Verb verb, Noun agent, Noun > patient) > > { > > switch(V) > > { > > case voice::active: > > switch(T) > > { > > case tense::past: > > case tense::present: > > return join(" ", [ > > agent, > > conjugate_en(verb, V, T, …), > > “the”, > > patient > > ]); > > case tense::future: > > return join(" ", [ > > agent, > > “will”, > > conjugate_en(verb, V, T, …), > > “the”, > > patient > > ]); > > … > > } > > case voice::passive: > > switch(T) > > { > > case tense::past: > > return join(" ", [ > > “the”, > > patient, > > “was”, > > conjugate_en(verb, V, T, …), > > “by” > > agent > > ]); > > case tense::present: > > return join(" ", [ > > “the”, > > patient, > > “is”, > > “being”, > > conjugate_en(verb, V, T, …), > > “by” > > agent > > ]); > > … > > } > > } > > } > > > We could then simply express that the verb “to kick” is an instance of > pattern pattern123 with something resembling: > > > > Clause kick<V, T>(Context context, Noun agent, Noun patient) > > { > > pattern123<V, T>(context, new Verb(“kick”, …), agent, patient); > > } > > or > > > Clause kick<V, T>(Context context, Noun agent, Noun patient) > > { > > pattern123<V, T>(context, getVerb(“https://…#kick”), agent, patient); > > } > > and this pattern could be reused for a large number of verbs. > > This use of patterns should extend to scenarios where there are more > parameters for other thematically-related nouns: > > > > Clause kick<V, T>(Context context, Noun agent, Noun patient, Noun > instrument) > > { > > pattern1234<V, T>(context, new Verb(“kick”, …), agent, patient, > instrument); > > } > > For English, there might be more generic parameters than those for voice > and tense; we could add those for aspect and mood (e.g. pattern1234<V, T, > A, M>(…)). > > In conclusion, with generic programming and functions for conjugation and > declension, we have expressiveness with which to discover, encode and reuse > language-specific patterns. > > > Best regards, > Adam Sobieski > > >

2 1

Re: [Abstract-wikipedia] Conjugation and Declension Functions
by Exocamp Exocamp 25 Jul '20

25 Jul '20

I would like to say first that I am new to this idea and project and not as familiar with coding or linguistics as some of you, so I apologize in advance if I am severely misunderstanding something in this thread. While any of these phrases would sound decent in a sentence, I believe that the context of the rest of the sentence would be needed to determine the correct thematic relation. Even if the output phrases all contain the same words, natural speech and language would not pick these phrases necessarily at random, because the three phrases have different "set-ups" as I would call them. I'll give examples so I become much more clear. Let us assume we have the agent-patient-instrument pair of Bobby, the ball, and the bat, and finish this clause with the directional relation "over the stadium". Thus our sentences would most likely be as follows: [1] Bobby hit the ball using the bat over the stadium. [2] Bobby, using the bat, hit the ball over the stadium. [3] Using the bat, Bobby hit the ball over the stadium. Despite all of these being technically correct sentences in English, sentence [1] in my opinion would definitely not look as natural to a native English speaker in text as [2] or [3] (though in my opinion [3] is best) Let's do another example with the phrase "while he hummed a song." [1] Bobby hit the ball using the bat while he hummed a song. [2] Bobby, using the bat, hit the ball while he hummed a song. [3] Using the bat, Bobby hit the ball while he hummed a song. Now with this new phrase, sentences [1] and [2] have become the most natural sentences (again, in my opinion), when in the previous sentence where the phrase "over the stadium" was used, these two were the most *un*natural. As such, I believe that the most accurate method to find the most natural phrasing would need to find a pattern in the context in order to apply the correct formation to. One last thought of mine has to do with spoken English and not written, but still may assist with our problem. From my thinking, the stressed word on a previous sentence may also affect the construction of the next. Let's treat our agent-patient-instrument as a complete sentence, and the sentence before this in spoken English as "Bobby had a ball and a bat" - introducing Bobby, ball, and bat beforehand. The stress could affect the construction like so, where * * indicates the stressed word in the sentence. [1] *Bobby* had a ball and a bat. Bobby hit the ball using the bat. [2] Bobby had a *ball* and a bat. Bobby, using the bat, hit the ball. [3] Bobby had a ball and a *bat.* Using the bat, Bobby hit the ball. Again, I am not a very experienced person in either linguistics or programming, so I may have missed the point of something, but I hope my thoughts help with this. Sincerely, SWork On Fri, Jul 24, 2020, 6:07 PM < abstract-wikipedia-request(a)lists.wikimedia.org> wrote: > Send Abstract-Wikipedia mailing list submissions to > abstract-wikipedia(a)lists.wikimedia.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.wikimedia.org/mailman/listinfo/abstract-wikipedia > or, via email, send a message with subject or body 'help' to > abstract-wikipedia-request(a)lists.wikimedia.org > > You can reach the person managing the list at > abstract-wikipedia-owner(a)lists.wikimedia.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Abstract-Wikipedia digest..." > > > Today's Topics: > > 1. Re: Conjugation and Declension Functions (Adam Sobieski) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 24 Jul 2020 23:07:03 +0000 > From: Adam Sobieski <adamsobieski(a)hotmail.com> > To: "General public mailing list for the discussion of Abstract > Wikipedia (aka Wikilambda)" < > abstract-wikipedia(a)lists.wikimedia.org> > Subject: Re: [Abstract-wikipedia] Conjugation and Declension Functions > Message-ID: > < > CH2PR12MB41841C5E1C4E820B9766AB1BC5770(a)CH2PR12MB4184.namprd12.prod.outlook.com > > > > Content-Type: text/plain; charset="windows-1252" > > In addition to broaching the discovery, encoding and reuse of > language-specific patterns, which I view as a discussion topic when > comparing and contrasting approaches (see: the DRY principle [1] and the > abstraction principle [2]), and indicating how conjugation and declension > functions would facilitate the discovery, encoding and reuse of these > patterns, I would like to share some topics which arose as I explored > adding the thematic relation [3] of instrument to the agent-patient pair. > > When exploring how best to add the thematic relation of instrument to the > agent-patient pair (e.g. adding “using the bat” to “Bobby hit the ball”), I > observed that, for the same input grammatical arguments, there was a set of > possible output paraphrases: > > > 1. “Bobby hit the ball using the bat” > 2. “Bobby, using the bat, hit the ball” > 3. “Using the bat, Bobby hit the ball” > > I wondered: how might we be able to generate each? > > One possibility is indicated. There could be a type for each thematic > relation [3]. Then, using explicit type conversions to these types, we > could have different functions for different sequences of input arguments. > > That is, > > hit<voice::active, tense::past, aspect::perfective, > mood::indicative>(context, (Agent)Bobby, (Patient)ball, (Instrument)bat) > --> “Bobby hit the ball using the bat” > hit<voice::active, tense::past, aspect::perfective, > mood::indicative>(context, (Agent)Bobby, (Instrument)bat, (Patient)ball) > --> “Bobby, using the bat, hit the ball” > hit<voice::active, tense::past, aspect::perfective, > mood::indicative>(context, (Instrument)bat, (Agent)Bobby, (Patient)ball) > --> “Using the bat, Bobby hit the ball” > > or > > hit<voice::active, tense::past, aspect::perfective, > mood::indicative>(context, Bobby as Agent, ball as Patient, bat as > Instrument) --> “Bobby hit the ball using the bat” > hit<voice::active, tense::past, aspect::perfective, > mood::indicative>(context, Bobby as Agent, bat as Instrument, ball as > Patient) --> “Bobby, using the bat, hit the ball” > hit<voice::active, tense::past, aspect::perfective, > mood::indicative>(context, bat as Instrument, Bobby as Agent, ball as > Patient) --> “Using the bat, Bobby hit the ball” > > These functions could each wrap the use of patterns (as indicated in > previous email) and attempt to realize output sentences utilizing the > arguments in the same sequence in which they were provided. This would, > however, mean that the callers of the functions would be responsible for > “shuffling” the input arguments to express the desired paraphrase ((1), > (2), (3)). > > There are, of course, other approaches to consider and other possibilities > to consider with respect to addressing the matter of outputting the example > paraphrases. > > Any thoughts on these topics? > > > Best regards, > Adam > > [1] https://en.wikipedia.org/wiki/Don%27t_repeat_yourself > [2] > https://en.wikipedia.org/wiki/Abstraction_principle_(computer_programming) > [3] https://en.wikipedia.org/wiki/Thematic_relation > > P.S.: We could also put the grammatical arguments on the context object > (context.voice, context.tense, context.aspect, context.mood, et cetera) and > then make use of generic parameters for other uses. > > From: Adam Sobieski<mailto:adamsobieski@hotmail.com> > Sent: Thursday, July 23, 2020 7:38 PM > To: General public mailing list for the discussion of Abstract Wikipedia > (aka Wikilambda)<mailto:abstract-wikipedia@lists.wikimedia.org> > Subject: RE: Conjugation and Declension Functions > > > I had an idea about discovering, encoding and reusing patterns in > languages that I would like to share with the group. > > > > The following is rough-draft pseudocode for a function with which to > generate sentences for the verb “to kick”. The function has generic > parameters for voice and tense and parameters for context, agent and > patient. > > > > Clause kick<V, T>(Context context, Noun agent, Noun patient) > > { > > switch(V) > > { > > case voice::active: > > switch(T) > > { > > case tense::past: > > case tense::present: > > return join(" ", [ > > agent, > > conjugate_en(“kick”, V, T, …), > > “the”, > > patient > > ]); > > case tense::future: > > return join(" ", [ > > agent, > > “will”, > > conjugate_en(“kick”, V, T, …), > > “the”, > > patient > > ]); > > … > > } > > case voice::passive: > > switch(T) > > { > > case tense::past: > > return join(" ", [ > > “the”, > > patient, > > “was”, > > conjugate_en(“kick”, V, T, …), > > “by” > > agent > > ]); > > case tense::present: > > return join(" ", [ > > “the”, > > patient, > > “is”, > > “being”, > > conjugate_en(“kick”, V, T, …), > > “by” > > agent > > ]); > > … > > } > > } > > } > > > > and > > > > kick<voice::active, tense::past>(context, Bobby, ball) returns “Bobby > kicked the ball”. > > > > In English, most combinations of tense, aspect, mood and voice are > expressed periphrastically, using constructions with auxiliary verbs. After > implementing a number of these for similar verbs, per the above example, we > would notice a pattern. That pattern could be expressed as something > resembling: > > > > Clause pattern123<V, T>(Context context, Verb verb, Noun agent, Noun > patient) > > { > > switch(V) > > { > > case voice::active: > > switch(T) > > { > > case tense::past: > > case tense::present: > > return join(" ", [ > > agent, > > conjugate_en(verb, V, T, …), > > “the”, > > patient > > ]); > > case tense::future: > > return join(" ", [ > > agent, > > “will”, > > conjugate_en(verb, V, T, …), > > “the”, > > patient > > ]); > > … > > } > > case voice::passive: > > switch(T) > > { > > case tense::past: > > return join(" ", [ > > “the”, > > patient, > > “was”, > > conjugate_en(verb, V, T, …), > > “by” > > agent > > ]); > > case tense::present: > > return join(" ", [ > > “the”, > > patient, > > “is”, > > “being”, > > conjugate_en(verb, V, T, …), > > “by” > > agent > > ]); > > … > > } > > } > > } > > > We could then simply express that the verb “to kick” is an instance of > pattern pattern123 with something resembling: > > > > Clause kick<V, T>(Context context, Noun agent, Noun patient) > > { > > pattern123<V, T>(context, new Verb(“kick”, …), agent, patient); > > } > > or > > > Clause kick<V, T>(Context context, Noun agent, Noun patient) > > { > > pattern123<V, T>(context, getVerb(“https://…#kick”), agent, patient); > > } > > and this pattern could be reused for a large number of verbs. > > This use of patterns should extend to scenarios where there are more > parameters for other thematically-related nouns: > > > > Clause kick<V, T>(Context context, Noun agent, Noun patient, Noun > instrument) > > { > > pattern1234<V, T>(context, new Verb(“kick”, …), agent, patient, > instrument); > > } > > For English, there might be more generic parameters than those for voice > and tense; we could add those for aspect and mood (e.g. pattern1234<V, T, > A, M>(…)). > > In conclusion, with generic programming and functions for conjugation and > declension, we have expressiveness with which to discover, encode and reuse > language-specific patterns. > > > Best regards, > Adam Sobieski > >

2 1

2024

2023

2022

2021

2020

Abstract-Wikipedia