APIs again: towards the interim report

I am writing here to remind myself, @melancon and @Jason_Vallet of what we need to do with API documentation.

  1. Normalize field names (Jason, Guy) directly in Drupal Views.
  2. Document APIs on Mashape (me). 
  3. Export a snapshot in json and upload it on Zenodo. This will generate a DOI. (me)
  4. In Zenodo, add links in the "related identifiers" field with a relation (e.g. is supplement to) to the Mashape documentation and, possibly, the edgeryders.eu waterhose itself (me).
  5. Periodically, repeat 3. 

Makes sense?

Please note this concerns ONLY data on edgeryders.eu. Everyone else will have to document their own data. Guy, you have to make a strategic choice: is your graph database going to be an internal resource (unpublished, just used to reaggregate the data for the purpose of building the SSN)? Or is it going to be a published dataset, with its own API etc? If you take the second path, you will also need to go through the same motions, or analogous ones.

After the call

We decide to NOT release the graph database as a separate dataset.

A few questions about the views

Hello @Alberto,

I have created a few new Drupal views to normalise the field names. This led me to the discovery of a few discrepancies:

  • The first one is the reference to unexisting users as posts and comments authors. The view I am currently using (opencare_users_rename) is a clone of the old one (opencare_users) where the fields are simply renamed. This issue concerns 139 posts and 635 comments (plus cascading responses) so that's quite a bit of them. I am wondering whether the problem may come from the filtering parameters as currently we select group_ID=4260 whereas other views select group_ID=5954. Could you validate which group ID we need to consider?
  • The second issue I have encountered is the triplication of some comments (old ones, published before 2015 apparently) and posts (only differing on according to their group definition). This is not really a big problem for the comments but not so for the posts as only one group ID is supposed to be defined per post (or at least I thought so?). Is this normal or should we further refine the views?

Wrong point of departure

@Jason_Vallet I have no idea what is in the opencare_users view, or who made them. I take my data from these two views:

  • opencare_content
  • opencare_comments

Works like this:

  • opencare_content selects (a) all nodes of content type == "challenge response" and (b) all nodes of any type in the group with ID == 5954. Group ID == 4260 is this group, where we talk about the opencare project, not open care as a practice. To verify: https://edgeryders.eu/node/4260 
  • opencare_comments selects all comments with nodeid satisfying conditions (a) and (b) above.
  • user names are simply pulled out of guy_content and guy_comments. If you want to pull other info out of Edgeryders profiles, you can do a join on a view that simply takes out all users, like Users for Assembl.

As of now, those two views return: 2004 comments, 305 nodes, 188 unique users.