Friday, June 08, 2012

Linked Data Basic Profile Distilled

Here are key practices we need to follow according to the Linked Data Basic Profile 1.0.

Use standard HTTP methods for touching resources.
As well as SPARQL, a resource server should provide HTTP methods of POST or PUT, DELETE, PUT or PATCH, and GET for creating, deleting, updating, and fetching resources. For update-collision tolerance, clients should use HTTP If-Match and ETags for updating resources (with PUT or PATCH).

Use RDF/XML for representing any resource indicated by and requested through a URI.

To be continued.

Tuesday, April 17, 2012

Essence of Linked Data Basic Profile

In April, the "Linked Data Basic Profile 1.0" was published as a W3C member submission, lead by IBM Rational but involving other vendors such as Oracle and RedHat as well as SemanticWeb.com. It specifies practical rules that clarify or extend Tim Berners-Lee's basic rules (Use URIs as names for things, provided with info in RDF* or through SPARQL accessible through HTTP for the URIs. Also, these info should include other URIs to discover more.)

The specification try to answer the rest of things practically inevitable to provide better Linked Data. The questions answered are:
  • How do we create a resource, or what do we POST to?
  • Where can we get the list of existing resources?
  • Which vocabulary and media types do we use?
  • How do we split the information into pages when it gets big?
  • How do we specify ordering?
For that, the set of rules focus on the following concepts:
  • Basic Profile Resources (BPR) - HTTP and RDF techniques to use to read/write liked data
  • Basic Profile Containers (BPC) - a BPR for POST to create new things and GET to find existing
  • Paging - a mechanism to get the content of a BPC in chunks
  • Ordering - a mechanism to specify the order of a sorted BPC

For more information, a developerWorks article and a paper and its presentation at WWW 2012 workshop on Linked Data on the Web (LDOW 2012) help to understand the motivation behind the spec. Also, there is a collection of use cases and requirements on which the spec was built.