LDPNext2015 Charter

From Linked Data Platform
Jump to: navigation, search

<html

 lang="en" xml:lang="en" xmlns="http://www.w3.org/1999/xhtml">
 <head>
   <meta content="text/html; charset=UTF-8" http-equiv="content-type" />
   <title>W3C Linked Data Platform Working Group *DRAFT* Charter</title>
   <meta content="Andrei Sambra" name="author" />
   <meta content="Arnaud Le Hors" name="author" />
   <meta content="Ivan Herman" name="author" />
   <meta content="Sandro Hawke" name="author" />
   <meta content="charter, W3C, linked data, semantic web" name="keywords" />
   <link media="screen" type="text/css" href="http://www.w3.org/2005/10/w3cdoc.css" rel="stylesheet" />
   <link href="http://www.w3.org/Guide/pubrules-style.css" type="text/css" rel="stylesheet" />
   <link href="http://www.w3.org/2006/02/charter-style.css" type="text/css" rel="stylesheet" />
   <style type="text/css">

table.timeline { border-width: 0px; border-spacing: 0px; border-style: outset; border-color: gray; border-collapse: collapse; background-color: white; } table.timeline th { border-width: 1px; padding: 4px; border-style: solid; border-color: gray; background-color: white; -moz-border-radius: ; // background-color: rgb(255, 255, 0); color: rgb(0, 102, 0); padding-left: 8px; padding-right: 8px; } table.timeline td { border-width: 1px; padding: 4px; padding-left: 8px; padding-right: 8px; border-style: solid; border-color: gray; background-color: white; -moz-border-radius: ; }

.alert {

  padding: 1em; 
  margin: 0em; 
  margin-bottom: 2em; 
  border:2px solid blue; 
  box-shadow: 10px 10px 5px #888;
  -moz-box-shadow: 10px 10px 5px #888;
  -webkit-box-shadow: 10px 10px 5px #888;
   -moz-border-radius: 5px;
   -webkit-border-radius: 5px;
   -khtml-border-radius: 5px;
   border-radius: 5px;

}

.opt {

 color: rgb(0, 119, 0);

} //#disclaimer { // font-size: 120%; // color: rgb(204, 0, 0); //} .note {

 font-style: italic;
 color: rgb(0, 102, 0);
 font-variant: small-caps;
 background-color: rgb(255, 255, 0);

} .toremove {

 text-decoration: line-through;

}

  1. issuesxxx {
 background-color: rgba(4, 255, 36, 0.34);
 border-left-width: medium;
 border-left-style: solid;
 padding-left: 0.5em;
 padding-top: 0.1em;
 padding-bottom: 0.1em;

} </style></head>

 <body>

1 ** This is merely a DRAFT for WG consideration**

<a shape="rect" href="http://www.w3.org/"><img width="72" height="48" src="http://www.w3.org/Icons/w3c_home" alt="W3C" /></a> <a shape="rect" href="/TandS/" class="domainlogo"><img alt="Technology and Society Domain" src="http://www.w3.org/Icons/ink" /></a>

2 Linked Data Platform (LDP) Working Group Charter

The mission of the <a href="http://www.w3.org/2012/ldp">Linked Data Platform (LDP) Working Group</a> 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.

<a href="https://www.w3.org/2004/01/pp-impl/55082/join">Join the Linked Data Platform (LDP) Working Group.</a>

<tbody> </tbody>
End date 1 December, 2018
Confidentiality Proceedings are <a shape="rect" href="/2005/10/Process-20051014/comm.html#confidentiality-levels"> public </a>
Chair TBD
Staff Contact
TBD
Teleconference Schedule One 60-90 minute call per week, plus task force calls as necessary
Face-to-Face Meetings 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.

2.1 Introduction

The proposed charter 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 that works with linked, shared, distributed data:

<a href="http://www.w3.org/TR/2014/ldp">Linked Data Platform 1.0</a> made a start in this direction but a lot more needs to be done. This charter continues the work of the LDP WG to strengthen the <a href="http://www.w3.org/TR/2014/ldp">Linked Data Platform 1.0</a> recommendation and solve additional problems.

  1. RDF, the Resource Description Framework, is a W3C <a href="http://www.w3.org/TR/rdf-concepts/">Recommended</a> general technique for conveying information. It has a handful of syntaxes, including <a href="http://www.w3.org/TR/rdf-syntax-grammar/">RDF/XML</a>, <a href="http://www.w3.org/TR/rdfa-core/">RDFa</a>, and <a href="http://www.w3.org/TR/turtle/">Turtle</a>, 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 <a href="http://www.w3.org/DesignIssues/LinkedData.html">Linked Data</a> and <a href="http://www.w3.org/standards/semanticweb/">the Semantic Web</a>.
  2. With RESTful APIs and RESTful Web Services, clients use basic <a href="http://www.w3.org/Protocols/rfc7230-7235/rfc7230-7235-sec9.html#sec9">HTTP verbs</a>, 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 <a href="#ref">References</a>. Within W3C, the SPARQL Working Group developed a <a href="http://www.w3.org/TR/sparql11-http-rdf-update/">RESTful protocol</a> for accessing data in SPARQL data stores and discussed its wider applicability. The participants in the <a href="http://www.w3.org/2011/09/LinkedData/Report">Linked Enterprise Data Patterns Workshop</a> 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 and to solve some commonly encountered development situations such as collections and paging.

