Re: TopQuadrant's position on RDF Shapes working group

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> 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)
>
>