Re: shapes-ISSUE-23 (punning): Shapes, classes and punning [SHACL Spec]

On Fri, Apr 3, 2015 at 1:12 PM, Richard Cyganiak <richard@cyganiak.de>
wrote:

> In a punning design, I think the main difference would be that the triple
> { rdfs:Class rdfs:subClassOf sh:Shape } would be absent.
>
> To make specialisation work, the cleanest version would appeal to RDFS
> inference to get additional rdf:type triples, and thus any constraints that
> happen to be attached to these types would go into effect as well. (I’m not
> saying that this would necessarily be my preferred solution, because it
> sucks for implementers. It’s just the simplest to specify.)
>
> In both your draft design and a punning design, the difference between
> sh:valueType and sh:valueShape is very subtle and difficult to explain.
> Shape authors that decide to attach constraints directly to classes would
> likely be confused which of those to use.
>

I am not too familiar with punning as well but, what if we made a
distinction between e.g. sh:ClassShape and sh:ResourceShape (both
subclasses of sh:Shape) and used punning only on sh:ClassShape?


>
> Best,
> Richard
>
>
> > On 2 Apr 2015, at 23:36, Holger Knublauch <holger@topquadrant.com>
> wrote:
> >
> > It may be more productive to look at specific proposals to this issue
> and then have those who have objections speak up and propose alternatives.
> >
> > My current draft has this implemented as follows:
> >
> > - There is a class sh:Shape which defines the system properties
> sh:property, sh:inverseProperty and sh:constraint.
> > - The class rdfs:Class is declared to be rdfs:subClassOf sh:Shape (in
> the context of the SHACL system vocabulary).
> > - As a result, any RDFS/OWL class is also a Shape.
> > - Some core language elements such as sh:valueShape and sh:OrConstraint
> take sh:Shapes as arguments, which means that people could also use classes
> there.
> > - Specialization of shapes (ISSUE-24) is addressed via the usual
> rdfs:subClassOf mechanism.
> > - People may prefer to instantiate sh:Shape directly to avoid conflicts
> with RDFS classes, but these cannot have specialization (i.e. I don't think
> we should have both rdfs:subClassOf and sh:extends).
> >
> > I believe this is the best possible compromise, especially for an
> incremental adoption path and existing data models. Another option that I
> could happily live with would be to delete sh:Shape and only have classes,
> but we had too much opposition to this earlier design called LDOM.
> >
> > See also the ISSUE 2 at http://w3c.github.io/data-shapes/shacl/#shapes
> >
> > Regards,
> > Holger
> >
> >
> > On 4/3/2015 6:27, Richard Cyganiak wrote:
> >> Arthur,
> >>
> >> I personally don’t see a problem with shapes being classes, but there
> is significant opposition to this notion from parts of the WG. I tried to
> paraphrase some of the justifications mentioned in the issue description.
> >>
> >> Richard
> >>
> >>
> >>> On 2 Apr 2015, at 21:20, Arthur Ryman <arthur.ryman@gmail.com> wrote:
> >>>
> >>> Richard,
> >>>
> >>> Thx. I believe that OWL needed to introduce punning because in strict
> >>> Description Logic there is a partitioning of resources into disjoint
> >>> sets, i.e. Class, Property, Individual.
> >>>
> >>> I don't believe that we are basing SHACL on DL. Therefore there is no
> >>> problem with SHACL triples having a their subject as a Class. Is there
> >>> some problem with this? What am I missing? Do you imagine that a SHACL
> >>> engine would need some way to distinguish a Shape from a Class? i.e.
> >>> given an IRI, if it's a Class to one thing else if it's a Shape do
> >>> some other thing?
> >>>
> >>> -- Arthur
> >>>
> >>> On Thu, Apr 2, 2015 at 4:00 PM, Richard Cyganiak <richard@cyganiak.de>
> wrote:
> >>>>
> >>>>> On 2 Apr 2015, at 20:44, Arthur Ryman <arthur.ryman@gmail.com>
> wrote:
> >>>>>
> >>>>> I am not familiar with the term "punning" in this context. Have you
> >>>>> got a reference? Thx.
> >>>> Arthur,
> >>>>
> >>>> In logic, “punning” means to use the same name for multiple distinct
> things. In our context, it means using the same IRI for multiple distinct
> things. I’m only familiar with the concept through its use in OWL 2, where
> a single IRI can denote multiple things, for example a class and an
> individual. So I don’t have any deeper background references to offer, but
> the examples here should be enlightening:
> >>>>
> >>>> http://www.w3.org/TR/owl2-new-features/#F12:_Punning
> >>>>
> >>>> In the context of SHACL, a punning approach would mean that classes
> and shapes are still conceptually distinct, but SHACL authors could use a
> single IRI to refer to both a class and a shape. Informally stated, I could
> dangle some subClassOf triples and some sh:constraint triples off the same
> RDF node. The semantics of SHACL would have to be carefully written to
> tease apart these separate aspects, so that the RDFS-related mechanisms and
> the SHACL-related mechanisms don’t trip each other up.
> >>>>
> >>>> Best,
> >>>> Richard
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>> -- Arthur
> >>>>>
> >>>>> On Sat, Mar 28, 2015 at 4:14 PM, RDF Data Shapes Working Group Issue
> >>>>> Tracker <sysbot+tracker@w3.org> wrote:
> >>>>>> shapes-ISSUE-23 (punning): Shapes, classes and punning [SHACL Spec]
> >>>>>>
> >>>>>> http://www.w3.org/2014/data-shapes/track/issues/23
> >>>>>>
> >>>>>> Raised by: Richard Cyganiak
> >>>>>> On product: SHACL Spec
> >>>>>>
> >>>>>> Some people want to apply different shapes to the same class.
> >>>>>> Some peope want to apply shapes to data that doesn't include type
> statements.
> >>>>>> Some people want to associate shapes directly with class
> definitions.
> >>>>>> Some people want to “inherit” shapes down existing class
> hierarchies.
> >>>>>> Some people want to “specialise” shapes where there are no existing
> class hierarchies.
> >>>>>> Some people don't want shapes to have anything to do with classes
> at all to avoid reinventing RDFS, badly.
> >>>>>>
> >>>>>> No proposal seems to satisfy all people.
> >>>>>>
> >>>>>>
> >>>>>>
> >>
> >
> >
>
>
>
>


-- 
Dimitris Kontokostas
Department of Computer Science, University of Leipzig
Research Group: http://aksw.org
Homepage:http://aksw.org/DimitrisKontokostas