Re: shapes-ISSUE-93 (hsolbrig): SHACL engine vs. SHACL instance requirements [SHACL Spec]

Part of SHACL validation is the production of validation reports, so I do not
believe that the definitions of the SHACL constructs can simply talk about
whether the construct is satisfied or not.

peter


On 09/29/2015 09:39 PM, Arnaud Le Hors wrote:
> Following up on my previous email, here is an example of how the spec reads
> today and how I think it should read instead:
> 
> *3.1.5 sh:minCount, sh:maxCount*
> 
> The properties sh:minCountand sh:maxCountrestrict the number of triples with
> the focus node as the subject and the given property as the predicate.
> 
> [...]
> ..
> TEXTUAL DEFINITION
> The default value of sh:minCountis 0. Let ?countbe the number of triples that
> have the focus node as the subject and the sh:predicateas the predicate. A
> validation result must be produced in either of the following cases: If
> ?countis less than the value of sh:minCount, or if sh:maxCountis present and
> ?countis greater than the value of sh:maxCount. The produced validation result
> must have the focus node as its sh:subject, and the predicate as its
> sh:predicate.
> 
> 
> *3.1.5 sh:minCount, sh:maxCount*
> 
> The properties sh:minCountand sh:maxCountdefine the minimum and maximum number
> of instances of the given property on the focus node.[Note: the current spec
> mixes properties and predicates]
> *Property*
>  
> *Value Type*
>  
> *Summary*
> sh:minCount xsd:integer The minimum cardinality. Default value is 0.
> sh:maxCount xsd:integer The maximum cardinality. Default interpretation is
> unlimited.
> 
> 
> 
> 
> I actually think that's all one needs but we could also have something like
> the following, which might be useful in other areas:
> 
> TEXTUAL DEFINITION
> Let ?countbe the number of triples that have the focus node as the subject and
> the value of sh:predicateas the predicate.
> When sh:minCountis defined, ?countMUST be greater or equal than the value of
> sh:minCount.
> When sh:maxCountis defined,?countMUST be less or equal than the value of
> sh:maxCount.
> 
> 
> This defines the language without getting into describing what a validation
> engine must do. Later on we can define a validation engine as a processor
> validating an instance graph or a node against a shapes graph and then define
> its API, specifying what validation results it has to report.
> --
> Arnaud  Le Hors - Senior Technical Staff Member, Open Web Technologies - IBM
> Software Group
> 
> 
> Arnaud Le Hors/Cupertino/IBM@IBMUS wrote on 09/29/2015 02:20:44 PM:
> 
>> From: Arnaud Le Hors/Cupertino/IBM@IBMUS
>> To: RDF Data Shapes Working Group <public-data-shapes-wg@w3.org>
>> Date: 09/29/2015 02:22 PM
>> Subject: Re: shapes-ISSUE-93 (hsolbrig): SHACL engine vs. SHACL
>> instance  requirements [SHACL Spec]
>>
>> I've thought about this one a bit and I think that it's actually a
>> mistake to talk about "SHACL engines". I think we've been using this
>> term to refer to validation engines but as we've said before there
>> are other possible uses of SHACL so validation engines aren't the
>> only possible types of "SHACL engines".
>>
>> With that in mind I think we should try to limit the text of the
>> spec to the definition of the language without referring to any sort
>> of "SHACL engines". This would be defining what it takes for a SHACL
>> document/schema/shapes graph to be conformant with the spec and the
>> associated semantics.
>>
>> Then we could define what it takes for an implementation to be a
>> conformant validation engine, validating an instance graph or node
>> against a shapes graph. But this should be done in a separate
>> section if not document.
>> --
>> Arnaud  Le Hors - Senior Technical Staff Member, Open Web
>> Technologies - IBM Software Group
>>
>>
>> "RDF Data Shapes Working Group Issue Tracker" <sysbot
>> +tracker@w3.org> wrote on 09/24/2015 01:47:58 PM:
>>
>> > From: "RDF Data Shapes Working Group Issue Tracker" <sysbot+tracker@w3.org>
>> > To: public-data-shapes-wg@w3.org
>> > Date: 09/24/2015 01:48 PM
>> > Subject: shapes-ISSUE-93 (hsolbrig): SHACL engine vs. SHACL instance
>> > requirements [SHACL Spec]
>> >
>> > shapes-ISSUE-93 (hsolbrig): SHACL engine vs. SHACL instance
>> > requirements [SHACL Spec]
>> >
>> > http://www.w3.org/2014/data-shapes/track/issues/93
>> >
>> > Raised by: Harold Solbrig
>> > On product: SHACL Spec
>> >
>> > Portions of the spec describes what it means to be a compliant SHACL
>> > "engine".  As an example, Section 3 states "Compliant SHACL engines
>> > MUST support all these constraints".  Other compliance points,
>> > however, appear to contain recommendations about what would
>> > constitute a good SHACL schema.  As an example, section 3.1 on
>> > Property constraints states that a sh:property reference SHOULD have
>> > an rdf:type triple.  From the SHACL engine perspective, there is
>> > nothing we can do with this assertion, because SHOULD is only a
>> > recommendation, so an engine will need to work correctly whether or
>> > not the rdf:type is actually present.
>> >
>> > Similarly, the document recommends the use of rdfs:comments and
>> > rdfs:labels, but there doesn't appear to be any assertions about how
>> > this would change the behavior of compliant SHACL engines.
>> >
>> > I would propose that we create a new document style with a different
>> > format that will allow us to include all of these these requirements
>> > and suggestions but would differentiate SHACL requirements from
>> > "good coding style" recommendations.
>> >
>> >
>> >
>

Received on Thursday, 8 October 2015 12:39:08 UTC