Design criteria
 Joe Corneli |
In earlier threads about Design ideas and Building a Prototype and elsewhere, we have discussed a lot of different thoughts. But I think we should collect our thoughts into one coherent place and flesh out what it means to "be an FTG prototype". We can then submit this as a proposal to the Knight Foundation. One useful reference is Fabrizio's wireframe, http:/ Let's try to add some more pictures, ideas, and clear requirements in this thread. |
|
Joe Corneli |
In order to make our discussion more fluid, let's combine our ideas in this pad:
|
|
Wouter Tebbens |
Hi there! I'm back. Being ill for a week has given me some time to think as well. The most important thing I thought of was the protocols. We have envisioned a platform for FTG that imports or synchs with external info and metadata, as users have their projects and profiles already on many other systems and platforms. So our system should be able to obtain that info. What protocols we haven't discussed much about IIRC. Distributed social networks highlight a few protocols we c/should take into account: FOAF, XMPP and OStatus as the most relevant I think. XMPP is the Extensible Messaging and Presence Protocol that we know from Jabber. The FTA Campus implements it through the OpenFire framework. We have it but didn't use it, basically as we wanted to implement it through a webinterface right here, and the way we had that was through Flash, which would force people to use proprietary tools. So that was not the way forward. But XMPP is here, and can be included at any point in our platform. We can just connect to it with a client, like Pidgin. OStatus is an open standard for distributed status updates that references a suite of open protocols including Atom, Activity Streams, PubSubHubbub, Salmon, Webfinger, that allows different messaging hubs to route status updates between users in near real-time. OStatus federation was first possible between StatusNet installations. Identi.ca is the first instance of StatusNet. Most interesting: FOAF: Friend of a friend, is a machine-readable ontology describing persons, their activities and their relations to other people and objects. Add SSL: FOAF+SSL makes for a secure web of trust, and is also called WebID. Lorea/N-1 is one of the bigger distributed social networks and has experimental support for FOAF+SSL. Lorea is basically an extension of Elgg, so we should be able to incorporate this into the current or next Elgg platform for the FTA. Interesting might also be to include the FTA as a node into the bigger Lorea/N-1 network. That way we could grow more easily and include / collaborate with their developers more easily. (see sys admin manual in Spanish) How would we implement FOAF+SSL and what can we do with it? See DataSources for FOAF providers. I'll try out this on: FOAF.me Any thoughts on this? |
|
Wouter Tebbens |
Hi Joe,yes that sounds sensible: adding additional ontologies to FOAF, related to task tracking, and I would add: experience, interests. Yesterday I stumbled upon people who did something like that, but for the relations between people: the poderopedia ontology, see this article. There they mentioned also an ontology on biographic data, but that seems to be mostly genealogic. Maybe we could find people who already designed and developed on ontology for the context of curricula/resume kind of data and we can add to that? Well, Google is still some kind of a friend, and pointed me to this: W3C proposal for FOAF extension to include resume info. Also the ResumeRDF Ontology Specification seems to be of interest. Joe, can you point me to what you implemented in planetary wrt ontologies? best, Wouter |
|
Joe Corneli |
Right now the Planetary ontology feature is mostly just a proof of concept; we use a new SKOS representation of mathematics subject classifications to provide a subject index to the content: http:/ And links back to the corresponding subject classification from individual articles, e.g. at the bottom of http:/ The actual code is here, if you want to take a look at the sorts of SPARQL queries needed to implement this. https:/ |
|
Joe Corneli |
Great summary! Soon let's complement it with a diagram. For implementation specifics maybe we should cross-correlate with the Github API (as a place to start). http:/ Here's another example of the sort of feed we might pull from (StatusNet's repo on Gitorious): http:/ It can also inspire us about the sorts of feeds we would produce. Without being too formal, let's think more about the terms that will show up in these feeds, and how to respond to them. In particular, I'm thinking about payments - at least sometimes, we would want those to be publicly documented (A transferred 200€ to B's account). Some additional inspiration: http:/ http:/ http:/ http:/ This all starts to get fairly technical (which I think is a good sign!). |
|
Joe Corneli |
Hi Group: Thanks for participating in the etherpad! I've condensed our work there into the document posted here: http:/ ... and I also supplied some "discussion questions". When we've sufficiently answered those (1 week?), we'll be ready to share this with potential partners for further feedback (1 week) and then make final revisions (1 week) -- so that we'll be ready to submit it in about 3 weeks. In terms of the timeline for work: I would suggest we propose a start-date of Jan 1 2013, when I'll have sufficient free time to contribute in a technical capacity. And, in terms of resources, while I'm in Brooklyn (about 2 more weeks), I will investigate http:/ Personally I would not have a problem relocating to NY to work on this stuff... Fabrizio, I wonder if you'd be interested in moving over here for a while to work on it as well? (@Wouter, I'm assuming that's not possible in your case!) Joe |
|
Fabrizio Terzi |
Fabry |
|
Joe Corneli |
Let's write some individual notes to people in these organizations, announcing our intentions, and asking them about how we can collaborate. This will help us revise our Knight proposal.
I'll start working on this on http:/
|