Re: [Wiki-research-l] New paper - Indigenous knowledge on Wikipedia
On Fri, Jul 5, 2019 at 10:11 PM Ocean Power wrote: > What about Australian indigenous songs that trace the path of songlines > that both document collective history and folk knowledge and also > rhythmically document land contours and other landmarks as a > map/timeline/travel guide and often compile folkloric and secondary and > primary knowledge over generations? I'm curious if you think these function > in some ways as tertiary sources which, at least according to the wiki, > include "travel guides, field guides, and almanacs." I'm out of my depth > but enjoying the back and forth here. > Hello :) Sounds like a tertiary source to me, whatever the format. I would say instructional, historical, and cataloging stories + songs are traditional tertiary sources. As are the maintainers of legal precedent and local data records. There are also a few independent dimensions where oral and written histories tend to differ, which are sometimes confused. Three at play here: * *Format*: Seen (video) vs. Spoken (audio) vs. written (text). Video or audio are sometimes considered more authentic than text for a primary source. * *Verifiability*: Contemporaneously recorded in a lasting medium, vs. remembered + retransmitted through the memory of recipients * *Closeness to observation*: Primary observation / Secondary analysis / Tertiary compilation A town elder remembering the town's history is primary; when I develop my own history based on it (w/o direct experience) and tell it to you, that is secondary; if you catalog different versions of town histories in an epic song, that's tertiary (even as your performance of it is a primary source for your singing style!) S. ___ Wiki-research-l mailing list Wiki-research-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wiki-research-l
Re: [Wiki-research-l] New paper - Indigenous knowledge on Wikipedia
Technically these are primary sources when they are first recorded / written down. The first recorded / written theorizing about them is secondary. Reporting on a concensus reached by that theorizing is tertiary. Assuming that the singing, theorizing and reporting is done by different parties. The model very much assumes a subject and an observer and written / recorded communication. The model (for better or worse) is very effective is suppressing things like arguing from the Bible or from direct religious experience. Presumably new models would either accept those or deal with them in other ways. Cheers Stuart On Sat, 6 Jul 2019 2:11 pm Ocean Power wrote: > What about Australian indigenous songs that trace the path of songlines > that both document collective history and folk knowledge and also > rhythmically document land contours and other landmarks as a > map/timeline/travel guide and often compile folkloric and secondary and > primary knowledge over generations? I'm curious if you think these function > in some ways as tertiary sources which, at least according to the wiki, > include "travel guides, field guides, and almanacs." I'm out of my depth > but enjoying the back and forth here. > > On Fri, Jul 5, 2019 at 5:20 PM, Stuart A. Yeates > wrote: > > > Hi Samuel > > > > Can you provide examples of tertiary sources from pure oral cultures? > I've > > never heard of any. > > > > Cheers > > Stuart > > > > On Sat, 6 Jul 2019 1:19 am Samuel Klein wrote: > > > >> I think we have all the mechanics needed for this. > >> > >> - Individual revisions aren't editable, once posted, and stay around > >> forever (unless revdeleted). > >> - Each wiki can have its own guidelines for how accounts can be shared. > >> - Rather than limiting who can edit, you could have a whitelist of > >> contributors considered by the local community to represent their > >> knowledge; and have a lens that only looks at those contributions. (like > >> flagged revs) > >> > >> (@stuart - tertiary sourcing can apply to any source; it does not > privilege > >> print culture. only particular standards of notability and verifiability > >> start to limit which sources are preferred.) > >> > >> On Thu, Jul 4, 2019 at 7:39 PM Kerry Raymond > >> wrote: > >> > >> > On en.WP we prohibit shared accounts and accounts that appear to > >> represent > >> > an organisation so that's a barrier. But assuming there was some > special > >> > case to allow a username to represent a community of knowledge, we > would > >> > still have a practical problem of whether the individual creating > such an > >> > account or doing the edit was authorised to do so by that community, > >> which > >> > would require some kind of real-world validation. But, let's say local > >> > chapters or local users could undertake that process using local > >> knowledge > >> > of how such communities identify and operate. > >> > > >> > The problem it still doesn't solve is that whatever information is > added > >> > by that account could then be changed by anyone. We would have to > have a > >> > way to prevent that happening, which would be a technical problem. > Also > >> > could that information ever be deleted by anyone (even for purely > >> innocent > >> > purposes, e.g. splitting a large article might delete the content from > >> one > >> > article to re-insert into other article). Or is the positioning of the > >> > content within a particular article a decision only that group might > be > >> > allowed to take? > >> > > >> > A possible technical/social solution is to have traditional knowledge > of > >> > this nature in a sister project, where rules on user names would be > >> > entirely different and obviously oral sourced material allowed. The > >> group > >> > could then produce named units of information as a single unit > (similar > >> to > >> > a File on Commons). These units could then be added to en.WP or others > >> > (obviously the language the units are written would have be > identified, > >> as > >> > Commons does with descriptions already) so only English content is > added > >> to > >> > en.WP and so on. The content would be presented in en.WP in a way (in > a > >> > "traditional language" box with a link to something explaining that > what > >> > means) so the reader understands what this info is and is free to > trust > >> it > >> > or not. The information itself cannot be modified on en.WP only on the > >> > sister project (requests on talk pages of the sister project would > need > >> to > >> > be allowed for anyone to make requests eg report misspelling). En.WP > >> would > >> > remain in control of whether the content was included but could not > >> change > >> > the content themselves. > >> > > >> > It seems to be a sister project similar to the current Commons would > be > >> > what we need to make this work. > >> > > >> > Sent from my iPad > >> > > >> > On 4 Jul 2019, at 6:03 pm, Jan Dittrich > >> wrote: > >> > > >> > >> Maybe not "signed" in
Re: [Wiki-research-l] New paper - Indigenous knowledge on Wikipedia
What about Australian indigenous songs that trace the path of songlines that both document collective history and folk knowledge and also rhythmically document land contours and other landmarks as a map/timeline/travel guide and often compile folkloric and secondary and primary knowledge over generations? I'm curious if you think these function in some ways as tertiary sources which, at least according to the wiki, include "travel guides, field guides, and almanacs." I'm out of my depth but enjoying the back and forth here. On Fri, Jul 5, 2019 at 5:20 PM, Stuart A. Yeates wrote: > Hi Samuel > > Can you provide examples of tertiary sources from pure oral cultures? I've > never heard of any. > > Cheers > Stuart > > On Sat, 6 Jul 2019 1:19 am Samuel Klein wrote: > >> I think we have all the mechanics needed for this. >> >> - Individual revisions aren't editable, once posted, and stay around >> forever (unless revdeleted). >> - Each wiki can have its own guidelines for how accounts can be shared. >> - Rather than limiting who can edit, you could have a whitelist of >> contributors considered by the local community to represent their >> knowledge; and have a lens that only looks at those contributions. (like >> flagged revs) >> >> (@stuart - tertiary sourcing can apply to any source; it does not privilege >> print culture. only particular standards of notability and verifiability >> start to limit which sources are preferred.) >> >> On Thu, Jul 4, 2019 at 7:39 PM Kerry Raymond >> wrote: >> >> > On en.WP we prohibit shared accounts and accounts that appear to >> represent >> > an organisation so that's a barrier. But assuming there was some special >> > case to allow a username to represent a community of knowledge, we would >> > still have a practical problem of whether the individual creating such an >> > account or doing the edit was authorised to do so by that community, >> which >> > would require some kind of real-world validation. But, let's say local >> > chapters or local users could undertake that process using local >> knowledge >> > of how such communities identify and operate. >> > >> > The problem it still doesn't solve is that whatever information is added >> > by that account could then be changed by anyone. We would have to have a >> > way to prevent that happening, which would be a technical problem. Also >> > could that information ever be deleted by anyone (even for purely >> innocent >> > purposes, e.g. splitting a large article might delete the content from >> one >> > article to re-insert into other article). Or is the positioning of the >> > content within a particular article a decision only that group might be >> > allowed to take? >> > >> > A possible technical/social solution is to have traditional knowledge of >> > this nature in a sister project, where rules on user names would be >> > entirely different and obviously oral sourced material allowed. The >> group >> > could then produce named units of information as a single unit (similar >> to >> > a File on Commons). These units could then be added to en.WP or others >> > (obviously the language the units are written would have be identified, >> as >> > Commons does with descriptions already) so only English content is added >> to >> > en.WP and so on. The content would be presented in en.WP in a way (in a >> > "traditional language" box with a link to something explaining that what >> > means) so the reader understands what this info is and is free to trust >> it >> > or not. The information itself cannot be modified on en.WP only on the >> > sister project (requests on talk pages of the sister project would need >> to >> > be allowed for anyone to make requests eg report misspelling). En.WP >> would >> > remain in control of whether the content was included but could not >> change >> > the content themselves. >> > >> > It seems to be a sister project similar to the current Commons would be >> > what we need to make this work. >> > >> > Sent from my iPad >> > >> > On 4 Jul 2019, at 6:03 pm, Jan Dittrich >> wrote: >> > >> > >> Maybe not "signed" in the sense of a signature of a Talk page, but >> each >> > > contribution is attributed automatically to its user as seen in the >> > > history. As someone who edits under my real name, I absolutely put my >> > name >> > > to my contributions. >> > > >> > > That is what I assumed, too, since it was coherent with some of the >> > > problems described in: >> > > >> > >> https://upload.wikimedia.org/wikipedia/commons/6/6c/PG-Slides-Wikimania18.pdf >> > > in this interpretation, Mediawiki (and lots of other software) code-ify >> > > knowledge production as done by single people [1]– a person can edit, >> > but >> > > not a group (which was one of the challenges in the project described >> in >> > > the slides, if I remember correctly) >> > > >> > > I would be much interested in more research on what values are "build >> in" >> > > our software (Some Research by Heather Ford and
Re: [Wiki-research-l] New paper - Indigenous knowledge on Wikipedia
The current mechanisms would allow anyone to alter the Indigenous content in an article. That is unlikely to be acceptable to Ingenenous Australians. This is why I propose a sister project with different rules to create such content and then import it into en.WP etc as an unalterable unit into en.WP (from where it can be deleted but not changed in content). The WP gets to decide if the content is welcome but does not control the content. This appears to me to strike be an acceptable balance between the two cultures. If our current mechanisms and policies were working, I don't think we'd be having this conversation. Sent from my iPad > On 5 Jul 2019, at 11:18 pm, Samuel Klein wrote: > > I think we have all the mechanics needed for this. > > - Individual revisions aren't editable, once posted, and stay around > forever (unless revdeleted). > - Each wiki can have its own guidelines for how accounts can be shared. > - Rather than limiting who can edit, you could have a whitelist of > contributors considered by the local community to represent their > knowledge; and have a lens that only looks at those contributions. (like > flagged revs) > > (@stuart - tertiary sourcing can apply to any source; it does not privilege > print culture. only particular standards of notability and verifiability > start to limit which sources are preferred.) > > On Thu, Jul 4, 2019 at 7:39 PM Kerry Raymond > wrote: > >> On en.WP we prohibit shared accounts and accounts that appear to represent >> an organisation so that's a barrier. But assuming there was some special >> case to allow a username to represent a community of knowledge, we would >> still have a practical problem of whether the individual creating such an >> account or doing the edit was authorised to do so by that community, which >> would require some kind of real-world validation. But, let's say local >> chapters or local users could undertake that process using local knowledge >> of how such communities identify and operate. >> >> The problem it still doesn't solve is that whatever information is added >> by that account could then be changed by anyone. We would have to have a >> way to prevent that happening, which would be a technical problem. Also >> could that information ever be deleted by anyone (even for purely innocent >> purposes, e.g. splitting a large article might delete the content from one >> article to re-insert into other article). Or is the positioning of the >> content within a particular article a decision only that group might be >> allowed to take? >> >> A possible technical/social solution is to have traditional knowledge of >> this nature in a sister project, where rules on user names would be >> entirely different and obviously oral sourced material allowed. The group >> could then produce named units of information as a single unit (similar to >> a File on Commons). These units could then be added to en.WP or others >> (obviously the language the units are written would have be identified, as >> Commons does with descriptions already) so only English content is added to >> en.WP and so on. The content would be presented in en.WP in a way (in a >> "traditional language" box with a link to something explaining that what >> means) so the reader understands what this info is and is free to trust it >> or not. The information itself cannot be modified on en.WP only on the >> sister project (requests on talk pages of the sister project would need to >> be allowed for anyone to make requests eg report misspelling). En.WP would >> remain in control of whether the content was included but could not change >> the content themselves. >> >> It seems to be a sister project similar to the current Commons would be >> what we need to make this work. >> >> Sent from my iPad >> >> On 4 Jul 2019, at 6:03 pm, Jan Dittrich wrote: >> Maybe not "signed" in the sense of a signature of a Talk page, but each >>> contribution is attributed automatically to its user as seen in the >>> history. As someone who edits under my real name, I absolutely put my >> name >>> to my contributions. >>> >>> That is what I assumed, too, since it was coherent with some of the >>> problems described in: >>> >> https://upload.wikimedia.org/wikipedia/commons/6/6c/PG-Slides-Wikimania18.pdf >>> in this interpretation, Mediawiki (and lots of other software) code-ify >>> knowledge production as done by single people [1]– a person can edit, >> but >>> not a group (which was one of the challenges in the project described in >>> the slides, if I remember correctly) >>> >>> I would be much interested in more research on what values are "build in" >>> our software (Some Research by Heather Ford and Stuart Geiger goes in >> this >>> direction). >>> >>> Best, >>> Jan >>> >>> [1] An interesting read on the concept of "transmitting knowledge" (e.g. >> in >>> articles and via the web) and knowledge as inherently social would be >>> Ingold’s "From the
Re: [Wiki-research-l] New paper - Indigenous knowledge on Wikipedia
Hi Samuel Can you provide examples of tertiary sources from pure oral cultures? I've never heard of any. Cheers Stuart On Sat, 6 Jul 2019 1:19 am Samuel Klein wrote: > I think we have all the mechanics needed for this. > > - Individual revisions aren't editable, once posted, and stay around > forever (unless revdeleted). > - Each wiki can have its own guidelines for how accounts can be shared. > - Rather than limiting who can edit, you could have a whitelist of > contributors considered by the local community to represent their > knowledge; and have a lens that only looks at those contributions. (like > flagged revs) > > (@stuart - tertiary sourcing can apply to any source; it does not privilege > print culture. only particular standards of notability and verifiability > start to limit which sources are preferred.) > > On Thu, Jul 4, 2019 at 7:39 PM Kerry Raymond > wrote: > > > On en.WP we prohibit shared accounts and accounts that appear to > represent > > an organisation so that's a barrier. But assuming there was some special > > case to allow a username to represent a community of knowledge, we would > > still have a practical problem of whether the individual creating such an > > account or doing the edit was authorised to do so by that community, > which > > would require some kind of real-world validation. But, let's say local > > chapters or local users could undertake that process using local > knowledge > > of how such communities identify and operate. > > > > The problem it still doesn't solve is that whatever information is added > > by that account could then be changed by anyone. We would have to have a > > way to prevent that happening, which would be a technical problem. Also > > could that information ever be deleted by anyone (even for purely > innocent > > purposes, e.g. splitting a large article might delete the content from > one > > article to re-insert into other article). Or is the positioning of the > > content within a particular article a decision only that group might be > > allowed to take? > > > > A possible technical/social solution is to have traditional knowledge of > > this nature in a sister project, where rules on user names would be > > entirely different and obviously oral sourced material allowed. The > group > > could then produce named units of information as a single unit (similar > to > > a File on Commons). These units could then be added to en.WP or others > > (obviously the language the units are written would have be identified, > as > > Commons does with descriptions already) so only English content is added > to > > en.WP and so on. The content would be presented in en.WP in a way (in a > > "traditional language" box with a link to something explaining that what > > means) so the reader understands what this info is and is free to trust > it > > or not. The information itself cannot be modified on en.WP only on the > > sister project (requests on talk pages of the sister project would need > to > > be allowed for anyone to make requests eg report misspelling). En.WP > would > > remain in control of whether the content was included but could not > change > > the content themselves. > > > > It seems to be a sister project similar to the current Commons would be > > what we need to make this work. > > > > Sent from my iPad > > > > On 4 Jul 2019, at 6:03 pm, Jan Dittrich > wrote: > > > > >> Maybe not "signed" in the sense of a signature of a Talk page, but > each > > > contribution is attributed automatically to its user as seen in the > > > history. As someone who edits under my real name, I absolutely put my > > name > > > to my contributions. > > > > > > That is what I assumed, too, since it was coherent with some of the > > > problems described in: > > > > > > https://upload.wikimedia.org/wikipedia/commons/6/6c/PG-Slides-Wikimania18.pdf > > > in this interpretation, Mediawiki (and lots of other software) code-ify > > > knowledge production as done by single people [1]– a person can edit, > > but > > > not a group (which was one of the challenges in the project described > in > > > the slides, if I remember correctly) > > > > > > I would be much interested in more research on what values are "build > in" > > > our software (Some Research by Heather Ford and Stuart Geiger goes in > > this > > > direction). > > > > > > Best, > > > Jan > > > > > > [1] An interesting read on the concept of "transmitting knowledge" > (e.g. > > in > > > articles and via the web) and knowledge as inherently social would be > > > Ingold’s "From the Transmission of Representation to the Education of > > > Attention" (http://lchc.ucsd.edu/MCA/Paper/ingold/ingold1.htm). > > > > > > Am Do., 4. Juli 2019 um 02:20 Uhr schrieb Kerry Raymond < > > > kerry.raym...@gmail.com>: > > > > > >> Maybe not "signed" in the sense of a signature of a Talk page, but > each > > >> contribution is attributed automatically to its user as seen in the > > >> history. As someone who edits under my
Re: [Wiki-research-l] New paper - Indigenous knowledge on Wikipedia
I think we have all the mechanics needed for this. - Individual revisions aren't editable, once posted, and stay around forever (unless revdeleted). - Each wiki can have its own guidelines for how accounts can be shared. - Rather than limiting who can edit, you could have a whitelist of contributors considered by the local community to represent their knowledge; and have a lens that only looks at those contributions. (like flagged revs) (@stuart - tertiary sourcing can apply to any source; it does not privilege print culture. only particular standards of notability and verifiability start to limit which sources are preferred.) On Thu, Jul 4, 2019 at 7:39 PM Kerry Raymond wrote: > On en.WP we prohibit shared accounts and accounts that appear to represent > an organisation so that's a barrier. But assuming there was some special > case to allow a username to represent a community of knowledge, we would > still have a practical problem of whether the individual creating such an > account or doing the edit was authorised to do so by that community, which > would require some kind of real-world validation. But, let's say local > chapters or local users could undertake that process using local knowledge > of how such communities identify and operate. > > The problem it still doesn't solve is that whatever information is added > by that account could then be changed by anyone. We would have to have a > way to prevent that happening, which would be a technical problem. Also > could that information ever be deleted by anyone (even for purely innocent > purposes, e.g. splitting a large article might delete the content from one > article to re-insert into other article). Or is the positioning of the > content within a particular article a decision only that group might be > allowed to take? > > A possible technical/social solution is to have traditional knowledge of > this nature in a sister project, where rules on user names would be > entirely different and obviously oral sourced material allowed. The group > could then produce named units of information as a single unit (similar to > a File on Commons). These units could then be added to en.WP or others > (obviously the language the units are written would have be identified, as > Commons does with descriptions already) so only English content is added to > en.WP and so on. The content would be presented in en.WP in a way (in a > "traditional language" box with a link to something explaining that what > means) so the reader understands what this info is and is free to trust it > or not. The information itself cannot be modified on en.WP only on the > sister project (requests on talk pages of the sister project would need to > be allowed for anyone to make requests eg report misspelling). En.WP would > remain in control of whether the content was included but could not change > the content themselves. > > It seems to be a sister project similar to the current Commons would be > what we need to make this work. > > Sent from my iPad > > On 4 Jul 2019, at 6:03 pm, Jan Dittrich wrote: > > >> Maybe not "signed" in the sense of a signature of a Talk page, but each > > contribution is attributed automatically to its user as seen in the > > history. As someone who edits under my real name, I absolutely put my > name > > to my contributions. > > > > That is what I assumed, too, since it was coherent with some of the > > problems described in: > > > https://upload.wikimedia.org/wikipedia/commons/6/6c/PG-Slides-Wikimania18.pdf > > in this interpretation, Mediawiki (and lots of other software) code-ify > > knowledge production as done by single people [1]– a person can edit, > but > > not a group (which was one of the challenges in the project described in > > the slides, if I remember correctly) > > > > I would be much interested in more research on what values are "build in" > > our software (Some Research by Heather Ford and Stuart Geiger goes in > this > > direction). > > > > Best, > > Jan > > > > [1] An interesting read on the concept of "transmitting knowledge" (e.g. > in > > articles and via the web) and knowledge as inherently social would be > > Ingold’s "From the Transmission of Representation to the Education of > > Attention" (http://lchc.ucsd.edu/MCA/Paper/ingold/ingold1.htm). > > > > Am Do., 4. Juli 2019 um 02:20 Uhr schrieb Kerry Raymond < > > kerry.raym...@gmail.com>: > > > >> Maybe not "signed" in the sense of a signature of a Talk page, but each > >> contribution is attributed automatically to its user as seen in the > >> history. As someone who edits under my real name, I absolutely put my > name > >> to my contributions. > >> > >> Or the other possible interpretation of "signed" here may be referring > to > >> the citations which are usually sources with one or small number of > >> individual authors, as opposed to a community of shared knowledge > >> custodians which is the case with Aboriginal Australians. > >> > >> Kerry > >> > >> Sent from my
[Wiki-research-l] Firewall on stat100x and notebook100x hosts
TL;DR: In https://phabricator.wikimedia.org/T170826 the Analytics team wants to add base firewall rules to stat100x and notebook100x hosts, that will cause any non-localhost or known traffic to be blocked by default. Please let us know in the task if this is a problem for you. Hi everybody, the Analytics team has always left the stat100x and notebook100x hosts without a set of base firewall rules to avoid impacting any research/test/etc.. activity on those hosts. This choice has a lot of downsides, one of the most problematic ones is that usually environments like the Python venvs can install potentially any package, and if the owner does not pay attention to security upgrades then we may have a security problem if the environment happens to bind to a network port and accept traffic from anywhere. One of the biggest problems was Spark: when somebody launches a shell using Hadoop Yarn (--master yarn), a Driver component is created that needs to bind to a random port to be able to communicate with the workers created on the Hadoop cluster. We assumed that instructing Spark to use a predefined range of random ports was not possible, but in https://phabricator.wikimedia.org/T170826 we discovered that there is a way (that seems to work fine from our tests). The other big use case that we know, Jupyter notebooks, seems to require only localhost traffic flow without restrictions. Please let us know in the task if you have a use case that requires your environment to bind to a network port on stat100x or notebook100x and accept traffic from other hosts. For example, having a python app that binds to port 33000 on stat1007 and listens/accepts traffic from other stat or notebook hosts. If we don't hear anything, we'll start adding base firewall rules to one host at the time during the upcoming weeks, tracking our work on the aforementioned task. Thanks! Luca (on behalf of the Analytics team) ___ Wiki-research-l mailing list Wiki-research-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wiki-research-l
