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

I'm in general agreement with Evren here.

In particular, in my view one of the central requirements in any RDF 
constraint system is the ability to associate constraints with RDF types, and 
have these constraints enforced against all instances of the type, even ones 
that come about implicitly.  So, a constraint that people's ages are in a 
particular range is enforced against students, and workers, and employees, and 
instances of all the other subclasses of Person.

Also, I very much agree with the idea of defining constraints using a model 
theory (either RDF or OWL), even though Evren is prepared to not do this. 
One would expect (and maybe require) that this definition be implementable by 
a mapping to SPARQL.  Using a new, complex system for defining the meaning of 
RDF constraints seems a very bad move to me.

There are some improvements that might be made to Stardog ICV, of course.   It 
should be possible to have constraints that are not tied to an ontology.  It 
should be possible to have constraints that don't follow the strict 
object/data divide for OWL properties.  For data languages that have a unique 
minimal model (as do RDF and RDFS) there is a simpler way to define the 
meaning of Stardog ICV constraints.  These are minor changes, however, and 
would move Stardog ICV closer to the other existing RDF constraint systems.

peter



On 07/19/2014 07:55 PM, Evren Sirin wrote:
> What I said at the workshop is what is written in our position paper.
> I said we are not obsessed about the syntax of constraints and there
> can even be multiple different syntaxes for the representation of
> constraints. This does not necessarily mean we should come up with a
> new syntax where there are three different deployed solutions (Stardog
> ICV, IBM Resource Shapes, TopQuadrant SPIN). Note that, the OWL
> constraints implemented in Stardog have the benefit of being already
> supported by existing tools, they are directly representable in RDF,
> and there is a concise human-friendly representation (Manchester
> syntax). We have many examples showing example constraints in RDF and
> Manchester syntax [1].
>
> 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.
>
> I must also emphasize that having the ability to translate from an
> arbitrary syntax to SPARQL is not enough by itself. As an example, one
> common feature in all three of the solutions mentioned above is the
> ability to associate constraints/shapes with an existing type. If I'd
> like to define a constraint that should be satisfied by all instances
> of Person type, I can do it with any of these systems:
>
> [ICV] ex:Person rdfs:subClassOf ...
> [ResSh] ex:PersonShape oslc:describes ex:Person ; ...
> [SPIN] ex:Person spin:constraint "ASK {...}"
>
> In each system a SPARQL query would be generated and every Person
> instance would be validated using this query. With ShEx, the problem
> is kind of reversed and one tries to find the resources that match a
> shape. So I can define a PersonShape in ShEx and a SPARQL query is
> generated but the query is used in a completely different way. As a
> result, every Person instance might not satisfy that shape (a Person
> instance can satisfy a different, irrelevant shape and would be
> considered valid).
>
> 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
>
> [1] http://docs.stardog.com/icv/#sd-ICV-Examples
> [2] http://docs.stardog.com/icv/icv-specification.html
>

Received on Sunday, 20 July 2014 05:52:11 UTC