RE: Can Shapes always be Classes?

Hmm ... This seems like a digression since there is no need to programmatically get any properties. When one uses SPIN, there is no inference or logic of any kind that gets "relevant" properties. 

For example:

SPIN template:

ss:PositivePropertyValueConstraint a spin:ConstructTemplate ;
    spin:constraint [ a spl:Argument
        spl:predicate arg:property ;
        spl:valueType rdf:Property ;
        rdfs:comment "The property to constrain (e.g. ss:width)"
    ] ;
    spin:body [ a sp:Construct ;
        sp:text """
            # The value of ss:width must be > 0
            CONSTRUCT {
                _:cv a spin:ConstraintViolation ;
                    spin:violationRoot ?this ;
                    spin:violationPath ?property ;
                    rdfs:label "Positive value expected"
            } 
            WHERE {
                ?this ?property ?value .
                FILTER (?value <= 0) .
            }
            """
    ] ;

Using the template:

ss:Rectangle
    spin:constraint [
        a ss:PositivePropertyValueConstraint ;
        arg:property ss:height ;
    ] ;
    spin:constraint [
        a ss:PositivePropertyValueConstraint ;
        arg:property ss:width ;
    ] .

There is nothing here that requires that ss:width is associated with ss:Rectangle using either a domain statement or a restriction. Any property can be used with this template with the result that if there are the following triples

?x a ss:Rectangle
?x <property specified as the argument for the template> ?value

The constraint will be checked.

One could possibly define a global constraint at the owl:Thing level, the role of which would be to check that all members of any class have all properties that they must have according to the ontology definitions and that their ranges are correct. Such template would take no arguments. And, indeed, if these properties are associated with classes using complex OWL axioms (note that not only "straight" restrictions are possible, but also combinations of intersections, restrictions, unions and so on - although in practice we don’t see much of these), the SPARQL behind the template would have to use some complex logic since finding all the "relevant" properties defined in an arbitrarily complex ontology is non trivial.

We use SPARQL extensibility to define property functions like tops:relevantPropertiesOfClass and tops:localRanges which take into account various things. But, as I said, this seems to be a digression.

Did I understand the question correctly?

Irene

-----Original Message-----
From: Eric Prud'hommeaux [mailto:eric@w3.org] 
Sent: Thursday, November 06, 2014 9:05 PM
To: Holger Knublauch
Cc: public-data-shapes-wg@w3.org
Subject: Re: Can Shapes always be Classes?

* Holger Knublauch <holger@topquadrant.com> [2014-11-07 08:28+1000]
> 
> On 11/7/14, 6:57 AM, Eric Prud'hommeaux wrote:
> >* 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?
> >
> 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 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.


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


> Honestly to me it feels like the whole concept of stand-alone, 
> detached Shapes was created as syntactic sugar for corner cases, while 
> being less than ideal for the "normal" case of classes with global 
> constraints. That's my impression at least, as I don't remember ever 
> having run into such scenarios where the above-mentioned work-arounds 
> would not have been acceptable.
> 
> 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 03:01:09 UTC