Comments on SHACL, especially regarding compatibility with OSLC Resource Shapes 2.0

Abstract should make it clearer that SHACL is intended to specify 
constraints on an RDF vocabulary for use in a particular context, and that 
those constraints are not intended to control the vocabulary in other 
contexts. That is, SHACL closes the world up for a specific purpose, but 
doesn’t enforce closed-world assumptions on all uses of a vocabulary.

2.1.1: I prefer the shape pointing to the thing it constrains - this keeps 
the constraints out of the vocabulary and allows the vocabulary to be 
easily reused in different contexts with different constraints for 
different purposes.

2.1.2 Example 4: why does the example include ex:ExampleClass a 
refs:Class? Wouldn’t the example be the same without it? Is this to 
highlight issue 23?

Using sh:ShapeClass couples the shape scope and the object definition 
together. This essentially closes the world because it is no longer 
possible to separate the vocabulary from constraints on that vocabulary in 
a context: e.g., validate(graph, shape) —> [true, false]. There’s no way 
to separate the graph from the shape in the arguments to validate.

issue 78, I like the idea of abstract classes, its helpful to know 
something is not intended to have direct instances and encourages the 
reader to go look for more specific, concrete subclasses.

3.1 mentions rdfs:label and rdfs:comment, but what about dcterms:title and 
dcterms:description? Would these be more general and not introduce 
additional coupling to RDFS?

There are some concepts defined in OSLC Resource Shapes 2.0 that are not 
in this SHACL draft:

1. oslc:readOnly - indicates a property value cannot be changed after the 
containing resource is created.

2. oslc:hidden - gives a hint to applications that the property may be 
hidden in a user interface

3. oslc:name - the name of the property being defined (not sure why this 
was needed).

4. oslc:representation - for properties whose oslc:valueType was Resource 
or AnyResource, specifies if the property value should be Inline, 
Reference or Either. This is important for defining resource 
representations that include property values in the same resource 
representation for efficient access. This is not the same as sh:nodeKind 
because oslc:Inline can still be an IRI, its just that the content of the 
IRI reference must be contained in the same resource representation.

5. oslc:isMemberProperty - to indicate the property is a membership 
property (used to specify shapes for Query results)

Jim Amsden, Senior Technical Staff Member
OSLC and Linked Lifecycle Data
919-525-6575