1 / 22

Connecting Social Content Services using FOAF, RDF and REST

Connecting Social Content Services using FOAF, RDF and REST . Leigh Dodds, Engineering Manager, Ingenta Amsterdam, May 2005. Introduction. Social Content Services REST A Web Service Review Recommendations and Observations RDF and REST. What is a Social Content Service?.

tait
Download Presentation

Connecting Social Content Services using FOAF, RDF and REST

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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 • Don’t ask, discover they have an Audioscrobbler account

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

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

  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

More Related