- From: Karen Coyle <kcoyle@kcoyle.net>
- Date: Sun, 10 May 2015 19:00:33 -0700
- To: public-data-shapes-wg@w3.org
Holger, I stayed on the call until nearly the end, and what I'm trying to get more of a handle on is what is the nature of the "mixing" of classes and shapes that seemed to be agreed on. I am asking Holger, Richard and Ted for a bit more detail on what they concluded would be an appropriate "mix" of shapes and classes during that discussion, and if it fits in with Holger's idea of ShapeClass as described below? (Which is different from Dimitri's suggested method.) Thanks, kc On 5/10/15 4:56 PM, Holger Knublauch wrote: > On 5/9/2015 0:33, Karen Coyle wrote: >> 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. > > The brief discussion after the official end of the call was mainly > between myself, Richard and Ted. We agreed that SHACL should allow the > IRIs of classes and shapes to be mixed. Those opposing this view point > had already left the conversation. > > Holger > > >> >> 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 Monday, 11 May 2015 02:01:06 UTC