2010/3/30 cal
<address@hidden>
On 15:29, Tue 30 Mar 10, Pablo Martin wrote:
> * rdf: i dont see any support (other than foaf), but should be easy to build a
> full rdf view(rdf views for all entities) based on the generic object model (as
> long as you can keep it arbitrary).
that would be the quick way, and we could have a pretty decent export for most of the objects (views for raw RDF, RDFa embedded on templates...). We could agree on the ontologies for objects / actions beforehand.
>> 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.
having a closer look at ARC2, it could be an option to tweak the entities system
that elgg uses so it can be exposed (and updated) using SPARQL. The API on the
surface could remain the same, so we can keep using nice plugins :)
Thoughts?
Makes sense, but you probably want to tackle the problem at the source. elgg already has what it calls global identifiers for al its entities, but they are global within a silo. To make things federated, make those values into URIs and you're well on your way to a distributed system. My friends list could then be distributed over several silos, and we can replace the internal message structures using the REST API. A little sprinkling of ARC2 and RDFa will help with the view, but I think let's start with the RDBMS and add some SPARQL here and there, as appropriate (perhaps use case driven) over time.
--
e pur si muove...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iQIcBAEBCAAGBQJLshJUAAoJECs+mdOp6Wb2fjkP/jHa2DJGjQ6MBmL2ZH/i4f6W
vdFzdekx981aVCIkFnU5crQxj5cKuA5REGCsqnEMeevD0YPp9WbQ2T5S/pmKVmQl
7ayVLfR7naMKm5OL0TLxba7JN1DV8L6LEmOEQdAS0RAWc5CHEpejDvAW+UKfX1W2
cThRLHBk5ZmL/vrNOSvt40kqeXRgPlNXeBFTGzuEwMyu/MpojgBPL6ZNUlweLqNi
je9qnJUZMLZ/TKtXkBN8sNiJohqhoNhqPcwOuzRGybVH/azIeQJ12E9Ee3xIHpo8
A7lYQ8YsXFk63pG1Js6efjzNsq2RJ0gUT/gYMr9J7uPSDoP809tkSUdMiWvDVbqC
FN4hqJLhhpEf4l5z4+fMipjsAdbLmf6xlPk5//DAJ4M8YNY5sHY1QWaa2X158lkm
e8E2qejReN0dNNSbbzNPlolw69Td4xqHXV0kfMnD4eluXMo0Eh6K3lSeyiGsfEWW
IfCx+K64MgLa7Yas1zz/yzKF/eE7iZxdfJmdkXCKKG+/ieGNU1KpZHyx5Tby22hE
KQjRHUR3Smaq+v+Aq8ny//Ze85Pc3JwIFrVR9JePI//XDYyYPwkiqhdsFeGarWOc
QNRypLn63v1mH5Z5nCg3igKgobg+qPFUfxCdt5EKL2k8TfWqnu5esK2Yn0lIrRmy
nfjsSJ2k/T1z1DYp3xsi
=RT68
-----END PGP SIGNATURE-----