RDF Data Shapes
Working Group Charter

Motivation

One motivation for this work is Application Integration, where different software components, potentially maintained by different organizations, need to function together smoothly. As a everyday example, imagine an international company with a dozen divisions, each providing a feed of their Human Resources data to authorized users. Different divisions might use different software to produce their feeds, and there might be many distinct applications which consume the data, ranging from an employee phone book to a hiring-compliance monitoring system.

While systems like this are built and maintained around the world today, their complexity often becomes a problem. Not only are the systems expensive and sometimes unpleasant to maintain, but changing data fields and adding new applications can grow to be practically impossible. An "RDF Data Shapes" standard would help manage the complexity, greatly reducing the cost and hassle, by separating components while still allowing them to work together.

Specifically, in this example, an RDF Data Shapes Language would allow:

• Developers of each data-consuming application could define the shapes their software needs to find in each feed, in order to work properly, with optional elements it can use to work better.
• When these developers want to modify their software, they can define new shapes they require
• Management can offer guidance in the relative priorities of outputing particular shapes, based on the application(s) that use them. There might be target goals and deadlines.
• Developers of data-providing systems can read the shape definitions (and possibly related RDF Vocabulary definitions) to learn what they need to provide
• Data providers can also validate their data against the definitions, to see if they are producing the right information. (Of course, this doesn't ensure the data is correct, just that it's the right shape.)
• Data consumers can validate incoming data against the expected shapes, to make sure they are getting the kind of data they were expecting. This can be done manually from time to time, or automatically on all data. This kind of validation is particularly important if producers and consumers keep updating their software to use new shapes to meet changing requirements.
• Intermediate systems can, in some cases, be written to convert data written to match one shape into data which matches a different shape.
• Some systems may be able to automatically generate user interface elements (eg HTML forms) and/or data bindings based on shapes.
• There may be optimizations in data processing possible when the data is known to conform to a single declared shape.

In all cases, the semantics of the data are determined by RDF and the vocabularies specified by the shape, so if the shapes match, the systems can reasonably be expected to interoperate correctly.

While RDF Data Shapes are expected to have immediate everyday utility, as illustrated above, they have even wider potential applicability, ranging in scale. At the large end, RDF Data Shapes might be used by loosely-knit communities, where data is provided by organizations which are not under any central authority, such as charities and researchers around the world concerned with quality-of-life measures. At the small end, RDF Data Shapes might be used within a mobile application environment to provide interoperability among independent sensor modules and tools for analyzing and acting on sensor results. The common thread is that RDF Data Shapes allow a loose coupling, where independently maintained elements of an overall system can reliably and comfortably interoperate.

Scope

This work group will address these design goals:

Association of properties with Primitive Data Types

Constrain the object of a property to have a particular datatype.

Association of properties with Structural Types

Assert that the object of a property must conform to a specific shape.

Hierarchies of shape definitions

Permit any of a set of shapes to stand for a specified shape, e.g. to say that either a User shape or an Employee shape can be used in place of a Commentor shape.

Data feed description

Description of data streams and query interfaces.

Conformance

The relation of schemata to RDF graph instances; obligations on schema-aware processors. The WG will define a process for checking to see that the constraints expressed in a schema are respected in an RDF graph (validation);

Extensibility

The language will enable implementations to take advantage of extensions in the language to perform verification or other actions not required for conformance.

The first order of business of the Working Group will be to review existing work in this space, including the W3C Submissions Resource Shapes 2.0, Shape Expressions 1.0 Primer, Shape Expressions 1.0 Definition, and SPIN, along with discussion at the RDF Validation Workshop (eg the Stardog ICV presentation). From these inputs, and other input it deems useful, the Working Group shall select appropriate Use Cases and decide on which Requirements are to be met by the group's eventual output. These Use Cases and Requirements are to be documented in a Working Group Note within 3-6 months after the start of the group.

Deliverables

Recommendation Track:

1. An RDF vocabulary, such as Resource Shapes 2.0, for expressing these shapes in RDF triples, so they can be stored, queried, analyzed, and manipulated with normal RDF tools, with some extensibility mechanism for complex use cases.

2. Semantics, possibly defined as SPARQL operations, specifying how shapes are evaluated against RDF graphs.

3. OPTIONAL - Compact, human-readable, non-RDF syntax for expressing constraints on RDF graph patterns (aka shapes), suitable for the use cases determined by the group.

Not Recommendation Track:

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

2. Relationship to SPARQL: The group will document how its output relates to SPARQL, including instructions for how to use SPARQL systems to perform validation.

3. Relationship to OWL: The group will document how its output relates to OWL, including OWL using the Closed World Assumption (CWA) and Unique Names Assumption (UNA), as reported at the Workshop. This may include instructions for translating to/from OWL, as the Working Group deems useful. (This deliverable may not be needed if OWL is integral to the group's output.)

4. Primer: W3C Note introducing users to the technical output of the group.

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

Schedule

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