Re: Can Shapes always be Classes?

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).  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.


On 11/05/2014 10:25 AM, Eric Prud'hommeaux wrote:
> * Holger Knublauch <> [2014-11-05 15:35+1000]
>> On 11/5/2014 15:26, Irene Polikoff wrote:
>>>> From: Holger Knublauch []
>>>> Sent: Wednesday, November 05, 2014 12:16 AM
>>>> To:
>>>> 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    <> .
> 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

Received on Wednesday, 5 November 2014 22:46:45 UTC