Hi Karen, all,
As I understood from Holger, the sh:message can only be used for ConstraintTemplate and not to PropertyConstraints or any other "instantiable" constraint... however, and as I mentioned in my comment, I don't see a strong reason why the logic that is applied for severity is not valid for the s:message, even considering that the same message would correspond to several constraint violations (this is actually what happens in our cases and should be so). "my" understanding is that it should be up to the shape "designer" to be aware of such "logic" and decide when he should split or not the constraints in order to provide more accurate messages.
About the second requirement, I am still trying to understand if it is actually a problem or a "feature". The owl:imports was designed with the intention of referring to/linking parallel ontologies, and not quite for structural subdivision (for convenience) even though it is possible to do so... Given this, I am in favor of raising it as a question and see what others think.
...btw, I have made a second version of the EDM shape ontology that uses owl:imports and define child Ontologies for each EDM class, see: https://github.com/hugomanguinhas/europeana/blob/master/edm-shapes/src/main/resources/etc/edm/shapes/external/edm_split.ttl , but was not able to check it using the Java implementation... I will ask Holger about it.
Kind regards,
Hugo
________________________________________
From: DCMI Architecture Forum [[log in to unmask]] on behalf of Karen Coyle [[log in to unmask]]
Sent: 23 February 2016 16:40
To: [log in to unmask]
Subject: Re: [RDF AP] Commenting on SHACL
Thanks, Hugo. As for the first comment, does sh:message not do what you
need?
"5.5 sh:message
Validation results may have values for the property sh:message to
communicate additional textual details to humans. While sh:message may
have multiple values, there should not be two values with the same
language tag."
I think your second observation is a good one and could be sent to the
list. It seems to me that this may need to be added to any user
documentation that is created. Should I try to re-word it as a comment?
kc
On 2/19/16 8:10 AM, Hugo Manguinhas wrote:
> Hi Karen, all,
>
> Sorry for taking this long to respond!
>
> After giving it some thought the most important requirement I would like to raise from our evaluation (so far) to the SHACL community is this one:
>
> "One of the requirements we would like to have for validation is the ability to change the message that is outputted as a result of a constraint violation, the same way as it is possible to change its severity level. In fact, the same logic applied for severity can also be applied for messages, meaning that default message will be returned “unless overridden at the constraint”. An additional clarification that at the moment, the message can only be defined for template definitions and not to constraints (including template “instantiations”)."
>
> I had one suggestion though that could help make our rules much more short which was to allow for some of the constraints (namely sh:class) that now only apply to properties, to be also applicable to a focus node (a Shape)... But, it seems that this has already been discussed in ISSUE-98 and will likely come to the spec (see Section 3.1). So there's no point of raising it...
>
> One second requirement (non-functional one) that I had identified and which I discussed with Holger was related to the ability to split the Shapes document:
>
> "The shapes document can become significantly long which makes it very difficult to find and manage the rules. The specification does allow for a Shapes definition (Ontology) to include other Shapes Ontologies using the owl:imports property. However, and according to the OWL specification, the range of the property must be an Ontology (meaning that it must have an Ontology declaration inside which implies a different URI than the URI of the domain Ontology). Another option would be to use the sh:shapesGraph property, but this can not really be considered as an alternative since it should define the relation between a graph resource and the shape graph, and not an inclusion of a shapes graph by another."
>
> ...but, I have been thinking a bit more about it and I am starting to realize that if we wish to split the shape document, we may need to have different base URIs so that all constraints remain resolvable. So, if we chose to split them e.g. per class, we may have (in the Europeana case) the base shape document/ontology at "http://www.europeana.eu/schemas/shapes/external.ttl" which then imports the shape doc/ontology for ProvidedCHO at "http://www.europeana.eu/schemas/shapes/external/ProvidedCHO.ttl" which would then contain the constraint "http://www.europeana.eu/schemas/shapes/external/ProvidedCHO.ttl#constraint-1". It would be good though that the URIs remain agnostic with regards to format (without the .ttl) and rely on content negotiation to redirect to the shapes doc in the requested format.... we may wish to have human readable documentation like we do for the EDM schema.
>
> I would suggest to discuss this last requirement as I would also like to have your input, and see if it is necessary to raise to the SHACL community.
>
> Kind regads,
> Hugo
>
>
> ________________________________________
> From: DCMI Architecture Forum [[log in to unmask]] on behalf of Karen Coyle [[log in to unmask]]
> Sent: 12 February 2016 19:04
> To: [log in to unmask]
> Subject: [RDF AP] Commenting on SHACL
>
> I brought up the issue of the use of the Shapes mailing list for
> commenting on SHACL. All agreed that it had been done for expediency,
> might be unfortunate, but was not going to be changed. They did make a
> change to the description of the list on the archive page.
>
> I also agreed to bring as many DCMI comments to that list as possible,
> even informal ones. The group really does want comments, of any kind,
> and is willing to sort through them if some are not immediately
> relevant. So, Hugo, I'll ping you next week to see what comments have
> come out of your tests so far. We can weed out the ones that are only
> related to using TopBraid, but everything else is potentially a comment
> for the W3C group.
> --
> Karen Coyle
> [log in to unmask] http://kcoyle.net
> m: 1-510-435-8234
> skype: kcoylenet/+1-510-984-3600
>
--
Karen Coyle
[log in to unmask] http://kcoyle.net
m: 1-510-435-8234
skype: kcoylenet/+1-510-984-3600
|