clauwa.info

oEmbed is a format which allows to embed the representation of a resource on a third party site without needing to parse it. Therefore a Provider implements the oEmbed API and allows a Consumer to fetch the representation of a resource and embed it directly on the Consumer’s site.

The advantage of oEmbed is that the Consumer only needs to make one HTTP GET request with the URI of the resource to embed (and optionally the maxwidth, the maxheight and the desired format) as parameter, in order to get the representation of a resource which the Consumer can directly display.

But if we look for example at the  flickrcurl library created by Dave Becket, we see that for each photo stored on flickr an rdf representation can be created easily. That means that the Provider (flickr) does not need to support the oEmbed API. It is enough (or even better) if the Provider exposes its resources in RDF and makes them accessible for Consumers.

Why is it better if a Provider allows third party sites to embed its resources via querying an RDF graph than via querying an oEmbed API?

In the case of an oEmbed API a Consumer can only access one resource at time and he needs to know the identifier of the resource he wants to embed. In the case that an application exposes its resources as RDF graph, the Consumer can perform more complex queries, such as give me all representations of resources which have certain properties (e.g. are from type foaf:Image and are depicting a special foaf:Person).

So all in all oEmbed is nice for the Social Web, but becomes useless in the Social Semantic Web.