- From: Holger Knublauch <holger@topquadrant.com>
- Date: Thu, 14 May 2015 15:53:41 +1000
- To: public-data-shapes-wg@w3.org
Hi Karen, I hate to leave emails unanswered, but it feels like traffic has gone down quite a bit recently - I also have several unanswered questions on the list. While this is unsatisfactory, maybe everyone is just waiting for the higher bandwidth of the face to face meeting. On the specific question of shapes-vs-classes, I anticipate that a higher bandwidth will indeed help to explain things better than an email could. For now my draft reflects my suggested design - which allows people to pick and chose between multiple design patterns. Those who want to keep shapes and classes completely separate in their work can do this. Holger On 5/11/2015 12:00, Karen Coyle wrote: > 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 >>>> >>> >> >> >> >
Received on Thursday, 14 May 2015 05:55:33 UTC