Connecting Social Content Services using FOAF, RDF and REST

Leigh Dodds, Engineering Manager, IngentaAmsterdam, May 2005

Introduction

• Social Content Services• REST• A Web Service Review• Recommendations and Observations• RDF and REST

What is a Social Content Service?

A service whose primary goal is to allow users to contribute and freely share data,

A secondary goal of such services is to enable users to connect themselves to communities of interest either by direction participation, or

indirectly as a side effect of data sharing.

Social Content Service Examples

• 43Things• Audioscrobbler/last.FM• WebJay• MusicBrainz• del.icio.us• Flickr• Upcoming

What is REST?

• Representational State Transfer

REST is defined by four interface constraints: identification of resources; manipulation of

resources through representations; self-descriptive messages; and, hypermedia as the

engine of application state.-- Fielding, Section 5.1.5

Conducting A Web Service Review

• Compare a number of Social Content Sites– How RESTful are they?– What features do they have in common?

• Highlight common practices– Capitalize on existing experiences– Identify potential problem areas

• Help foster a community of practice– Scruffy antidote to other specification leaden initiatives

The Review Criteria

• How does the API use URLs to identify resources?• What HTTP methods does the API support?• What status codes are returned?• How are users and applications authenticated to the

API?• Are resources linked to one another (use of

hypermedia)?• What data formats does the API support?• How much user data is exposed?• What are the licencing agreements for the API and

the data?

Review Summary

• Most RESTful to some extent, no true REST interfaces

• GET/POST most common HTTP methods• Generally poor use of correct HTTP status codes• Little or no hyperlinking• Mixture of authentication methods

– Plain text, HTTP Basic Auth, Atom X-WSSE

• Not all data is clearly licenced– OpenContent (MusicBrainz); CreativeCommons (Flickr)

Usage Tracking

• API Keys– Typically unique hash value added to request URL to identify

originating application– Developer applies for a key for their use of the open API

• Used to track use and abuse

• Harmful: limits linking to a service• Harmful: limits ad hoc service integration

Alternatives to API Keys

• The origin of a request is request metadata…• …and request metadata belongs in HTTP

headers…• …so, use User-Agent to identify origin

• But: User-Agent is unstructured• Therefore consider using a new HTTP request

header• Description of a Project (DOAP)

Data Formats

• Most using XML, some RDF support– XML typically attribute-oriented– Little/no use of namespaces

• No standardisation in vocabularies• But there are common data elements:• People

– Name, email, homepage and/or 'blog url; picture

• Contacts/Friends• Groups

– Name, homepage, members

FOAF

• “Friend of a Friend” Project• RDF vocabulary for expressing metadata about

people, their interests, relationships and activities

• General framework for connecting specialised vocabulary

• Key elements: People, Groups, Images (plus Projects, Organization, etc)

• Excellent candidate for standardising social content service metadata

REST+RDF

• REST+RDF fit together very well• RDF identifies resource and vocabularies using

URIs• …has an XML syntax for document exchange• …RDF Schema + Ontologies describe messages• …supports hyperlinking (rdfs:seeAlso) to link

resources• Also easy to aggregate and extensible

REST+RDF

• Shift emphasis of integration from API mechanics to data model and formats

• REST defines a uniform interface• RDF defines a uniform data model• Focus on vocabulary development and data

mining

• An illustration...

Top Ten Artists Example: Use Case

• Online Music Sales– how do we personalise the application to recommend additional

artists, increase purchases, etc?

• Assume Audioscrobbler starts exposing its users Top Ten Artists

• How do you collect that information?– E.g. to recommend additional artists, purchases, etc.

• What happens when MusicBrainz exposes similar data?– I.e. how does the solution evolve?

Top Ten Artists Example: Stage 1

• Aka “The Web Service Mash-Up”• Implement a custom client for Audioscrobbler• Ask the user for their profile details, fetch the

data• As other data sources sites come online we must

– Implement new custom clients to for each API– Ask users to submit additional details

• Additional development work, and user interactions for each data source

Top Ten Artists Example: Stage 2

• Introduce FOAF support into the application• Instead of asking the user, let them register their

FOAF profile– Don’t ask, discover they have an Audioscrobbler account

Top Ten Artists Example: Stage 2

<foaf:Person>

<foaf:holdsAccount>

<foaf:OnlineAccount>

<foaf:accountName>ldodds</foaf:accountName>

<foaf:accountServiceHomepage rdf:resource="http://audioscrobbler.com"/>

</foaf:OnlineAccount>

</foaf:holdsAccount>

</foaf:Person>

Top Ten Artists Example: Stage 2

• Benefit from using FOAF data– Revisit profiles as new clients are implemented to discover new data

sources

• But still have to implement custom clients for each new service– Reduced interactions with user but not development overheads

Top Ten Artists Example: Stage 3

• Introduce new RDF vocabulary for capturing music metadata– Use RDF to model details of Top Ten favourite artists– Use URLs in RDF data to identify and then retrieve new data

• No longer need to implement custom clients for each new service– Everything you need to know is in the data

Top Ten Artists Example: Stage 3

<foaf:Person>

<eg:favouriteArtists>

<eg:TopTenArtists rdf:resource="http://audioscrobbler.com/p/ldodds/top-ten"/>

</eg:favouriteArtists>

</foaf:Person>

• As new data sources come online, your application will automatically support them

• In effect become data source agnostic– Ignore trust issues for now!

Summary

• Web Service Review identified areas for greater co-ordination and standardisation

• Important initial target areas for investigation are usage tracking, data formats, licensing

• FOAF is a good candidate as a basis for standardising personal metadata

• REST+RDF fit together very well• Adopting RDF allows for ad hoc service

integration, and a focus on data not mechanics