Re: ISSUE-139: Compromise

Just to make this simpler for people not so familiar with the extension
mechanism

with this proposal we allow all constraints in all contexts (even when they
do not make sense)
in the core language the main editorial change is to
- delete the table in section 4 and the "Supported Contexts" line in each
components
- adjust some component definitions

In the metamodel we leave the existing design where we can define up to two
validators (property / node constraints contexts) for a component
whenever a validator for a context is missing we assume the component does
not apply for that context and this is also a way for Holger to drive his
UI use cases

There are still some details left to decide here, in particular

- Extension authors do not have to implement validators for both cases.
>

We agree on the former, trying to sort out some details / simplifications
on the following


>    * If a validator is missing for the given context, no violations will
> be produced.
>    * A validator may be a blanket instance that always produces violations
> or a failure
>       (we can define a reusable instance of sh:SPARQLSelectValidator with
> a URI, e.g.
>       ex:MyComponent sh:nodeValidator sh:ViolatedForEachFocusNode)


but we can defer these details for later as they affect the implementation
of the issue-139 on the extension mechanism

On Mon, Jul 18, 2016 at 4:02 AM, Holger Knublauch <holger@topquadrant.com>
wrote:

> In the recent meeting, we had a straw poll on ISSUE-139 (Universal
> Applicability) and since I was the person with the strongest opposition to
> the proposed changes Arnaud asked me to talk to Dimitris to change my mind.
> I have meanwhile exchanged emails with him and I still believe this change
> is a major step in the wrong direction. However, in the interest of making
> progress, I would change my -1 to a -0.9 vote for the following approach:
>
> - We delete sh:context and related things such as the big table in section
> 4.
> - This means that all constraint components can be used for both node and
> property constraints
>
> - For the extension mechanism, we keep the currently specified approach
> (sh:validator etc)
> - Extension authors do not have to implement validators for both cases.
>    * If a validator is missing for the given context, no violations will
> be produced.
>    * A validator may be a blanket instance that always produces violations
> or a failure
>       (we can define a reusable instance of sh:SPARQLSelectValidator with
> a URI, e.g.
>       ex:MyComponent sh:nodeValidator sh:ViolatedForEachFocusNode)
>
> I believe this approach would give the proponents of universal
> applicability all they had asked for, while reducing the cost for extension
> authors. To indicate where a constraint component can be used, I will
> promote using sh:scopeClass and hope this establishes itself as a best
> practice. (I will simply add these triples to the copy of the SHACL vocab
> used by TopBraid).
>
> Unless I hear otherwise, this would be my PROPOSAL for the next meeting.
>
> Holger
>
>
>


-- 
Dimitris Kontokostas
Department of Computer Science, University of Leipzig & DBpedia Association
Projects: http://dbpedia.org, http://rdfunit.aksw.org,
http://aligned-project.eu
Homepage: http://aksw.org/DimitrisKontokostas
Research Group: AKSW/KILT http://aksw.org/Groups/KILT