Re: ISSUE-71 (was: ISSUE-176: Rules will not modify the data graph)

* 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?


> 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 Tuesday, 6 September 2016 12:23:38 UTC