W3C Linked Data Platform WG 2nd Face to Face meeting March 13-15 Boston

I just returned from the 2nd face to face meeting for the W3C Linked Data Platform (LDP) working group located at MIT in Cambridge, MA. There were about 14 attendees in all, a good number but perhaps low for a WG that has 50 total registered. Being the 2nd face to face meeting of a relatively new working group, meant this was the first meeting where we could dig in our heals and start tackling issues. We reviewed our deliveries: a must deliverable of the spec and a number of supporting documents: use case and requirements, access control guidance, possible primer, deployment guide (need a better name) and test suite.

We prioritized the issues we wanted to discuss early on the first day to make sure we got all the "big hitter" issues out on the table. I added to this list some of the key OSLC items such as binary resources and metadata, patch and more. One thing we learned as we got into the next day, there still was some confusion on the model. I surfaced ISSUE-59 to hopefully help simplify the model.

Here are the detailed meeting minutes from: day 1, day 2 and day 3.

Some of the key issues discussed were:

ISSUE-15 Sharing binary resources and metadata
The WG came to the following resolution after much discussion about concerns of different behavior of POST'ing RDF formats which create LDP-Rs and which response location headers should used.

Resolution: Assuming the existing qualifications that POST is optional, and supporting "binary" media types is optional: The expected response to a post for create that creates a non-LDPR is a 201, with location header whose URI I identifies the resource whose representation matches the POST input, and the response SHOULD include a Link header rel="meta" href= another URI P identifying the resource whose state is the server-managed properties. The URIs I and P MAY be distinct, but this is not required. When the object of a membership triple (I) is DELETEd, the server MUST automatically deletes any related resource P that it created previously

ISSUE-17 Recommended PATCH document (and 27 & 45) 

There were a number of PATCH related issues, like 27 whether POST could be used to tunnel PATCH but WG decided just to use PATCH. Also there is 45, which suggested the need to use POST'ing of RDF formats to LDP-Rs to append/add to existing resources. The WG decided that this would be fairly different than what is done with POSTing to LDP-Cs which creates a new resource and adds membership triples, plus we have a solution to append by using PATCH-insert. For 17, the original proposal was to use the Talis changeset format but due to a variety of reason this was withdrawn (don't recall the problems with Talis changeset). Instead the WG decided to pursue its own simple PATCH document that leveraged existing quad formats such as TriG. The WG has an action to define the minimal and work with issues and proposals to expand on it.

Other issues we discussed were on our list to watch as of course the resolution could impact us but the issues listed were not identified by OSLC community members as a high priority.  Overall it was very encouraging to see the WG make progress on such key issues.  It is also a little disappointing we didn't make more progress in other areas.  It is most likely that we won't enter into "Last Call" until after our 3rd face to face which is being planned for mid-June.

OSLC's relationship with Semantic Web technologies

The technical basis for accessing data through OSLC has its roots in Linked Data, which has its origins with Semantic Web technologies.  Some worry about the costs of supporting this for some simple integration scenarios, though OSLC only depends on a small amount of it.  For those that bought into the full stack of Semantic Web technologies for various domain solutions realize there is tremendous value in what it can provide but that it also comes at some cost.  The cost is in aspects of Semantic Web such as reasoners, inferencing, search engines, RDF and specialized repositories for dealing with these things.

OSLC takes a minimal incremental approach to depend on only what is needed to satisfy the integration scenarios.  So far that has led us to leverage a simple standard way of describing resources using RDF.  That is about where the Semantic Web technology dependency ends.  We leverage a few terms out of RDF Schema to help with defining our own vocabulary terms but do not go beyond that as it might imply that clients would need to process inference rules against the resource representations they receive to learn more.

Since a primary goal of OSLC is to not reinvent but leverage standards based approaches that meet our requirements, I can see cases where it might be good to adopt some more Semantic Web technologies.  Though to be clear, for tools to get value out of OSLC-based integrations, only some RDF syntax readers and writers are needed.  There is no need for tools to have be rehost or rewrite them onto a new technology base, they can simple adapt their solution with a simple fasade or update their existing REST APIs to provide this support.