Re: Can Shapes always be Classes?

* Eric Prud'hommeaux <eric@w3.org> [2014-11-06 09:20-0500]
> * Peter F. Patel-Schneider <pfpschneider@gmail.com> [2014-11-05 14:46-0800]
> > I'm having a hard time figuring out how "context-sensitive grammars"
> > fit into this discussion.  As far as I can tell, every proposal has
> > the ability to decouple the constraints/shapes from ontologies.  As
> > far as I can tell, every proposal has the ability to only run the
> > constraints/shapes against some nodes in a graph.  This doesn't make
> > any of these context-sensitive grammars in the formal sense of the
> > word, just that the determination of which nodes to look at when
> > doing constraint/shape checking depends on some notion of context.
> > 
> > It appears to be true that the only context that can be provided for
> > SPIN constraints comes from rdf:type triples (which are no way,
> > shape, form, or context to be considered annotations, by the way).
> 
> Try the exercise of validating this data:
>   _:IssueA :submittedBy _:Bob ; :assignedTo  _:Bob .
> against this schema:
>   OWL:
>     Class: x:NewIssueShape
>       SubClassOf:
>         :submittedBy some x:SubmitterShape,
>         :assignedTo some x:AssigneeShape
>   ShExC: 
>     x:NewIssueShape {
>       :submittedBy @x:SubmitterShape,
>       :assignedTo @x:AssigneeShape
>     }
> 
> In OWL, Resource Shapes, ShExC (DC Application Profiles, …), the
> validator is testing _:Bob against two shapes, one for submitters
> and one for assignees. In SPIN, one would have to first infer that
>   _:Bob a x:SubmitterShape, x:AssigneeShape .
> via e.g. some OWL RL inference in order to trigger the associated
> SPIN constraints.

Maybe I should add that I described the current limitation in terms of
context-sensitivity because the current algorithm doesn't enable the
context (e.g. an owl:Restriction) to assert that _:Bob (a foaf:Person)
should be constrained as a submitter and as an assignee.


