social-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Social-discuss] The Case for Branching Elgg?


From: László Török
Subject: Re: [Social-discuss] The Case for Branching Elgg?
Date: Tue, 30 Mar 2010 17:46:07 +0200

I've only skimmed Elgg and as Melvin notes, it's design is not exactly state-of-the-art, but it works today, so it might be an option to customize it and stick with it for a while.
We could continuously replace parts we don't like.

All in all, I'm delighted to see other advocates of semantic web technologies like RDF and SPARQL on this list.

Thanks,

L

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?
--
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-----



reply via email to

[Prev in Thread] Current Thread [Next in Thread]