Re: shapes-ISSUE-18 (S35 examples): S35 needs to state what constraints are required

On 12/20/2014 01:34 AM, Eric Prud'hommeaux wrote:
>
> On Dec 19, 2014 5:01 AM, "RDF Data Shapes Working Group Issue Tracker"
> <sysbot+tracker@w3.org <mailto:sysbot%2Btracker@w3.org>> wrote:
>  >
>  > shapes-ISSUE-18 (S35 examples): S35 needs to state what constraints are
> required
>  >
>  > http://www.w3.org/2014/data-shapes/track/issues/18
>  >
>  > Raised by: Peter Patel-Schneider
>  > On product:
>  >
>  > S35
> https://www.w3.org/2014/data-shapes/wiki/User_Stories#S35:_Describe_disconnected_graphs
> talks about constraints over disconnected graphs.  However, it does not state
> why disconnected graphs are different from connected graphs?  Are the
> constraints supposed to recognize disconnected graphs?  Or are the constraints
> just supposed to work on disconnected graphs, and what differences in
> constraint handling are required for disconnected graphs.
>  >
>  > SPIN and OWL constraints don't care whether a graph is connected or
> disconnected.
>
> I'm trying to understand this last statement. If I had an OWL CWA/UNA engine,

I'm not sure what an OWL CWA/UNA engine is.

> I could presumably use something like OWL API to ask if a particular node
> conforms to some class (as a shape) definition. There's no mechanism in OWL
> that would enable that verification process to reach any node not connected to
> that started node. One would simply have to verify both nodes or invent some
> sort of packaging language which would entail both verifications.

Neither OWL constraints nor SPIN have a global notion of a starting node.  In 
SPIN you can think of a typical constraint as being attached to a class, and 
then think of incarnations of that constraint starting with instances of that 
class.  In OWL constraints constraints come in many forms, but a typical form 
is a class axiom stating that a class name is a subclass of a description. 
You can then consider incarnations of that constraint starting off at 
instances of the class.

> Likewise SPIN would depends on essentially separate verification processes
> kicked off by some mechanism to connect the starting nodes to some shapes.

I don't think that this is a good way of looking at SPIN.  SPIN constraints 
are generally pointed at from classes, and this connection is used to provide 
the bindings for the ?THIS variable in the SPARQL query, but not all SPIN 
constraints work this way.

> This is essentially a proposed requirement for the mechanism which triggers
> verification/validation (regardless of whether it's used for validation or
> description).

I would state what I think this means along the lines of:

It must be possible to check a condition on all instances of a class in an RDF 
graph.

This requirement doesn't depend on the graph being connected.


In both SPIN and OWL constraints, the general idea is to have multiple 
constraints in a single constraint document.  In this way it is easy to have 
one constraint that checks certain nodes in the RDF graph and a different 
constraint that checks other nodes.  There does not need to be any connection 
in the RDF graph from any of the first set of nodes to any of the second set 
of nodes.  This is another reason why I state that SPIN and OWL constraints 
don't care whether an RDF graph is connected or disconnected.

peter

Received on Saturday, 20 December 2014 15:04:16 UTC