RE: Can Shapes always be Classes?

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

Though I am only lurking on this list, I do agree with Holger on this point: SPARQL is the RDF query language. ShEx is new to me. If SPARQL/SPIN can satisfy requirements, then I would not be keen on introducing a different technology. 

-----Original Message-----
From: Holger Knublauch [] 
Sent: Wednesday, 19 November 2014 11:56 AM
Subject: Re: Can Shapes always be Classes?

On 11/19/2014 9:47, Eric Prud'hommeaux wrote:
> * Holger Knublauch <> [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:

     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.


Received on Wednesday, 19 November 2014 01:06:38 UTC