Re: shapes-ISSUE-134 (knowing inverse): does SHACL syntax distinguish inverse property constraints [SHACL Spec]

I suggest we continue to formulate the structural constraints in prose 
(section 4.1.1). This would keep the requirement for a formal SHACL file 
off our critical path. Remember that once we create such a file, then we 
also need to provide test cases etc. We have not even started to work on 
test cases for the "real" language, so what hope is there for the meta 
language...

Holger


On 7/04/2016 22:46, Peter F. Patel-Schneider wrote:
> On 04/06/2016 10:44 PM, Dimitris Kontokostas wrote:
>>
>> On Thu, Apr 7, 2016 at 3:58 AM, Peter F. Patel-Schneider
>> <pfpschneider@gmail.com <mailto:pfpschneider@gmail.com>> wrote:
>>
>>
>>
>>      >> ex:myConstraint rdfs:subClassOf sh:PropertyConstraint .
>>      >>
>>      >> _:c11 a ex:myConstraint ;
>>      >>       sh:predicate ex:q ;
>>      >>       sh:nodeKind sh:IRI .
>>      >
>>      > We could handle that case either way. We could allow subclasses of the system
>>      > constraint classes, or not. I have no strong opinion.
>>      >
>>      > In an attempt to resolve this (better) I have started a new section 4.1.1
>>      > Invalid Shapes Graphs:
>>      >
>>      >     http://w3c.github.io/data-shapes/shacl/#shapes-graph-invalid
>>
>>      Oh.  I was just looking at that section as if it had been around previously.
>>      Even with that section there are holes.
>>
>>
>> I suggest that we create a (normative) shapes document that can validate
>> shapes graphs and in section 4.1 we reference that document.
>> We say that shapes graphs that do not validate against our shapes document are
>> considered invalid..
> This would be a reasonable thing to do, if it is possible.
>
>> What a SHACL engine does with an invalid shapes graph is up to the engine to
>> decide. e.g. Virtuoso relaxes the sparql syntax on their endpoint interface to
>> make it easier for the users.
>> A SHACL engine could either reject the shapes graph or try to recover some
>> errors with some heuristics.
> I think that it would be better to require a strict mode where all documents
> that are not serializations of valid SHACL shapes graphs are rejected by the
> SHACL processor and no validation is done.
>
> peter
>

Received on Friday, 8 April 2016 00:57:52 UTC