Re: Simplification of scopes section (see also ISSUE-148)

On 20/05/2016 0:37, Dimitris Kontokostas wrote:
> IIRC, This is the proposal we voted for
> https://lists.w3.org/Archives/Public/public-data-shapes-wg/2015Dec/0044.html
>
> and there were some followup questions e.g. the following that was 
> tagged by mistake under a different issue
> https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Jan/0015.html
> here it is clarified that scoping and filters are ignored when the 
> shapes are referenced from another shape

This is not what the spec currently states. I believe the spec has the 
desirable semantics that filterShapes will also be considered in 
reference use cases such as sh:valueShape. See Section 3, validation 
definition, first bullet item. We should clarify this fact but we have a 
red TODO for this already, at the end of 2.2.

Holger


>
>
>
> On Thu, May 19, 2016 at 4:59 PM, Karen Coyle <kcoyle@kcoyle.net 
> <mailto:kcoyle@kcoyle.net>> wrote:
>
>     Thanks. Can you describe or point me to the resolution? - kc
>
>     On 5/18/16 10:59 PM, Dimitris Kontokostas wrote:
>
>         Karen,
>
>         This is an issue I raised sometime ago and we have a
>         resolution with the
>         current design
>         https://www.w3.org/2014/data-shapes/track/issues/49
>
>
>         On Thu, May 19, 2016 at 3:26 AM, Holger Knublauch
>         <holger@topquadrant.com <mailto:holger@topquadrant.com>
>         <mailto:holger@topquadrant.com
>         <mailto:holger@topquadrant.com>>> wrote:
>
>             Not all shapes need to have a scope IMHO. It's the same
>         situation as
>             in ontology development. Not every class that is published
>         in an
>             ontology is used by everyone, and thus does not need to have
>             instances. Sometimes shapes will be defined in one file so
>         that they
>             can be extended with a scope in another file, for one specific
>             application.
>
>             I don't see a problem with our current design, and
>         sh:scopeProperty
>             being sometimes a bit redundant. As I said elsewhere,
>         there are
>             cases where sh:scopeProperty and sh:predicate are in fact
>         different.
>             I would not favor introducing a new concept for nested shapes.
>
>             Holger
>
>
>
>
>             On 19/05/2016 2:22, Karen Coyle wrote:
>
>
>
>                 On 5/15/16 10:37 AM, Peter F. Patel-Schneider wrote:
>
>                     If all shapes are to have scopes then there are
>         ways around
>                     this problem.  One
>
>                             would be that shapes are not embedded in other
>                             shapes.  Instead there would be
>                             a new kind of SHACL thing that is used
>         when the
>                             current effect of embedding
>                             shapes in shapes is desired.
>
>
>                 +1. I can't think of a good name for these, but it
>         seems to me
>                 that we have:
>
>                 SHACL "file" (data set, whatever) - a set of shapes
>         and constraints
>                 shape - defines a scope, optional filters, and related
>         constraints
>                 constraint - the node that defines a set constraints
>         that will
>                 be applied to the focus node
>                 [X] - a set of constraints
>
>                 [X] can be a blank node, as it is in many shapes, or
>         it may have
>                 an IRI, which is what was formerly illustrated in
>         Example 1.
>                 (This assumes that the only difference between them is
>         IRI-v-bNode.)
>
>                 The "embedded" vs. "referenced" doesn't make sense in
>         an RDF
>                 context, to my mind. It has instead to do with whether the
>                 constraints are local-only (bnode) or shareable (IRI).
>
>                 kc
>                 p.s. This doesn't take into account Holger's latest
>         proposal to
>                 place shapes sub constraints, but I don't think that
>         makes a
>                 difference here
>
>
>
>
>
>
>         --
>         Dimitris Kontokostas
>         Department of Computer Science, University of Leipzig &
>         DBpedia Association
>         Projects: http://dbpedia.org, http://rdfunit.aksw.org,
>         http://aligned-project.eu
>         Homepage: http://aksw.org/DimitrisKontokostas
>         Research Group: AKSW/KILT http://aksw.org/Groups/KILT
>
>
>     -- 
>     Karen Coyle
>     kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net> http://kcoyle.net
>     m: 1-510-435-8234
>     skype: kcoylenet/+1-510-984-3600 <tel:%2B1-510-984-3600>
>
>
>
>
> -- 
> Dimitris Kontokostas
> Department of Computer Science, University of Leipzig & DBpedia 
> Association
> Projects: http://dbpedia.org, http://rdfunit.aksw.org, 
> http://aligned-project.eu
> Homepage: http://aksw.org/DimitrisKontokostas
> Research Group: AKSW/KILT http://aksw.org/Groups/KILT
>