On 5. März 2010 04:18, cal <[email protected]> wrote: > > Looks pretty cool. I think it's also worth looking at http://elgg.org/which > > is getting quite mature has qutie a bit of functionality, the RESTful API > makes > > it extensible, and they have plugins for things like realtime chat, > > hi, > > we are working with several elgg instances [0], and with a roadmap to > federate > activity streams among them. we have pulished openID support, and have > enabled > a javascript xmpp client based on strophe. >
Very nice! > We have ongoing tasks about enabling openmicrobloggin support for statusnet > compatibility (and maybe extend it to other kind of notifications), and > forwarding media > hosting to a tahoe [1] grid. > > Other experiments we are doing are encrypted mailing list integration, and > an experimental > psyc and xmpp pubsub backend for notifications. > > It is also pending to enhance the current semantic publishing of data: the > foaf export > is minimal, and sioc would be also desirable to start with some fancy > inferences. > It's great that elgg does FOAF export via autodiscovery, but their format could use a bit of tweaking. However, FOAF really needs the user to be able to edit it, for it to become truly valuable. This is the concept of user choice (free as in freedom) which allows you to maintain your profile the way you want it. Currently all Soc Nets lock you in to their paradigm, their data model, so interoperability is a struggle. The tools here will evolve relatively quickly since Update is part of the SPARQL 1.1, ability to update your FOAF should become the norm, rather than the exception. > > i'm not a fan of php, but it is pretty easy to get up running with elgg. > The > plugin-based api make it quick to choose and install your components. > > > but I'm not > > sure you want to be locked in to their paradigm ( I think dasiycha.inshould > > embrace a Web Scale Architecture compatible with Linked Datafrom the > start ), > > Can you develop a little more about this kind of architecture? (although I > guess > you have in mind something like this graph [2] ) > We had a telecon with TimBL this week and he went into some details. One thing he said is that APIs are not the best way of sharing data. The best way of sharing data is simply to mark it up as data and let the consumer of that data decide what they want to do with it. This is very well expressed by the four rules of linked data: http://www.w3.org/DesignIssues/LinkedData.html 1. Use URIs as names for things 2. Use HTTP URIs so that people can look up those names. 3. When someone looks up a URI, provide useful information, using the standards (RDF, SPARQL) 4. Include links to other URIs. so that they can discover more things. It's as simple as that. If you want to build something that scales like the web, just follow those 4 rules. The unspoken corollary is that if you dont follow all those rules, you probably wont scale with the web. > > I often find myself locked into the dilemma of chosing between delivering > (nearly-) > working applications for social collectives I work with -doing it quick > with frameworks > everybody can work with-, or keeping with investigations and proofs of > concept. > Agree. > > we have been collecting some ideas and state of the art [2] in the > search for secure, distributed and semantic social networking software, > perhaps > a bit biased towards python-based stuff, and something I realised in the > process > is that semweb tools are very mature, but indeed require some time to get > started with (maybe only that a little shift of paradigm is still needed, > but > most people I try to explain rdf goodies end by considering it "too > complex" > after a while, or just "inefficient" for some purposes). > It takes a while to understand, but when you do you realise how fundamentally simple it all is. I think it's a slight weakness in the sem web community in that it's often made to look more complex than it really is. Conceptually it's about making data like global variables, and letting them link. As TimBL said on the call, in some programming languages when you make variables global, they fall apart, in others like HTML, when you make the variables global, you get the web. > > My personal view is that triplestores are still a bit tricky for being > widely > adopted (i.e., heavy, or poorly packaged or documented), and maybe what is > needed > is more software that abstracts from the ontology internals and allow to > use it > comfortably from a web application framework, or event a desktop client. > > It's not a trivial task, but having a mapper that translates ontologies to > your native > type of object, and able to build optimised sparql queries, could make > semweb development > as easy as changing your relational backend for a triplestore. > This is a tricky problem, but there's tools to map relational databases to triples. I think the internal backend is your choice Relational, file, Sqlite, etc. However, the interoperability should be in the form of triples, so this means linking to a editable FOAF files (elgg does this already) or marking things up in RDFa. You may want to have a small triple store augmenting a relational DB. You can be brave and go for a scalable triplestore like 4store, but that may be too great a paradigm shift for many, to start with. > > Or maybe is not a problem at all to assume duplication and expose a > triplified version of your tables. But I like the fact that access control > can > be somehow embedded into your data. > Access Control is probably the trickiest problem on the web right now. No one has really done it right, but there's a few options. Hopefully something that can be explored as things progress. It's important for any GNU project to be seen as trusted. I'm actively looking into this area and am happy to help, donate PHP code under AGPL etc. > > > it's certainly a project worth learning from and perhaps it would be > > advantageous to set up a liaison to crabgrass and elgg. > > yep, I agree. If we find a not-too-complex and generic enough protocol for > representing > and consulting our "social aggregation stack" (identity, presence, > relationships, groups, > conversations/media), there shouldn't be any problem in interconnecting > instances > of different written of different languages/frameworks (there is also > pinax, for the > python lovers :p) > Sounds good. Would love to see a python client, there's gwibber already of course. > > [0] http://lorea.cc (mostly spanish, sorry). > [1] http://allmydata.org/trac/tahoe-lafs > [2] http://melvincarvalho.com/blog/architecture-of-web-30/ > [3] http://rhizomatik.net > > -- > e pur si muove... > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (GNU/Linux) > > iQIcBAEBCAAGBQJLkHgIAAoJECs+mdOp6Wb2cHAP/2BLh8n6ju9RQYhVVuaV6VeZ > 5p+KXfKW9JetoR66t7aMNq/xoECQNDZEkNmeWxxuRy/uJQxXdIogy5QqJW1etjvF > bKHIREgsax8pt8mXJmKYvQ4m1rvyYZbOlIYpkJIzYxgas7D4FoiKRspUdpMJOgOG > RP2sFEbyfmTKBdcuhOi8doRXySDopePQG760ph1nT7i3sT2s0WgkiLwoPh/5GVvh > P6Qt4LDjFP8Ff0RpVQvBZajkYu2syVmvo8fVYz5AWftu/tMgqW/0bUGJHEIeETFI > a4hKOj8SBj+SKiYb+Gp4V1x72zK1HKDuVHYfmCBYPkoZ3pYBXKvtjxQnS2bK/IzH > yrVS1bfmFB5Q7HmrZLfVXIoMP+zHHZ0Q8c9/9jIzD30v5srlk9xjDWP5j8JllYHW > hlnJvhJMkMyxYCQIBEiXcU3f46Hbvc7iGUWhZtWl+Uq4ZUyB5xXuTD+INwXiKFZD > LWhHQrxfDcPEMPX4MvXUT6so7nqd0Ikg/t+hojeNZOHEjFTuS08DfAA3AMFjjxhl > KycwnpRkHuo/0bkgELeAH9FIsnu34HvvpgnmXuZ/65bxJYr6cipVzrzkkiPEwZRW > MxryoQzbFklfGXkflnUuTP1eg/LDgn/1Hc5JBg9ovhr0w/DiNPQ0PBDS+WiBssXe > f/JkfTKtmg+J+4lkmdB8 > =0De2 > -----END PGP SIGNATURE----- > >
