Re: ISSUE-71

On 9/5/16 6:16 PM, Holger Knublauch wrote:
> 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.

sh:stem is a different use case - the requirement there is that the IRI 
must be identifiable as part of a particular namespace. It doesn't 
include de-referencing of the IRI. It says:

the value of dct:subject must have the stem

> What ISSUE-71 was originally motivated by is the case where large bodies
> of data are behind a SPARQL endpoint, and it would be very slow if the
> engine would have to live outside of the endpoint and pass thousands of
> SPARQL queries back and forth during validation. Instead, the idea would
> be to have a single transaction to send the whole shapes graph over,
> just waiting for the results to get back. Like rules, this would happen
> *before* validation, as a completely separate process.

Actually, I don't think that SPARQL endpoints are a necessary part of 
the use case because in some cases you have an IRI that can be 
de-referenced over http. Arthur's expression of the case, as I recall, 
was in part informational, noting which constraints would require 
de-referencing for the constraint to be fulfilled. Arthur explains it in 
the story[1]. It is based on oslc:reference. I don't think that the 
requirement was that SHACL *do* the de-referencing or searching, but 
that it should be possible to indicate that the triples necessary to 
fulfill the constraint will not be found in the data graph.

I see two cases, one simpler than the other:

1) an IRI that can be de-referenced
2) some non-IRI value (e.g. language code) that would need a lookup or query

Both are very common.

> Karen, I acknowledge your use cases, please also acknowledge mine.

Please stop it, Holger. This kind of sniping is just childish.


> 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]

Karen Coyle
m: 1-510-435-8234
skype: kcoylenet/+1-510-984-3600

Received on Tuesday, 6 September 2016 13:06:42 UTC