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

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>
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