> > It also appears to be true that ShEx constraints are provided
> > separately from the shapes themselves.  The context for OWL
> > constraints is determined by the form of the axiom, and can be the
> > class membership of a node, the properties of a node, a particular
> > node, and even other things.  OWL constraints can get context out of
> > RDF graphs that have no rdf:type triples at all, but they can also
> > exploit the full power of RDFS class membership.
> > 
> > peter
> > 
> > 
> > On 11/05/2014 10:25 AM, Eric Prud'hommeaux wrote:
> > >* Holger Knublauch <holger@topquadrant.com> [2014-11-05 15:35+1000]
> > >>On 11/5/2014 15:26, Irene Polikoff wrote:
> > >>>>From: Holger Knublauch [mailto:holger@topquadrant.com]
> > >>>>Sent: Wednesday, November 05, 2014 12:16 AM
> > >>>>To: public-data-shapes-wg@w3.org
> > >>>>Subject: Can Shapes always be Classes?
> > >>>>
> > >>>>I believe there is a fundamental difference in how the various proposals
> > >>>>treat the relationship between resources and their shapes:
> > >>>>
> > >>>>- In OWL and SPIN, constraints are attached to classes. rdf:type triples are
> > >>>>used to determine which constraints need to be evaluated for a given
> > >>>>instance.
> > >>>>
> > >>>>- In the original Resource Shapes and ShEx, Shapes are stand-alone entities
> > >>>>that may or may not be associated with a class. Other mechanisms than
> > >>>>rdf:type are used to point from instances to their shapes.
> > >>>>
> > >>>>I believe the main motivation for the latter design are the User Stories
> > >>>>S7 and S8: different shapes at different times, and properties can change as
> > >>>>they pass through the workflow. I would like to learn more about this and
> > >>>>have specific examples that we can evaluate.
> > >>>>
> > >>>>My current assumption is that these scenarios can be expressed via named
> > >>>>graphs, so that different class definitions are used in different contexts.
> > >>>>Which graph to use would be specified in some kind of header metadata or via
> > >>>>a special property (e.g. owl:imports). Alternatively, different classes
> > >>>>could be used, just like different shapes are used depending on the context.
> > >>>>I argue that using rdf:type and RDFS classes is a well-established mechanism
> > >>>>that we should try to build upon. What problems do the proponents of the
> > >>>>decoupling see with those ideas?
> > >
> > >I think the fundamental issue is whether these are effectively
> > >context-sensitive grammars. As currently proposed, SPIN depends on
> > >type annotations attached to the data. It would be possible to add a
> > >step which creates a premise when validating some node. I believe this
> > >would get around all of the issues stemming from requiring fully
> > >discriminating types.
> > >
> > >Use Case: context-sensitive-rooted-issue-interface
> > >
> > >An LDP service accepts new Issues. A posted issue is expected to have
> > >a :name, :status and a :submittedBy. If the status is :assigned, it
> > >must have an :assignedTo . It may also have references to other Issues
> > >which may or may not be in the system so they are referenced by :name.
> > >
> > >Sample Data:
> > >   _:IssueA a :Issue ;
> > >     :name        "funny smell and no lights" ;
> > >     :status      :assigned ;
> > >     :submittedBy _:Bob ;
> > >     :assignedTo  _:Bob ;
> > >     :related     [ a :Issue ; :name "smoke coming from unit" ],
> > >                  [ a :Issue ; :name "110V capacitor in French unit" ] .
> > >
> > >   _:Bob    a foaf:Person ;
> > >     foaf:givenName "Bob" ;
> > >     foaf:familyName "Smith" ;
> > >     foaf:mbox    <mailto:bob@example.com> .
> > >
> > >There are multiple nodes of type :Issue so the client can specify the
> > >start node as _:IssueA (e.g. in a header). This makes the posted data
> > >a "pointed graph".
> > >
> > >If the requirements for the :submittedBy and the :assignedTo are
> > >different, we have need context-sensitivity.
> > >
> > >   x:NewIssueShape {
> > >     :name LITERAL,
> > >     :submittedBy @x:SubmitterShape,
> > >     (:status (:unassigned :unknown)
> > >      | :status (:assigned),
> > >        :assignedTo @x:AssigneeShape),
> > >     :related { :name LITERAL }*
> > >   }
> > >
> > >   x:SubmitterShape {
> > >     foaf:givenName LITERAL,
> > >     foaf:familyName LITERAL?
> > >   }
> > >
> > >   x:AssigneeShape {
> > >     foaf:givenName LITERAL,
> > >     foaf:familyName LITERAL,
> > >     foaf:mbox IRI
> > >   }
> > >
> > >If we have some OWL like (eliding cardinalities):
> > >
> > >   Class: x:NewIssueShape
> > >     SubClassOf:
> > >       :name some rdfs:Literal,
> > >       :submittedBy some x:SubmitterShape,
> > >       (:status value :unassigned
> > >        or
> > >        (:status value :assigned and :assignedTo some x:AssigneeShape))
> > >       :related (:name rdfs:Literal)
> > >
> > >   Class: x:SubmitterShape
> > >     SubClassOf:
> > >       foaf:givenName some rdfs:Literal,
> > >       foaf:familyName some rdfs:Literal
> > >
> > >   Class: x:AssigneeShape
> > >     SubClassOf:
> > >       foaf:givenName some rdfs:Literal,
> > >       foaf:familyName some rdfs:Literal,
> > >       foaf:mboxName some rdf:Resource
> > >
> > >, we can validate the data with the premise _:IssueA a x:NewIssueShape.
> > >The validation will recursively test the nested constraints. This of
> > >course hinges on being able to verify a premise.
> > >
> > >It seems reasonable to extend SPIN to test premises. It could use the
> > >same idea where instead of an rdfs:range to specify an expected object
> > >type, one could use Resource Shapes' rs:valueShape. This would assert
> > >the premise that e.g. _:Bob a x:SubmitterShape and then another
> > >_:Bob a x:AssigneeShape .
> > >
> > >
> > >>>>I think this is a major design decision that we need to clarify early.
> > >>>>Instead of excluding those scenarios, I would like to accommodate them
> > >>>>without having to introduce completely new mechanisms.
> > >>>>
> > >>>Holger,
> > >>>
> > >>>I believe you are saying that there could be two (or more) named graphs each
> > >>>containing different sets of constraints for a particular classes (or
> > >>>classes). For example:
> > >>>
> > >>>Graph A: contains rdf:type statements for a set of classes and properties.
> > >>>Can also contain other RDFS or OWL axioms
> > >>>
> > >>>Graph B: contains some constraints for classes declared in Graph A
> > >>>
> > >>>Graph C: contains a different set of constraints for classes declared in
> > >>>Graph A
> > >>>
> > >>>And so on
> > >>>
> > >>>A given application can then chose what set of constraints it will be using
> > >>>- Graph B or Graph C.
> > >>>
> > >>>Is this correct?
> > >>
> > >>Yes sorry I was brief. Let's take an extreme use case, where the
> > >>same ex:Instance must fulfill different constraints in scenario A
> > >>and B.
> > >>
> > >>     ex:Instance
> > >>         a ex:Person ;
> > >>         foaf:firstName "John" .
> > >>
> > >>Scenario A: Each Person can have any number of first names.
> > >>
> > >>Scenario B: Each Person must have exactly one first name.
> > >>
> > >>In scenario A, it would have
> > >>
> > >>     <instance graph> owl:imports <schema A>
> > >>
> > >>where <schema A> is simply the unconstrained class definition.
> > >>
> > >>     ex:Person a rdfs:Class .
> > >>
> > >>In scenario B, it would owl:import <schema B> which is
> > >>
> > >>     ex:Person a rdfs:Class ;
> > >>         constraint foaf:firstName exactly 1 .
> > >>
> > >>I hope this explains the named graph work-around.
> > >>
> > >>Holger
> > >
> 
> -- 
> -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.
> 

-- 
-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 Thursday, 6 November 2014 15:29:47 UTC