Re: vote for supporting "closed shapes"

* Arthur Ryman <arthur.ryman@gmail.com> [2015-04-29 00:50-0400]
> Eric,
>  Small tweak. It's not that the server necessarily accepts the
> unexpected triples. Rather, it may simply drop them but report that
> fact in the response.
> 
> a server accepts only the expected triples and returns a list of the
> ignored, unexpected triples to the client.

How about
[[
Some data recipients will not act as generic triple stores.
"Closed shapes" identify triples not matched by a property constraint in a shape.
A few uses of closed shapes: a client tests that every triple being sent to a server will be accepted/processed; a server rejects any document with unexpected triples; a server accepts and ignores unexpected triples and returns a list of dropped triples to the client.
(The control can probably be applied to the whole schema rather than individual shapes. At least, there's no use case or implementation experience to the contrary.)
]]

Ted, Arthur, is this good enough?


> -- Arthur
> 
> On Tue, Apr 28, 2015 at 4:43 PM, Eric Prud'hommeaux <eric@w3.org> wrote:
> > * Karen Coyle <kcoyle@kcoyle.net> [2015-04-28 13:15-0700]
> >> 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?
> >
> > I took an action to add some text to make it more concrete for Ted:
> > [[
> > A few uses of closed shapes: a client tests that every triple being
> > sent to a server will be accepted/processed; a server rejects any
> > document with unexpected triples; a server accepts unexpected triples
> > but returns a list of expected triples to the client.
> > ]]
> > Arthur, do you accept that text?
> >
> > Note that this requirement is more general than was described in
> >   http://www.w3.org/2015/ShExpressivity
> >
> >
> >> 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
> >>
> >
> > --
> > -ericP
> >
> > office: +1.617.599.3509
> > mobile: +33.6.80.80.35.59
> >
> > (eric@w3.org)
> > Feel free to forward this message to any list for any purpose other than
> > email address distribution.
> >
> > There are subtle nuances encoded in font variation and clever layout
> > which can only be seen by printing this message on high-clay paper.

-- 
-ericP

office: +1.617.599.3509
mobile: +33.6.80.80.35.59

(eric@w3.org)
Feel free to forward this message to any list for any purpose other than
email address distribution.

There are subtle nuances encoded in font variation and clever layout
which can only be seen by printing this message on high-clay paper.

Received on Wednesday, 29 April 2015 08:45:00 UTC