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

On 11/10/2016 11:26, Karen Coyle wrote:
>
>
> 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

SHACL Core does not depend on the needs of SHACL full. But they happen 
to share some RDF terms, and therefore things sometimes have to overlap 
in the document. In the case of sh:message the spec clearly states which 
aspects are relevant to SHACL Core and which to Full.

Anyway, I think this is a discussion that had long been beaten to death 
and I see no new information that requires opening yet another ISSUE on 
this topic.

Holger



> - 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.
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>>
>

Received on Tuesday, 11 October 2016 03:56:12 UTC