- From: Holger Knublauch <holger@topquadrant.com>
- Date: Tue, 12 Apr 2016 11:46:21 +1000
- To: public-data-shapes-wg@w3.org
On 12/04/2016 11:38, Peter F. Patel-Schneider wrote:
>
> On 04/11/2016 06:19 PM, Holger Knublauch wrote:
>> On 12/04/2016 11:16, Peter F. Patel-Schneider wrote:
>>> On 04/11/2016 06:01 PM, Holger Knublauch wrote:
>>> [...]
>>>> If we were to merge shapes and constraints and drop sh:constraint, how could
>>>> people express different severities, e.g.?
>>>>
>>>> ex:MyShape
>>>> a sh:Shape ;
>>>> sh:constraint [
>>>> sh:closed true ;
>>>> sh:severity sh:Warning ;
>>>> ] ;
>>>> sh:constraint [
>>>> sh:stem "http://aldi.de/" ;
>>>> # default severity is sh:Error
>>>> ] .
>>>>
>>> Quite simply.
>>>
>>> ex:MyShape
>>> a sh:Shape ;
>>> sh:shape [
>>> sh:nodeKind sh:IRI ;
>>> sh:severity sh:Warning ;
>>> ] ;
>>> sh:stem "http://aldi.de/" .
>>> # default severity is sh:Violation
>>>
>> This is a very inconsistent syntax. Tools and algorithms would need to look
>> for two different cases for every constraint. For example, writing SPARQL
>> queries that walk through shape definitions becomes much harder.
>>
>> Holger
>>
> Not at all. This is a much more consistent syntax than the current one.
> Everything is a shape. Tools only have to look for shapes.
>
> peter
Ok, then please put substance behind your claim. I have mentioned SPARQL
queries that try to make sense of a given shape. Given a Shape ?shape,
the following query checks whether a shape is closed:
ASK {
?shape sh:constraint/sh:closed true .
}
Please show me the equivalent for your syntax, given that closedness may
be a warning.
Holger
Received on Tuesday, 12 April 2016 01:46:55 UTC