The basic technique 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). 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 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 <a href="http://www.w3.org/TR/rdf-schema/">RDFS</a>, <a href="http://www.w3.org/TR/sparql11-query/">SPARQL</a>, <a href="http://www.w3.org/TR/owl2-overview/">OWL</a>, <a href="http://www.w3.org/TR/rif-overview/">RIF</a>, and the <a href="http://www.w3.org/TR/prov-primer/">PROV</a> 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.

2.2 Scope

The starting point for this group is the W3C Recommendation <a href="http://www.w3.org/TR/2014/ldp">Linked Data Platform 1.0</a>. Based on this document and contributions from Working Group participants, the group is chartered to produce one or more W3C Recommendations that expand on this RESTful way of working with Linked Data to provide additional capabilities.

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

Parts of this work may overlap with or relate with work from other groups such as the <a href="http://www.w3.org/2011/gld/">Government Linked Data (GLD) Working Group</a> which is producing Best Practices advice for governments publishing Linked Data and the <a href="http://www.w3.org/2014/shapes">RDF Data Shapes Working Group</a>. When that is the case, the two groups should coordinate to make sure their deliverables and approaches are compatible.

This work is to be based on existing HTTP specifications developed within the IETF, including RFC 7230-7235 (<a href="http://tools.ietf.org/html/rfc7230-7235">HTTP/1.1</a>), RFC 5988 (<a href="http://tools.ietf.org/html/rfc5988">Web Linking</a>), and RFC 5789 (<a href="http://tools.ietf.org/html/rfc5789">PATCH Method for HTTP</a>). 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.

2.2.1 Technical Issues

To help explain the work expected of the group, here is a list of practical issues, many of which were brought up during the development of LDP 1.0 and recorded in the <a href="https://www.w3.org/2012/ldp/wiki/LDPNext">LDP Next Wish List</a>. These and other, similar issues should be discussed by the group and guidance provided in the delivered Recommendation where practical.

  1. How can retrieval of a container and its contained resources be combined so that fewer HTTP operations are required to work with them than it is necessary with LDP 1.0?
  2. How can a client filter what part of a resource or container the server is to return?
  3. How can a client be notified when a resource changes?
  4. How can a client find out whether a SPARQL endpoint is associated with a resource or set of resources?
  5. How can access to a resource be controlled?
  6. How can a client have greater control of how paging is done (size, sorting, etc.)?"
  7. How can a client learn what property constraints there are when creating or updating a resource?"
  8. How can changes to LDP resources be communicated efficiently, either some given set or rolling updates (feed) of changes?

2.3 Deliverables

Recommendation Track:

  • Linked Data Platform 1.1: W3C Recommendation, possibly as a collection of small specifications rather than a single document, defining an expanded platform based on RESTful read/write Linked Data, detailed in <a href="#scope">Scope</a>. Proposed extensions for LDP 1.1 include:

    • Extensibility and Discovery: allow clients to easily discover server affordances
    • Inlining on GET and POST: clients need a way to request and create multiple resource with a single HTTP request
    • Query/Search:
      • SPARQL on LDP (resource-centric): queries in SPARQL are either triple oriented (CONSTRUCT) or table oriented (SELECT); we need to be able to speak about resources such as the members of a container
      • RDF Source-scoped: being able to query LDP-Rs; perhaps each LDPR could be considered as its own SPARQL endpoint
      • Client-based paging of query results: allow clients to initiate and specify a set of preferences for paging through the query results

  • Linked Data Platform Paging 1.1: W3C Recommendation expanding on LDP Paging 1.0 with additional capabilities.
  • Access Control 1.0: W3C Recommendation defining an access control mechanism to control access to Linked Data Platform Resources.

Not Recommendation Track:

  • Use Case and Requirements 1.1: 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 LDP platform 1.1.
  • 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.

2.4 Schedule (TBD)

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

<tbody> </tbody>
Date Event Description
2015-12 Start Group Launch, First Teleconferences

2.5 Dependencies and Liaisons

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

2.5.1.1 Liaisons

