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