Re: shapes-ISSUE-181: SHACL conformance for partial validation reports [SHACL Spec]

Way down below...

On 9/29/16 11:06 PM, Dimitris Kontokostas wrote:
>
>
> On Fri, Sep 30, 2016 at 6:08 AM, Karen Coyle <kcoyle@kcoyle.net
> <mailto:kcoyle@kcoyle.net>> wrote:
>
>
>
>     On 9/29/16 5:14 PM, Holger Knublauch wrote:
>
>
>
>         On 30/09/2016 10:06, Karen Coyle wrote:
>
>
>
>             On 9/29/16 3:54 PM, Holger Knublauch wrote:
>
>                 Hi Jose
>
>                 others may correct me, but my understanding is that all
>                 conformant SHACL
>                 validation engines need to produce all the "mandatory"
>                 fields of the
>                 results format.
>
>
>             which are sh:focusNode and sh:severity - which is a bit
>             awkward since
>             the focus node (isn't that "target node" now?) doesn't tell
>             you what
>             constraints were evaluated.
>
>
>         Yes, we need to clarify the mandatory fields (see your recent
>         ticket).
>
>
>     I would put them first in the section, followed by the "MAY"
>     properties, rather than mixing them. Just a bit of readability assist.
>
>
>         There is a subtle difference between focus node and target node:
>         - the focus node is the currently evaluated node
>         - the target node is a node specified as target by a shape
>         - target nodes becomes focus nodes for the duration of the
>         validation
>         - but there are other ways for nodes to become focus nodes, e.g. via
>         sh:shape
>
>
>     That makes sense, but it wasn't clear to me which was being referred
>     to on reading that section. Oddly, the term "focus node" is not
>     described in the section on validation (3.0-3.3), which however is
>     where the focus node IS what is being validated. I suspect that at
>     least some of the references to "node" there should instead be
>     "focus node". E.g. in the first sentence:
>
>     "The definitions for validating a data graph against a shapes graph
>     as well as a *node* from the data graph against a shape from the
>     shapes graph are provided below"
>
>     Is that *node* a focus node? If so, it should say focus node there
>     and in the remainder of that section. Then, 3.4.1 Focus node will
>     make more sense.
>
>
> I reverted some of Holger's changes here wrt node->focus node
>
> Focus node is defined in the terminology as: "A node in the data graph
> that is validated against a shape is called a focus node."
>
> in the begining of section 4 (validation definitions) we want to say how
> to validate a node against a shape, as requested by the ShEx requirements
> meaning we take a node from the data graph and validate against a shape
> fromt he shapes graph, when the validation occus, that node becomes a
> focus node but the intent was to define the action prior to validation.

Dimitris, I disagree here. I think that the node becomes the focus node 
through the target/filter process, so at the point of validation 
(comparison to the constraints) it is already the focus node. Otherwise, 
you can't have a selected/targeted node to validate. I believe that you 
are saying that constraints create the focus node. That doesn't seem to 
be how it is described.

As an example, the property constraint section says:
"Property constraints specify conditions that must be met with respect 
to nodes that can be reached from the focus node either by directly 
following a given property (specified using sh:predicate) or a given 
property path (specified using sh:path)."

So although you follow a property or path, you reach it from the focus 
node. It doesn't say here that the property then becomes a new focus 
node. If it is the intention that the focus node is modified as 
constraints are applied, then that must be said in the document; that 
there is an initial focus node, but that the focus changes as 
constraints are followed.

kc

>
>
>
>
>
>
>
>              They may decide to return less, but that should only be
>
>                 an option.
>
>                 Our test cases should also include the full info,
>                 because engines that
>                 only produce true or false can still use these test
>                 cases, while the
>                 inverse is not the case.
>
>
>             Since severity is mandatory, how will T/F work?
>
>
>         Assuming that true means "no validations were found", then a
>         test case
>         would pass if no results are produced, or at least no results with
>         severity violation.
>
>
>     3.4 says "The validation report is the result of the validation
>     process and includes a set of zero or more validation results." Can
>     you give an example of a validation report without validation
>     results? If it is the absence of a validation result, I have trouble
>     with it being called a "set", which in my mind has an identity, even
>     when empty.
>
>     Thanks,
>     kc
>
>
>
>         Holger
>
>
>
>             kc
>
>
>                 Holger
>
>
>                 On 29/09/2016 19:59, RDF Data Shapes Working Group Issue
>                 Tracker wrote:
>
>                     shapes-ISSUE-181: SHACL conformance for partial
>                     validation reports
>                     [SHACL Spec]
>
>                     http://www.w3.org/2014/data-shapes/track/issues/181
>                     <http://www.w3.org/2014/data-shapes/track/issues/181>
>
>                     Raised by: Jose Emilio Labra Gayo
>                     On product: SHACL Spec
>
>                     When preparing the test-suite, it is not clear to me
>                     if we have to
>                     declare/check all the validation reports that must
>                     be returned by a
>                     SHACL processor or just a true/false.
>
>                     The spec contains the following phrase:
>
>                     "The validation process returns a validation report
>                     containing all
>                     validation results. For simpler validation
>                     scenarios, SHACL processors
>                     SHOULD provide an additional validation interface
>                     that returns only
>                     true for valid or false for invalid."
>
>                     A SHACL processor that wants to handle use case 3.31
>                     (https://www.w3.org/TR/shacl-ucr/#uc34-large-scale-dataset-validation
>                     <https://www.w3.org/TR/shacl-ucr/#uc34-large-scale-dataset-validation>)
>                     about validating very large datasets may decide to
>                     return just the
>                     first violation it finds, instead of continue
>                     processing/generating
>                     all the possible violations.
>
>                     Is that SHACL processor conformant with the spec? In
>                     that case, when
>                     defining the test-suite, is it enough if we just
>                     declare true/false as
>                     the possible result of SHACL validation? Or if a
>                     SHACL processor
>                     returns just the first violation report that it finds?
>
>                     In any case, I think the spec should be more clear
>                     about when a SHACL
>                     processor is conformant or not if it doesn't return
>                     all the violation
>                     reports and just returns the first one or signals
>                     that there was an
>                     error.
>
>
>
>
>
>
>
>
>
>
>
>
>     --
>     Karen Coyle
>     kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net> http://kcoyle.net
>     m: 1-510-435-8234
>     skype: kcoylenet/+1-510-984-3600 <tel:%2B1-510-984-3600>
>
>
>
>
> --
> Dimitris Kontokostas
> Department of Computer Science, University of Leipzig & DBpedia Association
> Projects: http://dbpedia.org, http://rdfunit.aksw.org,
> http://aligned-project.eu
> Homepage: http://aksw.org/DimitrisKontokostas
> Research Group: AKSW/KILT http://aksw.org/Groups/KILT
>

-- 
Karen Coyle
kcoyle@kcoyle.net http://kcoyle.net
m: 1-510-435-8234
skype: kcoylenet/+1-510-984-3600

Received on Friday, 30 September 2016 15:41:06 UTC