Fifth meeting of the Wikimedia Research Network.
- Single login
- Review Brion's collision estimates
- Review specification status
- Set timetable
- Taking things forward
- Use IEEE LOM?
- Based off Wikidata?
- Watchlist analysis
- Shared watchlist feature.
- Possible Budget needs
- Usage statistics (also based on single articles) - a server and methods to gather data without slowing down the wikis is needed
- Collaboration with universities
- Students working on MediaWiki-related projects
- Student project liason, etc.?
- Development tasks re-organisation and management
- please add another agendum
Started ~ 18:45 UTC
- Single user login
- Skipped as Brion was unavailable.
- Scepticism of using IEEE's LOM as the basis - LOM may not be applicable to what we want to do. Further analysis required.
- Wikidata may well be useful as a back-end for organising and applying metadata to objects; see http://wiki.ontoworld.org/index.php/San_Diego for an example of this.
- In-line definition of relations was shown to be too simplistic - labelling of different forms of the same meta-data
- The example given was of a book having different editions, or binding versions, printed by different publishers - referencing each one as a standard simple "publisher" meta-data "tags" would not allow differentiation. Instead, full "fragments" would be required, allowing a relation on each publisher fragment as "paperback", "hardback", "3rd edition", etc.
- Compared to current categories system, a full metadata system would allow non-boolean, time-ordered, and other relations to be encoded, and the same system referenced back ("List all articles about women born in the 16th century who were 3rd daughters of French Dukes") in a structured way.
- Example potential applications were given for Wikipedia, Wiktionary, and others.
- Dublin Core (http://dublincore.org/documents/usageguide/) examined as a possible metadata system (or, at least, interface).
- Wikidata now has another developer working on it, Ævar, and is now installable and in CVS ("wikidata" tree).
- Ultimate Wikitionary was discussed as the current main intended application for Wikidata right now.
- There is scope for moving the category system into Wikidata.
- Sharing of information between different language versions of a project, and between different projects, would make it much more useful
- Especially useful for a centralised inter-wiki link system
- Would require single user login.
- Budget ideas
- Dedicated log analysis box (like toolserver).
- Fund a proper analysis of adding peer-review mechanisms to the wiki.
- Fund development towards single user login and other Research projects (Wikidata; metadata; standardised Wikitax; etc.); possible funding methods:
- Fund partially towards long-term contracts (e.g. Brion) and then claim some of his time - but he's stretched enough as it is.
- Development bounty system (Has locking problems - if one person takes it on, no-one else will work on it.)
- Contractual development
- Full-time (or not) paid shepherder/liason for student-done mini-projects for MediaWiki extensions, etc.
- Development tasks
- Re-organisation through "wikimoney" might be worth trying again, though there are issues and previous attempts failed.
- The Network and developers should together try to hack out spec.s for things that are worth implementing (in their joint opinion) and submit them to the CDO for action (and the Board for approval first).
- The Network should in future discuss and come to agreement on priorities in the non-critical task list (that is, other than bugs, security holes, etc.), possibly stratified (needs/wants/wouldbenice/wishes) and with dependency links ("centralised inter-wikis depends on Wikidata and Single User Login").
- Shared watchlist feature
see Share watchlists
- Number of watchers may become social-networking-like race to the stars instead of using to fight vandalism and to better articles.
- Possibly individually-invited lists (friends-lists?)
- Several worries:
- Possible "wikistalking" problems, or mass POV-pushers'/trolls/... co-ordination.
- Overlaps rather with WikiProjects' scopes, but if semi-private not possible for outside review; cliques, cabals, roving gangs.
- Centralised public watchlists, rather than individuals' lists, might be a solution to this.
- Multiple watchlists could also help (could well be useful anyway, outside of shared lists)
- Watchlist analysis privacy concerns
- "Anonymous" watchlists (no user account given) are likely to be very highly correlated with the account's edits, so privacy would be violated.
- Opt-in will skew the data; taking the data directly means that only trusted internal parties (developers, essentially) can run scripts on it, and possibly return the results.
- "Automatically watch pages I edit" option users will also skew the articles (but are in-and-of-themselves interesting)
- Could do in reverse - take a sampling of pages, and work out who watches (anonymised), but suffers from same issue if too large a scope, and may not be useful.
- Collaboration with universities
- Mostly skipped, but see development tasks.
Closed at 21:15.