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

* Peter F. Patel-Schneider <pfpschneider@gmail.com> [2014-12-20 06:43-0800]
> There is no need for verification in OWL constraints or SPIN for the
> RDF graph under consideration to be connected.  All that OWL
> constraints and SPIN care about is what information is contained in
> the RDF graph.
> 
> Also, neither OWL constraints nor SPIN generally start off with a
> single node.  Instead the processing of a typical constraints (in
> SPIN the combination of a class and a SPIN constraint it is
> connected to, in OWL constraints an axiom of the form class <=
> description) starts out by finding all the instances of a class and
> then checking them against the body of the constraint.  The body of
> the constraint can only act on the information in the RDF graph, of
> course, but that's what RDF is all about.
> 
> As SPIN has the entire power of SPARQL, I think that it is possible
> to form constraints that state things like "if there is an instance
> of class X then there must be an instance of class Y in the graph".
> This particular constraint is no possible in OWL constraints,
> however.

Both of these involve a selection process and a verification
process. SPIN's selection process involves enumeration of each triple
in the graph:

* Holger Knublauch <holger@topquadrant.com> [2014-10-25 12:17+1000]
> …
> use owl:imports and spin:imports closure of domain graph
>     forEach triple (?class spin:constraint ?constraint)  # or sub-properties

and calculation of a (rdfs:subClassOf) type closure:

>         forEach ?type := rdfs:subClassOf* ?class
>             use domain graph only
>                 forEach ?instance of ?type

SPIN's verification process is straightforward:

>                     execute ?constraint, pre-binding ?this with ?instance
>                         -> Collect resulting constraint violations


In OWL, the selection process can type inferences from some profile of OWL:

my:CoAuthor 
  owl:equivalentClass 
    [ owl:unionOf (
        foaf:Person 
        [ owl:onProperty my:authored ;
          owl:someValuesFrom my:Papers ] ) ] .

and some constraints to enforce:

my:CoAuthor 
  rdfs:subClassOf 
    [ owl:onProperty foaf:givenName ;
      owl:minCardinality 1 ] ,
    [ owl:onProperty foaf:familyName ;
      owl:cardinality 1 ] ,
    [ owl:onProperty my:authored ; # can't actualy fail because of equiv class above.
      owl:minCardinality 1 ] .

There are likely to be many ways that folks may want to select terms
for verification, by no means limited to: by type (as in conventional
SPIN), query (Axel's proposal), rooted graph (one option in most ShEx
interfaces), every subject node (another option is most ShEx
interfaces). Conventional SPIN and OWL provide a couple.


> peter
> 
> 
> 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 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.
> >
> >Likewise SPIN would depends on essentially separate verification processes
> >kicked off by some mechanism to connect the starting nodes to some shapes.
> >
> >This is essentially a proposed requirement for the mechanism which triggers
> >verification/validation (regardless of whether it's used for validation or
> >description).
> >

-- 
-ericP

office: +1.617.599.3509
mobile: +33.6.80.80.35.59

(eric@w3.org)
Feel free to forward this message to any list for any purpose other than
email address distribution.

There are subtle nuances encoded in font variation and clever layout
which can only be seen by printing this message on high-clay paper.

Received on Saturday, 20 December 2014 19:29:33 UTC