W3C home > Mailing lists > Public > public-data-shapes-wg@w3.org > June 2015

Re: Specific proposals for ISSUE-1

From: Karen Coyle <kcoyle@kcoyle.net>
Date: Wed, 24 Jun 2015 07:26:55 -0700
Message-ID: <558ABE2F.8070202@kcoyle.net>
To: public-data-shapes-wg@w3.org

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.


> 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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:30:24 UTC