Those of you who are in the Oxford area (and are interested) are welcome to come along!

Elgg 1.0 provides a number of ways at getting at your data, including a number of natively supported data formats; including OpenDD (of course), JSON, PHP, and of course RSS.

If you’re putting together a mashup, you can use these views very simply. You may have noticed when you’re looking at a page with a list of items on it, that there are buttons in the top left which link to either a RSS or an OpenDD view.

Now when you click on one of those you’ll see your data presented in an entirely different way. Now one of the fun things you can do is change that by altering the “view” parameter, for example “view=json” to get a JSON view.

You can export individual items of data (that you have access to) in different ways by visiting the “export” url. For example, to export GUID 1 (which will almost certainly be the first site you set up) visit:

http://mysite.com/export/opendd/1/

Of course, if you replace “opendd” with “json” or “php” you can see this data presented in an entirely different way. Additionally, you can also add support for other formats, as I discussed in a previous article.

On top of that, there is an API system where plugin writers can export a function as public. These functions can then be called via a rest-like api (discussed in more detail here).

You can then select how you want to then see that data - whether its PHP, XML or JSON etc.

So, in a nutshell, Elgg has some quite powerful tools for quickly and easily creating some pretty funky mashups. Have fun!

It’s been a lot of work and a long day, but I’m pleased to announce that Elgg 1.0 has officially been released!

Go download, while I crack open the beer!

A lot of these things I and my colleagues have covered before in previous blog posts, but I thought I’d give a brief summary of just a few of them.

First of all, this is possibly one of the best looking versions of Elgg ever. A lot of this is due to the efforts of our resident design guru Pete Harris, who has done a fantastic job in making the graphics and the user experience top notch.

There has also been a lot of work done under the hood…

There’s the views system which easily lets you skin Elgg and completely change its look and feel. For example we have the default view, which is the one you see when you log into a site (and can be extended and changed by installed plugins). This could just as easily be a mobile view for display on mobile devices.

We have provided RSS and OpenDD views which you’ll see links for if you look a list of objects.

There’s the database schema which we have mentioned before. We have taken a very abstract view, so now everything is an entity with metadata and relationships between them… those of you familiar with the OpenDD schema will notice some familiarity. This is not an accident.

There is also the concept in Elgg 1 that pretty much everything is a plugin, and therefore we have made plugins stupidly easy to write. A lot of the stuff that every plugin has to do is taken care of by the framework. There are ways to list objects, a notification system, XML-RPC, import/export out of the box, a robust internationalisation system, API and even views designed for data import (which have protection against various forms of attack).

In Elgg there are a whole bunch of things that all come together and mean that plugin writers only need to worry about the thing their plugin needs to do.

There is a comprehensive admin panel which plugins can extend. Plugins can be individually enabled and disabled, and can have administrator and user configurable settings. There’s a framework for displaying widgets on pages which plugins can hook into.

As well as all the framework stuff that make development easier, the actual system is pretty fully featured. You have blogs, forums, messaging, bookmaking, a river of events (which again plugins can easily hook into), and an admin system log.

All this stuff and more come together to make a very easy to use and full featured social networking platform.

Give it a try!

If you’ve got a moment please go vote for Elgg!

If you’re a less technical user, we’d like to invite you to come into our test community. This is now open for registration, so all you need to do is visit test.elgg.org and sign up for an account. We’d love to hear your feedback, and you’ll find an Elgg Feedback group there for the purpose. (Please note that we’ll be blanking the database from time to time.)

If you’re a developer, we’re pleased to announce that our source code repository is now public. Point your Subversion client at the following repositories:

* Core Elgg: https://code.elgg.org/elgg/
* Elgg plugins: https://code.elgg.org/extensions/

Please note that this is not an end user release, and development is still ongoing. The intention is to bring developers in to help us test the platform.

Come in and join the fun!

I’m going to talk a little bit about how this works. Firstly, Export.

