Re: vote for supporting "closed shapes"

Thanks, Arnaud. I was looking in the list of approved requirements -- 
this one is "under consideration." Do you have it on your list of 
requirements to be discussed, or is an issue needed?

kc

On 4/28/15 11:47 AM, Arnaud Le Hors wrote:
> Hi Karen,
>
> This actually does refer to a proposed requirement:
> 2.6.11 expressivity: closed shapes
> https://www.w3.org/2014/data-shapes/wiki/Requirements#Expressivity:_Closed_Shapes
> --
> Arnaud  Le Hors - Senior Technical Staff Member, Open Web Technologies -
> IBM Software Group
>
>
> Karen Coyle <kcoyle@kcoyle.net> wrote on 04/28/2015 11:21:54 AM:
>
>  > From: Karen Coyle <kcoyle@kcoyle.net>
>  > To: public-rdf-shapes@w3.org
>  > Date: 04/28/2015 11:22 AM
>  > Subject: Re: vote for supporting "closed shapes"
>  >
>  > I did find this:
>  >
>  > http://www.w3.org/2014/data-shapes/track/actions/20
>  >
>  > ACTION-20: Update description of 2.6.11 expressivity: closed shapes to
>  > address concerns expressed to date
>  >
>  > However, that has not resulted in an issue or a requirement. I believe
>  > it refers to one version of the ShEx specification. If so, that does not
>  > promulgate it to the working group activities as a whole. I'm still
>  > looking to create an issue for this, but looking for help on wording.
>  >
>  > kc
>  >
>  > On 4/25/15 9:31 AM, Karen Coyle wrote:
>  > > Erik, I think I captured some of your requirements in a use case that
>  > > comes from the Dublin Core community:
>  > >
>  > > https://www.w3.org/2014/data-shapes/wiki/
>  > User_Stories#S37_Defining_allowed.2Frequired_values
>  > >
>  > >
>  > > In particular:
>  > >
>  > > 2) must be an IRI matching this pattern (e.g.
>  > > http://id.loc.gov/authorities/names/)
>  > >
>  > > There is a need within the closed environment where validation will
> take
>  > > place to limit the "anyone can say anything about anything" to a
>   set of
>  > > known namespaces. The user story only speaks of values (objects) but
>  > > this could also be the case for subjects and predicates.
>  > >
>  > > kc
>  > >
>  > >
>  > >
>  > > On 4/22/15 3:50 PM, Erik Wilde wrote:
>  > >> hello.
>  > >>
>  > >> i am not a member of the RDF shapes WG. but i have been encouraged to
>  > >> voice my opinion on the public mailing list, so here i go.
>  > >>
>  > >> it seems that the "closed shapes" feature so far is not a required
>  > >> feature for the envisioned language. i want to support this
> feature, and
>  > >> claim that having or not having this will make a huge difference in
>  > >> terms of how business-ready the language is.
>  > >>
>  > >> being able to exactly say what is or isn't allowed is a critical
> feature
>  > >> in business processes. very often, there even are validation
> pipelines,
>  > >> with various levels of openness and increasing levels of strictness,
>  > >> after cleanup and consolidation stages.
>  > >>
>  > >> not being able to "strict" validation (borrowing XSD's terminology of
>  > >> "lax" and "strict" and bending it a little bit here) would mean
> that the
>  > >> new language would only be useful for some validation tasks, but that
>  > >> others would still need to be hand-coded.
>  > >>
>  > >> having well-defined language features similar to the "wildcards"
> in XSD
>  > >> is critical in terms of getting RDF closer to be business-ready. in my
>  > >> work with XML, JSON, and RDF, one typical criticism of RDF is that it
>  > >> assumes well-meaning peers, and has little support for scenarios
> beyond
>  > >> that. supporting "closed shapes" could be one step in this direction,
>  > >> and i would like to consider the WG to make this a mandatory
> feature and
>  > >> provide fine-grained controls for how open/closed a model should be.
>  > >>
>  > >> thanks and kind regards,
>  > >>
>  > >> dret.
>  > >>
>  > >
>  >
>  > --
>  > Karen Coyle
>  > kcoyle@kcoyle.net http://kcoyle.net <http://kcoyle.net/>
>  > m: 1-510-435-8234
>  > skype: kcoylenet/+1-510-984-3600
>  >

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

Received on Tuesday, 28 April 2015 20:16:09 UTC