Re: Can Shapes always be Classes?

Simon,

I believe the argument here is that a) ShEx is an alternative to a well established language that b) is comparable to the established one in syntactic complexity and c) can't address all identified requirements.

We all agree with a). To help the group assess b) and c) you or Eric, as ShEx proponents, should write ShEx implementations for all identified use cases. To me this seems to be a necessary step.

Regards,

Irene


> On Nov 19, 2014, at 4:44 AM, Simon Steyskal <ssteyska@wu.ac.at> wrote:
> 
> Hi!
> 
>> 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.
> 
> Although I completly agree with your arguments regarding the redundancy of introducting a completely new formalism instead of sticking to the "old" establish ones, I see the major advantage of e.g. ShEx in its easy to read syntax and similarity to RegExp.
> 
> I'm working partly on industrial related projects with engineers which are not that familiar with semantic technologies but are somewhat open minded regarding the use of those technologies for their use cases. After I've attended this years SEMANTiCS and the headsup I gave them regarding RDF validation/"CW reasoning"/ShEx/etc. they(we) are really looking forward to the results of this WG (primarily because of the aforementioned reasons).
> 
> I think, if we want to reach even those data scientist/engineers/.. we might want to use a language/formalism like ShEx (maybe in addition?) which would ease their work.
> 
> cheers, simon
> 
> 
> ---
> Dipl.-Ing. Simon Steyskal
> Institute for Information Business, WU Vienna
> 
> www: http://www.steyskal.info/  twitter: @simonsteys
> 
> 
> 
> Am 2014-11-19 01:55, schrieb Holger Knublauch:
>> 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 12:43:15 UTC