- From: Karen Coyle <kcoyle@kcoyle.net>
- Date: Fri, 08 May 2015 07:33:04 -0700
- To: public-data-shapes-wg@w3.org
Could someone summarize the area of agreement discussed in the post call chat yesterday? It seemed to me to be different to what is below, but perhaps it was not. Thanks kc On 5/8/15 12:45 AM, Dimitris Kontokostas wrote: > Unless we declare rdfs:Class to be disjoint with sh:Shape we cannot > enforce users not to use the same IRI for both. > I am skeptical to direct relations from sh:Shape(s) to rdfs:Class (e.g. > rdfs:subClassOf) but, if we drop these for now until we make sure they > do not cause any problems it would be fine for me to start with > something like > > #1 separate definition > ex:ClassA a rdfs:Class . > ex:ShapeA a sh:ClassShape ; > sh:class ex:ClassA . > > #2 use of the same IRI if sh:class does not exists > ex:ClassA a rdfs:Class, sh:ClassShape . > > note that in option 2 we still have to declare ex:ClassA to be a > sh:ClassShape in addition to rdfs:Class. > My top-level class definition would be something like the following > without interfering with rdfs/owl reasoning > > sh:Shape a rdfs:Class. # "abstract" class not directly instantiated > sh:ClassShape a rdfs:Class ; rdfs:subClassOf sh:Shape . #Shapes used for > classes > sh:ResourceShape a rdfs:Class ; rdfs:subClassOf sh:Shape . #Shapes used > for ShEx shapes > sh:GlobalShape a rdfs:Class ; rdfs:subClassOf sh:Shape . #Shapes used > for global constraints > # additional shape types we might introduce e.g. sh:PropertyShape > > Could something like this set a common-ground to start with? > > Best, > Dimitris > > > On Thu, May 7, 2015 at 2:33 AM, Holger Knublauch <holger@topquadrant.com > <mailto:holger@topquadrant.com>> wrote: > > I have meanwhile updated my draft to include sh:ShapeClass. Works > nicely. I added an illustration that may help understand how these > metaclasses relate to each other: > > http://w3c.github.io/data-shapes/shacl/#shape-classes > > As shown in the illustration, I have added a relationship > sh:scopeClass that points from a sh:Shape to an rdfs:Class. This > should cover the cases where classes and shapes are developed and > maintained independently. To clarify its role, I have renamed the > property formerly known as sh:scope to sh:scopeShape. I also updated > my prototype implementation and noticed that sh:scopeClass > introduces all kinds of complications that will need to be worked > out, e.g. the sh:scopeClass triples will live in the Shapes graphs, > while the rdf:type triples remain in the data graphs. > > On this occasion I also created a diagram for some of the constraint > types: > > http://w3c.github.io/data-shapes/shacl/#shape-constraints > > Feedback appreciated, as usual. > > Holger > > > On 4/30/2015 12:34, Holger Knublauch wrote: >> I believe I could live with sh:classShape or sh:classScope, if we >> also introduced syntactic sugar for the case above. We should >> introduce a metaclass >> >> sh:ShapeClass >> a rdfs:Class ; >> rdfs:subClassOf sh:Shape ; >> rdfs:subClassOf rdfs:Class . >> >> which would be instantiated as follows: >> >> ex:MyClassAndShape >> a sh:ShapeClass ; >> sh:property [ ... ] . >> >> Such ShapeClasses would be instances of sh:Shape and rdfs:Class at >> the same time. In order to avoid the need to write down the >> superfluous sh:classShape triple pointing to itself, the engine >> would assume that this triple exists - a fairly small change to >> the algorithm. Introducing sh:ShapeClass would be similar to >> having owl:Class, which extends the rdfs:Class metaclass with >> additional properties. By having users instantiate the new >> metaclass they make a conscious choice that the URI of that class >> can also be used as a shape. The benefit is that we still have >> readable code with much fewer triples, and fewer people >> facepalming about the complexity of the trivial use cases - why >> introduce a separate sh:Shape when there is a one-to-one mapping >> anyway. >> >> Thanks for your feedback, >> Holger > > > > > -- > Dimitris Kontokostas > Department of Computer Science, University of Leipzig & DBpedia Association > Projects: http://dbpedia.org, http://http://aligned-project.eu > Homepage:http://aksw.org/DimitrisKontokostas > Research Group: http://aksw.org > -- Karen Coyle kcoyle@kcoyle.net http://kcoyle.net m: 1-510-435-8234 skype: kcoylenet/+1-510-984-3600
Received on Friday, 8 May 2015 14:33:34 UTC