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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



On 04/13/2015 10:19 PM, Holger Knublauch wrote:
> 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
> 
> 

You are arguing that it is a good thing to be able to query SHACL syntax
when performing SHACL checks.  If that is a good thing, then using SPARQL
syntax in SHACL is a *bad* thing because it prevents effective querying of
SHACL syntax.    (Yes, you could pull the SPARQL syntax apart and try to
analyze it, but that's not going to be effective.)

peter
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBAgAGBQJVLSVbAAoJECjN6+QThfjzztEH/08ripYftMl5ADNj9Fu3CTJ6
d3mZHntVcpTLKDvTtDLccPBpzuHCpG88/SlJeOxpX2CBpWVq0iD+dym0B+FXJHnr
m4nh3RQ8CYwSQMxwSvLw/dEp7YwzkfGIbrR0s0aLAucJ+2xqRkxHp7T4pKUTwQpt
BJckkJFIbQulhoSRQBs5wwZAOKHUhR3UhnNGIiSNSuF4aL2sAiwamJzL1/0y85KN
w5fa388cDpUP+iDYYpHT9KgSNuGCwjPU3HP67ZRx5GNedJaQ0hkLLYjEetaMnd3/
145uoshFrjGvM5YLhKCimjQ06QnIxX5cxjMSrh0Rq+b6uw/Fny8q0FQlF/n+Qu8=
=x6ss
-----END PGP SIGNATURE-----

Received on Tuesday, 14 April 2015 14:34:34 UTC