Re: SHACL syntax and metamodel complexity

On 8/03/2016 14:03, Peter F. Patel-Schneider wrote:
> On 03/07/2016 07:00 PM, Holger Knublauch wrote:
>> Among other details, your design has also deleted the custom scopes, e.g.
>>
>>      https://www.w3.org/TR/shacl/#sparql-scopes
>>
>> instead using various new properties for only the hard-coded scopes. If that's
>> what you are proposing then you may want to open a ticket for this and we can
>> discuss this individually.
> Yup, I had missed that on my first pass through the extension features.
>
> The metamodel thus needs a property for this, like
>
> sh:scopeSPARQL        a rdf:Property ; rdfs:domain sh:Shape; rdfs:range xs:string

And general sh:scope based on templates (section 8)?

>
> Also missing was derived properties.  That's a bit trickier to get right - the
> simple approach (putting the code in-line) isn't appealing.
>
>> There are also lots of unknowns with the SPARQL generation, and once you have
>> provided details I can send a full list of issues.
> Huh?  SPARQL generation is part of this task?  This is syntax and metamodel
> (and informal semantics).

It's part of the extension mechanism and of each built-in definition. I 
have not yet understood how your SPARQL would look like, e.g. for 
sh:pattern. Try it out and you'll discover problems with your 
metamodel... :)

>
>> (And no, I don't think paths are worth the effort - they make the whole
>> structure very unpredictable. Once you have deleted paths, there is no reason
>> not to use simple properties such as sh:predicate (or sh:inversePredicate)).
> It would be possible to put these properties into shapes.  I had thought about
> that, but I didn't like the idea that one property changed the meaning of the
> rest of the constructs in the shape.

Yes, that's why we currently have sh:property and sh:inverseProperty, 
which makes explicit which parameters are allowed (among other advantages).

Holger

Received on Tuesday, 8 March 2016 04:12:24 UTC