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

I do not think that my statement is misleading. Yes, the only current way to
access the other graphs in a dataset is via SPARQL, but if this is considered
to be an important feature, then it can be put in the core/high-level language.

My view is that the right place to "assemble" information together is outside
of SHACL, not inside it.

peter


On 08/04/2015 05:33 PM, Holger Knublauch wrote:
> 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.
> 
> Holger
> 
> 
>>
>> 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 <http://www.w3.org/ns/shacl> .
>>>
>>> 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 schema.org 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] http://www.w3.org/2014/data-shapes/track/issues/3
>>> [2] http://www.w3.org/2014/data-shapes/track/issues/44
>>>
> 
>

Received on Wednesday, 5 August 2015 00:43:58 UTC