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

Thanks, Simon. Looking at the code in your message in January, I am 
wondering if this, below, a variant using a bnode, is valid SHACL -

ex:IssueShape a sh:Shape;
   sh:scopeClass ex:Issue ;
   sh:property [
       sh:predicate ex:submitter ;
       sh:valueShape [
  a sh:Shape
  sh:scopeClass ex:Person ;
       sh:property [
             sh:predicate ex:username ;
             sh:minCount 1 ;
             sh:maxCount 1 ;
    ]
   ]

The examples all show nodes with IRIs. If a bnode is also valid, then we 
should add a short example showing that. If not, then the document 
should explain that.

kc

On 5/19/16 7:37 AM, 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
>
>
>
> 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
>

-- 
Karen Coyle
kcoyle@kcoyle.net http://kcoyle.net
m: 1-510-435-8234
skype: kcoylenet/+1-510-984-3600

Received on Thursday, 19 May 2016 17:56:44 UTC