RE: Can Shapes always be Classes?

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.

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.

Received on Thursday, 6 November 2014 20:35:07 UTC