- From: Irene Polikoff <irene@topquadrant.com>
- Date: Sun, 01 Nov 2015 23:38:53 -0400
- To: <kcoyle@kcoyle.net>, <public-data-shapes-wg@w3.org>
Hmm¡¦ I would think that any tool that can process RDF should be able to load a valid RDF file. SHACL requires more expressivity than what is possible with RDFS, so while one could create RDFS vocabulary for SHACL, it would be missing a lot of information. Irene Polikoff On 11/2/15, 12:17 AM, "Karen Coyle" <kcoyle@kcoyle.net> wrote: >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:39:37 UTC