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

Great, we seem to agree on this topic then. In my current design I am 
using a pre-bound variable ?shapesGraph (as earlier suggested by 
Richard) and this produces definitions such as

         SELECT ?this (?this AS ?subject) ?predicate ?object
         WHERE {
             ?this ?predicate ?object .
             FILTER NOT EXISTS {
                 GRAPH ?shapesGraph {
                     ?allowedValues (rdf:rest*)/rdf:first ?object .
                 }
             }
         }

(for sh:allowedValues). I think for a spec this is quite compact and 
elegant - nicer than requiring some query string generation mechanism. 
Implementations may of course still create a new query string for each 
sh:allowedValues statement, but such optimizations are not really our 
business as spec writers.

Thanks
Holger


On 4/23/2015 2:48, Dimitris Kontokostas wrote:
> My proposed resolution was not to forbid the querying of the shapes 
> graph but only to not require it.
> Your suggestion seems to follow this approach.
>
> The problem comes to very few facets (2-3 at the moment).
> For these facets, the spec can either define only way (with/without 
> querying) or both, but this can be a separate issue imho.
>
> Best,
> Dimitris
>
> On Tue, Apr 14, 2015 at 8:25 AM, Holger Knublauch 
> <holger@topquadrant.com <mailto:holger@topquadrant.com>> wrote:
>
>     On 4/14/2015 0:34, 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.
>
>             I understand that we need to maintain good performance,
>             including the
>             ability to use native query optimizations on database
>             level where
>             possible. Also there are cases where the shapes model is
>             really totally
>             separate from the database. Yet I believe there are also
>             cases where
>             being able to access the shapes definitions at runtime is
>             beneficial.
>
>             In this discussion here, I believe we should distinguish
>             between what we
>             use in the SPARQL queries of the specification versus what
>             optimized
>             implementations may do. I believe it should be doable to
>             assume that - in
>             the context of the spec - the shapes graph can be in the
>             same dataset as
>             the actual data. So by default we would have a single
>             dataset and
>             validation gets two parameters:
>
>             - the URI of the "instances" data graph (default graph) -
>             the URI of the
>             shapes graph
>
>         I would put this exactly the other way around, namely
>
>            I believe that it should be doable to assume that - in the
>         context of the
>            spec - the shapes graph can be completely separate from the
>         actual data. So
>            validation has two parameters:
>           - the "instances" data graph
>           - the shapes graph
>
>         I believe that this setup is much cleaner than a design that
>         *needs* to do
>         something special when the shapes graph is inaccessible from
>         the data graph.
>         In this setup special things *can* but do *not* need to be
>         done when the
>         shapes graph is accessible from the data graph.
>
>         [...]
>
>
>     First and foremost we need a resolution whether SHACL constraints
>     can query other shape definitions consistently. Only after we have
>     this option, the question becomes what variant of SPARQL mapping
>     we select for the formal specification. Quite possibly the SHACL
>     spec could define sh:allowedValues by a string generation
>     algorithm that turns the rdf:List of allowed values into a FILTER
>     NOT IN clause. Yet, once we have the possibility to query the
>     named graph of shape definitions plus the template mechanism, then
>     I'd argue that it will be more elegant and more compact to use the
>     mechanism that we already have, as long as we make sure that
>     string generation still remains a possibility to implementers. (A
>     consequence of that would be to specify that the members of
>     sh:allowedValues cannot be blank nodes, because those could not be
>     mapped into a proper SPARQL string, but I assume we agree on that
>     anyway).
>
>     Regards,
>     Holger
>
>
>
>
>
> -- 
> Dimitris Kontokostas
> Department of Computer Science, University of Leipzig & DBpedia 
> Association
> Projects: http://dbpedia.org, http://http://aligned-project.eu
> Homepage:http://aksw.org/DimitrisKontokostas
> Research Group: http://aksw.org
>