Existing landscape and challenges
- FOSS - hard to know out of the box who’s using it
- We have this pingback feature but
- PM doesn’t know how to access the data it’s outputting
- The pingback is anonymous which is hard because
- We currently can only see the information that we intentionally build into the pingback (to collect)
- It doesn’t help in terms of community building, increasing project visibility, and federation
- Working assumption: in an open data ecosystem, the types of projects that we’re invested in supporting _want_ to be known. The logic being that
- They want to participate in a thriving community
- They want to be visible and findable (aligned w their fundamental project goals and what attracted them to the ecosystem
- They want to be able to link their data to others in the ecosystem to saving time in data modelling and maintenance, benefit their projects and benefit others from being able to gather insight across a LOD web of instances aka Federation
Goals
- (spike type work) Figure out what exists in terms of
- Existing, anonymous pingback feature (see links above)
- Default available public data in a standard Mediawiki + Wikibase instance, ex.
- Action API
- Special:pages
- Special: statistics
- Individual page view data
- MVP - more accessible view on low hanging fruit data w/out any changes to code we ship
- build and/or get jon access to existing simple dashboard from pingback
- See what’s possible to collect via default APIs, scraping, etc from a manually collected list of known instances Data in WBS Instances
- Page info, random example: https://meta.wikimedia.org/w/index.php?title=Schema_talk:WikibasePingback&action=info
- Suggest cool data that we might collect _if x_ and what it would take to get there
- And how does that work in parallel w what pingback is currently able to collect
- How we might access information around data model more… perhaps through SPARQL or Action API … how many entities, etc.
Special considerations
- Privacy
- Opt-ing in