- From: Karen Coyle <kcoyle@kcoyle.net>
- Date: Tue, 11 Oct 2016 05:47:33 -0700
- To: public-data-shapes-wg@w3.org
On 10/10/16 8:55 PM, Holger Knublauch wrote: > > > 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 Holger, you don't get to decide when my questions are answered - I do. And they are not. I'm going to add these to issue 189. kc > > > >> - 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 12:48:06 UTC