W3C home > Mailing lists > Public > public-shacl@w3.org > September 2018

Re: Expressing conditional properties

From: Gary Murphy <gary@schemaapp.com>
Date: Wed, 12 Sep 2018 09:12:49 -0400
Message-ID: <CADnyxpsRF7WVO+07LF=S3wVvKA-=9WXoFjqmZ9u4VCme3OK=yw@mail.gmail.com>
To: Holger Knublauch <holger@topquadrant.com>
Cc: public-shacl@w3.org
Thanks for the advice and background; it's good to know I'm not alone in
needing this facility ;) -- I am trying to avoid SPARQL-based solutions as
much as possible so the validation can be done on the client (data-entry)
side without access to an endpoint, so the either/or approach seems my best

On Tue, Sep 11, 2018 at 7:03 PM Holger Knublauch <holger@topquadrant.com>

> As a bit of history, the SHACL WG had included a feature called
> sh:filterShape for a long time, but we got bogged into all kinds of
> technical discussions and in the end had to drop that feature. It was one
> of the optional things, and it was difficult enough to agree on anything in
> that WG. I think it was a quite elegant solution to the scenarios you
> describe, yet it would also have caused complications to many algorithms.
> The proposed work-around was to use a pattern along the lines of "either a
> BroadcastEvent or have minCount 1" using sh:or. Of course such complex
> expressions are harder to maintain and hard to understand by algorithms
> such as form builders too, but I cannot think of a much better solution now
> in SHACL Core.
> One approach would be to re-instantiate sh:filterShape as a de-facto
> standard, if enough people agree that it should be brought back. SHACL 1.0
> isn't the last word, and this Community Group would be the right place to
> discuss that.
> And yes, as Irene says SPARQL-based targets are able to express what you
> need, although this isn't supported by the SHACL playground. SPARQL-based
> target types would even allow you to encapsulate recurring design patterns
> into a high-level vocabulary. Then, as these target types get used and
> reused, tools may start to support them more "natively".
> Holger
> On 12/09/2018 7:13 AM, Gary Murphy wrote:
> Another novice question in my quest to translate my spin ;) I know I can
> do these things with sh:sparql but thought I'd ask if there is a more
> elegant strategy for defining shapes that apply only conditionally to a
> property based on the particular subclass of $this.
> So for example, if I have a schema:Event, I would want to ensure that it
> has the schema:location but not if it happens to be a BroadcastEvent or
> OnDemandEvent -- normally I'd express this in spin rules with a filter on
> the ?type of ?this.  Is there a shacl equivalent?
> A similar pattern happens where the rule applies only if some other
> property is or is not in a list of classes, for example, an ItemListElement
> only needs a position specified if its sibling property itemListOrder is
> ascending or descending, so in one sh:property I need to test the
> value/class of another property of the current focus.
> by the way, the shacl playground is wonderful :)
> --
> *Gary Murphy*
> Developer, Schema App
> e: gary@schemaapp.com <martha@schemaapp.com>
> w: https://www.schemaapp.com
> --
*Gary Murphy*
Developer, Schema App
e: gary@schemaapp.com <martha@schemaapp.com>
w: https://www.schemaapp.com
Received on Wednesday, 12 September 2018 13:13:25 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 12 September 2018 13:13:25 UTC