Re: Can Shapes always be Classes?

On 11/19/2014 9:47, Eric Prud'hommeaux wrote:
> * Holger Knublauch <holger@topquadrant.com> [2014-11-06 09:38+1000]
>> I think it's encouraging to read suggestions on how we could merge
>> ideas from the various proposals, e.g. extend SPIN to make the
>> scenario below easier to represent. This is always a possibility.
>>
>> Thanks for providing a specific example, which makes our discussion
>> more focused. I do believe that the example below can be expressed
>> with the existing SPIN spec via something like
>>
>> :Issue
>>      spin:constraint [
>>          a sp:Ask ;
>>          sp:text """
>>              # The assignee must have an mbox
>>              ASK {
>>                  ?this :assignedTo ?assignee .
>>                  FILTER NOT EXIST { ?assignee foaf:mbox ?any }
> multiplied out for cardinality over :submittedBy:{given,family},
> status=unassigned | (status=assigned &&
> assignedTo/{givenName,familyName,mbox}), etc. gave me the 107 lines of
> SPARQL at the bottom of this message.

Instead of all these nested SELECTS to compute cardinalities, in SPIN 
you would just use the function spl:objectCount(?subject, ?predicate). 
Any number of similar helper functions can be defined to make the 
queries significantly shorter.

So hypothetically assuming someone would really want to mix everything 
into a single query, here is how your example could be expressed in SPIN:

ASK {
     FILTER shape:constrain(?this, :name, rdfs:Literal, 1, 1) .

     ?this :submittedBy ?submitter .
     FILTER shape:constrain(?submitter, foaf:givenName, rdf:Literal, 1, 1) .
     FILTER shape:constrain(?submitter, foaf:familyName, rdf:Literal, 0, 
1) .

     ?this :status ?status .
     {
          FILTER (?status = :assigned) .
          ?this :assignedTo ?assignee .
          FILTER shape:constrain(?assignee, foaf:givenName, rdf:Literal, 
1, 1) .
          FILTER shape:constrain(?assignee, foaf:familyName, 
rdf:Literal, 1, 1) .
          FILTER shape:constrain(?assignee, foaf:mbox, rdfs:Resource, 1, 
1) .
     }
     UNION {
         FILTER (?status = :unassigned || ?status = :unknown) .
     }

      FILTER shape:constrain(?this, :related, rdfs:Literal, 0, -1) .
}

where shape:constrain would be a helper function which checks that all 
values of a given subject/predicate combination are of a given type, and 
have given min/max cardinalities.

With this helper function, the SPARQL syntax has the same number of 
lines like your ShExC snippet. (There could probably even be a converter 
that takes a controlled subset of SPARQL and rewrites it into ShExC and 
vice versa - the focus of ShEx is on combinations of cardinality and 
range constraints, and not much else).

Eric, I would encourage you now to do the same that I am doing here for 
you: please show us how the various other examples in the User Stories 
section are expressed in ShEx. Let's please level the playing field 
here, and not just look at the examples that motivated the creation of 
ShEx. It is quite easy to make a point if you can define the 
requirements and select the examples yourself. There is no doubt that 
ShEx is good for a certain class of use cases.

Once you look at other examples, you may discover that ShEx is not 
expressive enough for many other real-world use cases.  Nor do I believe 
that those context-sensitive scenarios like the artificial bug tracker 
example are representative of the majority of use cases.

My point in this discussion is that with ShEx we would basically create 
an alternative to SPARQL, and I do not see enough convincing arguments 
that would favor a completely new language over an already established 
one, especially if that new language lacks many other features that have 
already been shown to be needed in practice. SPARQL could certainly need 
syntactic sugar for our constraint use cases, and SPIN functions like 
the one above would be one way of achieving that without even requiring 
a change to SPARQL itself.

I would also welcome other people on this WG to join this discussion - I 
don't see why it always has to be me defending SPARQL :)

> Any time you see a restriction in OWL you have an example of a 
> contextual constraint. OWL literature pretty much indoctrinates for 
> constraining general predicates for us in particular classes, e.g. the 
> pizza tutorial's :hasTopping. I've used many nested property 
> restrictions in the projects that I've worked on. 

That's fine, and can be expressed in SPARQL too.

Regards,
Holger

Received on Wednesday, 19 November 2014 00:58:18 UTC