- From: Karen Coyle <kcoyle@kcoyle.net>
- Date: Sun, 1 Nov 2015 18:31:00 -0800
- To: public-data-shapes-wg@w3.org
Holger, without getting into details (because those will need to be worked out), can we at least agree that it would be useful to create a vocabulary that does not require a SHACL engine and that covers, at least initially, only the core SHACL properties and classes? On 11/1/15 3:47 PM, Holger Knublauch wrote: > On 11/1/2015 0:46, Karen Coyle wrote: >> Holger, I think the question is a different one -- it's not whether we >> use RDFS or OWL, but what we want to express, and who the audience is. >> >> The turtle file that we have today implements SHACL as a validation >> language. I would like to see a file that serves creators of SHACL >> documents. We do have these two "halves" of SHACL -- the description >> of desired validation, and the validation itself. While the two can be >> combined in a single software implementation, they shouldn't HAVE to >> be combined. I think of this as something like the difference between >> HTML as a language and the rendering that takes place in browsers. The >> person creating the HTML document has a different view from the >> software rendering the document. >> >> A vocabulary for SHACL document creation would not need any abstract >> classes. > > A role of the abstract classes is to group properties together. While it > would be possible to attach every property to, say, sh:PropertyConstraint > > sh:PropertyConstraint > can have sh:minCount > can have sh:maxCount > can have sh:datatype > ... > > such a flattening would lose some information, e.g. that sh:pattern and > sh:flags belong together (with sh:flags being optional), and > sh:qualifiedMinCount must always co-exist with sh:qualifiedValueShape. > The abstract classes furthermore provide focused documentation about > these combinations, contain the produced error messages and even the > SPARQL queries - at some stage we decided that SHACL should be expressed > in SPARQL as much as possible. This info is still useful even for human > readers of the data model. > >> I don't know enough about templates to know how such a vocabulary >> could address named templates, so perhaps it is best that we focus >> first only on the defined core. Whether RDFS is sufficient or whether >> OWL functionality is needed will come out as the vocabulary is >> developed. It looks to me like most of the properties are fairly >> simple, and ranges are defined in the SHACL document. > > Many properties such as sh:minCount are reused in multiple places, which > makes pure rdfs:range statements insufficient to express them. These > would either require owl:unionOf classes or owl:Restrictions. That's fine, although perhaps this will be an opportunity to look further into simplifying. Either way, let's keep an open mind and see what we can do. > >> >> In a sense, this becomes a test of the core vocabulary - whether it >> can be expressed as a standard vocabulary, and if not, is that a bug >> or a feature of SHACL? > > Yes, there is value in trying to model SHACL in OWL, e.g. to help OWL > tools and users. There is also value in modeling SHACL in SHACL, e.g. to > help SHACL tools and users. Right. As I said, I see two sets of audiences, and therefore I assume that both will be needed. At the moment, we only have SHACL.SHACL, unless there is another version somewhere that I haven't run into. kc -- Karen Coyle kcoyle@kcoyle.net http://kcoyle.net m: 1-510-435-8234 skype: kcoylenet/+1-510-984-3600
Received on Monday, 2 November 2015 02:31:32 UTC