W3C home > Mailing lists > Public > public-data-shapes-wg@w3.org > September 2016

Re: ISSUE-71

From: Eric Prud'hommeaux <eric@w3.org>
Date: Wed, 7 Sep 2016 03:26:24 -0400
To: Holger Knublauch <holger@topquadrant.com>
Cc: public-data-shapes-wg@w3.org
Message-ID: <20160907072622.GA5600@w3.org>
* Holger Knublauch <holger@topquadrant.com> [2016-09-07 09:00+1000]
> On 6/09/2016 22:23, Eric Prud'hommeaux wrote:
> >* Holger Knublauch <holger@topquadrant.com> [2016-09-06 11:16+1000]
> >>On 6/09/2016 1:13, Karen Coyle wrote:
> >>>ISSUE-71 is about validation that takes place within the SHACL validation
> >>>workflow. If it were not, then it wouldn't be an issue and a requirement.
> >>I believe what you are referring to (also on your edits to ISSUE-71 on the
> >>Proposals page [1]) had previously been discussed under ISSUE-80 [2] which
> >>was closed by introducing sh:stem. Although we had discussed the issue of
> >>de-referencing resources at runtime a couple of times, I believe the
> >>consensus was that this is opening a whole lot of complexity and that such a
> >>feature is too big and too unwieldy for the Core language.
> >>
> >>[[elided dereferencing discussion]]
> >>
> >>Back to the topic of rules, having them as a separate deliverable is of
> >>course also an option. If we do this, then I would hope that we can at least
> >>mint some reserved URIs in the sh: namespace, to make the syntax easier to
> >>use.
> >I would expect that the AC would consider rules to be a radical
> >departure from our charter and would require completely new approval
> >and patent disclosures. We'd also want to reach out to the SWRL
> >community as it is pretty actively used by e.g. Protege users. They
> >probably have a greater claim than e.g. JESS because they work
> >directly with RDF. The AC may be a bit nervous about this as RIF
> >hasn't been an overwhelming success, but it seems reasonable to have a
> >WG that makes that work more approachable by providing a SPARQL
> >dialect.
> >
> >Is there any reason that rules are better done in the Data Shapes WG?
> 
> It would be mostly for practical purposes. There is no current WG that could
> tackle SPARQL-based rules. Neither am I aware of plans to create such a WG.
> The process would probably take another 2 years at minimum. Meanwhile many
> practitioners use SPARQL-based rules (with our without SPIN) on a daily
> basis. RIF seems to be rather dead, and SWRL is too OWL-centric. Each
> database vendor invents their own variation of a similar solution. A
> standard vocabulary would at least allow the exchange of such rules across
> platforms.
> 
> A reason for doing it within SHACL is that SHACL is "almost there" and has
> all the necessary infrastructure already in place. sh:rule would be "just" a
> variant of sh:sparql (constraints), while the mechanisms to operate on
> targets and focus nodes remain the same.
> 
> I would find it rather disappointing if formal process issues are obstacles
> to sneaking such a useful feature in, although I acknowledge that the
> process is there for good reasons. We can of course continue with SPIN, if
> that's what W3C prefers.

I understand the frustration with the process but its purpose is to
enforce the good practice of declaring the scope of work, inviting the
appropriate parties, and protecting against future patent
problems. Even if this process were not formalized, it would be
inappropriate for us to work on rules without AC review and, perhaps
more importantly, without searching for the relevent parties to
participate or guide.

A good way to convince the AC that this work is achievable and has
community support is to develop it in a Community Group. CGs are easy
to launch and offer a good path to creating a specification which can
be used as a Candidate Recommendation in a short-lived, tightly
chartered Working Group.


> Holger
> 
> 
> >
> >
> >>Karen, I acknowledge your use cases, please also acknowledge mine.
> >>
> >>Thanks,
> >>Holger
> >>
> >>[1] https://www.w3.org/2014/data-shapes/wiki/Proposals#Issue_71:_SHACL_Endpoint_Protocol
> >>[2] https://www.w3.org/2014/data-shapes/track/issues/80
> >>
> >>
> >>>kc
> >>>
> >>>On 9/4/16 3:13 PM, Holger Knublauch wrote:
> >>>>I cannot follow this train of thought. According to that logic, the
> >>>>SHACL network prototol ISSUE-71 (that you seem to want) cannot be part
> >>>>of SHACL either. We should standardize what is *useful*, not because of
> >>>>some artificial boundaries. Rules are the most popular feature in SPIN,
> >>>>and here is an opportunity to make SHACL more useful at low cost. Rules
> >>>>are in the same category as other forms of entailment, which are
> >>>>officially part of SHACL, see sh:entailment.
> >>>>
> >>>>Holger
> >>>>
> >>>>
> >>>>On 5/09/2016 3:42, Karen Coyle wrote:
> >>>>>If it happens BEFORE the invocation of a SHACL graph/data graph
> >>>>>comparison, then it cannot be part of the SHACL standard. After all,
> >>>>>we haven't included the creation of explicit rdf:type statements
> >>>>>within SHACL.
> >>>>>
> >>>>>kc
> >>>>>
> >>>>>On 8/31/16 11:59 PM, Holger Knublauch wrote:
> >>>>>>From the recent meeting minutes I can see that Ted remarked [1]
> >>>>>>long ago we decided that SHACL engines would be fed a graph which it
> >>>>>>would validate, and that SHACL engines would not change that graph
> >>>>>>before validation ... but this reverses that and re-opens many past
> >>>>>>decisions
> >>>>>>
> >>>>>>I agree with the previous decision and notice that the wording in the
> >>>>>>proposed section was not clear. I have changed the wiki page to
> >>>>>>clarify
> >>>>>>that the execution of rules happens *before* the data graph is
> >>>>>>produced,
> >>>>>>i.e. the data graph is the result of applying rules on some other
> >>>>>>"input" graph. Rules will not modify the data graph, but operate in
> >>>>>>the
> >>>>>>same way that other entailments are implemented.
> >>>>>>
> >>>>>>Holger
> >>>>>>
> >>>>>>[1] https://www.w3.org/2016/08/25-shapes-minutes.html#item04
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>
> >>>>
> >>
> 
> 

-- 
-ericP

office: +1.617.599.3509
mobile: +33.6.80.80.35.59

(eric@w3.org)
Feel free to forward this message to any list for any purpose other than
email address distribution.

There are subtle nuances encoded in font variation and clever layout
which can only be seen by printing this message on high-clay paper.
Received on Wednesday, 7 September 2016 07:26:33 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:30:36 UTC