<div dir="ltr">Sorry for being late to the party. Clearly the "quest for data" is a commonly shared one, with many different approaches, questions, and reporting/results.<div><br></div><div>One of the already mentioned solutions is the sugar-stats package, originally developed by Aleksey, which have now been part of dextrose-sugar builds for over a year, and the server side (xsce). </div>
<div><br></div><div><a href="http://wiki.sugarlabs.org/go/Platform_Team/Usage_Statistics">http://wiki.sugarlabs.org/go/Platform_Team/Usage_Statistics</a></div><div><br></div><div>The approach we followed was to collect as much data as possible without interfering with sugar-apis or code. The project has made slow progress on the visualization front, but the data collection front has already been field tested.</div>
<div><br></div><div><br></div><div>I for one think there are a few technical trade-offs, which lead to larger strategy decisions:</div><div>* Context v/s Universality ... Ideally we'd like to collect (activity) context specific data, but that requires tinkering with the sugar api itself and each activity. The other side is we might be ignoring the other types of data a server might be collecting ... internet usage and the various other logfiles in /var/log</div>
<div><br></div><div>* Static v/s Dynamic ... Analyzing journal backups is great, but they are ultimately limited in time resolution due to the datastore's design itself. So the key question being "what's valuable?" ... a) Frequency counts of activities? b) Data such as upto the minute resolution of what activities are running, which activity is active (visible & when), collaborators over time ... etc ... </div>
<div><br></div><div>In my humble opinion, the next steps could be: </div><div>1 Get better on the visualization front. </div><div>2 Search for more context. Maybe arm the sugar-datastore to collect higher resolution data. </div>
<div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jan 7, 2014 at 12:24 PM, Christophe Guéret <span dir="ltr"><<a href="mailto:christophe.gueret@dans.knaw.nl" target="_blank">christophe.gueret@dans.knaw.nl</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div>Dear Sameer, all,<br><br></div>That's a very interesting blog post and discussion. I agree that collecting data is important but knowing that are the questions aimed to be answered with that data is even more so. If you need help with that last bit, I could propose to use the journal data as a use-case for the project KnowEscape ( <a href="http://knowescape.org/" target="_blank">http://knowescape.org/</a> ). This project is about getting insights out of large knowledge spaces via visualisation. There is wide (European) community of experts behind it coming from different research fields (humanities, physic, computer science, ...). Something useful could maybe come out...<br>
<br></div>I would also like to refer you to the project ERS we have now almost finished. This project is an extension of the ideas behind SemanticXO some of you may remember. We developed a decentralised entity registry system with the XO as a primary platform for coding and testing. There is a description of the implementation and links to code on <a href="http://ers-devs.github.io/ers/" target="_blank">http://ers-devs.github.io/ers/</a> . We also had a poster at OLPC SF (thanks for that !). <br>
<br>
<p style="margin:0px;text-indent:0px">In a nutshell, ERS creates global and shared knowledge spaces through series of statements. For instance, "Amsterdam is in the Netherlands" is a statement made about the entity "Amsterdam" relating it to the entity "the Netherlands". Every user of ERS may want to either de-reference an entity (*e.g.*, asking for all pieces of information about "Amsterdam") or contribute to the content of the shared space by adding new statements. This is made possible via "Contributors" nodes, one of the three types of node defined in our system. Contributors can interact freely with the knowledge base. They themselves take care of publishing their own statements but cannot edit third-party statements. Every set of statements about a given entity contributed by one single author is wrapped into a document in couchDB to avoid conflicts and enable provenance tracking. Every single XO is a Contributor. Two Contributors in a closed P2P network can freely create and share Linked Open Data. In order for them to share data with another closed group of Contributors, we haves "Bridges". A Bridge is a relay between two closed networks using the internet or any other form of direct connection to share data. Two closed communities, for example two schools, willing to share data can each setup one Bridge and connect these two nodes to each other. The Bridges will then collect and exchange data coming from the Contributors. These bridges are not Contributors themselves, they are just used to ship data (named graphs) around and can be shut-down or replaced without any data-loss. Lastly, the third component we define in our architecture is the "Aggregator". This is a special node every Bridge may push content to and get updated content from. As its name suggests, an Aggregator is used to aggregate entity descriptions that are otherwise scattered among all the Contributors. When deployed, an aggregator can be used to access and expose the global content of the knowledge space or a subset thereof.</p>
<br></div>One could use ERS to store (part of) the content of the Journal on an XO (Contributor), cluster information as the school level (Bridge put on the XS) and provide higher level analysis (Aggregator). The best things about ERS, I think is that:<br>
</div>* It can store and share any data that consists of property/values about a given thing identified with a unique identifier<br><div><div><div><div><div><div><div><div><div class="gmail_extra">* It is "off-line by default", all the upper level components are optional. So is the connectivity to them<br>
</div><div class="gmail_extra">* It's conservative in terms of bandwidth used<br><br></div><div class="gmail_extra">The creation of graphs could be done at every level to get some statistics on the XO, on the XS and at a more global level. All these potentially using the same code as the data is always stored using the same model (a variant of JSON-LD).<br>
</div><div class="gmail_extra"><br></div><div class="gmail_extra">We are now finalising a small social-networking activity to demo&test ERS. You can easily play with it using the virtual images we put on the site. Here is a video showing it running: <a href="https://vimeo.com/81796228" target="_blank">https://vimeo.com/81796228</a><br>
<br></div><div class="gmail_extra">Please have a look and let us know how what you think of it :-) The project is still funded for a bit less than three months and we would really like it to be useful for the OLPC community (that's why we targeted the XO) so don't hesitate to ask for missing features!<br>
</div><div class="gmail_extra"><br></div><div class="gmail_extra">Cheers,<br>Christophe<br><br></div><div class="gmail_extra"><div><div class="h5"><div class="gmail_quote">On 6 January 2014 02:03, Andreas Gros <span dir="ltr"><<a href="mailto:andigros72@gmail.com" target="_blank">andigros72@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Great utilization of CouchDB and its views feature! That's definitely something we can build on. But more importantly, to make this meaningful, we need more data. <div>
It's good to know what the activities are that are used most, so one can come up with a priority list for improvements, and/or focus developer attention. </div>
<div>CouchDB allows to pull data together from different instances, which should make aggregation and comparisons between projects possible. And for projects that are not online, the data could be transferred to a USB stick quite easily and then uploaded to any other DB instance.</div>
<div><br></div><div>Is there a task/todo list somewhere?</div><div><br></div><div>Andi </div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><br>
<div class="gmail_quote"><div><div>On Fri, Jan 3, 2014 at 11:16 AM, Sameer Verma <span dir="ltr"><<a href="mailto:sverma@sfsu.edu" target="_blank">sverma@sfsu.edu</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div><div>
<div>On Fri, Jan 3, 2014 at 4:15 AM, Martin Abente<br>
<<a href="mailto:martin.abente.lahaye@gmail.com" target="_blank">martin.abente.lahaye@gmail.com</a>> wrote:<br>
> Hello Sameer,<br>
><br>
> I totally agree we should join efforts for a visualization solution, but,<br>
> personally, my main concern is still a basic one: what are the important<br>
> questions we should be asking? And how can we answer these questions<br>
> reliably? Even though most of us have experience in deployments and their<br>
> needs, we are engineers, not educators, nor decision makers.<br>
><br>
<br>
</div>Agreed. It would be helpful to have a conversation on what the various<br>
constituencies need (different from want) to see at their level. The<br>
child, the parents/guardians, the teacher, the<br>
principal/administrator, and educational bureaucracy. We should also<br>
consider the needs of those of us who have to fundraise by showing<br>
progress of ongoing effort.<br>
<div><br>
> I am sure that most of our collection approaches cover pretty much the<br>
> trivial stuff like: what are they using, when are they using it, how often<br>
> they use it, and all kind of things that derive directly from journal<br>
> metadata. Plus the extra insight that comes when considering different<br>
> demographics<br>
<br>
</div>True. Basic frequency counts such as frequency of use of activities,<br>
usage by time of day, day of week, scope of collaboration are a few<br>
simple one. Comparison of one metric vs the other will need more<br>
thinking. That's where we should talk to the constituents.<br>
<div><br>
><br>
> But, If we could also work together on that (including the trivial<br>
> questions), it will be a good step forward. Once we identify these questions<br>
> and figure out how to answer them, it would be a lot easier to think about<br>
> visualization techniques, etc.<br>
<br>
</div>If the visualization subsystem (underlying tech pieces) are common and<br>
flexible, then we can start with a few basic templates, and make it<br>
extensible, so we can all aggregate, collate, and correlate as needed.<br>
I'll use an example that I'm familiar with. We looked at CouchDB for<br>
two reasons: 1) It allows for sync over intermittent/on-off<br>
connections to the Internet and 2) CouchDB has a "views" feature which<br>
provides selective subsets of the data, and the "reduce" feature does<br>
aggregates. The actual visual is done in Javascript. Here's the<br>
example Leotis had at the OLPC SF summit<br>
(<a href="http://108.171.173.65:8000/" target="_blank">http://108.171.173.65:8000/</a>).<br>
><br>
> What you guys think?<br>
><br>
<br>
A great start for a great year ahead!<br>
<br>
> Saludos,<br>
<br>
cheers,<br>
> tch.<br>
Sameer<br>
_______________________________________________<br></div></div><div>
Sugar-devel mailing list<br>
<a href="mailto:Sugar-devel@lists.sugarlabs.org" target="_blank">Sugar-devel@lists.sugarlabs.org</a><br>
<a href="http://lists.sugarlabs.org/listinfo/sugar-devel" target="_blank">http://lists.sugarlabs.org/listinfo/sugar-devel</a><br>
</div></blockquote></div><br></div>
</blockquote></div><br><br clear="all"><br></div></div>-- <br><div dir="ltr"><div>Onderzoeker<br><a href="tel:%2B31%280%296%2014576494" value="+31614576494" target="_blank">+31(0)6 14576494</a><br><a href="mailto:christophe.gueret@dans.knaw.nl" target="_blank">christophe.gueret@dans.knaw.nl</a><br>
<span style="font-family:arial,helvetica,sans-serif"><div>
<span style="color:rgb(220,36,31)"><br></span></div>
</span><p style="margin:0px;color:rgb(229,59,40)"><span style="font-family:arial,helvetica,sans-serif"><b>Data Archiving and Networked Services (DANS)</b></span></p><span style="font-family:arial,helvetica,sans-serif">
</span><p style="margin:0px"><span style="font-family:arial,helvetica,sans-serif">DANS bevordert duurzame toegang tot digitale onderzoeksgegevens. Kijk op <a href="http://www.dans.knaw.nl" target="_blank"><span style="color:rgb(4,51,255)">www.dans.knaw.nl</span></a> voor meer informatie. DANS is een instituut van KNAW en NWO.</span></p>
<span style="font-family:arial,helvetica,sans-serif">
</span><p style="margin:0px;min-height:12px"><span style="font-family:arial,helvetica,sans-serif"><br></span></p><span style="font-family:arial,helvetica,sans-serif">
</span><p style="margin:0px"><span style="font-family:arial,helvetica,sans-serif">Let op, per 1 januari hebben we een nieuw adres: </span></p><span style="font-family:arial,helvetica,sans-serif">
</span><p style="margin:0px"><span style="font-family:arial,helvetica,sans-serif">DANS | Anna van Saksenlaan 51 | 2593 HW Den Haag | Postbus 93067 | 2509 AB Den Haag | <a href="tel:%2B31%2070%20349%2044%2050" value="+31703494450" target="_blank">+31 70 349 44 50</a> | <a href="mailto:info@dans.kn" target="_blank"><span style="color:rgb(4,51,255)">info@dans.knaw.nl</span></a> | <a><span style="color:rgb(4,51,255)">www.dans.knaw.nl</span></a></span></p>
<span style="font-family:arial,helvetica,sans-serif">
</span><p style="margin:0px;min-height:12px"><span style="font-family:arial,helvetica,sans-serif"><br></span></p></div><span style="font-family:arial,helvetica,sans-serif"><b>Let's build a World Wide Semantic Web!</b><br>
<a href="http://worldwidesemanticweb.org/" target="_blank">http://worldwidesemanticweb.org/</a><br></span><div><span style="font-family:arial,helvetica,sans-serif"><br><b>e-Humanities Group (KNAW)</b><br><a href="http://www.ehumanities.nl/" target="_blank"><img style="max-width:300px;width:auto" src="http://www.ehumanities.nl/beheer/wp-content/uploads/2013/10/eHumanities-Logo-Overlap-497X156-300x94.png" alt="eHumanities" height="62" width="200"></a></span><br>
</div></div>
</div></div></div></div></div></div></div></div></div></div>
<br>_______________________________________________<br>
Sugar-devel mailing list<br>
<a href="mailto:Sugar-devel@lists.sugarlabs.org">Sugar-devel@lists.sugarlabs.org</a><br>
<a href="http://lists.sugarlabs.org/listinfo/sugar-devel" target="_blank">http://lists.sugarlabs.org/listinfo/sugar-devel</a><br>
<br></blockquote></div><br></div>