Export works via the views system, and involves creating a brand new view hierarchy for your new format.

We first need to create a plugin, and in this plugin we create a “views” directory. We need to then create a new directory for your format, and then create a couple of views underneath.

The image to the left shows the necessary file hierarchy that you need to create - in this instance to export “myformat”.

Create a directory called “export”. In this directory place the three php files - entity.php, metadata.php and relationship.php - which handle entities, metadata (and annotations) and relationships respectively.

Each of these files are passed objects via $vars. Depending on which file you are in, this might be $vars['entity'], $vars['metadata'] or $vars['relationship'].

It is then up to you to encode and output the object according to your format.

All that remains is to provide the pageshell which handles how the overall page is displayed. This file may set the content-type header or provide wrapping tags (e.g. for XML output).

pageshell.php is passed $vars['body'] containing the output of your other files.

Providing a handler to deal with importing data is also fairly simple, and works through the action interface.

In your plugin’s init function register the action “import/YOURFORMAT”, and point it to your actions/import/myformat.php, e.g.

<?php

	function myformatplugin_init()
	{
		global $CONFIG;

		// Register import action
		register_action('import/myformat', false,
		  $CONFIG->pluginspath . "myformatplugin_init/actions/import/myformat.php");
	}

	// Initialise
	register_elgg_event_handler('init','system','myformatplugin_init');
?>

This will then register an import action which will be picked up by the administrator import export utility. Your action can access the information it needs to import with the call:

$data = get_input('data');

Elgg 1.0 will ship with native support for OpenDD (both import and export) which will allow administrators to migrate between Elgg classic and the new codebase with a minimum amount of effort.

Elgg 1.0 also offers export views in JSON and PHP native, making it easier to reference the data directly and create mashups.

Over time we will be adding more import and export functionality, and I hope you will be too!

There are technologies around that are all working on bits of the puzzle; OpenID, OAuth etc. I think OpenDD solves a key part of the problem by providing a way to link between and move arbitrary data about in a generic and easily understandable way.

In my last post I illustrated the syndication usecase for OpenDD; how you can subscribe to a feed for a user and get a list of their activity in the form of a river. One important thing that I forgot to mention of course is there is absolutely no reason why you couldn’t use the same technique to subscribe to and receive updates about any resource.

Another powerful use case for OpenDD is its use in a live push context, and that is what I’m going to write a bit about today. Now we have already touched on the fact that OpenDD components are all atomic; they do not require a great deal of context or state around them, so for example if you establish a relationship between two entities you do not need to include the complete description of the entities in question - just the relationship.

In the latest specifications I have introduced the concept of being able to unset and remove things, so as well as creating a relationship it is also possible to remove it. This turns OpenDD into quite a powerful tool in your arsenal.

If you take Elgg as an example, Elgg has an events system which we have touched on in previous articles and as well as providing a syndication of an events log in the form of a river, we can also look at pushing those events as they happen out to interesting parties as a sequence of OpenDD components.

So, for example, you could request to be notified when a user joins a group or when something changes on a file (or indeed any other resource) and this can then be pushed out to you in a way that is simple to understand - and again, because we have the concept of an UUID, it isn’t necessary to have the complete context in order for the message to be useful. Everything else can be worked out.

So, using OpenDD, it is now possible to subscribe to users and resources on different networks and receive a feed of updates, but it is also now possible to push messages between networks in an open way that is understood by both platforms.

One of the cool things you can do with that is for example Sharing. In one network you could create a resource, for example a photo of you at a party or a URL you were interested in. Then you could select between the friends on the network you are in but also from friends elsewhere to share the resource with.

The user on the foreign network would then receive an OpenDD push update message saying that you have created a resource and have shared it with them (or rather the platform would receive and interpret it), and because users and the resource are all addressed by UUID the user would be able to see this seamlessly on their own network.

This feature - made popular by the facebook “mini-feed” - has become one of the things that users expect from any platform they use and is rather compelling.

