- From: Gary Murphy <gary@schemaapp.com>
- Date: Wed, 12 Sep 2018 09:12:49 -0400
- To: Holger Knublauch <holger@topquadrant.com>
- Cc: public-shacl@w3.org
- Message-ID: <CADnyxpsRF7WVO+07LF=S3wVvKA-=9WXoFjqmZ9u4VCme3OK=yw@mail.gmail.com>
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 strategy. On Tue, Sep 11, 2018 at 7:03 PM Holger Knublauch <holger@topquadrant.com> wrote: > 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