On 5. März 2010 04:18, cal
<address@hidden> 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,
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.in should
> embrace a Web Scale Architecture compatible with Linked Datafrom the start ),
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.html1. 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-----