Re: Specific proposals for ISSUE-1

On 6/18/15 3:07 PM, Holger Knublauch wrote:
> I suggest we split the topic into several resolutions:
>
>
> Proposal 1: SHACL should include a property sh:sparqlEntailment that can
> be used to specify a required inferencing level for each SPARQL query,
> as described in http://w3c.github.io/data-shapes/shacl/#sparql-entailment

This requires the user of SHACL to understand the back-end SPARQL and to 
code to that rather than the requirements for a shape. I think that all 
of the properties should speak to requirements for the shape as seen by 
the user, not for the SPARQL back-end. Therefore, the property needs to 
be in terms of what inferencing the user needs for the shape in 
question. I don't know if this just changes the name of the property, or 
if it is a larger change in the logic.

kc

>
>
> Proposal 2: sh:valueType must also match subclasses, with its SPARQL
> implementation using rdfs:subClassOf* as described in
> http://w3c.github.io/data-shapes/shacl/#sparql-AbstractValueTypePropertyConstraint
>
>
>
> Proposal 3: SHACL shall include another property sh:directValueType that
> only matches the directly asserted types (for OSLC use case).
>
>
> Proposal 4: sh:scopeClass must also include instances of subclasses,
> with its SPARQL implementation using rdfs:subClassOf*
>
>
> Proposal 5: SHACL shall include a high-level mechanism to express the
> scope of direct instances. (Details on that depend on our resolution to
> the general scoping topic - I hope we allow templates there).
>
> Holger
>
>
>

-- 
Karen Coyle
kcoyle@kcoyle.net http://kcoyle.net
m: 1-510-435-8234
skype: kcoylenet/+1-510-984-3600

Received on Wednesday, 24 June 2015 14:27:24 UTC