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

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:minCount and sh:maxCount restrict 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:minCount is 0. Let ?count be the number of triples 
that have the focus node as the subject and the sh:predicate as the 
predicate. A validation result must be produced in either of the following 
cases: If ?count is less than the value of sh:minCount, or if sh:maxCount 
is present and ?count is 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:minCount and sh:maxCount define 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 ?count be the number of triples that have the focus node as the 
subject and the value of sh:predicate as the predicate.
When sh:minCount is defined, ?count MUST be greater or equal than the 
value of sh:minCount.
When sh:maxCount is defined,?count MUST 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.
> > 
> > 
> >