Re: shapes-ISSUE-178 (sh:message constraints): Should sh:message be permitted at constraints, too? [SHACL - Core]

On 10/10/16 5:35 PM, Holger Knublauch wrote:
>
>
> On 10/10/2016 13:32, Karen Coyle wrote:
>> I do agree that sh:message should be included in the constraint graph.
>> I don't know how to interpret the meaning of the "default message". It
>> isn't defined, and the document currently says that SHACL does not
>> define the content of sh:message, so I don't see how there can be an
>> undefined default.
>
> I have tried to further clarify the current situation, see
>
> https://github.com/w3c/data-shapes/commit/98f00d658c89b5d26717870a3cda5c2737c5c176
>
>
>>
>> What this seems to imply is that there is some way for SHACL "engines"
>> to generate the sh:message object value without getting an sh:message
>> from the shapes graph. If that is to be part of the standard then the
>> standard needs to include the rules for generating sh:message from
>> constraint validations. If the intention is that engines can return
>> whatever messages they want, then the property has no predictable
>> value from one engine to another, and I don't see how something that
>> undefined can be part of a standard.
>
> In the upcoming meeting, we'll probably decide to allow sh:message in
> all constraints, and this will make this discussion redundant. But your
> view of SHACL seems to remain very SHACL Core centric. sh:message is
> well-defined in the SHACL Full and always has been, so deleting
> sh:message only because it was poorly supported by the Core doesn't make
> sense to me.

I do not agree that SHACL Core should be dependent on the needs of SHACL 
full - I read that SHACL full is an extension of Core. If Core were a 
reduction of Full (as is the case with the flavors of OWL) then that 
would be a different situation. However, that is not my understanding of 
what we have developed. All elements of SHACL Core need to work well for 
SHACL Core independent of SHACL Full and regardless of how they are used 
in SHACL Full.

Given that Full can be implemented in any language, I don't think that 
the SPARQL Full implementation can dictate elements of the Core either 
since other languages may have different needs. It looks to me that what 
we have is a set of SPARQL-based constraints that make up some version 
of SHACL Full, but I am not sure that there is a formalism of SHACL Full 
that would allow the creation of SHACL Full implementations in other 
models or languages. It doesn't look like it to me, but I would be happy 
to learn otherwise.

My strong preference would be for a SHACL Core that is not dependent on 
SHACL Full. If this is not something that we can decide in this 
discussion, I will make it an issue for the group to take on. I think 
this is an important point.

kc

>
> Holger
>
>
>>
>> kc
>>
>> On 9/21/16 5:27 PM, Holger Knublauch wrote:
>>> PROPOSAL: Add sh:message as outlined in the description of the ISSUE. If
>>> present, then the sh:message attached to a constraint (e.g. sh:property)
>>> is used with precedence over the default message (from the constraint
>>> component).
>>>
>>> Holger
>>>
>>>
>>> On 21/09/2016 15:21, RDF Data Shapes Working Group Issue Tracker wrote:
>>>> shapes-ISSUE-178 (sh:message constraints): Should sh:message be
>>>> permitted at constraints, too? [SHACL - Core]
>>>>
>>>> http://www.w3.org/2014/data-shapes/track/issues/178
>>>>
>>>> Raised by: Holger Knublauch
>>>> On product: SHACL - Core
>>>>
>>>> I believe SHACL should allow sh:message to be used at each constraint
>>>> instance.  If present, this sh:message should be preferred over the
>>>> default messages stored by the constraint components.
>>>>
>>>> Example (real case from TopBraid, actually):
>>>>
>>>> configconstraints:ConfigShape
>>>>      rdf:type sh:Shape ;
>>>>      sh:property [
>>>>          sh:predicate cfg:teamworkRootProject ;
>>>>          sh:pattern "^[a-zA-Z_\\.]+$" ;
>>>>      ] ;
>>>>      sh:targetClass cfg:ServerConfiguration .
>>>>
>>>> The user should see a message such as "The root project name may only
>>>> contain letters or the dot", but there is no way to specify this right
>>>> now. What I want is:
>>>>
>>>> configconstraints:ConfigShape
>>>>      rdf:type sh:Shape ;
>>>>      sh:property [
>>>>          sh:predicate cfg:teamworkRootProject ;
>>>>          sh:pattern "^[a-zA-Z_\\.]+$" ;
>>>>          sh:message "The root project name may only contain letters or
>>>> the dot" ;
>>>>      ] ;
>>>>      sh:targetClass cfg:ServerConfiguration .
>>>>
>>>> Note that the message would apply to all violations produced by the
>>>> constraint, even across multiple constraint components, but I believe
>>>> that's acceptable because the shape designer has the choice to bundle
>>>> only those constraint components that belong together.
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>
>
>

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

Received on Tuesday, 11 October 2016 01:27:00 UTC