Re: ISSUE-71

On 6/09/2016 22:23, Eric Prud'hommeaux wrote:
> * Holger Knublauch <> [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.


>> Karen, I acknowledge your use cases, please also acknowledge mine.
>> Thanks,
>> Holger
>> [1]
>> [2]
>>> 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]

Received on Tuesday, 6 September 2016 23:00:53 UTC