Connecting Social Content Services using FOAF, RDF and REST

1
Connecting Social Content Services using FOAF,
RDF and REST

• Leigh Dodds, Engineering Manager, Ingenta
• Amsterdam, May 2005

2
Introduction

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

3
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.

4
Social Content Service Examples

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

5
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

6
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

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

8
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)

9
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

10
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)

11
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

12
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

13
RESTRDF

• RESTRDF 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 (rdfsseeAlso) to link
  resources
• Also easy to aggregate and extensible

14
RESTRDF

• 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...

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

16
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

17
Top Ten Artists Example Stage 2

• Introduce FOAF support into the application
• Instead of asking the user, let them register
  their FOAF profile
• Dont ask, discover they have an Audioscrobbler
  account

18
Top Ten Artists Example Stage 2

• ltfoafPersongt
• ltfoafholdsAccountgt
• ltfoafOnlineAccountgt
• ltfoafaccountNamegtldoddslt/foafaccountNamegt
• ltfoafaccountServiceHomepage
  rdfresource"http//audioscrobbler.com"/gt
• lt/foafOnlineAccountgt
• lt/foafholdsAccountgt
• lt/foafPersongt

19
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

20
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

21
Top Ten Artists Example Stage 3

• ltfoafPersongt
• ltegfavouriteArtistsgt
• ltegTopTenArtists rdfresource"http//audios
  crobbler.com/p/ldodds/top-ten"/gt
• lt/egfavouriteArtistsgt
• lt/foafPersongt
• As new data sources come online, your application
  will automatically support them
• In effect become data source agnostic
• Ignore trust issues for now!

22
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
• RESTRDF fit together very well
• Adopting RDF allows for ad hoc service
  integration, and a focus on data not mechanics