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

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>> 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 http://kcoyle.net
m: 1-510-435-8234
skype: kcoylenet/+1-510-984-3600

Received on Thursday, 19 May 2016 14:00:17 UTC