The online version of this newsletter can be found here: https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Updates/2023-03-15
Quo vadis, Abstract Wikipedia?
Abstract Wikipedia will allow more people to contribute their voices to a baseline of knowledge, whilst working in an interface in their language. This shared baseline of knowledge will then be made available in many languages. This will be achieved by creating, storing, and maintaining the baseline of knowledge, per individual article, in a notation that is independent of natural language. We call content written in that notation "abstract content". This abstract content will then be turned into text in a specific natural language, with the help of the library of functions from Wikifunctions. Thus, Abstract Wikipedia will allow a speaker of any language to contribute content for readers of many different languages. This will allow more people to read more content in their language. Example
Assume that we want to create a new Wikipedia article for the planet Jupiter, and the first version of this article shall be the following (these are the first two sentences of the Simple English Wikipedia https://simple.wikipedia.org/wiki/Jupiter article): *Jupiter is the largest planet in the Solar System. It is the fifth planet from the Sun.*
The abstract content representing this natural text could look like this:
Article( text: [ Superlative( subject: Jupiter, quality: large, class: planet, location constraint: Solar System), Definition( subject: Jupiter, definition: Rank( rank: Positive integer( value: 5), object: planet, by: Relational noun( noun: distance, to: Sun)))], categories: [Jupiter, planet, Solar System])
Wikifunctions would have types for Article, Superlative, Definition, Rank, *etc.*, which are used here as the abstract notation for the content of these two sentences. This abstract content is shown using labels in English here for our convenience, whereas in fact they would all be ZIDs (from Wikifunctions) and QIDs (from Wikidata). There will be software components to provide for the viewing, creation, and editing of abstract content. Wikifunctions will then also provide functions that take this object as an argument and generate natural language text such as the above.
One question that needs to be answered is where these objects would be stored, and how to associate the above object with the Wikidata item for Jupiter, Q319 https://www.wikidata.org/wiki/Q319. We were originally planning to have this conversation and decision before the launch of Wikifunctions, but looking at the complexity of the system and the fact that it is very difficult to imagine given that so little of it is tangible so far, we decided not to open this question for discussion now, but to wait until after the launch of Wikifunctions, when we will all have a better understanding of how that part of the ecosystem works.
Below, we outline a few options that came up in the discussion between folks on the Abstract Wikipedia team and the Wikidata team at Wikimedia Deutschland. It also ties to some of the questions Lydia Pintscher and I were answering in an interview on the Wikimove podcast episode https://meta.wikimedia.org/wiki/WIKIMOVE/Podcast that was released today and that we invite you to listen to. Thanks to Nicole Ebber and Nikki Zeuner for the interview!
We are genuinely undecided about the best answer, and we would benefit from a wider discussion of the options, and potentially other options as well. Please also ask questions - these can often clarify and shine light on points that are muddy to us as well. We currently are focusing on the following five options:
1. A new tab on items in Wikidata 2. Create a new data type for objects on Wikidata 3. Objects on Wikifunctions 4. Objects on a new Wikipedia language edition 5. Unattached namespace on an existing project
Let’s discuss these five options in the following. Option 1: A new tab on items in Wikidata
We could add a tab, leading to a new namespace on Wikidata with a new content type, where the abstract content would live. This namespace would be attached to the item namespace in Wikidata. This way, every abstract content would have a natural place to store its associated abstract content.
Given the little use of the item talk pages on Wikidata, it seems an additional talk page may not be valuable, so we might want to redirect people to the item's main talk page for any discussions.
One big question would be where to store content for Wikivoyage and other projects about the same items (*e.g.* the abstract content we might want to write about Q90/Paris from the perspective of Wikipedia would be different from that for Wikivoyage). Would that need yet another namespace? Adding a new associated namespace would be a technical challenge; adding several would be a complex task, and we hope that not to happen often. Option 2: Create a new data type for Wikifunction objects
We could create a new data type on Wikidata for Wikifunctions objects. Then the community could create a property on Wikidata that stores the abstract content on a given item as a literal. This would have the added flexibility that the community could add more abstract contents to an item for specific use cases, e.g. to represent content from Wikivoyage, or to represent the history of an item, the etymology of a word, *etc.*
We will need such a datatype and the UX for it anyway, given our planned support for abstract descriptions https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Updates/2021-07-29. In fact, this might be the simplest way to support abstract description.
However, the UX of Wikidata doesn't lend itself to this easily, and adapting to this model would be challenging given the constraints of an item page. Existing properties are edited as one or a small number of simple, short text boxes, often with auto-complete; abstract content would instead be a larger text area, with helpers and possibly a toolbar, a preview control, *etc.*. One option could in principle be a modal dialog for editing, but these come with their own inherent UX downsides and are usually more complex to implement than the same functionality in its own dedicated environment. Also, this would break the current design patterns of an item page, and may not be aligned with the patterns that might be planned for its future.
Further, while abstract content is somewhat structured and machine-readable, it is less (or differently) so than an Item, and its structure would probably not be queryable with SPARQL.
This option comes with two additional challenges: some Wikidata items, already nearing the maximum size, would grow still further, and we would need a solution to allow that, and second how to deal with the visualization, editing, and diffing of potentially very large and complex values. Option 3: Objects on Wikifunctions
Instead of having objects live in Wikidata as the values of statements or on an additional tab, Wikidata could merely store a pointer to an object on Wikifunctions. We still would create a new data type, but that data type would be just the ZID of an object stored in Wikifunctions.
This would solve all the challenges of the previous option, and retain many of its advantages.
It would have the additional advantage that several items could refer to the same object on Wikifunctions. Whereas this sounds rarely useful for the abstract content of Wikipedia articles, this might prove very useful for abstract descriptions of Wikidata items and the abstract glosses of lexemes. With the creation of abstract content, types, and natural language generation functions on the same platform, collaboration between people who focus on one of these areas would be more direct.
This option could be a challenge for the Wikifunctions community. The scope would expand to cover content as well as functions. This could make it difficult for the smaller community, and need more community patrollers like those already active on Wikidata. Option 4: Objects on a new Wikipedia language edition
We could launch a new Wikipedia language edition in which the main namespace is abstract content. This could be called e.g. the multi-lingual Wikipedia (mul.wikipedia.org) language edition, or the abstract Wikipedia language edition (abstract.wikipedia.org). Like all other language editions, the pages are connected to the items via sitelinks in Wikidata.
If Wikivoyage wanted to use the same approach, they would need to copy the setup and create a multi-lingual Wikivoyage edition (or, as Option 4B, perhaps these could be a different namespace on a single shared ‘abstract’ content wiki?).
This would give a very clear distinction of what is Wikipedia content and what is not, and give the abstract content a distinct visibility, which would otherwise be somewhat hidden between Wikifunctions and Wikidata. On the other hand, it would splinter the communities further, and mix in a "new" concept of a wiki that isn't really a Wikipedia but is labelled as such. Option 5: Unattached namespace on existing project
We could introduce a new namespace to an existing project where the abstract content for Wikipedia would effectively live. Here are the most likely options:
1. Wikidata (as a separate namespace, not attached to the items) 2. Commons 3. Meta 4. English Wikipedia (not attached to the articles)
Whereas technically all these options would be the same, they would be extremely different from a social and community perspective. We will refrain here from discussing these differences for now, unless this starts becoming a more likely option. Rant: One Wikimedia movement, or many projects?
Conway’s law https://en.wikipedia.org/wiki/Conway%27s_law states that software mirrors organization, or, as it was put, if you put three teams to work on a compiler, you get a three-pass compiler. The opposite is also true, as previously observed https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/message/WV47OWZA5DHM3EF6IBQM2SKKF2A2BDWG/ by Guillaume Paumier https://meta.wikimedia.org/wiki/User:Guillom: a software system determines the community structure that evolves around the system. Within the Wikimedia projects, we often see this effect in the dynamics between the different Wikipedia language communities, the Wikidata community, the Commons community, Meta, *etc.* The stories of local protection of media files on Commons, of wikis opting-out from global anti-abuse tools, or of short descriptions in English Wikipedia should be warning enough.
The question we ask today is not only hard because there are genuine technical challenges that we have to overcome, and we have to make a tradeoff. It is additionally so much harder because we can anticipate that there will be fracture lines between the different projects, and maybe even anticipate how these fracture lines would shape out. The whole story would be so much easier if we would, in general, regard ourselves as being part of one common movement, as one large community. But I doubt that we will see much progress on this trajectory before we have to resolve the above question.
Until then we only can remain mindful about the possible solutions, their effects, and that we should be careful to design for the world as it is and as it likely will be, and not for the world we wish to be. Public NLG workstream on Tuesday
On Tuesday, March 21, there will be the third public NLG workstream meeting on JITSI. Feel free to reach out to me and suggest presentations beforehand if you want. We have a bit already planned, but there is still space. The meeting is 16:30-17:30 UTC https://zonestamp.toolforge.org/1679416242, which is an hour off for US friends.
I thought about not writing anything yet... but then the queryable topic was just to important not to speak out about now rather than later.
I'd definitely go for Option 2. This has several benefits:
1. queryable - What's the point of making structure, if we cannot query the structures en masse? There's no point in making structures then in the first place. Are we saying that we don't want to include abstract content in the database of knowledge? It doesn't have to be queryable via SPARQL, *but abstract content needs to be queryable*. Not being able to query abstract content will be a complete non-starter for me and likely many other contributors later on. 2. RDF tool extensions later on can be developed to understand the abstract content structures; so I'm not worried that it won't be queryable later on given some time for tooling to develop. 3. The UX is something that will need to "break the mold" certainly, but it needs to be and probably a good thing to start doing and working forward on toward a design system around *context control *where historically that was namespaces, but that segments the relationships of items too much and makes tooling, metadata, and many other things much harder. One possible way that works across all browsers is <iframe>. Simple, ancient tech yeah, but it also has the same effect as the tab option since it can encapsulate even an entirely different app (Vue3?) within the same viewing window of browsers. The downside is that the HTML page indeed grows larger in size (<iframe>'s are embedded in existing pages), but showing and hiding <iframe>'s is trivial and can be a preference.
In the end, we can see that through all the options you listed and maybe others, we are looking for a good hard relationship between an Item and its abstract contents. Some of the options make this explicit, and others implicit. I'd go for explicit with option 2 by having the new datatype, that automatically brings the ability to add new metadata when the future needs arise (like we've done before for certain datatypes), which is something that will be needed for context, such as your examples of "history", "etymology", "wikivoyage", etc.
Thad https://www.linkedin.com/in/thadguidry/ https://calendly.com/thadguidry/
Turning the objects into RDF structures will be trivial. I'm currently not planning on running a triplestore with those structures loaded (just as I didn't when Wikidata was started), but I can totally see the benefit of doing that. I think Lydia would very much prefer not to load it into Wikidata's query service, as that one is already creaking at the seams. But yeah, I would hope that such a thing would be set up. You are right, querying that would be lots of fun.
On Thu, Mar 16, 2023 at 7:56 PM Thad Guidry thadguidry@gmail.com wrote:
I thought about not writing anything yet... but then the queryable topic was just to important not to speak out about now rather than later.
I'd definitely go for Option 2. This has several benefits:
- queryable - What's the point of making structure, if we cannot query
the structures en masse? There's no point in making structures then in the first place. Are we saying that we don't want to include abstract content in the database of knowledge? It doesn't have to be queryable via SPARQL, *but abstract content needs to be queryable*. Not being able to query abstract content will be a complete non-starter for me and likely many other contributors later on. 2. RDF tool extensions later on can be developed to understand the abstract content structures; so I'm not worried that it won't be queryable later on given some time for tooling to develop. 3. The UX is something that will need to "break the mold" certainly, but it needs to be and probably a good thing to start doing and working forward on toward a design system around *context control *where historically that was namespaces, but that segments the relationships of items too much and makes tooling, metadata, and many other things much harder. One possible way that works across all browsers is <iframe>. Simple, ancient tech yeah, but it also has the same effect as the tab option since it can encapsulate even an entirely different app (Vue3?) within the same viewing window of browsers. The downside is that the HTML page indeed grows larger in size (<iframe>'s are embedded in existing pages), but showing and hiding
<iframe>'s is trivial and can be a preference.
In the end, we can see that through all the options you listed and maybe others, we are looking for a good hard relationship between an Item and its abstract contents. Some of the options make this explicit, and others implicit. I'd go for explicit with option 2 by having the new datatype, that automatically brings the ability to add new metadata when the future needs arise (like we've done before for certain datatypes), which is something that will be needed for context, such as your examples of "history", "etymology", "wikivoyage", etc.
Thad https://www.linkedin.com/in/thadguidry/ https://calendly.com/thadguidry/
Abstract-Wikipedia mailing list -- abstract-wikipedia@lists.wikimedia.org List information: https://lists.wikimedia.org/postorius/lists/abstract-wikipedia.lists.wikimed...
About the "discussion" tab on Wikidata items : it now includes the template "item documentation" through automated headers, so the (in)existence of the talk page might not be a good proxy to know if the discussion tab is actually used or not. Hard to know if the community uses it a lot though.
Elaborating on that, the fact that it’s hidden on the talk page might make it not used as often as it could be. It might be a lesson for abstract content, how its existence is discovered, how visible it is. It might be a big factor of how the project gain traction and builds a community. If the content is not easily discovered and seems buried in some part that looks like the technical plumbing of the Wikimedia movement — in the wikidata cases, in the beginning, some non enthusiastic contributors could refer to Wikidata, not in a good way, to a "database". Abstract Wikipedia deserves a shiny portal and a good discoverability of the content, which might be a different discussion even.
Le jeu. 16 mars 2023 à 03:44, Denny Vrandečić dvrandecic@wikimedia.org a écrit :
The online version of this newsletter can be found here: https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Updates/2023-03-15
Quo vadis, Abstract Wikipedia?
Abstract Wikipedia will allow more people to contribute their voices to a baseline of knowledge, whilst working in an interface in their language. This shared baseline of knowledge will then be made available in many languages. This will be achieved by creating, storing, and maintaining the baseline of knowledge, per individual article, in a notation that is independent of natural language. We call content written in that notation "abstract content". This abstract content will then be turned into text in a specific natural language, with the help of the library of functions from Wikifunctions. Thus, Abstract Wikipedia will allow a speaker of any language to contribute content for readers of many different languages. This will allow more people to read more content in their language. Example
Assume that we want to create a new Wikipedia article for the planet Jupiter, and the first version of this article shall be the following (these are the first two sentences of the Simple English Wikipedia https://simple.wikipedia.org/wiki/Jupiter article): *Jupiter is the largest planet in the Solar System. It is the fifth planet from the Sun.*
The abstract content representing this natural text could look like this:
Article( text: [ Superlative( subject: Jupiter, quality: large, class: planet, location constraint: Solar System), Definition( subject: Jupiter, definition: Rank( rank: Positive integer( value: 5), object: planet, by: Relational noun( noun: distance, to: Sun)))], categories: [Jupiter, planet, Solar System])
Wikifunctions would have types for Article, Superlative, Definition, Rank, *etc.*, which are used here as the abstract notation for the content of these two sentences. This abstract content is shown using labels in English here for our convenience, whereas in fact they would all be ZIDs (from Wikifunctions) and QIDs (from Wikidata). There will be software components to provide for the viewing, creation, and editing of abstract content. Wikifunctions will then also provide functions that take this object as an argument and generate natural language text such as the above.
One question that needs to be answered is where these objects would be stored, and how to associate the above object with the Wikidata item for Jupiter, Q319 https://www.wikidata.org/wiki/Q319. We were originally planning to have this conversation and decision before the launch of Wikifunctions, but looking at the complexity of the system and the fact that it is very difficult to imagine given that so little of it is tangible so far, we decided not to open this question for discussion now, but to wait until after the launch of Wikifunctions, when we will all have a better understanding of how that part of the ecosystem works.
Below, we outline a few options that came up in the discussion between folks on the Abstract Wikipedia team and the Wikidata team at Wikimedia Deutschland. It also ties to some of the questions Lydia Pintscher and I were answering in an interview on the Wikimove podcast episode https://meta.wikimedia.org/wiki/WIKIMOVE/Podcast that was released today and that we invite you to listen to. Thanks to Nicole Ebber and Nikki Zeuner for the interview!
We are genuinely undecided about the best answer, and we would benefit from a wider discussion of the options, and potentially other options as well. Please also ask questions - these can often clarify and shine light on points that are muddy to us as well. We currently are focusing on the following five options:
- A new tab on items in Wikidata
- Create a new data type for objects on Wikidata
- Objects on Wikifunctions
- Objects on a new Wikipedia language edition
- Unattached namespace on an existing project
Let’s discuss these five options in the following. Option 1: A new tab on items in Wikidata
We could add a tab, leading to a new namespace on Wikidata with a new content type, where the abstract content would live. This namespace would be attached to the item namespace in Wikidata. This way, every abstract content would have a natural place to store its associated abstract content.
Given the little use of the item talk pages on Wikidata, it seems an additional talk page may not be valuable, so we might want to redirect people to the item's main talk page for any discussions.
One big question would be where to store content for Wikivoyage and other projects about the same items (*e.g.* the abstract content we might want to write about Q90/Paris from the perspective of Wikipedia would be different from that for Wikivoyage). Would that need yet another namespace? Adding a new associated namespace would be a technical challenge; adding several would be a complex task, and we hope that not to happen often. Option 2: Create a new data type for Wikifunction objects
We could create a new data type on Wikidata for Wikifunctions objects. Then the community could create a property on Wikidata that stores the abstract content on a given item as a literal. This would have the added flexibility that the community could add more abstract contents to an item for specific use cases, e.g. to represent content from Wikivoyage, or to represent the history of an item, the etymology of a word, *etc.*
We will need such a datatype and the UX for it anyway, given our planned support for abstract descriptions https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Updates/2021-07-29. In fact, this might be the simplest way to support abstract description.
However, the UX of Wikidata doesn't lend itself to this easily, and adapting to this model would be challenging given the constraints of an item page. Existing properties are edited as one or a small number of simple, short text boxes, often with auto-complete; abstract content would instead be a larger text area, with helpers and possibly a toolbar, a preview control, *etc.*. One option could in principle be a modal dialog for editing, but these come with their own inherent UX downsides and are usually more complex to implement than the same functionality in its own dedicated environment. Also, this would break the current design patterns of an item page, and may not be aligned with the patterns that might be planned for its future.
Further, while abstract content is somewhat structured and machine-readable, it is less (or differently) so than an Item, and its structure would probably not be queryable with SPARQL.
This option comes with two additional challenges: some Wikidata items, already nearing the maximum size, would grow still further, and we would need a solution to allow that, and second how to deal with the visualization, editing, and diffing of potentially very large and complex values. Option 3: Objects on Wikifunctions
Instead of having objects live in Wikidata as the values of statements or on an additional tab, Wikidata could merely store a pointer to an object on Wikifunctions. We still would create a new data type, but that data type would be just the ZID of an object stored in Wikifunctions.
This would solve all the challenges of the previous option, and retain many of its advantages.
It would have the additional advantage that several items could refer to the same object on Wikifunctions. Whereas this sounds rarely useful for the abstract content of Wikipedia articles, this might prove very useful for abstract descriptions of Wikidata items and the abstract glosses of lexemes. With the creation of abstract content, types, and natural language generation functions on the same platform, collaboration between people who focus on one of these areas would be more direct.
This option could be a challenge for the Wikifunctions community. The scope would expand to cover content as well as functions. This could make it difficult for the smaller community, and need more community patrollers like those already active on Wikidata. Option 4: Objects on a new Wikipedia language edition
We could launch a new Wikipedia language edition in which the main namespace is abstract content. This could be called e.g. the multi-lingual Wikipedia (mul.wikipedia.org) language edition, or the abstract Wikipedia language edition (abstract.wikipedia.org). Like all other language editions, the pages are connected to the items via sitelinks in Wikidata.
If Wikivoyage wanted to use the same approach, they would need to copy the setup and create a multi-lingual Wikivoyage edition (or, as Option 4B, perhaps these could be a different namespace on a single shared ‘abstract’ content wiki?).
This would give a very clear distinction of what is Wikipedia content and what is not, and give the abstract content a distinct visibility, which would otherwise be somewhat hidden between Wikifunctions and Wikidata. On the other hand, it would splinter the communities further, and mix in a "new" concept of a wiki that isn't really a Wikipedia but is labelled as such. Option 5: Unattached namespace on existing project
We could introduce a new namespace to an existing project where the abstract content for Wikipedia would effectively live. Here are the most likely options:
- Wikidata (as a separate namespace, not attached to the items)
- Commons
- Meta
- English Wikipedia (not attached to the articles)
Whereas technically all these options would be the same, they would be extremely different from a social and community perspective. We will refrain here from discussing these differences for now, unless this starts becoming a more likely option. Rant: One Wikimedia movement, or many projects?
Conway’s law https://en.wikipedia.org/wiki/Conway%27s_law states that software mirrors organization, or, as it was put, if you put three teams to work on a compiler, you get a three-pass compiler. The opposite is also true, as previously observed https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/message/WV47OWZA5DHM3EF6IBQM2SKKF2A2BDWG/ by Guillaume Paumier https://meta.wikimedia.org/wiki/User:Guillom: a software system determines the community structure that evolves around the system. Within the Wikimedia projects, we often see this effect in the dynamics between the different Wikipedia language communities, the Wikidata community, the Commons community, Meta, *etc.* The stories of local protection of media files on Commons, of wikis opting-out from global anti-abuse tools, or of short descriptions in English Wikipedia should be warning enough.
The question we ask today is not only hard because there are genuine technical challenges that we have to overcome, and we have to make a tradeoff. It is additionally so much harder because we can anticipate that there will be fracture lines between the different projects, and maybe even anticipate how these fracture lines would shape out. The whole story would be so much easier if we would, in general, regard ourselves as being part of one common movement, as one large community. But I doubt that we will see much progress on this trajectory before we have to resolve the above question.
Until then we only can remain mindful about the possible solutions, their effects, and that we should be careful to design for the world as it is and as it likely will be, and not for the world we wish to be. Public NLG workstream on Tuesday
On Tuesday, March 21, there will be the third public NLG workstream meeting on JITSI. Feel free to reach out to me and suggest presentations beforehand if you want. We have a bit already planned, but there is still space. The meeting is 16:30-17:30 UTC https://zonestamp.toolforge.org/1679416242, which is an hour off for US friends. _______________________________________________ Abstract-Wikipedia mailing list -- abstract-wikipedia@lists.wikimedia.org List information: https://lists.wikimedia.org/postorius/lists/abstract-wikipedia.lists.wikimed...
Oh, I didn't see the item documentation thing, that's pretty neat!
... which makes your argument even stronger, good point!
On Fri, Mar 17, 2023 at 3:27 AM Thomas Douillard thomas.douillard@gmail.com wrote:
About the "discussion" tab on Wikidata items : it now includes the template "item documentation" through automated headers, so the (in)existence of the talk page might not be a good proxy to know if the discussion tab is actually used or not. Hard to know if the community uses it a lot though.
Elaborating on that, the fact that it’s hidden on the talk page might make it not used as often as it could be. It might be a lesson for abstract content, how its existence is discovered, how visible it is. It might be a big factor of how the project gain traction and builds a community. If the content is not easily discovered and seems buried in some part that looks like the technical plumbing of the Wikimedia movement — in the wikidata cases, in the beginning, some non enthusiastic contributors could refer to Wikidata, not in a good way, to a "database". Abstract Wikipedia deserves a shiny portal and a good discoverability of the content, which might be a different discussion even.
Le jeu. 16 mars 2023 à 03:44, Denny Vrandečić dvrandecic@wikimedia.org a écrit :
The online version of this newsletter can be found here: https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Updates/2023-03-15
Quo vadis, Abstract Wikipedia?
Abstract Wikipedia will allow more people to contribute their voices to a baseline of knowledge, whilst working in an interface in their language. This shared baseline of knowledge will then be made available in many languages. This will be achieved by creating, storing, and maintaining the baseline of knowledge, per individual article, in a notation that is independent of natural language. We call content written in that notation "abstract content". This abstract content will then be turned into text in a specific natural language, with the help of the library of functions from Wikifunctions. Thus, Abstract Wikipedia will allow a speaker of any language to contribute content for readers of many different languages. This will allow more people to read more content in their language. Example
Assume that we want to create a new Wikipedia article for the planet Jupiter, and the first version of this article shall be the following (these are the first two sentences of the Simple English Wikipedia https://simple.wikipedia.org/wiki/Jupiter article): *Jupiter is the largest planet in the Solar System. It is the fifth planet from the Sun.*
The abstract content representing this natural text could look like this:
Article( text: [ Superlative( subject: Jupiter, quality: large, class: planet, location constraint: Solar System), Definition( subject: Jupiter, definition: Rank( rank: Positive integer( value: 5), object: planet, by: Relational noun( noun: distance, to: Sun)))], categories: [Jupiter, planet, Solar System])
Wikifunctions would have types for Article, Superlative, Definition, Rank, *etc.*, which are used here as the abstract notation for the content of these two sentences. This abstract content is shown using labels in English here for our convenience, whereas in fact they would all be ZIDs (from Wikifunctions) and QIDs (from Wikidata). There will be software components to provide for the viewing, creation, and editing of abstract content. Wikifunctions will then also provide functions that take this object as an argument and generate natural language text such as the above.
One question that needs to be answered is where these objects would be stored, and how to associate the above object with the Wikidata item for Jupiter, Q319 https://www.wikidata.org/wiki/Q319. We were originally planning to have this conversation and decision before the launch of Wikifunctions, but looking at the complexity of the system and the fact that it is very difficult to imagine given that so little of it is tangible so far, we decided not to open this question for discussion now, but to wait until after the launch of Wikifunctions, when we will all have a better understanding of how that part of the ecosystem works.
Below, we outline a few options that came up in the discussion between folks on the Abstract Wikipedia team and the Wikidata team at Wikimedia Deutschland. It also ties to some of the questions Lydia Pintscher and I were answering in an interview on the Wikimove podcast episode https://meta.wikimedia.org/wiki/WIKIMOVE/Podcast that was released today and that we invite you to listen to. Thanks to Nicole Ebber and Nikki Zeuner for the interview!
We are genuinely undecided about the best answer, and we would benefit from a wider discussion of the options, and potentially other options as well. Please also ask questions - these can often clarify and shine light on points that are muddy to us as well. We currently are focusing on the following five options:
- A new tab on items in Wikidata
- Create a new data type for objects on Wikidata
- Objects on Wikifunctions
- Objects on a new Wikipedia language edition
- Unattached namespace on an existing project
Let’s discuss these five options in the following. Option 1: A new tab on items in Wikidata
We could add a tab, leading to a new namespace on Wikidata with a new content type, where the abstract content would live. This namespace would be attached to the item namespace in Wikidata. This way, every abstract content would have a natural place to store its associated abstract content.
Given the little use of the item talk pages on Wikidata, it seems an additional talk page may not be valuable, so we might want to redirect people to the item's main talk page for any discussions.
One big question would be where to store content for Wikivoyage and other projects about the same items (*e.g.* the abstract content we might want to write about Q90/Paris from the perspective of Wikipedia would be different from that for Wikivoyage). Would that need yet another namespace? Adding a new associated namespace would be a technical challenge; adding several would be a complex task, and we hope that not to happen often. Option 2: Create a new data type for Wikifunction objects
We could create a new data type on Wikidata for Wikifunctions objects. Then the community could create a property on Wikidata that stores the abstract content on a given item as a literal. This would have the added flexibility that the community could add more abstract contents to an item for specific use cases, e.g. to represent content from Wikivoyage, or to represent the history of an item, the etymology of a word, *etc.*
We will need such a datatype and the UX for it anyway, given our planned support for abstract descriptions https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Updates/2021-07-29. In fact, this might be the simplest way to support abstract description.
However, the UX of Wikidata doesn't lend itself to this easily, and adapting to this model would be challenging given the constraints of an item page. Existing properties are edited as one or a small number of simple, short text boxes, often with auto-complete; abstract content would instead be a larger text area, with helpers and possibly a toolbar, a preview control, *etc.*. One option could in principle be a modal dialog for editing, but these come with their own inherent UX downsides and are usually more complex to implement than the same functionality in its own dedicated environment. Also, this would break the current design patterns of an item page, and may not be aligned with the patterns that might be planned for its future.
Further, while abstract content is somewhat structured and machine-readable, it is less (or differently) so than an Item, and its structure would probably not be queryable with SPARQL.
This option comes with two additional challenges: some Wikidata items, already nearing the maximum size, would grow still further, and we would need a solution to allow that, and second how to deal with the visualization, editing, and diffing of potentially very large and complex values. Option 3: Objects on Wikifunctions
Instead of having objects live in Wikidata as the values of statements or on an additional tab, Wikidata could merely store a pointer to an object on Wikifunctions. We still would create a new data type, but that data type would be just the ZID of an object stored in Wikifunctions.
This would solve all the challenges of the previous option, and retain many of its advantages.
It would have the additional advantage that several items could refer to the same object on Wikifunctions. Whereas this sounds rarely useful for the abstract content of Wikipedia articles, this might prove very useful for abstract descriptions of Wikidata items and the abstract glosses of lexemes. With the creation of abstract content, types, and natural language generation functions on the same platform, collaboration between people who focus on one of these areas would be more direct.
This option could be a challenge for the Wikifunctions community. The scope would expand to cover content as well as functions. This could make it difficult for the smaller community, and need more community patrollers like those already active on Wikidata. Option 4: Objects on a new Wikipedia language edition
We could launch a new Wikipedia language edition in which the main namespace is abstract content. This could be called e.g. the multi-lingual Wikipedia (mul.wikipedia.org) language edition, or the abstract Wikipedia language edition (abstract.wikipedia.org). Like all other language editions, the pages are connected to the items via sitelinks in Wikidata.
If Wikivoyage wanted to use the same approach, they would need to copy the setup and create a multi-lingual Wikivoyage edition (or, as Option 4B, perhaps these could be a different namespace on a single shared ‘abstract’ content wiki?).
This would give a very clear distinction of what is Wikipedia content and what is not, and give the abstract content a distinct visibility, which would otherwise be somewhat hidden between Wikifunctions and Wikidata. On the other hand, it would splinter the communities further, and mix in a "new" concept of a wiki that isn't really a Wikipedia but is labelled as such. Option 5: Unattached namespace on existing project
We could introduce a new namespace to an existing project where the abstract content for Wikipedia would effectively live. Here are the most likely options:
- Wikidata (as a separate namespace, not attached to the items)
- Commons
- Meta
- English Wikipedia (not attached to the articles)
Whereas technically all these options would be the same, they would be extremely different from a social and community perspective. We will refrain here from discussing these differences for now, unless this starts becoming a more likely option. Rant: One Wikimedia movement, or many projects?
Conway’s law https://en.wikipedia.org/wiki/Conway%27s_law states that software mirrors organization, or, as it was put, if you put three teams to work on a compiler, you get a three-pass compiler. The opposite is also true, as previously observed https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/message/WV47OWZA5DHM3EF6IBQM2SKKF2A2BDWG/ by Guillaume Paumier https://meta.wikimedia.org/wiki/User:Guillom: a software system determines the community structure that evolves around the system. Within the Wikimedia projects, we often see this effect in the dynamics between the different Wikipedia language communities, the Wikidata community, the Commons community, Meta, *etc.* The stories of local protection of media files on Commons, of wikis opting-out from global anti-abuse tools, or of short descriptions in English Wikipedia should be warning enough.
The question we ask today is not only hard because there are genuine technical challenges that we have to overcome, and we have to make a tradeoff. It is additionally so much harder because we can anticipate that there will be fracture lines between the different projects, and maybe even anticipate how these fracture lines would shape out. The whole story would be so much easier if we would, in general, regard ourselves as being part of one common movement, as one large community. But I doubt that we will see much progress on this trajectory before we have to resolve the above question.
Until then we only can remain mindful about the possible solutions, their effects, and that we should be careful to design for the world as it is and as it likely will be, and not for the world we wish to be. Public NLG workstream on Tuesday
On Tuesday, March 21, there will be the third public NLG workstream meeting on JITSI. Feel free to reach out to me and suggest presentations beforehand if you want. We have a bit already planned, but there is still space. The meeting is 16:30-17:30 UTC https://zonestamp.toolforge.org/1679416242, which is an hour off for US friends. _______________________________________________ Abstract-Wikipedia mailing list -- abstract-wikipedia@lists.wikimedia.org List information: https://lists.wikimedia.org/postorius/lists/abstract-wikipedia.lists.wikimed...
Abstract-Wikipedia mailing list -- abstract-wikipedia@lists.wikimedia.org List information: https://lists.wikimedia.org/postorius/lists/abstract-wikipedia.lists.wikimed...
Thank you.
Sent from Yahoo Mail for iPhone
On Friday, March 17, 2023, 11:27 AM, Thomas Douillard thomas.douillard@gmail.com wrote:
About the "discussion" tab on Wikidata items : it now includes the template "item documentation" through automated headers, so the (in)existence of the talk page might not be a good proxy to know if the discussion tab is actually used or not. Hard to know if the community uses it a lot though.
Elaborating on that, the fact that it’s hidden on the talk page might make it not used as often as it could be. It might be a lesson for abstract content, how its existence is discovered, how visible it is. It might be a big factor of how the project gain traction and builds a community. If the content is not easily discovered and seems buried in some part that looks like the technical plumbing of the Wikimedia movement — in the wikidata cases, in the beginning, some non enthusiastic contributors could refer to Wikidata, not in a good way, to a "database". Abstract Wikipedia deserves a shiny portal and a good discoverability of the content, which might be a different discussion even.
Le jeu. 16 mars 2023 à 03:44, Denny Vrandečić dvrandecic@wikimedia.org a écrit :
The online version of this newsletter can be found here:https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Updates/2023-03-15
Quo vadis, Abstract Wikipedia?
Abstract Wikipedia will allow more people to contribute their voices to a baseline of knowledge, whilst working in an interface in their language. This shared baseline of knowledge will then be made available in many languages. This will be achieved by creating, storing, and maintaining the baseline of knowledge, per individual article, in a notation that is independent of natural language. We call content written in that notation "abstract content". This abstract content will then be turned into text in a specific natural language, with the help of the library of functions from Wikifunctions. Thus, Abstract Wikipedia will allow a speaker of any language to contribute content for readers of many different languages. This will allow more people to read more content in their language.
Example
Assume that we want to create a new Wikipedia article for the planet Jupiter, and the first version of this article shall be the following (these are the first two sentences of the Simple English Wikipedia article):
- Jupiter is the largest planet in the Solar System. It is the fifth planet from the Sun.
The abstract content representing this natural text could look like this: Article( text: [ Superlative( subject: Jupiter, quality: large, class: planet, location constraint: Solar System), Definition( subject: Jupiter, definition: Rank( rank: Positive integer( value: 5), object: planet, by: Relational noun( noun: distance, to: Sun)))], categories: [Jupiter, planet, Solar System]) Wikifunctions would have types for Article, Superlative, Definition, Rank, etc., which are used here as the abstract notation for the content of these two sentences. This abstract content is shown using labels in English here for our convenience, whereas in fact they would all be ZIDs (from Wikifunctions) and QIDs (from Wikidata). There will be software components to provide for the viewing, creation, and editing of abstract content. Wikifunctions will then also provide functions that take this object as an argument and generate natural language text such as the above.
One question that needs to be answered is where these objects would be stored, and how to associate the above object with the Wikidata item for Jupiter, Q319. We were originally planning to have this conversation and decision before the launch of Wikifunctions, but looking at the complexity of the system and the fact that it is very difficult to imagine given that so little of it is tangible so far, we decided not to open this question for discussion now, but to wait until after the launch of Wikifunctions, when we will all have a better understanding of how that part of the ecosystem works.
Below, we outline a few options that came up in the discussion between folks on the Abstract Wikipedia team and the Wikidata team at Wikimedia Deutschland. It also ties to some of the questions Lydia Pintscher and I were answering in an interview on the Wikimove podcast episode that was released today and that we invite you to listen to. Thanks to Nicole Ebber and Nikki Zeuner for the interview!
We are genuinely undecided about the best answer, and we would benefit from a wider discussion of the options, and potentially other options as well. Please also ask questions - these can often clarify and shine light on points that are muddy to us as well. We currently are focusing on the following five options:
- A new tab on items in Wikidata - Create a new data type for objects on Wikidata - Objects on Wikifunctions - Objects on a new Wikipedia language edition - Unattached namespace on an existing project
Let’s discuss these five options in the following.
Option 1: A new tab on items in Wikidata
We could add a tab, leading to a new namespace on Wikidata with a new content type, where the abstract content would live. This namespace would be attached to the item namespace in Wikidata. This way, every abstract content would have a natural place to store its associated abstract content.
Given the little use of the item talk pages on Wikidata, it seems an additional talk page may not be valuable, so we might want to redirect people to the item's main talk page for any discussions.
One big question would be where to store content for Wikivoyage and other projects about the same items (e.g. the abstract content we might want to write about Q90/Paris from the perspective of Wikipedia would be different from that for Wikivoyage). Would that need yet another namespace? Adding a new associated namespace would be a technical challenge; adding several would be a complex task, and we hope that not to happen often.
Option 2: Create a new data type for Wikifunction objects
We could create a new data type on Wikidata for Wikifunctions objects. Then the community could create a property on Wikidata that stores the abstract content on a given item as a literal. This would have the added flexibility that the community could add more abstract contents to an item for specific use cases, e.g. to represent content from Wikivoyage, or to represent the history of an item, the etymology of a word, etc.
We will need such a datatype and the UX for it anyway, given our planned support for abstract descriptions. In fact, this might be the simplest way to support abstract description.
However, the UX of Wikidata doesn't lend itself to this easily, and adapting to this model would be challenging given the constraints of an item page. Existing properties are edited as one or a small number of simple, short text boxes, often with auto-complete; abstract content would instead be a larger text area, with helpers and possibly a toolbar, a preview control, etc.. One option could in principle be a modal dialog for editing, but these come with their own inherent UX downsides and are usually more complex to implement than the same functionality in its own dedicated environment. Also, this would break the current design patterns of an item page, and may not be aligned with the patterns that might be planned for its future.
Further, while abstract content is somewhat structured and machine-readable, it is less (or differently) so than an Item, and its structure would probably not be queryable with SPARQL.
This option comes with two additional challenges: some Wikidata items, already nearing the maximum size, would grow still further, and we would need a solution to allow that, and second how to deal with the visualization, editing, and diffing of potentially very large and complex values.
Option 3: Objects on Wikifunctions
Instead of having objects live in Wikidata as the values of statements or on an additional tab, Wikidata could merely store a pointer to an object on Wikifunctions. We still would create a new data type, but that data type would be just the ZID of an object stored in Wikifunctions.
This would solve all the challenges of the previous option, and retain many of its advantages.
It would have the additional advantage that several items could refer to the same object on Wikifunctions. Whereas this sounds rarely useful for the abstract content of Wikipedia articles, this might prove very useful for abstract descriptions of Wikidata items and the abstract glosses of lexemes. With the creation of abstract content, types, and natural language generation functions on the same platform, collaboration between people who focus on one of these areas would be more direct.
This option could be a challenge for the Wikifunctions community. The scope would expand to cover content as well as functions. This could make it difficult for the smaller community, and need more community patrollers like those already active on Wikidata.
Option 4: Objects on a new Wikipedia language edition
We could launch a new Wikipedia language edition in which the main namespace is abstract content. This could be called e.g. the multi-lingual Wikipedia (mul.wikipedia.org) language edition, or the abstract Wikipedia language edition (abstract.wikipedia.org). Like all other language editions, the pages are connected to the items via sitelinks in Wikidata.
If Wikivoyage wanted to use the same approach, they would need to copy the setup and create a multi-lingual Wikivoyage edition (or, as Option 4B, perhaps these could be a different namespace on a single shared ‘abstract’ content wiki?).
This would give a very clear distinction of what is Wikipedia content and what is not, and give the abstract content a distinct visibility, which would otherwise be somewhat hidden between Wikifunctions and Wikidata. On the other hand, it would splinter the communities further, and mix in a "new" concept of a wiki that isn't really a Wikipedia but is labelled as such.
Option 5: Unattached namespace on existing project
We could introduce a new namespace to an existing project where the abstract content for Wikipedia would effectively live. Here are the most likely options:
- Wikidata (as a separate namespace, not attached to the items) - Commons - Meta - English Wikipedia (not attached to the articles)
Whereas technically all these options would be the same, they would be extremely different from a social and community perspective. We will refrain here from discussing these differences for now, unless this starts becoming a more likely option.
Rant: One Wikimedia movement, or many projects?
Conway’s law states that software mirrors organization, or, as it was put, if you put three teams to work on a compiler, you get a three-pass compiler. The opposite is also true, as previously observed by Guillaume Paumier: a software system determines the community structure that evolves around the system. Within the Wikimedia projects, we often see this effect in the dynamics between the different Wikipedia language communities, the Wikidata community, the Commons community, Meta, etc. The stories of local protection of media files on Commons, of wikis opting-out from global anti-abuse tools, or of short descriptions in English Wikipedia should be warning enough.
The question we ask today is not only hard because there are genuine technical challenges that we have to overcome, and we have to make a tradeoff. It is additionally so much harder because we can anticipate that there will be fracture lines between the different projects, and maybe even anticipate how these fracture lines would shape out. The whole story would be so much easier if we would, in general, regard ourselves as being part of one common movement, as one large community. But I doubt that we will see much progress on this trajectory before we have to resolve the above question.
Until then we only can remain mindful about the possible solutions, their effects, and that we should be careful to design for the world as it is and as it likely will be, and not for the world we wish to be.
Public NLG workstream on Tuesday
On Tuesday, March 21, there will be the third public NLG workstream meeting on JITSI. Feel free to reach out to me and suggest presentations beforehand if you want. We have a bit already planned, but there is still space. The meeting is 16:30-17:30 UTC, which is an hour off for US friends. _______________________________________________ Abstract-Wikipedia mailing list -- abstract-wikipedia@lists.wikimedia.org List information: https://lists.wikimedia.org/postorius/lists/abstract-wikipedia.lists.wikimed...
_______________________________________________ Abstract-Wikipedia mailing list -- abstract-wikipedia@lists.wikimedia.org List information: https://lists.wikimedia.org/postorius/lists/abstract-wikipedia.lists.wikimed...
Notice: In the option 1 and 2, You give the warning on the voted licences: https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Updates/2021-12-21
Dušan Kreheľ
In option n. 4, I suggest that there should also be an option for multi.wikipedia.org.
D. K.
Yeah, the existing domains were just examples.
On Fri, Mar 17, 2023 at 2:16 PM Dušan Kreheľ dusankrehel@gmail.com wrote:
In option n. 4, I suggest that there should also be an option for multi.wikipedia.org.
D. K. _______________________________________________ Abstract-Wikipedia mailing list -- abstract-wikipedia@lists.wikimedia.org List information: https://lists.wikimedia.org/postorius/lists/abstract-wikipedia.lists.wikimed...
Yes, absolutely!
On Fri, Mar 17, 2023 at 10:14 AM Dušan Kreheľ dusankrehel@gmail.com wrote:
Notice: In the option 1 and 2, You give the warning on the voted licences: https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Updates/2021-12-21
Dušan Kreheľ _______________________________________________ Abstract-Wikipedia mailing list -- abstract-wikipedia@lists.wikimedia.org List information: https://lists.wikimedia.org/postorius/lists/abstract-wikipedia.lists.wikimed...
abstract-wikipedia@lists.wikimedia.org