- From: Arthur Ryman <arthur.ryman@gmail.com>
- Date: Tue, 23 Jun 2015 20:50:22 -0400
- To: Dimitris Kontokostas <kontokostas@informatik.uni-leipzig.de>
- Cc: Holger Knublauch <holger@topquadrant.com>, public-data-shapes-wg <public-data-shapes-wg@w3.org>
+1 However I suggest a name change. Use sh:valueClass in Proposal 2. This consistent with sh:scopeClass in Proposal 4. Use sh:valueType in Proposal 3. -- Arthur On Fri, Jun 19, 2015 at 9:34 AM, Dimitris Kontokostas <kontokostas@informatik.uni-leipzig.de> wrote: > +1 > > On Fri, Jun 19, 2015 at 1:07 AM, Holger Knublauch <holger@topquadrant.com> > 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 >> >> >> 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 >> >> > > > > -- > Dimitris Kontokostas > Department of Computer Science, University of Leipzig & DBpedia Association > Projects: http://dbpedia.org, http://http://aligned-project.eu, > http://rdfunit.aksw.org > Homepage:http://aksw.org/DimitrisKontokostas > Research Group: http://aksw.org >
Received on Wednesday, 24 June 2015 00:50:51 UTC