Re: Can Shapes always be Classes?

One further thought. When the validity of submitter and assignee only/mostly exist in the context of the submitted item (issue), then the validation constraint can be,and probably should be, attached at the issue level, e.g., an issue must have a submitter such that the submitter has an e-mail.

In this case, there would be no need to have the submitter type triple for Bob.

Irene 

> On Nov 6, 2014, at 10:46 AM, Irene Polikoff <irene@topquadrant.com> wrote:
> 
> 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. 
> 
> 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.
>>

Received on Thursday, 6 November 2014 16:11:59 UTC