Re: Proposal c)

On 5/8/2015 7:10, Eric Prud'hommeaux wrote:
> * Holger Knublauch <holger@topquadrant.com> [2015-05-07 22:09+1000]
>> On 5/7/2015 21:46, Eric Prud'hommeaux wrote:
>>> It's got SPIN templates, SPIN calling conventions (embedding
>>> arguments in lists) and SPIN variable conventions (?this). None of
>>> these things exist in SPARQL. To call them SPARQL is quite
>>> misleading.
>> Templates are an RDF vocabulary that is used by a SHACL engine. Of
>> course SPARQL cannot know anything about SHACL templates or variable
>> naming conventions or arguments, neither does it need to. SHACL
>> still operates on SPARQL engines.
> Are they different from SPIN? It seems like
>    http://www.w3.org/Submission/2011/SUBM-spin-modeling-20110222/
> describes them exactly.

SPIN is an unrelated specification. Yes, SHACL templates and functions 
are very similar to SPIN templates and functions, but they are 
independent. I would say that SHACL has cleaned up some things that I 
always wanted to fix on SPIN anyway.

>
>
>>> We could invent a new name for SPARQL templates but SPIN seems
>>> pretty accurate.
>> What about "SHACL templates"?
> The templating system is a general-purpose SPARQL function invocation
> system which happens in this case to be applied to shapes.

You seem to be mixing up SHACL Templates with SHACL Functions. SHACL 
Templates allow things like

ex:MyShape
     sh:constraint [
         a ex:MyTemplate ;
         ex:myArgument ex:someValue ;
     ] .

i.e. templates define high-level language elements, including the 
built-in core elements.

SHACL Functions look similar in their definition, but are used inside of 
SPARQL queries only, e.g.

ex:MyShape
     sh:constraint [
         sh:sparql """
             SELECT *
             WHERE {
                 FILTER ex:myFunction(ex:someValue) .
             }
             """ ;
     ] .

Yes, these functions are a general-purpose SPARQL extension, templates 
merely *use* SPARQL.

>
>
>>>> unfortunately a completely inconsistent and incomplete set of
>>>> unrelated documents. Where did the content of chapters 1 - 6 end up?
>>>> Does your Core Semantics document even have the same semantics? How
>>> Not yet. The core semantics is more complex and will require some work
>>> to express in templates.
>> Can we make this a bit more concrete rather than asserting that
>> insurmountable differences exist? We need to make some real
>> decisions in the next two weeks. Could you give me some specific
>> pointers about which features of your language could not be
>> expressed in templates, and where your definition of the core
>> language differs from mine? Ideally can we look at some specific use
>> cases, e.g. expressed as test cases with input and expected output?
> A good one is multi-occurance. The original semantics for ShEx came
> from Resource Shapes which didn't really say what happened with more
> than one rule for the same property. (Probably failed, but it wasn't
> clear.)

Ah Ok. So something like

ex:MyShape
     a sh:Shape ;
     sh:property [
         sh:predicate ex:name ;
         sh:minCount 1 ;
     ] ;
     sh:property [
         sh:predicate ex:name ;
         sh:minCount 2 ;
     ] .

In my draft the behavior is simply that all constraints will be 
executed, with the result that the most specific constraint will matter 
more than the less restrictive. So in the example above, ex:name must 
have at least 2 values. An optimized engine may recognize that it can 
skip evaluating the minCount 1, but that's an implementation detail.

>
>
>>>   Note that the ShEx semantics started out
>>> quite simple (basically Resource Shapes) and grew in response to user
>>> feedback (e.g. multi-occurance).
>> Where are those requirements written down and approved? What do you
>> mean with multi-occurance?
> described just above
>
>
>>>   David Booth's proposal is to profile
>>> out the intersection but I think we may be able to offer a more useful
>>> language if we extend the templates to meet more of these use cases.
>> For complex use cases we propose SPARQL instead of reinventing a new
>> variation of it. A huge amount of cases can be covered quite
>> elegantly with user-defined functions.
> It would useful to characterize those, including whether they cover
> things like multi-occurance, one-of (e.g. the usual
>    (foaf:name) | (foaf:givenName+, foaf:familyName)
> example).

Is this an exclusive-or? If yes, where has this requirement been approved?

There are certainly many ways of representing the above in plain SPARQL, 
and if the operands were shapes then this could be probably written as

     FILTER (sh:hasShape(?value, ?shape1) = sh:hasShape(?value, ?shape2))

which reports errors if ?value either matches both shapes or none. Such 
an Xor could be turned into another template if there are enough people 
who need it.

Holger

Received on Thursday, 7 May 2015 23:04:13 UTC