Re: Can Shapes always be Classes?

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 09:45:17 UTC