Re: vote for supporting "closed shapes"

Eric,

Perfect. Thx.

-- Arthur

On Wed, Apr 29, 2015 at 4:44 AM, Eric Prud'hommeaux <eric@w3.org> wrote:
> * 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 14:20:29 UTC