Linked Data Platform (LDP) Working Group Charter

The mission of the Linked
Data Platform (LDP) Working Group is to produce a W3C Recommendation for
HTTP-based (RESTful) application integration patterns using read/write Linked Data.
This work will benefit both small-scale in-browser applications (WebApps) and
large-scale Enterprise Application Integration (EAI) efforts. It will complement
SPARQL and will be compatible with standards for publishing Linked Data, bringing
the data integration features of RDF to RESTful, data-oriented software development.

Three expected during the course of the group, although the chairs may
schedule or cancel meetings as needed to help the group reach its goals. These
meetings will use teleconferencing facilities, but effective participation
generally requires attending in person, so participants should budget for
travel.

Introduction

This group is based on the idea of combining two Web-related concepts to help
solve some of the long-standing challenges involved in building and combining
software:

RDF, the Resource Description Framework, is a W3C Recommended
general technique for conveying information. It has a handful of syntaxes,
including RDF/XML, RDFa,
and Turtle, any of which can be used
to transmit RDF statements. The items about which information is expressed in
RDF documents are identified with URIs (eg,
http://example.com/products/Widget-71) but the existing RDF specifications do
not cover dereferencing them. RDF is the basis for Linked
Data and the Semantic
Web.

With RESTful APIs and RESTful Web Services, clients use basic
HTTP verbs,
with their simple and direct meaning, to obtain and alter the state of objects
on the server. In these APIs, the remote information objects are identified with
URIs which are dereferenced in every operation. RESTful APIs can be defined
independent of the formats used for conveying the state of the objects;
typically services use custom XML and/or JSON encodings of state information.

The combination of RDF and RESTful APIs is therefore natural, with RDF providing
a standard way to serialize information about things identified by URIs and REST
providing a way to obtain and alter the state of those things. This approach has
been proposed and explored for some time, in academia and industry, as shown by
the items listed in References. Within W3C, the SPARQL Working
Group developed a RESTful
protocol for accessing data in SPARQL data stores and discussed its wider
applicability. The participants in the Linked
Enterprise Data Patterns Workshop expressed general support for the creation
of a Working Group to define a way to use RDF with RESTful APIs in support of
application integration.

The basic technique here is to expose application data objects ("resources") on
the Web, allowing authorized clients to see and modify object state using HTTP
operations (GET, PUT, etc) with an RDF data format. This RESTful approach
leverages existing Web technology, including caching, linking, and indexing, and
the use of RDF facilitates integration of data across systems and applications.
This approach dovetails with SPARQL and is positioned for developers who want more
direct access to the application data.

The Linked Data Platform is envisioned as an enterprise-ready collection of
standard techniques and services based on using RESTful APIs and the W3C Semantic
Web stack. Simple LDP applications can be developed and deployed using only RDF
and conventional HTTP infrastructure. More extensive LDP applications can be built
using other elements of the stack, including RDFS,
SPARQL, OWL,
RIF, and the PROV
provenance vocabulary. Although expertise in these specialized elements may be
helpful, it is not necessary for participation in this group and should not be
required for using the Linked Data Platform.

Scope

The starting point for this group is the W3C Submission Linked
Data Basic Profile 1.0. Based on this document and contributions from
Working Group participants, the group is chartered to produce one or more W3C
Recommendations that define a RESTful way to read and write Linked Data, suitable
for use in application integration and the construction of interoperable and
modular software systems.

The group will also produce supporting materials, such as a description of uses
cases, a list of requirements, and a test suite and/or validation tools to help
ensure interoperability and correct implementation.

Parts of this work may overlap with general Linked Data patterns and best
practice. When they do, the group must take special care to coordinate with other
stakeholders who might not otherwise be interested in the group's work. For
example, the group may give advice on how to design URIs for long-term stability,
as needed for its use cases. This issue is also in scope for the Government
Linked Data (GLD) Working Group which is producing Best Practices advice for
governments publishing Linked Data. On issues like this, the two groups must
coordinate to make sure their advice is compatible. Also, wherever possible and
practical, the LDP WG should develop semantics that align well with the SPARQL
Graph Store Protocol and the RDF WG’s updates to RDF.

The Working Group will not produce a Recommendation specifying solutions for
access control and authentication for Linked Data. However the Working Group may
identify, based on a set of real world use cases, requirements for authentication
and authorization technologies for use with Linked Data.

This work is to be based on existing HTTP specifications developed within the
IETF, including RFC 2616 (HTTP/1.1),
RFC 5988 (Web Linking), and RFC
5789 (PATCH Method for HTTP). The
group may document requirements for additional HTTP standards work, but it is out
of scope for this group to specify additions or modifications to HTTP, such as new
headers or new verbs.

Technical Issues

To help explain the work expected of the group, here is a list of practical
issues, many of which are addressed in Linked
Data Basic Profile 1.0, that can arise in trying to use RDF and RESTful
APIs for application integration. These issues and ones like them should be
discussed by the group and guidance provided in the delivered Recommendation
when practical.

What is the minimum set of RDF datatypes that must be supported by clients
and servers?

Which RDF serialization syntax (eg Turtle or JSON-LD) must be supported by
clients and servers?

How to create a new resource, which might be a new collection?

How to create a resource with information describing the resource, when the
resource address isn't known at creation time?

How to access resource state in reasonably-sized chunks (paging)?

How to safely (predictably) modify a resource simultaneously from multiple
clients? (concurrency)

Can resource have multiple rdf:types? Can their rdf:types change?

How can a client modify a resource without replacing the complete contents?

How to get a list of all the resources in collection?

How to move a resource in or out of a collection?

How may a client determine whether/how it may modify a resource?

How to operate on multiple resources at once, for efficiency or to group a
set of changes into one atomic operation?

How to integrate with SPARQL, including how to find a SPARQL endpoint
serving data for a particular resource? (To be coordinated with SPARQL
community/WG.)

Which vocabulary terms are to be used for resource metadata, when necessary
for interoperation?

Are there situations where use of blank nodes is allowed/disallowed?

How client software may determine at runtime which RDF vocabulary terms to
use when reading/writing resource state? (This information may be used to
support validation and vocabulary changes.)

Answering these questions may involve such work as:

Defining new RDF vocabulary terms, in new or existing namespaces

Defining URI construction patterns, such as the practice of using "?page=nnn"
for paging

Deliverables

Use Case and Requirements: a collection of use cases and a derived
list of requirements that gives a practical foundation with which to analyze
proposed designs for elements of the platform. The group will chose the form
of this deliverable, such as a set of wiki pages.

Test Suite and/or Validator: to help ensure
interoperability and correct implementation. The group will chose the form
of this deliverable, such as a git repository.

Access Control: Working Group Note on Use Cases and Requirements
for access control and authentication mechanisms needed for this work.

Schedule

The group will document significant deviations from this schedule on its home
page.

Date

Event

Description

2012-06

Start

Group Launch, First Teleconferences

2012-07

UCR

Release initial lists of proposed Use Cases and Requirements

2012-09

F2F1

Face-to-face meeting

2012-10

WD1

First public Working Drafts published

2013-01

WD2

Second public Working Drafts published

2013-03

F2F2

Face-to-face meeting

2013-05

LCWD

Last Call Working Drafts published

2012-06

F2F3

Face-to-face meeting, if needed

2013-10

CR

Candidate Recommendation published

2014-01

PR

Proposed Recommendation published

2014-03

REC

Recommendation published

Dependencies and Liaisons

W3C Groups

Many of groups listed below will complete their work before this Working
Group is done, in which case the Working Group should liaise with the
appropriate successor groups, or, if there is none, make a reasonable attempt
to communicate with involved individuals and the larger community.

the GLD Working Group is also working on advices on vocabulary selection
and creation; there is therefore an overlap between the work mentioned for
the LDP WG in section 2.2, and the ongoing work in
the GLD Working Group. However, while the GLD Working Group concentrates on
governmental data, the goal of the LDP WG is more general. The liaison
between the groups should ensure a proper coordination between the two
Working Groups.

Dependencies

This group is chartered
to produce Recommendations for Turtle and a JSON syntax for RDF. One of
these syntaxes might be chosen as the standard RDF serialization for LDP.
The work of the RDF Working Group on graph identification is also relevant
to the work of the LDP Working Group.

External Groups

Liaisons

Although the LDP Working Group will not define any new HTTP headers or
verbs, a liaison with the HTTP Working Group may be useful to help ensure
proper use of existing HTTP mechanisms.

Participation

In general, people participate in this group as representatives of W3C
member organizations. At least one representative from each participating
organization is expected to devote significant time to this effort (about
one day per week, or more, depending on duties), to accept and complete
appropriate action items on a timely basis, and to travel to face-to-face
meetings, as scheduled by the chairs in consultation with the group.

On a case-by-case basis, using the invited
expert process, people may be allowed to participate as individuals,
not representing an organization.

To be successful, the Working Group is expected to have between ten and
thirty active participants for its duration.

Communication

This group primarily conducts its work on the mailing list
public-ldp-wg@w3.org (public
archives). The mailing list member-ldp-wg@w3.org (W3C
member-access-only archives)
may be used for administrative purposes, such as travel planning.

Information about the group (deliverables, participants, face-to-face
meetings, teleconferences, etc.) will be available from the group's home
page.

Decision Policy

As explained in the Process Document (section
3.3), this group will seek to make decisions when there is consensus.
When the Chair puts a question and observes dissent, after due consideration
of different opinions, the Chair should record a decision (possibly after a
formal vote) and any objections, and move on.

Patent Policy

This Working Group operates under the W3C
Patent Policy (5 February 2004 Version). To promote the widest
adoption of Web standards, W3C seeks to issue Recommendations that can be
implemented, according to this policy, on a Royalty-Free basis.

About this Charter

This charter for the Linked Data Platform Working Group has been created
according to section
6.2 of the Process
Document. In the event of a conflict between this document or the
provisions of any charter and the W3C Process, the W3C Process shall take
precedence.

References

The following items should be included as background material by the
Working Group, documenting some of the work in this field: