Plans of the DCMI RDF AP Group for 2016

1. Continue interaction with W3C Shapes group DCMI continues to have an active role in the W3C RDF validation group that is developing SHACL. DCMI group members have created some test data, some of which has already been delivered. That group has an end of 2016 deadline to fulfill W3C requirements, including implementations and test suite.

2. Compare SHACL outcomes with DCMI requirements The group developed an extensive list of requirements for validation. There is an ongoing comparison of these requirements and the capabilities of SHACL (which are still undergoing changes). At this moment most of the DCMI requirements overlap with those being addressed by SHACL, but there are a few outlyers. Those will be addressed in the final report of this group.

3. Analyse the potential interaction between SHACL and DCMI standards Where SHACL is focused solely on RDF validation, DCMI has a more contextual model that is provided by the Singapore Framework, some of which was integrated into the Description Set Profile. DCMI also has the Dublin Core Abstract Model. That latter is not identical to models in which the Semantic Web is grounded, and we need to keep this in mind as we integrate (if we integrate) SHACL into the broader DCMI model. This group may be able to make recommendations to the DC Technical Board in that regard.

4. Analyse AP needs that are not, and are not logically, part of SHACL (esp. non-validation) SHACL focuses solely on validation, although there are some concessions to documentation and iinteraction with the user interface. The Dublin Core Application Profile (DCAP) has a more comprehensive set of goals that include full metadata scheme documentation. The DCAP is possibly a user-friendly view that can interact with the actionable SHACL technology.

5. Analyse community data flow needs that are outside of the SHACL purvue SHACL assumes that the engine will receive instance data and SHACL shape declarations. How the instance data is retrieved, received or processed before bieng passed to the SHACL engine is not addressed. There are a number of questions that have come up in this area, including requirements for inferencing, and dependencies on data that is stored remotely and must be accessed as part of the validation. Some of this analysis has been initiated in a document produced by Corey Harper, Tom Johnson, and Karen Coyle that outlined. fn:(http://wiki.dublincore.org/index.php/RDF_Application_Profiles/blendingDoc) In addition, Lars Svensson has been active in the W3C's Linked Data Platform (LDP) standards group and has articulated a potential solution to providing documentation and negotiation of metadata exchange where there are options available (e.g. serving bibliographic data described with the BIBFRAME elementset vs the RDA elementset -- this is orthogonal to serving the data in RDF.TTL vs RDFXML).

6. Explore SHACL suitability for DCMI community We would like to understand SHACL's suitability for the DCMI community. As it may be some time before there is sufficient varied experience with this, this may be something that we would pursue at a later date, perhaps at a conference.

7. Document SHACL for DCMI community SHACL is a complex standard as a whole, but it should be possible to document the most common. We will have some examples to offer soon, and could develop a web page where these are easy to find.

We expect to document our findings for the board.