Re: ISSUE-23: sh:ShapeClass?

On May 8, 2015 5:33 PM, "Karen Coyle" <kcoyle@kcoyle.net> 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.

I don't think there was any consensus yesterday mainly two sides and some
people in the middle.

Dimitris

>
> 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
>