Re: [SHACL Feedback] Vocabulary for Constraint Violations / security levels

Dimitris,

I'd like to propose a friendly amendment. Instead of calling these
"security" levels, let's call them "severity" levels. The term
"security" normally refers to access control, privacy, etc. which is
not the case here. "Severity" refers to how problematic an issue is.

-- Arthur

On Mon, Mar 2, 2015 at 1:50 AM, Dimitris Kontokostas
<kontokostas@informatik.uni-leipzig.de> wrote:
> Thanks Holger
>
> On Mon, Mar 2, 2015 at 1:40 AM, Holger Knublauch <holger@topquadrant.com>
> wrote:
>>
>> On 3/2/2015 0:12, Dimitris Kontokostas wrote:
>>>
>>> Dear all,
>>>
>>> I provide a more structured proposal for handling security levels that
>>> was discussed at the F2F meeting that is also (not fully) implemented in
>>> RDFunit.
>>>
>>> Security levels (error, warning,...) can be attached at a sh:Shape or
>>> sh:property, or in a shape group (if we define such a classification).
>>> If more than one different security levels are defined in the hierarchy,
>>> the weakest is applied in the current scope.
>>>
>>> Execution semantics:
>>> The overall results of a validation can be expressed with a single
>>> true/false (valid/invalid). In case of false, the validation engine can
>>> additionally provide a security level that is the strongest level of all
>>> failed violation.
>>> This comes in addition to other detailed violation messages we may
>>> provide
>>>
>>> Users can optionally execute a validation requiring the reporting of a
>>> minimum security level (i.e. Error). In that case the execution engine will
>>> skip the execution of all shapes or shape properties that have a weaker
>>> security level than the one requested at the execution time
>>
>>
>> Thanks, I have recorded a link to your suggestion into the current draft
>>
>>
>> https://lists.w3.org/Archives/Public/public-data-shapes-wg/2015Mar/0011.html
>>
>> This topic, as well as other details, will certainly keep us busy for the
>> rest of the year.
>>
>>>
>>> Other comments for the result vocabulary
>>> Would we like to enrich the existing vocabulary with additional
>>> provenance metadata? Example data that are currently stored in RDFUnit are:
>>> start/end timestamps, execution statistics (tests run, failed, violation
>>> instances), dataset URI and list of tests (shapes) taking part in the
>>> validation.
>>
>>
>> You may want to turn this question into one or more Requirements before
>> they get frozen.
>
>
> I can do that as long people find it useful, would anyone like this idea? I
> could also back it up with a user story if needed.
>
>>
>> Thanks,
>> Holger
>>
>>
>
>
>
> --
> Dimitris Kontokostas
> Department of Computer Science, University of Leipzig
> Research Group: http://aksw.org
> Homepage:http://aksw.org/DimitrisKontokostas

Received on Tuesday, 3 March 2015 16:27:57 UTC