I have now updated RyderEx to only use the intersection operator.
I fixed this, see the same state on our own deployment.
We still need to dig down into this, there might still be some differences.
Good to know for the future, let’s look at possible implementing this down the line.
This is now fixed, more or less. RyderEx now sees 5,867 annotations in the NGI corpus Still a very slight difference, but I think it might have to do with RyderEx not counting two instances of the same code as two annotations.
I have made a few other fixes:
One improvement over the old dashboard is that it becomes a lot easier to understand how the primary data (posts) and secondary data (annotations) are related and how these are represented in the graph.
@matthias - how are we doing with that database connection to the platform?
I have set up the cronjob, so once that connection is made we are ready to use RyderEx on up-to-date data as we go.
Are you sure? Annotations are their own entities. Even when they point to the same code, they have different snippets.
Also:
This link no longer works for me (502 Bad Gateway).
Just checked POPREBEL.
Data explorer query: 6,658 annotations
RyderEx: 5,771 annotations
Still a big difference.
Are you explicitly excluding annotations on posts by users from which we do not have consent? I have a feeling this might be the issue.
Or actually, perhaps it it because of posts in protected categories? That is more likely.
RyderEx only loads public posts.
No, you are right. The query is here: https://edgeryders.eu/admin/plugins/explorer?id=12.
I have no idea how to add that filter.
That too.
I just changed your query to only include posts in public categories, and it now yields 5,781 annotations for POPREBEL. Checking the consent is not obvious as that information does not seem to be accessible through the DataExplorer, but I can imagine that one or two posts in the corpus might be from unconsenting users, given the problems we had with the consent funnel last year.
We are using RyderEx to fulfill the NGI deliverable D2.6. Interactive Graphryder Dashboard II. I’ve included the following in the report:
Interactions on the Edgeryders.eu platform are annotated in deliverable 2.2 “Coding ontology I” and these annotations are displayed through the dashboard.
Annotations are linked to ethnographic codes, and the dashboard allows exploration of how often these codes co-occur with each other.
Interactions between participants in the conversation can also be displayed in a graph in tandem with the co-occurrence network. Through exploring the interactions and co-occurring concepts a researcher can discover novel themes and trends. She can then read the original content by selecting it in the content list after filtering through the graph.
A researcher may also use the dashboard to investigate if a hunch is supported by the ethnographic data. In this case, she might have read a post on Edgeryders.eu that seemed to indicate that contact tracing apps are associated with distrust and surveillance. Through the co-occurrence graph she finds out that these codes occur together often in the conversation, and she can support her claim that this is a significant theme in the conversation.
Good work. But of course researchers want access to the material in protected categories, which creates a more complicated issue of data protection and confidentiality. This does not affect the deliverable, but it does affect the extent to which the ethnographers will want to use the software. Maybe, with the deliverable past, we can imagine some kind of workaround.
One workaround would be to modify my script so that it does include annotations for posts in protected categories, but that the script redacts the content of those posts, the quoted snippet of text, and the author. That way, the annotations still contribute to the co-occurrence graph.
It could look like this:
When the link to the post is clicked, it would still take you to the right URL, which you can then read if you have permission.
As I see it, there is really only one major problem with this. Every post need to be associated to a user in the RyderEx graph, and if we want to hide the real association we would have to create dummy users to hold ownership of protected posts. Either we create one dummy user that owns all redacted posts or one dummy user user that owns any protected post. That way, users with protected posts would be represented by two nodes in the participant graph - one with their real username, and one under a pseudonym.
Maybe there would also be the possibility to pseudonymize all users. This is what we do for the public-facinng datasets we save in Zenodo.
True, but that would make the dashboard a lot less useful for community managers and outreach efforts.
I’m going to try the thing I proposed above, I think it will not be too hard to modify my script to do that.
Isn’t this a little bit of a play for the galleries anyway? Seeing that the only thing you need to to find out who wrote a post is to enter a string from any post into google, or the Edgeryders search function itself?
Even if you pseudonymize all users and redact content and titles of protected posts, it will still be very easy to figure out which user has written content in protected categories that has been annotated with “criticism”, “police” and “corruption” by doing the following:
In a sense, yes. But it seems you are thinking about security, whereas we were thinking about consent. Of course Edgeryders can never guarantee full anonymity, we say it right at the front door. The use case goes like this:
@anon12345.Marco felt it was a reasonable compromise.
On another note, you once told me that the social network is induced like this:
What happens if post A is a reply to post B and it contains a quote from post C? Or if someone quotes posts of several different authors?