Re: Can Shapes always be Classes?

* Holger Knublauch <holger@topquadrant.com> [2014-11-07 12:47+1000]
> On 11/7/2014 12:05, Eric Prud'hommeaux wrote:
> >* Holger Knublauch <holger@topquadrant.com> [2014-11-07 08:28+1000]
> >>This context-sensitive constraint would be attached to Issue
> >>(because it is really issue-specific, and does not apply to all
> >>Person instances).
> >Could you mock that up using the data and schema earlier in this
> >thread?
> 
> I believe I already did here:

For others following this thread....

> http://lists.w3.org/Archives/Public/public-data-shapes-wg/2014Nov/0044

This one uses SPARQL like "FILTER NOT EXIST { ?assignee foaf:mbox ?any }",
which I don't think bears on the Shapes=Classes discussion. (All of the
technologies can be compiled to SPARQL; what differs is whether the more
declarative form can be convey constraints that don't require a fully-
discriminating type. It also proposes an extension to enable context-
sensitive constraints, but this is explored more fully below.


> and (with possible extensions) here:
> 
> http://lists.w3.org/Archives/Public/public-data-shapes-wg/2014Nov/0075

This proposes a spin:ContextSensitiveConstraint extension to the SPIN
constraint vocabulary, enabling SPIN to express contextual constraints
that aren't tied to a type. Extending this to capture the initial example:


> :Issue
>     spin:constraint [
>         a spin:ContextSensitiveConstraint ;
>         spin:context :assignedTo ;
>         spin:childConstraint [     // This gets executed for the Assignees
>             a spl:RequiredPropertyConstraint ;
>             spl:property foaf:mbox
>         ]
>     ]


> >I ask because the uses of SPIN templates that I've seen have
> >all involved rdfs:range inference applied globally to a predicate
> >while common practice (at least among the OWL community) is to keep
> >predicates as reusable as possible by constraining their use in
> >particular contexts with onProperty restrictions.
> 
> No. I am not sure which SPIN templates you have seen, but there is
> zero reliance on rdfs:range or inferencing in general in SPIN. I
> must misunderstand what you mean.

I've been looking at messages on this list, e.g.
  http://lists.w3.org/Archives/Public/public-rdf-shapes/2014Jul/att-0002/sotaspin-text.spin.ttl
This is an old message and maybe I should be looking at newer
examples but the implementation of Resource Shapes in SPIN
  http://www.w3.org/mid/53D1FDF7.7040304@topquadrant.com
doesn't show me the SPIN proposal for oslc:valueShape . Settling the
questions of whether shapes should be separable from types requires
some examination for how the use cases met by OWL restrictions,
oslc:valueShape or ShExC valueReferences ("@<shapename>") can be met.


> I would actually consider global domains/ranges as an anti-pattern:
> all object-oriented systems allow the reuse of property names and
> scope those properties relative to a class, not globally. schema.org
> is a good example of that, and the problems of enforcing global
> ranges/domains. I had given examples of how SPIN can represent
> localized Resource Shapes and even owl:allValuesFrom using SPIN

I didn't find the example of a spin template for owl:allValuesFrom,
though I did find refs to it in replies to Karen and Axel.

OWL can certainly express these constraints, and per the paper that
Peter cited, can be compiled to SPARQL. I expect that anything that
can be compiled to SPARQL can also be parameterized in a SPIN template
to effectively execute that same SPARQL query (using arg variables
bound by matching a particular OWL idiom).

I'm afraid I don't follow the reference to "localized Resource Shapes".
Is this another way of capturing the spin:ContextSensitiveConstraint you
sketched out in 0075?


> templates. The fact that SPIN uses the class hierarchy as its basic
> evaluation structure makes it natural to attach range constraints to
> a branch of the class tree only.
> 
> >>                    Most other constraints on Person would remain
> >>globally, so one would only need to cover the small differences that
> >>are Issue-specific (and the default constraints get owl:imported
> >>from another file). So the delta that is actually needed here is
> >>quite small. And is this even a real use case, or a constructed
> >>example? Why should not every user of the Issue tracker have an
> >>email address?
> >Just about any time you see re-used types, there is a strong
> >possibility that different people will have different restrictions on
> >their use.
> 
> Yes, and that's not a bug but a feature. I also wonder how the
> situation would change with stand-alone Shapes. In ShEx someone
> would publish an ontology together with a set of Shapes, and others
> can chose to reuse or ignore those Shapes. In OWL or SPIN they would
> just use named graph, and we usually recommend separating the schema
> itself (just the classes and properties) from their constraints into
> separate named graphs/files. People can then chose what they want to
> owl:import. Yet all these semantic variations can be published on a
> web server. I am obviously not talking about "The Semantic Web"
> here, where everything would be union'ed together - this is
> unrealistic to begin with.

If we examine this in my context-sensitive example, types don't have
any bearing on the constraint. The example data had a foaf:Person
serving a couple roles in an issue:

* Eric Prud'hommeaux <eric@w3.org> [2014-11-05 13:25-0500]
>   _:IssueA a :Issue ;
…
>     :submittedBy _:Bob ;
>     :assignedTo  _:Bob ;
…   .
>   _:Bob    a foaf:Person ;
>     foaf:givenName "Bob" ;
>     foaf:familyName "Smith" ;
>     foaf:mbox    <mailto:bob@example.com> .

The requirements for those roles differ:

>   x:SubmitterShape {
>     foaf:givenName LITERAL,
>     foaf:familyName LITERAL?
>   }
> 
>   x:AssigneeShape {
>     foaf:givenName LITERAL,
>     foaf:familyName LITERAL,
>     foaf:mbox IRI
>   }

To what type would we assign the submitter and assignee constraints?

The instance data may or may not have a foaf:Person type (it doesn't
affect the application logic) and we wouldn't want to make sweeping
assertions about foaf:Person anyways. We can attach constraints to
types x:SubmitterShape and x:AssigneeShape and test premises:

  when validating _:IssueA :submittedBy _:Bob .
  assume that _:Bob a x:SubmitterShape .
  and validate _:Bob.

  when validating _:IssueA :assignedTo _:Bob .
  assume that _:Bob a x:AssigneeShape .
  and validate _:Bob.

This basically emulates the semantics of owl:allValuesFrom and the
behavior of oslc:valueShape or ShExC valueReferences. Adding
contextual constraints to SPIN would allow it to meet many clinical
use cases where specific observations confer restrictions on the
result.


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

Received on Friday, 7 November 2014 11:46:08 UTC