Re: TopQuadrant's position on RDF Shapes working group

Off the top of my head, standardizing SPIN as a whole could include:

Recommendation Track:
- SPIN Constraints and Templates (spin:constraint, sp:text etc [2], [4])
- SPIN Constraints Standard Template Library (spl:Argument, 
spl:MinCardinality etc, TODO)
- SPIN Rules (spin:rule [3])

Not Recommendation Track (i.e. not mandatory for implementations)
- SPIN RDF Syntax [1]
- SPIN Functions/Magic properties [5]

This includes some features that are not essential for constraint 
checking: SPIN rules are widely used for ontology mapping use cases. An 
example use case is the OWL 2 RL implementation [6]. SPIN functions and 
magic properties are a mechanism to define new SPARQL functions based on 
other SPARQL functions (as stored procedures). These are in our 
experience extremely helpful in defining maintainable SPARQL queries, 
constraints and rules that reuse functionality.

The Member Submission includes a few more features that likely can be 
pruned off because they are not essential and would only delay an 
agreement process. This includes spin:constructors, the properties used 
to select the execution order of rules, and INSERT/DELETE rules 
(non-monotonic reasoning).

To those from the W3C: would forming a new WG just for SPIN be a 
realistic option? As Simon says, the other WG on Closed-world OWL would 
be orthogonal to that SPIN group, because both approaches can be used in 
conjunction with each other.

Cheers,
Holger

[1] http://spinrdf.org/sp.html
[2] http://spinrdf.org/spin.html#spin-constraint-construct
[3] http://spinrdf.org/spin.html#spin-rules-construct
[4] http://spinrdf.org/spin.html#spin-templates
[5] http://spinrdf.org/spin.html#spin-functions
[6] http://topbraid.org/spin/owlrl-all.html


On 7/22/2014 15:03, Simon Spero wrote:
>
> I think I'm pretty much in agreement, but with differently ordered 
> preferences.
>
> As I mentioned previously, I think it might be better to
>
> (a) Rec. Track SPIN as a whole, and:
>
> (b) Rec. Track an CWA/minimized nUNA semantics s for OWL,  (basically 
> ICV), with summaries of complexity results, together with:
>
> (c) a fully specified mapping to SPARQL/SPIN, with the subset of SPIN 
> used being:
>
> (d) a SPIN Constraint Profile (the subset)
>
> (e)  A review of common constraints may find that many are already in 
> OWL, and may suggest where syntactic sugar is needed.  There may be 
> existing work that may indicate potential problems (which may or may 
> not carry over to ICV semantics).
>
> ---
>
> Given that  just matching rdf:type in ShEx may be in PSPACE, changing 
> it to handle the output of any entailment regime beyond D-entailment 
> may require some work.
>
> A revised specification, defined as mappings to SPIN constraint, or 
> ICV may be a useful experiment, and could be a useful WG Note.
> Important constructs that cannot be mapped may suggest changes to the 
> other systems.
>
>   Conversely, converting ICV  constraints to ShEx and examine the 
> complexity may indicate places where ShEx might require modifications.
>
> I don't think it is a good idea to RT ShEx as it stands.
> Autocorrect on my tablet keeps talking about sheds - it's dangerous to 
> have more than one or paint any.
>
> Simon
>
> On Jul 21, 2014 11:23 PM, "Holger Knublauch" <holger@topquadrant.com 
> <mailto:holger@topquadrant.com>> 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)
>