Re: Shapes/ShEx or the worrying issue of yet another syntax and lack of validated vision.

On Sat, Jul 19, 2014 at 10:55 PM, Evren Sirin <evren@clarkparsia.com> wrote:


> At the workshop, I focused on other points that we think are
> more important: expressivity and semantics. We think the expressivity of
> constraints should be equivalent to SPARQL and the semantics should
> be defined via translation to SPARQL. Defining semantics in terms of
> SPARQL solves the issue of how reasoning interacts with constraints since
> there are SPARQL entailment regimes for RDFS, OWL 2 and RIF.


[...]

The semantics of Stardog ICV is given in terms of a model theory [2] but it
> can alternatively be described via SPARQL translation and that
> is how our implementation works.
>

[...]
> As a summary, ignoring the existing solutions that have been in use for
> quite some time and starting from scratch with a new syntax and
> completely new semantics is not the right way to go.
>
> Best,
> Evren
>
> [2] http://docs.stardog.com/icv/icv-specification.html


+1

BLUF: It is better to build on  existing production experience. There are
some  issues with current SPARQL entailment regime recommendations . If
SPIN is used as part of a solution SPIN should go through recommendation
track process. OWL may be a good starting point for specifying constraints.
  Patterns in constraints may suggest new syntactic sugar for OWL.  There
are semantic extensions of OWL used in constraint processing that might be
worth standardizing separately.  Any working group chartered to prepare a
recommendation on constraints should be chartered to update/advance any
recommendations it depends on, with membership composed accordingly.

Also, epistemic.

-------

I would note that the SPARQL Entailment Regimes  document is out of sync
with RDF 1.1 semantics (mostly the new semantics of D-entailment and
ill-typed literals).

If a recommendation track working group is going to be chartered for a
SPARQL based solution, the charter ought to include producing a revised RDF
1.1 compatible version of the entailment regimes document.

I would also note that SPIN is too powerful a tool just for handling
constraints.  If the mappings from a Recommendation Track  Constraint
language are to  SPIN then it would seem to be a good idea to put SPIN
through the Rec Track process so that the constraint language can use of
the desired subset (it would seem troubling to have a Recommendation that
made normative use of a simple submission, and it would seem unwise to fork
a  subset of SPIN used by one class of application.

OWL would seem to be the obvious choice for specifying RDF constraints, and
the ICV semantics are quite well grounded.

There may be some constraints that are common enough to deserve additional
 syntactic sugar . A common example is expressing type constraints on the
value of a predicate  based on the type of the subject.  Restriction
classes are hard to explain to new OEs;  constructs equivalent to  the ACE
sentence "Everything that a weasel eats is an egg.", or the Cyc interArgIsa
predicate may simplify matters (though the ACE sentence is handled by the
ACE->OWL translator).

There are issues of locally closed  classes and predicates;  there are
several systems out that have implemented this, and there are choices that
can be made as to whether these extensions are worthy of standardization.
 It may be desirable to distinguish between classes where the complete
extent is known (by inference), and classes where the complete extent is
asserted (no inference);  this distinction is possible in Cyc, but does not
seem to be used in any OWL NAF approaches.

There are also issues of general n-UNA control that might be worthy of
consideration.

As a side note, I believe it may be desirable to model the underlying
semantics using some epistemic logic , but I don't know.
K bye