Re: Proposal to close ISSUE-3 and ISSUE-44

On 8/5/2015 6:51, Peter F. Patel-Schneider wrote:
> I think that the first part of this proposal, i.e., that a SHACL processor is
> invoked with an RDF dataset (or RDF graph) as its data and a shapes graph for
> control, is fine.  This is a solution to ISSUE-3.
> I think that the solution to ISSUE-44 also comes from this part of the
> proposal.  Giving an RDF dataset to SHACL lets it combine information from
> different RDF graphs.  This removes the need for sh:Graph and all the related
> machinery.

How so? SHACL is invoked with a dataset but will execute its SPARQL 
queries on the default graph of that dataset only. The other graphs in 
the dataset may be used by those SPARQL queries, but by default they are 
not, so your statement "SHACL lets it combine information from different 
RDF graphs" is misleading.

In order to create a (virtual) default graph that includes multiple 
named graphs, somebody needs to assemble those named graphs first. My 
proposed sh:include mechanism can be used for that purpose, outside of 
the engine. Furthermore this is helpful to inform tools about the 
imports closure for editing purposes. Likewise, sh:shapesGraph is an 
informative property that tools may exploit to collect the relevant 
shapes graph, and to communicate the meaning to others.

All these are simple vocabularies, and I do not know how editing tools 
like TopBraid could work without them. Again, nobody is forced to use 
them, but we should specify them before every tool comes up with their 
own custom conventions.


> Peter F. Patel-Schneider
> Nuance Communications
> On 07/27/2015 04:27 PM, Holger Knublauch wrote:
>> Both tickets [1] and [2] essentially talk about the same thing - how a SHACL
>> engine selects which shapes apply to a given data graph. My proposal is to
>> resolve both as follows:
>> The SHACL engine is invoked with two parameters:
>> 1) a dataset including the data graph as its default graph
>> 2) a shapes graph (we don't need to decide on whether that must be in the
>> dataset here)
>> There is a class sh:Graph, instances of which can represent the named graphs
>> themselves similar to owl:Ontology, but the use of sh:Graph is not mandatory.
>> Graphs that wish to help an engine find its default shapes graph can use the
>> property sh:shapesGraph in a triple such as
>>      <dataGraph> sh:shapesGraph <shapesGraph>
>> to point at one or more shapes graph - the union of those becomes the input 2)
>> unless specified otherwise. If the SHACL core vocabulary is needed then it
>> could look like
>>      <dataGraph> a sh:Graph ;
>>          sh:shapesGraph <> .
>> In addition, graphs can point to each other using a property sh:include, which
>> plays a similar role like owl:imports, only without the OWL
>> dependency/ballast. It defines an imports closure of graphs, e.g. myGraph
>> sh:include to help tools such as SHACL editors figure out which
>> other files need to be loaded when the user opens the base graph.
>> Holger
>> [1]
>> [2]

Received on Wednesday, 5 August 2015 00:34:13 UTC