- From: Holger Knublauch <holger@topquadrant.com>
- Date: Fri, 24 Apr 2015 12:40:34 +1000
- To: RDF Data Shapes Working Group <public-data-shapes-wg@w3.org>
On 4/24/2015 12:18, Michel Dumontier wrote:
> in any case, there are three fundamental issues, as I currently see it
> 1. that the specification should indicate how a shape can be defined
> in terms of an existing vocabulary, rather than be intrinsic to the
> vocabulary definition (although I don't mind if this is shown as in
> Example 1)
If (for whatever reason) you don't want to put your constraints into a
vocabulary file, you could use named graph/file imports to store
different shape definitions in different named graphs. That's similar to
taking an OWL ontology and reusing its class definitions in another file
(that owl:imports the ontology). The SHACL validation is started with a
parameter, which is the named graph containing the shapes for this
session. So e.g.
File1
ex:Person
a rdfs:Class ;
rdfs:label "Person"
.
File 2:
ex:Person
sh:constraint [ ... ] .
Then start validation with File 2 as shapes graph.
> 2. that the valueType should be an IRI for a class or a shape, and we
> should drop sh:shape.
I already responded to that and disagree that we should merge them together.
> 3. that a simple SPARQL query should or should not return that data
> are instances of shapes regardless of the validation.
The system designer has a choice between using sh:Shapes and
Classes-as-shapes. There are all kinds of engineering solutions,
including named graphs, to take complete control.
Holger
Received on Friday, 24 April 2015 02:42:15 UTC