<a href="http://www.w3.org/2011/rdf-wg/wiki/Main_Page">RDF Working Group</a>
to identify those technical issues that may be better developed in the RDF Working Group and vice versa.
<a href="http://www.w3.org/2009/sparql/wiki/Main_Page">SPARQL Working Group</a>
to identify the exact relationships of the planned deliverables with the <a href="http://www.w3.org/TR/sparql11-service-description/">SPARQL 1.1 Service Description</a>, the <a href="http://www.w3.org/TR/sparql11-http-rdf-update/">SPARQL 1.1 Graph Store HTTP Protocol</a>.
<a href="http://www.w3.org/community/json-ld/">JSON for Linking Data Community Group</a>
to explore whether the HTTP response format used for the Linked Data RESTful API can be based on the <a href="http://json-ld.org/spec/latest/json-ld-syntax/">JSON-LD</a> specification.
<a href="http://www.w3.org/2001/sw/CG/wiki/Main_Page">Semantic Web Coordination Group</a>
to ensure a proper coordination between the work of this group and all the other Working Groups in the Semantic Web and eGov activities
<a href="http://www.w3.org/2011/gld/wiki/Main_Page">Government Linked Data Working Group</a>
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 <a href="#ldpvocab">section 2.2</a>, 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.
<a href="http://www.w3.org/2011/01/prov-wg-charter">Provenance Working Group</a>
to ensure that the work on getting information about Linked Data resources is in line with the work on <a href="http://www.w3.org/TR/2012/WD-prov-aq-20120110/">Provenance Access and Query</a>
<a href="http://www.w3.org/community/networked-data/">W3C Network Data Community Group</a>
The use cases and requirement defined by that Community Group may be considered as input to the work of this Working Group.

2.5.1.2 Dependencies

<a href="http://www.w3.org/2011/rdf-wg/wiki/Main_Page">RDF Working Group</a>
This group is <a href="http://www.w3.org/2010/09/rdf-wg-charter.html">chartered</a> 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.

2.5.2 External Groups

2.5.2.1 Liaisons

<a href="http://datatracker.ietf.org/wg/httpbis/charter/">IETF Hypertext Transfer Protocol (HTTP) Working Group</a>
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.

2.6 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 <a href="http://www.w3.org/2004/08/invexp">invited expert process</a>, 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.

Participants are reminded of the <a shape="rect" href="/2005/10/Process-20051014/groups.html#good-standing"> Good Standing requirements</a> of the W3C Process.

2.7 Communication

This group primarily conducts its work on the mailing list public-ldp-wg@w3.org (<a href="http://lists.w3.org/Archives/Public/public-ldp-wg/">public archives</a>). The mailing list member-ldp-wg@w3.org (W3C member-access-only <a href="https://lists.w3.org/Archives/Member/member-ldp-wg/">archives</a>) 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.

2.8 Decision Policy

As explained in the Process Document (<a shape="rect" href="/Consortium/Process/policies#Consensus">section 3.3</a>), 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.

2.9 Patent Policy

This Working Group operates under the <a shape="rect" href="/Consortium/Patent-Policy-20040205/">W3C Patent Policy</a> (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.

For more information about disclosure obligations for this group, please see the <a shape="rect" href="/2004/01/pp-impl/">W3C Patent Policy Implementation</a>.

2.10 About this Charter

This charter for the Linked Data Platform Working Group has been created according to <a shape="rect" href="/Consortium/Process/groups#GAGeneral">section 6.2</a> of the <a shape="rect" href="/Consortium/Process">Process Document</a>. 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.

2.11 References

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

[1] <a href="http://www.w3.org/2001/Annotea/User/Protocol">Annotea Protocols</a>, Ralph Swick et al. 2002.

[2] <a href="http://www.w3.org/DesignIssues/ReadWriteLinkedData.html">Read-Write Linked Data</a>, Tim Berners-Lee. 2009.

[3] <a href="http://dret.typepad.com/dretblog/2009/05/rest-and-rdf-granularity.html">REST and RDF Granularity</a>, Eric Wilde. 2009.

[4] <a href="http://data.gov.uk/blog/guest-post-developers-guide-linked-data-apis-jeni-tennison">A Developers' Guide to the Linked Data APIs</a>, Jeni Tennison. 2010.

[5] <a href="http://code.google.com/p/callimachus/wiki/REST_API">Callimachus API</a>, David Wood and James Leigh. Last updated Feb 29, 2012.


           <address> <a href="https://deiu.rww.io/profile/card#me">Andrei Sambra</a>
             (<a href="mailto:andrei@w3.org">andrei@w3.org)</a>, <a href="http://www.w3.org/People/Alexandre/">Alexandre Bertails</a>
             (<a href="mailto:bertails@w3.org">bertails@w3.org)</a>, <a href="http://www.w3.org/People/Sandro/">Sandro
               Hawke</a> (<a href="mailto:sandro@w3.org">sandro@w3.org</a>), and <a href="http://www.w3.org/People/Ivan/">Ivan
               Herman</a> (<a href="mailto:ivan@w3.org">ivan@w3.org</a>), editors </address>

$Id: charter.html,v 1.46 2013-04-23 11:56:45 sandro Exp $

 </body>

</html>