What if you want to see what they have been doing on other networks? Would it not be a pretty neat thing to be able to subscribe to their activity in order to receive updates about what they have been up to in a similar way as you would be able to subscribe to their blog via RSS?

This turns out to be a simple yet powerful use case for OpenDD, and this is how we’re doing it in the new version of Elgg.

I talked a bit about how the river was implemented in Elgg 1.0 in previous articles. In a nutshell we have a system log which stores events as they happen in terms of a simple relationship, e.g. “User X CREATED BlogPost”, “User X UPDATED profile”, etc.

Once you have that information it becomes very easy to mine that for extra information and turn it into a River event. Essentially, a plugin would create a view on the specific event and entity and then be able to render it as a river item and provide new views on existing data.

If you remember, I also talked about how I changed the river code to use this thing called ElggRiverStatement, which lets you construct the river in a much more linguistic way and also provides all the information needed by the river views.

Creating a “Friends activity elsewhere” syndication view becomes quite easy. Essentially, all you need to do is export the system log for a user, which you can do very easily using OpenDD as a sequence of OpenDD Relationships. This is because “User X CREATED BlogPost” can be thought of in terms of a relationship.

Once this is done, an aggregation client can retrieve the feeds of all the friends that you’ve signed up to and then sort the relationships by published data, and then - because everything has a UUID - you can then drill down and pull the extra information required - details about the user who initiated the action, the object the event was performed on, metadata etc.

This essentially means you can construct a succession of ElggRiverStatement objects out of an OpenDD feed. This is quite cool, because it means you can take those objects and inject them into the already existing river views and get a river entry back. This means that for absolutely zero extra work, every plugin has the ability to render a “Friend elsewhere” event… and it becomes seamless!

Additionally, you can look to digging further and getting extra information about the entities involved and actually be able to see the entity in question - whether by linking to the entity elsewhere or using the information you have about it to render it locally.

This is quite a simple example, but it shows some of the power of OpenDD. Additionally, I should point out that since OpenDD is atomic, you don’t ever have to get all the information in one go!

In a nutshell, the river generation function now passes a variable called "statement" to your river views instead of passing the object, event etc as separate values. "statement" is a class called ElggRiverStatement.

Loosely speaking all river items are in the form of “X does something to Y”, where X is usually a user and Y is either an entity or another statement. I borrowed a bit from linguistics, and X is called the Subject and Y is the Object.

Subject, as I said, is the user, so this is easy. The ElggRiverStatement will provide you with a fully created user entity.

The statement “does something to” translates to the event in the system which you will be used to if you’ve implemented plugins for Elgg 1.0 already… so that’s “create”, “update”, etc.

Object will either by an ElggEntity in the case of simple statements like “User X updated their Profile”, or an array which represents compound statements.

What do I mean by compound statements? Well, take the following for example:

“User X is now friends with User Y”

As far as the system is concerned, what you are actually saying is:

“User X created a new friend relationship between User X and User Y”

In terms of language, User X is the Subject and “a new friend relationship between User X and User Y” (yes, the whole thing) is the Object (and yes, before someone jumps in I am aware this is highly simplified!).

I use the terms Subject and Object again in the array, so to take the above example our array would look something like this:

Array (
    "subject" => User X (ElggUser object),
    "relationship" => "friend",
    "object" => User Y (ElggUser object again)
)

If you take the example of adding some metadata (writing a note on a file for example), you’ve got another compound query. You are making the statement:

“User X has created some metadata which relates to File Y”

In this instance “some metadata which relates to File Y” is our Object, and the array returned would look something like this:

Array (
    "subject" => Metadata object,
    "object" => File Y
)

In summary then, the ElggRiverStatement provides a pretty flexible way of representing diverse river statements with a common interface. The entities referenced are provided in full to your view so that you do not have to load them yourself.

Although this is a small change under the hood it makes it possible to do some other cool stuff (which I will discuss a little bit later).