ISSUE-123: Shall we unify the syntax of sh:directType and sh:class?
DirectType syntax
Shall we unify the syntax of sh:directType and sh:class?
- State:
- CLOSED
- Product:
- SHACL - Core
- Raised by:
- Holger Knublauch
- Opened on:
- 2016-02-28
- Description:
- The spec currently has sh:directType as a way to limit values to have the specified rdf:type only. In contrast to sh:class this will not walk into subclasses of that class.
One issue here is that we currently have sh:classIn (for multiple classes) but no sh:directTypeIn.
Another issue is that the distinction between sh:class and sh:directType is fairly small, and basically meaningless if inferencing has been activated.
I think we should consider changing the syntax so that it becomes
ex:MyShape
sh:property [
sh:predicate ex:myProperty ;
sh:class ex:Person ;
sh:excludeSubclasses true ;
] .
The sh:excludeSubclasses would serve as a flag to not walk into subclasses. It would also work for sh:classIn, solving the first issue without introducing yet another core construct. - Related Actions Items:
- No related actions
- Related emails:
- regrets and votes for RDF Data Shapes WG 5 May 2016 meeting (from eric@w3.org on 2016-05-05)
- Re: shapes-ISSUE-123 (DirectType syntax): Shall we unify the syntax of sh:directType and sh:class? [SHACL - Core] (from holger@topquadrant.com on 2016-04-28)
- Re: shapes-ISSUE-123 (DirectType syntax): Shall we unify the syntax of sh:directType and sh:class? [SHACL - Core] (from pfpschneider@gmail.com on 2016-04-28)
- Re: Some ISSUE proposals for this week (from holger@topquadrant.com on 2016-04-28)
- Re: Some ISSUE proposals for this week (from lehors@us.ibm.com on 2016-04-27)
- Some ISSUE proposals for this week (from holger@topquadrant.com on 2016-04-27)
- Some issues that may be close to resolution (from holger@topquadrant.com on 2016-04-06)
- shapes-ISSUE-123 (DirectType syntax): Shall we unify the syntax of sh:directType and sh:class? [SHACL - Core] (from sysbot+tracker@w3.org on 2016-02-28)
Related notes:
For background, OSLC Resource Shape 2.0 is silent on the subject of subtypes, and also silent on inferencing. As a result, OSLC does not constrain shape processing - it might apply to resources with rdf:type values that are subclasses of the oslc:describes value or it might not.
The OSLC Core 2.0 spec includes the phrase
"Formally, a shape S applies to a resource R if there is a triple R rdf:type T and there is a triple S oslc:describes T."
But that does not say whether or not the triples are explicit or inferred, nor does it say "if and only if". In fact, we know that 'only if' is not intended, since oslc:instanceShape and oslc:valueShape introduce other ways that shapes apply to resources.
RESOLUTION: Close ISSUE-123, dropping sh:directType
See http://www.w3.org/2016/05/05-shapes-minutes.html#resolution03
Display change log