W3C home > Mailing lists > Public > public-rdf-shapes@w3.org > July 2014

Re: TopQuadrant's position on RDF Shapes working group

From: Holger Knublauch <holger@topquadrant.com>
Date: Thu, 24 Jul 2014 13:20:06 +1000
Message-ID: <53D07B66.9080706@topquadrant.com>
To: public-rdf-shapes@w3.org
More feedback on the current Charter for this WG. We believe the WG 
should produce an RDF vocabulary to represent Resource Shapes for the 
most widely needed kinds of constraints, and another vocabulary that can 
be used to describe additional constraints, using SPARQL. The 
architecture should be created so that it allows the consistent 
execution and definition of those two kinds of constraints with the same 
underlying principles.

Our proposal is to have the following two normative deliverables:

- An RDF vocabulary that can be used to associate RDFS/OWL class 
definitions with constraints, and to define constraints based on 
declarative, reusable building blocks (shapes). Our proposed candidate 
solution to this is the SPIN Mini Profile [1] because SPIN is already 
the de-facto standard in this area. Needless to say we would be happy to 
adjust SPIN where needed.

- A library of specific shapes for the most common patterns, similar in 
scope to the Resource Shapes proposal [2]. We hope that this library can 
be expressed in terms of SPIN templates, leading to a very consistent 
and easy to understand architecture. However, the end user of this 
shapes vocabulary does not even have to know that SPARQL exists, and 
tools can implement support for the Shapes vocabulary without a SPARQL 
engine (e.g. to drive user interface forms).

Non-Recommendation deliverables would include:

- Use Cases and Requirements

- Relationship to OWL (for example a syntactic mapping that allows 
existing OWL ontologies to be converted into the Shapes vocabulary, but 
with closed world semantics).

- Primer

- Test Suite

- RDF Syntax for SPARQL (optional)

- Compact syntax: if there is a consensus that the RDF vocabulary (using 
Turtle and JSON-LD) is not user friendly enough, then this WG could 
define syntactic sugar that maps into the Shapes vocabulary. This does 
not necessarily require a completely new language, but could simply be 
an extension to Turtle. A somewhat crazy proposal to that is [3].

The scope should allow for extensions that are closely related to the 
original constraint checking problem, in particular generalizing (SPIN) 
constraints into "rules", and a mechanism to define new SPARQL functions 
based on other SPARQL queries. It would be a hugely wasted opportunity 
to not also include those once we are revisiting the semantic web stack, 
even if the original charter was motivated by constraint checking only. 
SPIN functions lead to significantly easier to maintain SPARQL queries 
(and thus constraint definitions), and rules can be used to formalize 
relationships between properties (e.g. to infer the uncle) in very same 
ways that constraints narrow down the possible structures. Both of these 
features are very easy to formalize once we have constraints and 
templates in place.


[1] http://spinrdf.org/spin-min.html
[2] http://www.w3.org/Submission/2014/SUBM-shapes-20140211/

On 7/22/2014 13:22, Holger Knublauch wrote:
> This is to clarify TopQuadrant's position with regards to this working 
> group and its charter.
> We believe that the topic of defining structural constraints on RDF 
> graphs is an important issue that we and our customers have 
> encountered in many real-world use cases. TopQuadrant would like to 
> join and actively contribute to this working group. We have also 
> started to contact users of SPIN to see who else may want to join us 
> with our efforts.
> Our preference is that the starting point of this working group should 
> be SPIN, and our goal will be to collaborate with the other group 
> members to upgrade a sub-set of the current SPIN specification to 
> become the standard recommendation on constraint checking. We do not 
> support the introduction of yet another language such as ShEx and will 
> continue to strongly argue against it. Many previous emails have 
> detailed concerns shared by others.
> Specifically (and I haven't worked out the details), we could propose 
> a sub-set of SPIN consisting of the property spin:constraint that is 
> used to link OWL/RDFS class definitions with SPARQL CONSTRUCT or ASK 
> queries that deliver constraint violations, and to allow the use and 
> definition of SPIN templates. The standard would include a library of 
> standard templates that would cover the most frequently needed use 
> cases (including minimum/maximum cardinality etc). This template 
> library would make it possible to cover a wide range of use cases in a 
> declarative RDF vocabulary, even for people who do not know SPARQL. 
> However, we believe it is important to have the "escape mechanism" 
> allowing the inclusion of SPARQL queries directly. The exact scope 
> (e.g. whether the SPIN RDF syntax would be included) of the submission 
> needs to be worked out and I can see arguments going both ways.
> If the working group decides that SPIN is not the right starting 
> point, then our next best proposal is to make something like StarDog 
> ICV the standard. This would have a key advantage that the 
> "restrictions" defined for many OWL ontologies already exist. Indeed, 
> the absence of intuitive closed-world semantics has been a major 
> obstacle to wider adoption of OWL, and it would be a great outcome if 
> an OWL extension would be standardized that allows to repurpose 
> existing work and tooling for constraint checking. Besides, Manchester 
> Syntax may be a good starting point for a human-readable syntax.
> If this WG focuses on defining closed-world semantics for OWL, then we 
> consider to open a completely new working group for the whole SPIN 
> specification (including SPIN rules), if there is enough interest. OWL 
> and SPIN can happily be used together, and in fact we have SPIN 
> libraries that use OWL declarations and execute them as constraints. 
> SPIN would remain the best choice for cases where the expressivity of 
> OWL is not sufficient.
> Regards
> Holger (on behalf of TopQuadrant)
Received on Thursday, 24 July 2014 03:21:32 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:02:39 UTC