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

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

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 ldodds

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