RE: Can Shapes always be Classes?

So that would mean it's within SPARQL expressivity (so long as it's not
recursive) but not in the more declarative template language.

On Nov 6, 2014 10:15 PM, "Irene Polikoff" <irene@topquadrant.com> wrote:
>
> Yes, along these lines.
>
> -----Original Message-----
> From: Eric Prud'hommeaux [mailto:eric@w3.org]
> Sent: Thursday, November 06, 2014 3:57 PM
> To: Irene Polikoff
> Cc: 'Peter F. Patel-Schneider'; 'Holger Knublauch';
public-data-shapes-wg@w3.org
> Subject: RE: Can Shapes always be Classes?
>
> * Irene Polikoff <irene@topquadrant.com> [2014-11-06 15:34-0500]
> > I would put these constraints directly on the Issue class.
> >
> > Peter's suggestion of associating constraints with rdfs:Resource also
works. Although, in the presence of large data sets/streams, one doesn’t
want to have to check everything for every resource. A key feature of
class-associated constraints is that they provide for scoping. When data is
small, it doesn’t really matter. For larger data sets, a better practice
would be to minimize the number of un-scoped or too broadly scoped
constraints.
>
> If I understand, you would add the submitter and assignee constraints to
the Issue class itself. Would that be in the form of a SPARQL that tested
the cardinality and object of all of their respective properties?
>
>
> > Irene
> >
> > -----Original Message-----
> > From: Eric Prud'hommeaux [mailto:eric@w3.org]
> > Sent: Thursday, November 06, 2014 12:59 PM
> > To: Irene Polikoff
> > Cc: Peter F. Patel-Schneider; Holger Knublauch;
> > public-data-shapes-wg@w3.org
> > Subject: Re: Can Shapes always be Classes?
> >
> > * Irene Polikoff <irene@topquadrant.com> [2014-11-06 10:46-0500]
> > > True - if you have data without any type triples, they would need to
be inferred first. Not a problem and, furthermore, in my experience, this
situation is atypical.
> >
> > _:Bob has a type arc (foaf:Person), but that type doesn't fully
discriminate all of the possible constraints to which it may conform, as
would be the case with pretty much any publicly-consumable data.
> > This is less an issue for proprietary data confined to a known number
of business processes.
> >
> >
> > > Applications know what 'objects' they are dealing with. They specify
this info in their output and expect it in their input.
> > >
> > > Also, to get any kind of validation for assignee and submitter, there
must be some triples with them as subjects in this example - otherwise,
there is nothing to validate.
> > >
> > > Irene
> > >
> > > Sent from my iPhone
> > >
> > > > On Nov 6, 2014, at 10:29 AM, Eric Prud'hommeaux <eric@w3.org> wrote:
> > > >
> > > > * 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.
> > > >
> >
> > --
> > -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.
>