Tag Archives: semanticweb

Tales from the SIOC-o-sphere #7

20080403a.png It’s been three months since my last round-up of all things SIOC-ed, so here is entry number seven in the series:

Previous SIOC-o-sphere articles:

#6 http://sioc-project.org/node/310
#5 http://sioc-project.org/node/294
#4 http://sioc-project.org/node/272
#3 http://sioc-project.org/node/271
#2 http://sioc-project.org/node/138
#1 http://sioc-project.org/node/79

Kingsley remixes my DataPortability slides as "Data Accessibility and Me: Introducing SIOC, FOAF and the Linked Data Web"

Kingsley Idehen told me on IRC that he remixed my presentation on DataPortability and SIOC from yesterday as Data Accessibility and Me: Introducing SIOC, FOAF and the Linked Data Web.

I’ve never had my slides remixed before, I’m honoured! Here’s the new version:

DataPortability, Microsoft's Contacts API and OpenSocial.org

20080326a.png (No, the picture I created on the right ISN’T the new DataPortability logo; I totally missed out on the closing date, but it will serve as an image for this blog post. There have been some very cool submissions for the competition however.)

There were two interesting announcements yesterday in the portability space. The first was from Microsoft, announcing that they would be “working with Facebook, Bebo, Hi5, Tagged and LinkedIn to exchange functionally-similar Contacts APIs, allowing us to create a safe, secure two-way street for users to move their relationships between our respective services” (Contacts APIs provide contact data portability). The second was from Google, Yahoo! and MySpace, jointly announcing that an OpenSocial Foundation is to be formed as a non-profit entity (OpenSocial provides social application portability). Unfortunately, there is still some confusion regarding exactly what data portability functionality OpenSocial will offer (if any), and at the moment the consensus seems to be that DataPortability and OpenSocial aren’t as related as previously thought.

DataPortability (including Microsoft’s move in this area) is mainly about users being able to have portable data (profiles, identities, content like photos, videos, discussion posts) that they can move between the services and sites that they trust and choose to use. (See Uno de Waal’s interesting post on how the Microsoft Invite2Messenger service allows you to get your Facebook friends’ e-mail addresses in plain text.)

OpenSocial on the other hand is more about “gadget” portability, where social applications can be deployed across a variety of social networking sites. As summarised by Julian Bond, OpenSocial consists of a gadget API (for gadget programmers) and a standard for site owners to implement these gadgets on their own sites. The part of OpenSocial related to DataPortability is a REST API, details of which are a bit vague right now. Not to be confused with OpenSocial (although the similar names make this difficult), the Social Graph API from Google is more related to DataPortability as it indexes semantic data from many social networking sites like Hi5, MySpace, LiveJournal, Twitter, etc. and allows users to bring their social graph with them when they sign up for a new site that supports the API.

Apart from the lack of intersection between Microsoft (plus affiliate Facebook) and Google, a good few companies are in multiple “camps” (DataPortability, Contacts APIs, OpenSocial), as shown by the Venn diagram I drew below:


Marc Canter and others have pointed out that although the Contact APIs from Microsoft are not open in themselves, at least the APIs seem to export as much data as they can import. Marc also says that Microsoft (and other big companies) may not be explicitly following the actions (e.g. the technical recommendations) of the DataPortability initiative, but rather claims that it would hurt them if they didn’t open up and go along with some portable data efforts given the current climate and the tide of users in favour of this.

For users to have true data portability, there needs to be some consensus on both the APIs and the formats needed to transfer / represent this portable data. It may be that a number of APIs and formats are required for different scenarios. The Semantic Web is an ideal means for representing the data to be ported from social websites, in that is well suited (using vocabularies like SIOC and FOAF) to represent how people and all kinds of objects on these sites are connected together (documents, discussions, meetups, places, interests, media files – whatever). Of course other data formats may be used, but most importantly, it would be a waste of time to come up with a bunch of new formats for representing the data that needs to be portable, because a lot of work has been done on how to best provide interoperable, reusable and linked data through efforts like the Semantic Web, AtomPub and the microformats community.

I’ll be attending the DataPortability Lunch Meetup in London on the 6th April 2008 if anyone there feels like a chat about some of these topics…

Related posts:

Semantic Web for Dummies

20080220a.jpg I referenced this on the SIOC-Dev mailing list recently, and when I pasted it on the DataPortability.org steering group chat this morning (in parallel with our first phone conference), Drummond Reed suggested I blog it. It’s originally from MIT’s Stefan Marti:

XML customised tags, like:
+ RDF relations, in triples, like:
(Nena) (is_dog_of) (Kimiko/Stefan)
+ Ontologies / hierarchies of concepts, like:
mammal -> canine -> Cotton de Tulear -> Nena
+ Inference rules like:
If (person) (owns) (dog), then (person) (cares_for) (dog)
= Semantic Web!

(Picture by Duncan Hull.)

int.ere.st – create and share tags across your online communities

As mentioned in a previous blog post, int.ere.st has just launched. The main objective of int.ere.st is to demonstrate how Semantic Web and Web 2.0 technologies can be combined to provide better metadata creation and sharing support across various online communities.

With int.ere.st, you can save, tag and bookmark your own as well as other people’s tag clouds, as represented using the SCOT ontology. The tag meta search also allows you to look for similar patterns of tagging from other people based on their interests (as expressed using tags).

Some functionalities of int.ere.st include:

  • Various options for tag searching, such as and (&), or (space), co-occurrence (+), broader (>), and narrower (< )
  • User searching
  • Resource searching
  • Integrating tagged data across communities
  • Meta tagging
  • Ontology bookmarking
  • Sharing metadata produced using the FOAF, SIOC, and SCOT ontologies

You can try it at out at http://int.ere.st/. Here are some video demos of int.ere.st in action, and some more videos are forthcoming:



State of the SIOC-o-sphere (#5)

It’s that random time of the year again where I summarise what’s been going on in the world of SIOC

Testing Yahoo! Pipes

Yes, it’s very cool! RSS fans, prepare to be blown away. Via this Slashdot article and CaptSolo’s post on sioc-dev:

“Yahoo has introduced a new product called Pipes. It seems to be a GUI-based interface for building applications that aggregate RSS feeds and other services, creating Web-based apps from various sources, and publishing those apps. Sounds very cool. TechCrunch has a decent write-up, and Tim O’Reilly is all over it. The site was down for a few hours and is just back up. Has anybody tried this?”

and from the Pipes page:

Pipes is an interactive feed aggregator and manipulator. Using Pipes, you can create feeds that are more powerful, useful and relevant.

So I created a basic pipe to take three feeds from Planet Journals, IrishBlogs.ie and awards.ie about the forthcoming Irish Blog Awards using the “Fetch” module. I then used their “For Each: Annotate” module to add a sioc:topic annotation, using the first matching result from a Yahoo! search for the phrase “Irish Blog Awards”. The graphical interface is very easy to use, and a screenshot of the pipe construction is shown on the left. You can see the pipe output on the right below; unfortunately the RSS 2.0 dump loses the sioc:topic annotation I added, but the JSON dump still retains it so with a bit of manipulation this could provide the appropriate RDF.