- From: Karen Coyle <kcoyle@kcoyle.net>
- Date: Sun, 1 Nov 2015 20:17:33 -0800
- To: Irene Polikoff <irene@topquadrant.com>, public-data-shapes-wg@w3.org
Well, I have to say that I have not been successful in loading SHACL.SHACL.ttl directly into tools such as Protege because they don't recognize SHACL - As Holger says, SHACL.SHACL is SHACL defined in SHACL. Yes, it's RDF, but note what he says below: >>> 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. Since those properties are not defined using owl, then there isn't an OWL or RDFS way to use them. I'd be happy to be proven wrong, but AFAIK you need SHACL understanding to make use of SHACL.SHACL. If that isn't a SHACL engine, then let's call it something else. It's a bit like Java being written in Java -- you need a Java compiler to make use of it. I suppose you could say that SHACL requires a "SHACL compiler". It is NOT written in RDFS or OWL, which is what many of today's tools use. Unless W3C will provide the "SHACL compiler" then I see this as an impediment to adoption. kc On 11/1/15 6:55 PM, Irene Polikoff wrote: > <can we at least agree that it would be useful to create a > vocabulary that does not require a SHACL engine> > > But isnąt this already the case? SHACL vocabulary doesnąt require > anything. Well, except may be RDF processor because it is in RDF. > > It would be the other way around. SHACL engine requires a vocabulary in > order to understand and process SHACL constraints. > > > > Irene Polikoff > > > > > > > On 11/1/15, 10:31 PM, "Karen Coyle" <kcoyle@kcoyle.net> wrote: > >> 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 >> > > > -- 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 04:18:05 UTC