Re: shapes-ISSUE-30 (shape-and-data-graphs): Are shapes and data in the same graph? [SHACL Spec]

On 4/14/2015 0:26, Peter F. Patel-Schneider wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 04/12/2015 05:01 PM, Holger Knublauch wrote:
>> One of the main selling points of RDF technology has always been the
>> fact that instance and schema are represented uniformly. RDF Schema and
>> OWL class definitions are instances (of metaclasses) themselves. This
>> means that such data can not only be stored and shared together, but also
>> be queried uniformly. In general, SPARQL queries can freely walk between
>> meta-levels.
>>
>> Many other formalisms such as XML and SQL databases have a stricter
>> separation between those levels. If we agree on a similarly strict
>> separation by making it impossible to query the shapes graph from the
>> instances graph (and vice versa), then we may throw away a unique
>> advantage that RDF technology has. I am generally not in favor of
>> selecting the lowest common denominator for all use cases, only because
>> certain cases may not have the best performance.
> If the working group followed this advice, then all SHACL constructs would
> have to be representable as RDF triples, i.e., it would not be possible to
> use SPARQL syntax in SHACL.  This does not seem to me to be a good way to
> proceed, unless SHACL turns into something completely different.

I cannot follow your train of thought here. I do not expect anyone to 
write constraints that walk through the SPARQL strings, or a syntax tree 
of that (although this may be theoretically possible if we allow 
constraints written in JavaScript). However, it is very well possible 
for one constraint to look at high-level instances of SHACL Templates 
(macros). In "my" current design, the following property constraint is 
represented as such a template:

ex:MyShape
     sh:property [
         a sh:PropertyConstraint ; # Optional rdf:type statement
         sh:predicate ex:myProperty ;
         sh:minCount 1
     ] .

A SPARQL-based constraint such as the implementation of Closed Shapes 
could now walk these template instances, e.g.

SELECT... WHERE {
     GRAPH ?shapesGraph {
         ?shape sh:property/sh:predicate ?predicate .
     }
     // do something with the values of ?predicate
}

which looks like a perfectly normal operation that many people now do 
with RDFS class definitions or OWL restrictions. My point is that SHACL 
shouldn't disallow such operations, and in principle allow constraints 
to query a dedicated named graph that contains the shape definitions. 
This doesn't imply that all SHACL constructs would have to be 
representable as RDF triples.

Thanks,
Holger

Received on Tuesday, 14 April 2015 05:21:02 UTC