Re: ISSUE-23: A specific proposal

On 4/28/2015 16:55, Dimitris Kontokostas wrote:
>
>
> On Tue, Apr 28, 2015 at 8:16 AM, Simon Steyskal 
> <simon.steyskal@wu.ac.at <mailto:simon.steyskal@wu.ac.at>> wrote:
>
>     Hi!
>
>         since ex:myShExShapeA, ex:myShExShapeB are now an rdfs:Class will
>         change behavior and will be treated as class shapes.
>         This will trigger validation for all instances of
>         ex:myShExShapeA &
>         ex:myShExShapeB instead of the expected
>
>
>     as far as I understood, ex:myShExShapeA & ex:myShExShapeB would
>     only be used by associating individuals via sh:nodeShape to them.
>     They would not be instantiated by themselves.
>
>
> But if a shape is associated with a class it has different validation 
> behavior.
> Or not in this proposal?

As far as I see, in this proposal it doesn't have different validation 
behavior, at least not in the associated Operations such as

http://w3c.github.io/data-shapes/shacl/#operation-validateGraph

where rdf:type and sh:nodeShape are almost interchangeable. The main 
difference, as Simon stated, is that rdf:type should not be used to 
point at sh:Shapes - use sh:nodeShape for those cases.

Holger



>
>     simon
>
>     ---
>     DDipl.-Ing. Simon Steyskal
>     Institute for Information Business, WU Vienna
>
>     www: http://www.steyskal.info/ twitter: @simonsteys
>
>
>     Am 2015-04-28 08:09, schrieb Dimitris Kontokostas:
>
>         ok, assuming we have the following shapes, I am skipping the
>         actual
>         constraints as they are not relevant
>
>         === before inference ===
>
>         ex:myClassA a rdfs:Class . # directly triggers validation for all
>         instances of ex:myClassA
>
>         ex:myClassB a rdfs:Class ; # directly triggers validation for all
>         instances of ex:myClassB
>            rdfs:subClassOf ex:myClassA.  # inherits the constraints of
>         ex:myClassA
>
>         ex:myShExShapeA a sh:Shape . # works as a linked shape or starting
>         node
>
>         ex:myShExShapeB a sh:Shape ; # works as a linked shape or starting
>         node
>            rdfs:subClassOf ex:myShExShapeB .  # inherits the
>         constraints of
>         ex:myShExShapeA
>
>         === after inference ===
>
>         ex:myClassA a rdfs:Class, a sh:Shape .
>
>         ex:myClassB a rdfs:Class, a sh:Shape ;
>            rdfs:subClassOf ex:myClassA.
>
>         ex:myShExShapeA a rdfs:Class, sh:Shape . # directly triggers
>         validation for all instances of ex:myShExShapeA
>
>         ex:myShExShapeB a rdfs:Class, sh:Shape  ;  # directly triggers
>         validation for all instances of ex:myShExShapeB
>            rdfs:subClassOf ex:myShExShapeB .
>
>         since ex:myShExShapeA, ex:myShExShapeB are now an rdfs:Class will
>         change behavior and will be treated as class shapes.
>         This will trigger validation for all instances of
>         ex:myShExShapeA &
>         ex:myShExShapeB instead of the expected
>
>         Again, this is based on how I understood your proposal so far.
>         Maybe I
>         missed a detail that could clear things up.
>
>         Best,
>         Dimitris
>
>         On Tue, Apr 28, 2015 at 12:43 AM, Holger Knublauch
>         <holger@topquadrant.com <mailto:holger@topquadrant.com>> wrote:
>
>             On 4/28/2015 8:41, Dimitris Kontokostas wrote:
>
>                 Assuming the shapes reside along with the data graph
>                 (which is a
>                 possible scenario) and rdfs inference is applied on
>                 the graph,
>                 then the ShEx / stand-alone shape will become an
>                 rdfs:Class.
>                 In this case, a shape engine will mistaken the
>                 stand-alone shape
>                 to a class-shape right?
>                 Or am I missing a detail from your proposal?
>
>
>             Yes, a sh:Shape would then also be an instance of
>             rdfs:Class. Why
>             would this be a problem? Any shape can also be a class (in
>             this
>             design).
>
>             Holger
>
>
>         --
>
>          Dimitris Kontokostas
>          Department of Computer Science, University of Leipzig & DBpedia
>         Association
>         Projects: http://dbpedia.org [1],
>         http://http://aligned-project.eu [2]
>         Homepage:http://aksw.org/DimitrisKontokostas [3]
>
>         Research Group: http://aksw.org [4]
>
>
>
>         Links:
>         ------
>         [1] http://dbpedia.org
>         [2] http://aligned-project.eu
>         [3] http://aksw.org/DimitrisKontokostas
>         [4] http://aksw.org
>
>
>
>
> -- 
> 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
>